OK, another possible bell-and-whistle to look at: Configuring in
checkstyle (http://checkstyle.sourceforge.net/) and possibly PMD
(http://pmd.sourceforge.net/pmd-5.0.0/) so the project won't build if
there's any code formatting errors. CXF uses both so feel free to raid
its poms. I just spoke with Dan Kulp on the CXF team, his experience is
that Checkstyle is much faster as you can add lots of checks without it
slowing down much (it scales well), while PMD eats up more time with
each test and hence should be used primarily for the more advanced
things checkstyle can't handle.
Glen
On 07/25/2012 12:50 PM, Joseph Ottinger wrote:
Well, as far as I could tell, there *are* no tests yet - which worries
me. But that's part of what motivated my desire to move to Maven; we
can configure Arquillian to crank up a Qpid instance so that we can
run tests as part of the build without too much fuss.
And sure, if there're any things we need to confirm are working as
desired before we cut over, if we cut over, I have no problem putting
those in place at all.
On Wed, Jul 25, 2012 at 12:38 PM, Glen Mazza <[email protected]> wrote:
That should do it, just change the <url> to Qpid. But before proceeding
with a patch, I would certainly configure the tests in (I guess the patch
doesn't need to include the moved files/folders, just the pom.xml and
instructions on the file movements a committer needs to do for the pom.xml
to work.) Raphael may also want you to jump through a few hoops w.r.t.
multiple assembly builds and profiles (even if contrived for proton-j) just
to confirm it will work.
Glen
On 07/25/2012 12:12 PM, Joseph Ottinger wrote:
Incidentally, since we've talked about it, here's the pom.xml
(attached); this is not a patch (since the patch will need to move
directories). It also targets Java 7 by default; that's easily
changed. (I don't know the target VM yet; IMO, it SHOULD be 7, since 6
is at the end of its support cycle.)
This includes no tests, although it would be easy to provide for tests
as part of the build. But, as Glen suggests, this is in fact ready for
"mvn package" or "mvn clean install" - and deployment capabilities are
also available.
On Wed, Jul 25, 2012 at 12:06 PM, Glen Mazza <[email protected]> wrote:
Umm, I would say the main priority is that Joseph creates the pom such
that
proton builds via "mvn clean install" OOTB (as any good Maven project
should.) As long as he's met that threshold, I don't see a need anymore
for
maintaining two sources of records for builds.
Maven is really mind-numbingly simple for those building with it. No
matter
what you're building, it's always "mvn clean install" (so long as the pom
is
properly written, as it nearly always is). All you need to do is
download
Maven, add $MAVEN_HOME/bin to your system path (just like you do for Ant)
and you're all set.
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. :) Also, burdening Joseph by having him create/maintain a
separate Ant build also takes away his efforts towards creating an
awesome
Maven build.
Glen
Hi,
It looks for me that the structure of proton-j sub-project will be
quite simple and will not require the creation of complicated building
scripts similar to what we have in qpid java tree right now. I believe
that we can have 2 building systems for proton-j at least on first
stages of the project. That would allow developers to use either ant
or maven depending from their preferences.
IMHO, it should not be big overhead for the project.
Kind Regards,
Alex
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
