qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew MacBean <andymacb...@gmail.com>
Subject Re: Maven build for the QMF2 tools
Date Thu, 13 Mar 2014 14:22:01 GMT
Robbie/Fraser,

I have been contributing to QPID-5048 for a while now, so am obviously
bias, but  would agree with the sentiment that it would be beneficial and
makes most sense long term to also have the QMF stuff "mavenised".  I also
think we should "harmonise" the maven build of the 1.0 stuff with the rest
as soon as it makes sense (common versions, plugins and overall parent etc).

I agree with Robbie wrt to the Ant build being a pain in the ass but can
also understand Frasers initial concerns. Maven is not perfect by any means
and is prone to bloat, but the use of a standard, convention driven build
system will allow us to concentrate more on Qpid itself.  It will also
easily allow us to split up the tree and move to a component based release
mechanism in the near future, which I also think would be a good idea.  One
good thing about Maven is that it is very easy to pick up... a bit like a
virus Fraser ;)

Based on the options you suggest Robbie, I would vote for option 2 and if
that is successful, further work to move to option 3 could be picked up
later if desired.

Andrew


On 11 March 2014 20:53, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:

> On 11 March 2014 19:10, Fraser Adams <fraser.adams@blueyonder.co.uk>
> wrote:
>
> > On 10/03/14 22:56, Robbie Gemmell wrote:
> >
> >> Hi all, but especially Fraser.
> >>
> >> Now that the Maven build work progressing in the main Java tree under
> >> QPID-5048 is sufficiently progressed, it is time we look at providing a
> >> Maven build for the QMF2 tools so that they can integrate with the other
> >> components, just be more easily built generally, and be published to
> maven
> >> central for people to pick up in their builds as has been requested. I
> >> have
> >> raised https://issues.apache.org/jira/browse/QPID-5610 to track this.
> >>
> > Sounds reasonable, though I'm slightly concerned 'cause I've got no
> > experience of Maven
>
>
> Since I've work mainly on the Qpid Java bits, other than to complete the
> pieces that generate the poms in the Ant build I'd barely ever used Maven
> until the last year when other bits have popped up using it. Its certainly
> not difficult to pick up, and for the many people who do use it elsewhere
> it should make things far easier than picking up our Ant build is :)
>
>
> > and TBH I've been generally avoiding it 'cause it seems like bloatware to
> > me, but it does appear to have taken hold like a virus so I guess that's
> > "progress" for you.
> >
> > It's all fair enough though and as you point out people have begun to
> > request this stuff in Maven central.
> >
> >
> >
> >> As per the JIRA itself, the current layout of the qmf2 tools in the repo
> >> doesn't lend itself to a Maven build, so we will need to look at
> >> reorganising the content as part of the process
> >>
> > I've go no real issues with code reorganisation, but I wouldn't mind
> > knowing what you mean. I'm guessing it's because Maven expects a specific
> > layout so it can automagically do stuff, but as I say I know pretty much
> > zero about Maven.
> >
> >
> I simply meant the layout proposals described further down the mail, moving
> bits so there is a clearer heirarchy for each of the individual components,
> in part to facilate the automagic you refer to...though even the Ant build
> in the main Java tree couldnt cope with the existing semi nested layout.
>
>
> >
> >  (likely at the expense of
> >> the Ant build going away, it would need rewritten).
> >>
> > I'm kind of worried about that, I use ant all the time, but moreover I've
> > only got Maven2 - I'm currently running a relatively old Ubuntu and I
> can't
> > see Maven3 in the repo. I know that I should look to upgrade, but it's
> > blinking disruptive and I can never find the time. If there's an easy
> > Maven3 install I might be less nervous but not being able to build it
> would
> > upset me a bit.
> >
> > I still use ant to build the main Java stuff,
>
>
> I dont use Ubuntu currently (but I did use Maven 3 on an old Ubuntu 8.04 VM
> not that long ago hehe) so I dont know if it is packaged or not, but its a
> simple java app with a startup script just like Ant, I dont personally tend
> to install either one of them using the distro package manager. The core
> maven install is a 5-6MB download from http://maven.apache.org depending
> on
> version. I'm mainly using 3.0.5 to make sure stuff works on the old
> releases, whereas 3.2.1 is the current version. Maven 2 has been declared
> EOL by the Maven project for what its worth, there hasnt been a release of
> it in over 4 years, with Maven 3 now being more than 3 years old.
>
> One of the reasons that we are working on a Maven build (beyond just being
> able to integrate easily with all the stuff that expects Maven these days)
> is so that we can later split the Java tree up and move to more a
> component-related heirarchy for the project as discussed on the list
> previously. We have done the work in-situ so far in order to avoid
> disruption and minimise the modifications required to the Ant build because
> touching it is generally a time hole (I say that as the person who has
> easily spent by far the most time tweaking it in recent years; its a
> complete pain in the ass), but once we do start breaking things up it will
> need to go. In the case of the QMF stuff, layout changes are required up
> front to facilitate the initial work and these changes would require a
> complete rewrite of the Ant build, doing which doesnt seem an ideal use of
> time to me given the end goal and that the Maven build should be a lot
> nicer to use in this case (for example, not requiring setting system
> properties and adding things to the classpath in order to build the QMF
> components as currently required).
>
> though it looks like the new AMQP 1.0 JMS client is Maven only? (TBH that's
> > what has put me of trying it out)
> >
> >
> It is Maven only (but has no dependencies on the main tree), though that
> wouldnt really be what prevents you trying it out hehe, there isnt really
> enough there to support proper application usage yet as we have front
> loaded the work on the messages specifically (rather than the covering
> client as a whole) in tandem with the work on the JMS Mapping at OASIS in
> the AMQP Bindings & Mappings TC, as thats basically the most complex part
> of the JMS<->AMQP mapping when considering things comprehensively.
>
>
>
> >
> >
> >> We will want to end up with a few (or more) modules such that we are
> able
> >> to produce the main jar, rest api jar, broker plugin jar, and
> additionally
> >> archives containing all the bits people would need to use either the
> >> broker
> >> plugin or the tools+GUI.
> >>
> > Seems fair enough.
> >
> >
> >    I have a few suggestions below as to the new
> >> modules we would created in the tools/src/java directory and what the
> >> contents of them would be based on the current layout, with Option 1
> being
> >> the closest to what would be produced now and Option 3 splitting it up
> the
> >> most.
> >>
> >> Thoughts?
> >>
> >> Robbie
> >>
> >>
> >>
> >>
> >> Option 1:
> >> =======
> >>
> >> qpid-qmf2:
> >>   -src/main/java
> >>   #contains most of (see further down) or all the code currently in
> >> src/main/java
> >>
> >> qpid-qmf2-rest:
> >>   -src/main/java
> >>   #contains all the code currently in src/restapi/java
> >>
> >> qpid-qmf2-tools:
> >>   -bin
> >>   #contains everything currently in bin
> >>   -src/main/assembly
> >>   #contains an assembly descriptor for a release binary which would
> result
> >> in a tar containing the bin dir with all the scripts etc, any docs
> wanted,
> >> and a lib dir with the qpid-qmf2 and qpid-qmf2-rest modules and their
> >> dependencies (e.g the client).
> >>
> >> qpid-broker-plugins-management-qmf2:
> >>   -src/main/java
> >>   #contains all the code currently in
> >> src/qpid-broker-plugins-management-qmf2/java
> >>   -src/main/assembly
> >>   #contains an assembly descriptor for a release binary which would
> result
> >> in a tar containing the qpid-qmf2 and
> qpid-broker-plugins-management-qmf2
> >> modules and their dependencies (e.g the client).
> >>
> >> Plus appropriate src/main/resources folders to handle additional
> non-java
> >> files as necessary.
> >>
> >> Something would also need done with the current 'tests' folder, though
> as
> >> they don't appear to be automated JUnit tests I haven't yet decided on a
> >> final suggestion there.
> >>
> >>
> >> Option 2:
> >> =======
> >>
> >> As above, but modified such that the qpid-qmf2-tools module isn't just
> an
> >> assembly of the others, but actually contains the
> >> org/apache/qpid/qmf2/tools package rather than it remaining in the
> >> qpid-qmf2 module.
> >> The assembly produced by the qpid-qmf2-tools module would be updated to
> >> also include the resulting new qpid-qmf2-tools jar as well.
> >>
> >>
> >> Option 3:
> >> =======
> >>
> >> Taking Option 2 further still, split qpid-qmf2 up in line with its
> current
> >> main package composition, e.g. creating the below module jars and
> >> incorporating them into the broker plugin and tools assemblies as
> >> appropriate.
> >>
> >> qpid-qmf2-agent
> >> qpid-qmf2-common
> >> qpid-qmf2-console
> >> qpid-qmf2-tools
> >>
> >>  I guess that I'd go with the consensus on this.
>
>
> I have my own preference of course, but I'd like to see some other thoughts
> before saying :)
>
>
> > Option 3 has a certain appeal though it brings out bits I hate about
> Java.
> > Having lots of separate source trees is a right royal pain in the
> backside
> > when trying to find things.
> >
> > There's a lot of that in the main Java code and navigating around
> > broker-plugins/management-amqp/src/main/java/org/apache/
> > qpid/server/management/amqp
> > broker-core/src/main/java/org/apache/qpid/server/model
> >
> > etc.
> > just gets tedious when all the "main/java/org/apache/qpid" is the same.
> >
> >
> I can't say I really share the same frustration. We have a lot more
> directories in the main tree, and I find that that often makes it more
> obvious where to find things (so long as they are named appropriately). I
> actually had a lot more trouble than expected figuring out what/where the
> various parts of the QMF stuff are in order to consider how to package it
> and write my earlier email hehe :D
>
> Either way, editors usually [can be made to] hide or handle much of this
> for you. What are you using?
>
>
> >
> > But whatever's most useful I'll go with the flow on, I just want this
> > stuff to be useful and used.
> >
> > Frase
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message