We all seems to agree that it should change, so why dont we start work towards agreeing on what it should change to so everyone ends up happy :)
I like Martin's idea of having the build system output artifacts into build/broker, build/client etc, each composed of the jars needed to run that component rather than everything ending up in build/ as present. That way we can test exactly what we release, avoid class path hell as much as possible, reduce the number of potentially useless jars going into releases, and when it comes to release time all we do is tar up whichever module sub-directories we want in a particular component bundle...eg broker, client, broker + client, management/x, management/y, all of the above. Robbie > -----Original Message----- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 10 December 2009 21:21 > To: dev@qpid.apache.org > Subject: Re: Release artifacts > > Martin Ritchie wrote: > > 2009/12/9 Rafael Schloming <rafa...@redhat.com>: > >> Robbie Gemmell wrote: > >>> I think you have misunderstood what I meant by that entirely, as by > "the > >>> build system in general to always generate the release style > artifacts" I > >>> meant exactly what you are suggesting, that the build system should > be > >>> modified to generate something we can simply take a (partial) > tarball of and > >>> end up with what we release...ie release style. The reason there is > anything > >>> else in place right now is that they arent, IMO. > >> Sorry, I see how you meant that now. My mistake. Clearly I've been > too eager > >> to rant recently. ;) > >> > >> --Rafael > > > > As the one who modified our current Java build system to produce > > 'release' artefacts I can say it is very easy to generate a packaged > > that contains the dependecies for a module. Add 1 line to the > module's > > build.xml: > > > > <target name="release-bin" depends="release-bin-tasks"/> > > I wasn't suggesting that this is difficult to do, merely that it uses a > completely different mechanism than the one for generating build > artifacts. > > > That said I undestand the desire to have a directory that we then > just > > tar up for release. However, the thought that tar-ing a directory is > > in some way better than using the properties of the build system to > > make a tar is some what erroneous. There is no reason that the two > > cannot be the same. > > I think I may be missing something here. If they're the same, why not > do > it the simple way (i.e. tar up the directory). > > In any case, I'm not really saying that we shouldn't use build system > properties. What I'm saying is that I don't want the process for > generating release artifacts to be independent from the one used for > generating build artifacts. > > I have to say I have NEVER used the files in the > > build directory and the fact that all the jars end up in the lib dir > > and so get put in to qpid-all.jar makes for a very dangerous > situation > > IMO. Testing with this setup can result in runtime dependencies not > > being reflected by the build system. > > You may not use the files in the build directory directly, but you do > use them indirectly because that's the environment that the tests are > run in, e.g. when the external java broker is launched, it's done by > executing build/bin/qpid-server. > > > I would be all for having the release artefacts being built in their > > own build directories build/broker, build/client, build/qmf, etc. I'm > > totally open to suggestions on how we can do this I simply used the > > build system for the task last time as it has knowledge of all the > > library dependencies and shipping jars that we don't need as part of > > our packages is quite unhelpful, forcing these on to the class path > > via qpid-all.jar as we do in the current build directory is just a > > receipe for disaster. > > > > Now I feel I may have rant a bit, that wasn't really my intention. I > > mearly wanted to point out that if we want to do component releases > > form the Java directory for 0.6 it would take less that 2minutes to > > sort out. So I think it is a totally doable. > > I completely agree qpid-all.jar is a bad idea. I believe it exists as a > substitute for the giant client.jar that we used to generate by munging > all the class files together into a single jar, and it replicates some > of the same problems that system had. I'm not sure why this still > exists, or indeed why it ever existed. I would be +1 on killing > qpid-all.jar and using properly defined classpaths instead. (After 0.6 > goes out.) > > I'm also fine on adding a component release for qman for 0.6. What I > don't think is a good idea at this stage (i.e. for 0.6) is to remove > the > full release or recompose it from the component releases since the full > release is the environment that we actually run our tests in. > > --Rafael > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
