Robbie Gemmell wrote:
Hi all,
Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users.
I think it's a bit late for 0.6, if I understand the timeline correctly.
The "Java broker, client, and tools" multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together.
I sort of disagree with this. There is a "philosophy" behind using the
"just a copy" approach. The benefit is that we can eliminate a whole
class of bugs resulting from complex transformations necessary to turn
the build artifacts into release artifacts. Not to mention it is easier
for us to reproducer user issues if dev and user environments are as
similar as possible.
That said I'm fine cleaning up the release artifacts and what not, I'm
just -1 on doing it by introducing complex transformations between build
and release artifacts. If we want the release artifacts to look
different we should make the build artifacts look different.
As I've said before I'm happy to help with this, but we sort of need to
figure out what we want things to look like first, and IMHO such an
effort should also include making release artifacts more consistent
across the whole project.
Another result of the above is that QMan is shipped in the Java multi-component
bundle despite the fact it is only useful if you have a C++ broker. I realise
it is written in Java, but those packages don't seem to me like they should
necessarily be language specific. If anything I would say that QMan should
surely ship in the multi-component bundle along with the items it can actually
be used with (ie the C++ broker and client bundle), or just be made available
standalone (which it already is). Users aren't necessarily going to expect they
need to download both multi-component packages to make use of everything
contained in one of them, and as mentioned above, splitting QMan alone out of
the java multi-component bundle would be a bit hideous and non obvious anyway.
I would also like to see us tagging the source-only release artifacts with 'src', ie the
C++ and the "full" release artifact that is just a copy of the entire repo. It
isn't exactly helpful for a user to download the 50MB file then find out what they are
looking for isn't actually in there.
I also think it's a shame that our artifacts look like they come from
entirely different projects. Even little things like readme
capitalization, general directory layout, etc is completely different
from artifact to artifact, and this is even after the release script
hacks to rearchive stuff to make things a bit more consistent.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
