On Mon, Nov 29, 2010 at 11:31 PM, Philippe Van Dyck <[email protected]> wrote: > Looks like one of the side-effect to the success of Maven, it is now used as > a project structure other IDE can import from... > I understand your griefs about Maven, I don't think the last version will > solve any.
Yes, I have been hoping that Maven would one day actually become more useful for each day that pass, but one of the biggest issues is that for every new version (I mean plugin version, and everything are plugins practically) you don't know what will break. So that then led to the "nail down the plugin versions" with the enforcer plugin, but then you need to manage 2 dozen versions manually, or in my/our case; Don't bother... I have to say that Maven's modularity model doesn't scale and something important to remember for the future, even for us. > The way Git is now managed by Qi4j is awesome, do you think we could do the > same for Maven ? (let's put it another way... why everybody > using isn't Gradle instead of Maven?) Well, Gradle was announced in 2008, so it is newer than Qi4j!. When I attended Evan's DDD course in London in February 2009, Hans Dockter was a DDD trainer candidate being trained to do the course later. 4 full days with him, kind of impressed; Someone has actually tried to think this through, instead of just hacking... The fact that quite a lot of high profile projects are seeking themselves away from Maven also says something. So despite Maven's ever increasing popularity, I think a lot will burn themselves, and some of us "early adopters" (I never learned) are now looking at alternatives; Gradle being one, Buildr is another interesting one, and if you know of something in the same caliber, even a full automated Ant system, I am willing to take a look. This doesn't have to happen over night. > I have nothing against Gradle, but it may add an another adoption barrier to > qi4j... Gradle builds a 'wrapper', so theoretically only a single developer needs to have Gradle installed via download. If you look in qi4j-core, there is a gradlew and gradlew.bat, which are files built by Gradle, which should bootstrap Gradle itself from scratch if run (and there after used as the gradle starter). So, technically speaking the adoption barrier is near nil, IMHO. But I agree that not knowing Groovy is a hinder when reading the 'advanced stuff' that guys over at Spring Integration, Spring Security and Hibernate are doing. The basic principle is that the build.gradle executes the equivalent of an Qi4j Assembly, and then executes that afterwards by Gradle itself. And since closures/functions are supported in Groovy, those are being executed during the build, in the right order, and not as part of the sweep through the build script itself. YMMV. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
