Hot topic indeed :) Disclaimer: I like maven a lot. Maven gave me a lot of pain.
I think that maven expose projects to developpers with a standard structure and behavior that helps a lot. When you know maven you're up and running really quickly when dealing with new projects. Plus, IDE integration is good now. For the releasing part and repository hosting, I think that self hosting is a must have for a project to be independent of the central artifacts policy. Mirroring into central is a plus so that users^W developpers do not have to add a repository to their pom. Le mardi 26 janvier 2010 14:37:21, Niclas Hedhman a écrit : > Looking at the needs we have; > > * Module support and reuse across GIT repositories. Do you mean reusing "build" features/configurations accross several git repositories ? Maven plugins and parent inheritance mechanisms can solve a lot of use cases. Certainly not all. > * Development work flow should be both fast and intuitive. And no > online checks for builds. Maven needing to be online for every build is a myth. I use maven offline by default (-o) and have no problem. Using the dependency:go-offline goal once when starting on a project minimize the possible troubles a lot. > * Test workflow, unittest, performance tests, integration tests, > regressions tests are not the same thing and has different needs. This is true that maven tests and integrations-tests phases where not done the right way but since the 2.5 version of the surefire plugin things are a lot different, thanks to the Stephen Connolly hard work two weeks ago. See http://old.nabble.com/-Vote-Proposal-:-failsafe-and-surefire-td27016430.html > * Javadoc generation, packaging, merging, versioning, publishing. Why the maven way of doing theses things feels not right to you ? > * Test coverage measurement, reporting and publishing. Nexus can handle reporting, javadoc and htmlized sources publishing too (via maven sites). > * Release Life Cycle management; > fork->dev->freeze->cut->review->sign->publish, and each of these have > their 'requirements'. The staging feature of Nexus Pro (ie. ! free ) is nice, it's sad that's it's not in the free version. > * Dependency & Version Management. Is Maven really doing the right > thing? How should it be done? All thoses things can be done with maven. release:branch, staging, jar-signer, release:prepare & release:perform > * Installer? (I have just received license for install4j from > ej-technologies (the JProfiler folks)). I don't think that's it's a build tool issue. All this is mostly thoughts and feedback, if there's some areas I can help with maven usage in qi4j, just ask me. As a side note, I'm using the 3.0-alphaX versions (faster) with qi4j projects without errors but several warnings that I know how to fix easily. That's something I could do if you're interested (as maven 3 will be out soon it should be good that the 1.0 release is 3.0-friendly). All this if maven stays in the run of course : ) Paul _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
