I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together.
Robbie > -----Original Message----- > From: Rafael Schloming [mailto:rafa...@redhat.com] > Sent: 09 December 2009 17:17 > To: dev@qpid.apache.org > Subject: Re: Release artifacts > > 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 --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
