On 7 August 2014 20:18, Justin Ross <[email protected]> wrote: > On Wed, Aug 6, 2014 at 9:04 AM, Robbie Gemmell <[email protected]> > wrote: > > > I still havent got round to using the output, but inspecting the > structure > > of whats there I had a few comments (that unfortunately got really long > > :P). > > > > The Short Version: > > > > - We need to start building the QMF2 bits. > > > > As you note below, this needs a bit more work from a release standpoint. > Right now it produces four different jars. >
Thats atually as expected, the individual jars will get deployed to Nexus (and then eventually Central) but the build also produces two tar.gz files (which will also be deployed) for the main components that are the release assemblies we could ship via the website, one for the broker plugin and one for the tools(inc gui) pieces: qpid-qmf2-tools/target/qpid-qmf2-tools-0.30-SNAPSHOT-bin.tar.gz qpid-broker-plugins-management-qmf2/target/qpid-broker-plugins-management-qmf2-0.30-SNAPSHOT-bin.tar.gz The things needing done are to finalise the README/LICENCE/NOTICE stuff, and prevent a 'source release' archive being created for the whole directory. I'll look at at least the later in the morning as well, but neither should pevent proceeding with the beta since we wont actually be releasing the staged artifacts and the repo will just get dropped once each RC comes round. > > > - Do we need a duplicate java source artifact? > > > > To start, I'm fine removing it. It's easy either way. > > However, I want to argue well for what I consider its merits. I don't > recall participating in the original debate. > > - Java is the oddball here. Almost everything else has its own source > tarball. > True, though I dont think they should have really, until we start releasing them independently and those archives actually become 'the release' for those components, which they currently arent really. Whilst there are certainly benefits to having them, I think one of the reasons which essentially forced the situation of the original cpp specific archive is that the Java tree was huge due to historically containing binary libs. I wouldnt remove what is already there but I would resist adding more duplication for now, instead focusing on your later point of having independently releaseable modules, which would entirely remove the problem. > - To a point, It's nice for people to be able to get what they want and > just what they want, without downloading a bunch of other stuff. > I completely agree. This is the reason we ship separate binaries for all the individual Java components rather than only a single overall binary (an archive I am particularly happy will no longer exist, it was a mess). > - The java source tarball on offer corresponds directly to the java build > system entry point, making it one cohesive source module. > This is indeed true (mostly, there are things you can do to make the build reference out to the specs dir, but it doesnt do that by default anymore since I committed the code it was always generating from those files, and that can certainly be stopped entirely). > If duplication is the chief concern, Its certainly a concern but its not the main concern, see next bit. > I'd personally be more in favor of > getting rid of the "full release" tarball and simply point folks at > subversion for that. We can only do that once we stop it actually being 'the release'. From an Apache point of view that archive is currently what constitutes our 'Qpid release' and so is really what we vote on, with the other archives (particularly the binaries) being conveniences. We can certainly start to release e.g. the C++ or Java bits independently in their own archives, with their own associated votes, removing those bits from the overall archive until the point it no longer exists. > I'd add that I favor the move to independently > releasable modules, and I'd love to see that happen as soon as we're all > ready (I am). > > Justin > I'm also in favour, its one of the reasons I did the initial work on the maven build, we just arent quite at the end state yet since its still all being released 'as one'. I was planning to bring this point up again myself once our first release using the new maven build was out the way. Robbie
