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
