I threw up a pull request for some maven files based on the ones we use.

https://github.com/apache/incubator-storm/pull/13

I verified that the build works, and that the tests run and pass.  The
theory in practice clojure plugin, that seems to be the default, does not
work with surefire.  I am not sure if there is a better clojure test
runner out there for maven.  I have not looked in a while. It could also
be that most of these are fixed in newer versions of the plugin.  I would
love to be wrong about this.

The one big difference over the standard lein build is that this one uses
JaCoCo to optionally gather code coverage numbers during testing.  The
number are not great because the clojure macros seems to add in a lot of
code under a single line, but it at least gives a basic idea of how what
is not being executed.

—Bobby

On 12/23/13, 12:54 PM, "Ted Dunning" <[email protected]> wrote:

>Is this a non-standard test running you speak of?  Surefire works great
>and
>handles all of this.
>
>
>On Mon, Dec 23, 2013 at 8:50 AM, Bobby Evans <[email protected]> wrote:
>
>> I also agree that having two build systems is a pain, but both maven and
>> lein currently have different sets of issues.  I know because I maintain
>> both build systems for storm for different reasons.  I am very happy to
>> give our maven build scripts as a starting point if someone is
>>interested.
>>
>> The current clojure build plugin for maven will not output any error
>> messages unless you are using clojure 1.5 or above (or 1.4 with my patch
>> on it).
>> http://dev.clojure.org/jira/browse/CLJ-1154
>> The maven test runner will also not run a test case in isolation, it
>>must
>> be all or nothing.  In addition it has no way to fail the build if the
>> tests fail.  If the tests crash horribly the build will fail, but not on
>> simple test failures.
>>
>> Lein has bad multi-project integration and there are no good tools for
>> integrating it with Jenkins.  Test reports do not come out in a format
>> that Jenkins can read, there are no easy tools for doing code coverage
>> analysis, and pushing/installing packages to repos is a pain.  Even the
>> dependency resolution is a pain, this is why the build actually creates
>>a
>> pom.xml and calls into maven to place all of the dependencies in a
>>single
>> directory.
>>
>> We need to decide which of these two systems is going to be the best
>>long
>> term, and which errors need to be fixed before we can drop the other
>>build
>> system (CLJ-1154 is a blocker for me on maven).
>>
>> Also be aware that having both maven and lien in a multi-module project
>> can also be really ugly.  I am sure there are things we could do to make
>> this less ugly, but we did not want to modify the lein build process at
>> all so for us it really is ugly. This is because maven requires the pom
>> file of sub-projects to be called pom.xml, and under lein the part of
>>the
>> build that gathers the dependencies for packaging generates a pom.xml,
>>so
>> we had to create new maven specific directories with a pom.xml in it and
>> symlinks back to the src and test directories.
>>
>> I personally am fine with either solution so long as the integration
>> issues are fixed.  I am happy to help in either effort. But from what I
>> see lein has some structural issues with multi-project builds that may
>>be
>> difficult to resolve, but maven’s clojure plugins have a ways to go
>>before
>> they are good enough for me as a developer to consider them as my
>>primary
>> build system.
>>
>> —Bobby
>>
>> On 12/23/13, 10:04 AM, "Herbert Mühlburger" <[email protected]> wrote:
>>
>> >-----BEGIN PGP SIGNED MESSAGE-----
>> >Hash: SHA256
>> >
>> >+1 for maven.
>> >
>> >Am 23.12.13 14:11, schrieb Hugh Xedni:
>> >> +1 for maven.
>> >>
>> >>
>> >> On Sat, Dec 21, 2013 at 7:06 PM, Supun Kamburugamuva
>> >> <[email protected]>wrote:
>> >>
>> >>> I'm also trying to develop on storm and had some problems with
>> >>> Leiningen. For a developer like me who is familiar with maven,
>> >>> switching Storm to maven will be a nice thing.
>> >>>
>> >>> Thanks, Supun..
>> >>>
>> >>>
>> >>> On Sat, Dec 21, 2013 at 3:35 PM, Ed Kohlwey <[email protected]>
>> >>> wrote:
>> >>>
>> >>>> Maven has much better IDE tooling built on top of it. While
>> >>>> Lein has some minor advantages for those who want to get
>> >>>> started quickly in Clojure, it doesn't have good multi module
>> >>>> support. The current build system significantly complicates
>> >>>> developing projects like Storm on Yarn in ways that maven would
>> >>>> not. I think there is also a lot to be said for a declarative
>> >>>> build language that actually constrains you to best practices
>> >>>> rather than encouraging everyone to roll everything from
>> >>>> scratch (and to Ted's point, usually get it wrong).
>> >>>>
>> >>>> +1 for maven. On Dec 20, 2013 4:27 PM, "Ted Dunning"
>> >>>> <[email protected]> wrote:
>> >>>>
>> >>>>> The difference between Maven and Leiningen in the Apache
>> >>>>> context hasn't even really come into view.  When it comes to
>> >>>>> IP clearance, packaging
>> >>> in
>> >>>>> standard ways, signing and interfacing with Nexus, Maven is
>> >>>>> going to be worlds easier.  It isn't so much about doing the
>> >>>>> things that most developers know and care about better, it is
>> >>>>> about doing the things
>> >>> that
>> >>>>> most developers don't care about, but which are *really*
>> >>>>> important to
>> >>> get
>> >>>>> right.  Because few developers care, very few developers will
>> >>>>> get these things right.  Maven helps with this in two ways.
>> >>>>> First, many Apache projects use maven so there is a tribal
>> >>>>> knowledge available to help
>> >>> out.
>> >>>>> Second, Maven incorporates community development into normal
>> >>>>> practice. This means that if one project makes project
>> >>>>> signing better, everybody wins.  This community focus means
>> >>>>> that enough resources actually get
>> >>>> spent
>> >>>>> on the frictional parts of releasing code to make them much
>> >>>>> less
>> >>> painful.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Dec 20, 2013 at 12:29 PM, Brian O'Neill
>> >>>>> <[email protected]
>> >>>>>> wrote:
>> >>>>>
>> >>>>>> +1 for a switch to maven
>> >>>>>>
>> >>>>>> I¹m all for lowering the hurdles for other developers to
>> >>>>>> get
>> >>> involved.
>> >>>>>>
>> >>>>>> By eliminating the zeromq dependency and converting to
>> >>>>>> maven, we¹ll
>> >>>> lower
>> >>>>>> those barriers, and increase the base of people capable
>> >>>>>> of/willing to contribute.
>> >>>>>>
>> >>>>>> (the cost of submitting a small fix/enhancement right now
>> >>>>>> is too high
>> >>>> for
>> >>>>>> the casual java developer)
>> >>>>>>
>> >>>>>> -brian
>> >>>>>>
>> >>>>>> --- Brian O'Neill Chief Architect Health Market Science The
>> >>>>>> Science of Better Results 2700 Horizon Drive € King of
>> >>>>>> Prussia, PA € 19406 M: 215.588.6024 € @boneill42
>> >>>>>> <http://www.twitter.com/boneill42>  €
>> >>>>>> healthmarketscience.com
>> >>>>>>
>> >>>>>> This information transmitted in this email message is for
>> >>>>>> the
>> >>> intended
>> >>>>>> recipient only and may contain confidential and/or
>> >>>>>> privileged
>> >>> material.
>> >>>>> If
>> >>>>>> you received this email in error and are not the intended
>> >>>>>> recipient,
>> >>> or
>> >>>>>> the person responsible to deliver it to the intended
>> >>>>>> recipient,
>> >>> please
>> >>>>>> contact the sender at the email above and delete this email
>> >>>>>> and any attachments and destroy any copies thereof. Any
>> >>>>>> review,
>> >>> retransmission,
>> >>>>>> dissemination, copying or other use of, or taking any
>> >>>>>> action in
>> >>>> reliance
>> >>>>>> upon, this information by persons or entities other than
>> >>>>>> the intended recipient is strictly prohibited.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 12/20/13, 3:19 PM, "P. Taylor Goetz" <[email protected]>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> I was hoping not to have to ask this question, since it¹s
>> >>>>>>> likely to
>> >>>>> start
>> >>>>>>> a heated debate. But here goesŠ
>> >>>>>>>
>> >>>>>>> How would Storm developers feel about switching the build
>> >>>>>>> system
>> >>> from
>> >>>>>>> Leiningen to Maven?
>> >>>>>>>
>> >>>>>>> This has nothing to do with personal preference (I¹m fine
>> >>>>>>> with
>> >>>> either).
>> >>>>> I
>> >>>>>>> ask in the context of release management and integration
>> >>>>>>> with the
>> >>> ASF
>> >>>>>>> infrastructure.
>> >>>>>>>
>> >>>>>>> I know Leiningen is very concise (since it uses clojure)
>> >>>>>>> and Maven
>> >>> is
>> >>>>>>> often looked at as a ³mess of xml². And there are a lot
>> >>>>>>> of other differences that people feel passionate about.
>> >>>>>>> So I¹d like to put
>> >>>>> ³minor²
>> >>>>>>> differences aside for a minute and focus on a few points
>> >>>>>>> that are important from a release management
>> >>>>>>> perspective.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 1. ASF infrastructure support
>> >>>>>>>
>> >>>>>>> This is probably the biggest factor. From what I can tell
>> >>>>>>> (I could
>> >>> be
>> >>>>>>> wrong) Storm is the first ASF project to use Clojure and
>> >>>>>>> Leiningen,
>> >>> so
>> >>>>> it
>> >>>>>>> is not well supported from an infrastructure perspective.
>> >>>>>>> For
>> >>> example,
>> >>>>>>> although there is a Leiningen plugin for Jenkins, it¹s
>> >>>>>>> not installed
>> >>>> on
>> >>>>>>> builds.apache.org, so we¹d have to ask INFRA to install
>> >>>>>>> it which
>> >>>> could
>> >>>>>>> take a long time. To work around that, the build would
>> >>>>>>> have to do a temporary install of Leiningen with each
>> >>>>>>> build. We¹d probably have
>> >>> to
>> >>>>> add
>> >>>>>>> a bunch of support scripts as well to do things like
>> >>>>>>> detect test failures, etc.
>> >>>>>>>
>> >>>>>>> Maven on the other hand is pretty much a first class
>> >>>>>>> citizen in
>> >>> terms
>> >>>> of
>> >>>>>>> ASF infrastructure, and using Maven makes it easy to
>> >>>>>>> build/sign
>> >>>>> releases,
>> >>>>>>> stage to Sonatype, etc. There are a wealth of plugins as
>> >>>>>>> well that integrate well with infra for such things as
>> >>>>>>> publishing docs,
>> >>> project
>> >>>>>>> websites, etc.
>> >>>>>>>
>> >>>>>>> 2. Developer productivity One thing lot of people seem to
>> >>>>>>> like about Lieningen is the ability
>> >>> to
>> >>>>>>> quickly bring up a REPL and start hacking away. For this
>> >>> experiment, I
>> >>>>>>> used to the clojure maven plugin
>> >>>>>>> (https://github.com/talios/clojure-maven-plugin) and
>> >>>>>>> found it (for
>> >>>> me)
>> >>>>> to
>> >>>>>>> be on par with Leiningen. To bring up a REPL you just
>> >>>>>>> type:
>> >>>>>>>
>> >>>>>>> `mvn clojure:repl`
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> To do a comparison, I put together a quick and dirty
>> >>>>>>> experimental
>> >>>> branch
>> >>>>>>> with Leiningen replaced with Maven:
>> >>>>>>>
>> >>>>>>> https://github.com/ptgoetz/incubator-storm/tree/maven-test
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >I¹d encourage anyone to check it out play around to see what
>> >>>> developing
>> >>>>>>> Storm with Maven would be like.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> I¹d like to hear opinions from other committers and
>> >>>>>>> developers. If switching to Maven is something we want to
>> >>>>>>> do, I¹ll volunteer to do
>> >>>> the
>> >>>>>>> work.
>> >>>>>>>
>> >>>>>>> Thanks,
>> >>>>>>>
>> >>>>>>> Taylor
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> -- Supun Kamburugamuva Member, Apache Software Foundation;
>> >>> http://www.apache.org E-mail: [email protected];  Mobile: +1 812
>> >>> 369 6762 Blog: http://supunk.blogspot.com
>> >>>
>> >>
>> >>
>> >>
>> >-----BEGIN PGP SIGNATURE-----
>> >Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> >Comment: GPGTools - http://gpgtools.org
>> >
>> >iF4EAREIAAYFAlK4XyAACgkQBJGnfYOuu33lwAD9Ga8Ol8luiU8y9TTCj0KtPGtt
>> >URyr7y23RW4bH5tkXOIBALpNokRDJObyOB5v1+eRPFMx21KkzHQ8nnXbJLCt80VH
>> >=3dmy
>> >-----END PGP SIGNATURE-----
>>
>>

Reply via email to