Ken wrote:
> Marina Vatkina wrote:
>> Why would you need to remove ORB from ~/.m2/repository? Can there be
>> a conflict with the versions?
> Because when I'm testing, I deploy the ORB locally (to
> ~/.m2/repository only), avoiding the time delay in
> deploying to maven. When I'm ready to commit, I do a build fetching
> the current version from
> the maven repo at download.java.net, and then do a build, forcing the
> current definition of the ORB
> to be fetched from maven. I suspect the problem here may be that we
> did not get the ORB correctly
> deployed in version 007 (the other issue I'm working on with Jane).
> In particular, the POM file for
> glassfish-corba-orb does not contain the correct dependency
> information in version 3.1.0-b007.
> 3.1.0-b006 is almost identical (except for a few cosmetic changes) to
> 3.1.0-b007, but it has the
> correct dependencies. I'm doing a build right now of rev 41383
> against 3.1.0-b006 to see if the
> dependency issue is the problem.
Looks like this is indeed the problem. Jill deployed the 7 ORB jars for
me in version 007, but not
with the pom files generated for these artifacts in the ORB release
target. The compiler seems to
be lying at least slightly about the problem, because
com.sun.corba.ee.spi.orb.ORB is certainly
present in the 007 version of glassfish-corba-orb. Probably something
that the ORB class depends on
was missing, causing the strange build failure in JTS. In any case, my
41383 build against ORB 006
is in the packager now, so that works. I think I'll just go with the
006 ORB, unless Jane and I can figure
out why I can't deploy the ORB sooner than I can get everything tested
AGAIN (but I'll skip the CTS smoke
this time, as the problem last time was not in the ORB).
Ken.