On 11 March 2014 19:10, Fraser Adams <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
