This thread is mixing a number of issues together. First off, there are at least three audiences being discussed here and they all have a distinct set of requirements:
1. Core Proton Developers These are the people that actually spend every day writing, testing, and debugging proton code. They interact with the build system on a daily basis and its primary role for them is to improve their overall productivity. For these people their choice of build system is really a preference based on how it impacts that productivity. 2. Proton Integrators These people don't develop proton (modulo an occasional patch), but they do build it, sometimes for the purpose of making it available in a distro, sometimes to keep up with the latest changes, or maybe just to make a trimmed down build for their favorite watch. The key thing is that they consume source, not binary artifacts. For these people the build system functions in the role of an installer. 3. Proton Users These people don't build the software themselves, but simply consume the artifacts produced from groups (1) and/or (2). They don't directly interact with the build system at all, merely with what it produces. Given these groups I think there are three points worth noting. First, groups (1) and (2) tend to pull things in different directions. For example some of the bells and whistles you get with maven are liked by developers in the personal productivity arena, however they tend to contribute to a spiderweb of dependencies that are far from ideal in an installer. This is especially true for members of group (2) that are not solely indoctrinated in the Java world, e.g. distro maintainers. Second, the overall structure of the project intentionally reflects these different concerns as proton-j can function as a top level entry point for people in group (2), however as a core proton developer, you really need to test interop against other proton components (it is a protocol implementation afterall), and so your entry point really needs to be the top level proton dir. The third point follows somewhat from the first two. Because core proton developers can't narrow their view to just Java, and real testing will involve interacting with stuff not implemented in Java, it's fairly likely that a maven build suitable for group (1) will be a bit more complicated than you might think from just looking at the proton-j directory. One final note, I would highly recommend going through the full build/test/debug cycle at least once with all the tests in the proton/tests directory if you want to get a better handle on some of these issues. --Rafael On Wed, 2012-07-25 at 22:34 +0100, Robbie Gemmell wrote: > I also took Alex's suggestion to mean leaving the Ant build in place and > then adding a Maven build too. > > Whilst I have stated my dislike for this idea in the past in relation to > the main Qpid tree, if this is what it took to have a maven build for > proton I think it would be the way to go, i.e. instead of having an Ant > build and making it easy for others to add a Maven build themselves, we > should just do it. > > Robbie > > On 25 July 2012 18:52, Gordon Sim <[email protected]> wrote: > > > On 07/25/2012 05:06 PM, Glen Mazza wrote: > > > >> The problem with providing an Ant build is that non-Maven users, never > >> having worked with it, tend to awfulize Maven, and then stick with Ant, > >> continuing their misconception of Maven. Maven is really an ice cream > >> cone, not a brussels sprout, but sometimes people need to be given a > >> push to find that out. :) > >> > > > > Last time I tried it tasted like something much worse than brussel > > sprouts! It may have improved since then; it may be that there is a way to > > pinch your nose so it doesn't taste quite so bad; it may one of those > > flavours that some love and others hate. (It may be I'm stretching the > > analogy too far!) > > > > > > Also, burdening Joseph by having him > >> create/maintain a separate Ant build also takes away his efforts towards > >> creating an awesome Maven build. > >> > > > > I don't think that was what was being proposed. There is already an ant > > build in place and I think the assumption was the ongoing maintenance would > > not be great given the simplicity of the project. > > > > It seems like a good idea to me, though as mentioned I don't currently see > > myself as a key user/developer in the very near future at least and so > > wouldn't want to impose anything on those who are. It would however let > > people have a nibble at the latest maven and either be astounded at its > > delicious nature or be able to take the bad taste away with a nice bite of > > ant. (Sorry, I couldn't resist!). > > > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: > > [email protected].**org<[email protected]> > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
