Kedar Mhaswade wrote:
> Tim, others,
>
> Please help me understand this better.
>
> You revved Module X from Version v1-> v2.
Yes.
>
> All currently checked out workspaces with all modules that depend on
> X will have an effective pom.xml that refers to "v1". If these modules
> have been built at least once with X at v1, they should continue to
> build right until there is an update. [I am hoping that we are doing
> away with SNAPSHOT versions].
>
> All new checkouts/updates of workspace would show that they depend on
> v2 for module X. This should trigger a "download" of new binaries into
> your local repository (~/.m2), assuming X(v2) has been pushed into one
> of the
> maven repositories we depend on. I assume upload of X(v2) to a remote
> maven repo happened.
Yes, although the Hudson builds lately have been somewhat erratic in
their success rate, for no obvious reason. The build and tests of the
top-level glassfish-v3 processing work, but somewhere in the final steps
the build claims to be unable to find a module JAR that must have been
there for the build and tests to have worked. Which module it says it
cannot find varies from failure to failure. This could be related.
>
> So, I guess I fail to understand why this failed. Of course, there are
> several things that I don't understand about our build system, but this
> looked like a straightforward use case that we are going to run into
> every now and then.
I think there were two points in addition to this.
First, it should be possible for a module to depend on a range of
versions of some other module. Ken's experiment suggests that's not
possible right now. I'm also not sure whether our current naming
convention for the glassfish-api version matches what the maven range
comparison can handle. It might; I just haven't read the version range
information carefully enough to know.
Second, the GUI module was still declared to depend on rev4 while I had
bumped the module itself to rev5 and had also bumped the
glassfish-api.version setting in the top-level GlassFish pom to rev5
also. Given that hard dependency in the GUI module our packaging of the
GlassFish distributions seems not to account for versions of modules
that supplier modules depend on. Only the versions specified in the
GlassFish pom are packaged into the distribution, as shown by the
failures described earlier on this thread that the rev4 module could not
be found at runtime. At that point it's not a build issue, it's a
runtime issue: the GUI declared a dependency on rev4 but that dependency
was not honored when the distributions were created.
I guess part of the problem that has afflicted the GUI module in
particular is that we are building it as a module but are packaging it
assuming that the GlassFish distribution into which it is loaded will
satisfy its dependencies, rather than packaging those dependencies with
the GUI in some way. That way we avoid having to package all the
modules that the GUI depends on with the GUI, modules that should indeed
already be present in the GlassFish distribution. And one could say
that I should have known about this and therefore known I needed to
update the declared dependency in the GUI's top-level pom. Now that I
know, if I update the glassfish-api version again I'll know to make sure
I or someone update's the GUI's top-level pom also.
But it's error-prone to depend on people to know they have to do that
for the GUI module today and for potentially other modules in the
future. My point was that maven and/or our build and packaging is what
should "know" about this and that our build should do some checking at
build-time so we can avoid errors like this at runtime.
- Tim