Awesome. Thanks Bobby. What I have is very very close to this (with a bunch of extra release management stuff). I was able to get the theory in practice plugin to work with surefire (at least so the results show up in the report) by adding the “target/test-reports” directory to the report config.
The JaCoCo stuff looks interesting. I’ll have to take a look. Thanks again, Taylor On Dec 23, 2013, at 4:23 PM, Bobby Evans <[email protected]> wrote: > 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----- >>> >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
