qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Maven build for the QMF2 tools
Date Tue, 11 Mar 2014 19:10:28 GMT
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 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.

> (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, 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)

> 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. 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

just gets tedious when all the "main/java/org/apache/qpid" is the same.

But whatever's most useful I'll go with the flow on, I just want this 
stuff to be useful and used.


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message