+1 for Maven. We have also been using maven from a long time now in many projects including the contributed ogce-gadget-container, have some complaints now and then and but over all happy with it. I used to be a ant guy and reluctantly adopted maven but completely onboard with it now, occasionally resort back to ant tasks using maven ant run plugin, but that works well.
Suresh On Apr 7, 2011, at 7:30 AM, Ate Douma wrote: > On 04/07/2011 12:02 PM, Okke Harsta wrote: >> As stated by Niels we from SURFnet have a strong preference for Maven (also >> because Shindig uses maven and it makes distribution of the deliverables >> very easy). I'm willing to do the maintenance and to act as the maven expert >> if there is need for this... Having said this I must admit I'm not very >> familiar with Ivy so that might explain my preference;-) > > If Maven would be chosen I'd be willing to help setup and maintain as well. > I've been pretty deep in maven configurations and setups the last 6+ years > (yeah: even since maven 1.0.2 but I'd rather forget that). > Writing maven plugins (been there, done that) is definitely not desirable, > but for most use-cases the already available plugins are now good enough that > there is little need for that anymore. > > Ivy I don't know much about, other than having to use it to build Wookie. I > don't particular like the limited Eclipse IDE (IvyDE) support but as a > non-expert that very well might be because of my lack of experience. > > Gradle I never used but could be cool. > I see it is supposed to have good IDE support but I see no reference to other > ASF projects using it. > > I'd like to know how the Gradle support is for ASF specific requirements like > artifact and distribution building/validating (rat, etc.) and deployments? > And the same question I have for Ant/Ivy in general. > > With Maven this nowadays is all pretty much standardized and automated with > little to no configurations needed anymore to set it up, and importantly, > constantly maintained and used by most Java ASF projects. > > As long as the build engine is capable of standardizing these things pretty > easy and provide good IDE integration/support I'm OK with any choice we make. > > For the record: Maven eclipse integration using its own maven-eclipse-plugin > is IMO definitely *not* good, for multi-module projects that is. I always and > only use the m2eclipse Eclipse plugin and that one is pretty good. > > One thing I'd like to add though is that for artifact release and deployment > I strongly suggest we at least use the Maven Central repository (e.g. as > Maven artifact) to support end users to integrate and use Rave from within > Maven based projects. > AFAIK both Ivy and Graddle could or should be able to do so, right? > >> >> On Apr 7, 2011, at 11:36 AM, Ross Gardler wrote: >> >>> My preference is Ant/Ivy (maybe EasyAnt not used that yet). It is much more >>> flexible than Maven (or is that just because I know I well). But... >>> >>> I do not object to Maven as long as someone else is available to maintain >>> it and use it properly. I can maintain Ant, I need to learn about Maven. >>> >>> So, >>> -0 Maven >>> +0 Ant + Ivy (EasyAnt?) >>> >>> Ross >>> >>> Sent from my mobile device. >>> >>> On 7 Apr 2011, at 09:50, Ate Douma<[email protected]> wrote: >>> >>>> As we're about to bootstrap the new Rave code base, it would be good to >>>> decide now what build engine we will use. This choice will have impact on >>>> how we structure and configure our source tree, build, test and >>>> integration environments. >>>> >>>> As a Java based project I think we have three options: >>>> - Ant >>>> - Ant/Ivy >>>> - Maven >>>> >>>> OSEC is Ant based, OGCE, SURFNet and Shindig are Maven based, Wookie uses >>>> Ant/Ivy. >>>> >>>> I have a strong preference to use Maven as I'm using that for almost every >>>> other project already and IMO has nowadays the strongest (automated) ASF >>>> infrastructure support. But for those not accustomed to Maven this might >>>> require some learning curve to get used to as Maven does have specific >>>> restrictions and requirements, not the least concerning structure and >>>> layout of the source tree itself. >>>> >>>> So I'd like to hear the preference of the other developers. >>>> If Ant or Ant/Ivy turns out to have the biggest support, I'm fine with >>>> that as well. >>>> >>>> Ate >> >> >> >> >>
