You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2011/04/07 10:50:57 UTC
Bootstrapping Rave code: choice of build engine
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
Re: Consensus Building (was Re: Bootstrapping Rave code: choice of build engine)
Posted by Hadrian Zbarcea <hz...@gmail.com>.
+1 on Maven
+1 on the Good Practice guide.
Thanks Ross :),
Hadrian
On Apr 7, 2011, at 6:36 AM, Ross Gardler wrote:
> Every now and again I'll put my mentor hat on and attempt to communicate some of the "good practice" stuff I've seen in other ASF projects. Here's one such post on consensus building.
>
> # Making Decisions
>
> In ASF projects we don't like to vote. We reserve that for things that need official approval for legal or process reasons (e.g. a release, a new committer). Most of the time we work with consensus building.
>
> ## Lazy Consensus
>
> What this means is that if you are convinced you know what the communities consensus on an issue is you just assume that you already have consensus and get on with the work. This is called "lazy consensus." You don't have to call a vote to get approval you just assume you have it unless someone says otherwise.
>
> We have a time machine (SVN) so as long as you commit early and often the community has plenty of opportunity to indicate that they do not agree with the approach. When you believe you can operate on lazy consensus just get on with it, but be prepared to roll back work if a valid objection is raised.
>
> The key thing about lazy consensus is that it's easier for people to agree by doing nothing than it is for them to object by providing an alternative. This has two effects, firstly people are less likely to object just for the sake of it and secondly it cuts down on the amount of unnecessary traffic.
>
> Lazy consensus stops us waiting for a decision before proceeding. However, it does require everyone who cares to watch what is happening. Objecting to far down the road will cause upset, but objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is checking on our work.
>
> People may choose to indicate their support for the actions taken with a +1 mail - quick and easy to read and reassuring for the implementer, However, remember, in a lazy consensus world silence is support, noise is objection.
>
> ## Consensus Building
>
> In some cases there is no obvious path to take, or you might be a new community, or a new member of an existing community. In these cases people will often need to build consensus by making proposals and eliciting responses. This is just fine too.
>
> The confusing thing in the ASF is that some people (like me) when given one or more options will use the same notation to indicate their preferences as they would use in a formal vote. Knowing when something is a vote and when it is a preference is important. It's easy to tell though, if the subject does not have "[Vote]" at the start then it's just an opinion.
>
> The notation used is "+1", "-1" and "0". It's also common to see "+0" and "-0".
>
> So, what do these notations mean?
>
> +1 means "I agree with this and will help make it happen"
>
> +0 means "I agree with this but probably won't make it happen, so my opinion is not that important"
>
> -0 means "I don't agree with this, but I'm offering no alternative so my opinion is not that important"
>
> -1 means "I don't agree and I am offering an alternative that I am able to help implement"
>
> Many people will use fractions to indicate the strength of their feelings, e.g. "+0.5". Some will even indicate this is a "no brainer" with something like "+1000".
>
> The important thing is that this is not an exact science. It's just a shorthand way of communicating strength of feeling.
>
> Not everyone does this, but I do. the reasons I like it is because when someone wants to summarise a thread discussing the proposal they can mentally add up the strength of feeling of the community and decide if there is consensus.
>
> Once there is a consensus building people can proceed with the work under the lazy consensus model.
>
> ## Stating Lazy Consensus
>
> Sometimes you will believe a specific action to be the correct one for the community but are not sure enough to proceed with the work under the lazy consensus model. In these circumstances you can state Lazy Consensus is in operation.
>
> What this means is that you make a proposal and state that you will start implementing it in 72hours unless someone objects.
>
> In this approach you are not requiring people to explicitly support your actions but are still allowing space for objections and corrections to the proposal. Again, most people are happy for you to do their work for them and thus in many cases there will be no objection.
>
> People may choose to indicate their willingness to help implement the proposal with a +1 mail - quick and easy to read and reassuring for the proposer, However, remember, in a lazy consensus world silence is support, noise is objection.
>
> ## Voting
>
> Very occasionally a "feel" for consensus is not enough. Sometimes we need to have a measurable consensus. For example, when voting in new committers or releases. We use the same system of notation for this. the only difference is you can't use fractions or "+/-0".
>
> In a vote things mean:
>
> +1 - yes I agree
> 0 - I have no strong opinion
> -1 - I object on the following grounds
>
> If you object you must support your objection and provide an alternative course of action that you are willing and able to implement (where appropriate).
>
> ## Putting it to the test
>
> I propose making this a "good practice" guide for the Rave project. I stress is different from a required behaviour - individuals will find their own way, but I suggest this practice has been shown to work in a great many ASF projects and thus is a model I will be using here.
>
> If nobody objects in the next 72 hours or so I will put an (edited) version of this mail on your website on a "consensus building" page.
>
> Ross
>
> On 07/04/2011 10:36, 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<at...@douma.nu> 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
>
Re: Consensus Building (was Re: Bootstrapping Rave code: choice of
build engine)
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 4/7/11 6:36 AM, "Ross Gardler" <rg...@apache.org> wrote:
>Every now and again I'll put my mentor hat on and attempt to communicate
>some of the "good practice" stuff I've seen in other ASF projects.
>Here's one such post on consensus building.
>
># Making Decisions
>
>In ASF projects we don't like to vote. We reserve that for things that
>need official approval for legal or process reasons (e.g. a release, a
>new committer). Most of the time we work with consensus building.
>
>## Lazy Consensus
>
>What this means is that if you are convinced you know what the
>communities consensus on an issue is you just assume that you already
>have consensus and get on with the work. This is called "lazy
>consensus." You don't have to call a vote to get approval you just
>assume you have it unless someone says otherwise.
>
>We have a time machine (SVN) so as long as you commit early and often
>the community has plenty of opportunity to indicate that they do not
>agree with the approach. When you believe you can operate on lazy
>consensus just get on with it, but be prepared to roll back work if a
>valid objection is raised.
>
>The key thing about lazy consensus is that it's easier for people to
>agree by doing nothing than it is for them to object by providing an
>alternative. This has two effects, firstly people are less likely to
>object just for the sake of it and secondly it cuts down on the amount
>of unnecessary traffic.
>
>Lazy consensus stops us waiting for a decision before proceeding.
>However, it does require everyone who cares to watch what is happening.
>Objecting to far down the road will cause upset, but objecting (or
>asking for clarification of intent) early is likely to be greeted with
>relief that someone is checking on our work.
>
>People may choose to indicate their support for the actions taken with a
>+1 mail - quick and easy to read and reassuring for the implementer,
>However, remember, in a lazy consensus world silence is support, noise
>is objection.
>
>## Consensus Building
>
>In some cases there is no obvious path to take, or you might be a new
>community, or a new member of an existing community. In these cases
>people will often need to build consensus by making proposals and
>eliciting responses. This is just fine too.
>
>The confusing thing in the ASF is that some people (like me) when given
>one or more options will use the same notation to indicate their
>preferences as they would use in a formal vote. Knowing when something
>is a vote and when it is a preference is important. It's easy to tell
>though, if the subject does not have "[Vote]" at the start then it's
>just an opinion.
>
>The notation used is "+1", "-1" and "0". It's also common to see "+0"
>and "-0".
>
>So, what do these notations mean?
>
>+1 means "I agree with this and will help make it happen"
>
>+0 means "I agree with this but probably won't make it happen, so my
>opinion is not that important"
>
>-0 means "I don't agree with this, but I'm offering no alternative so my
>opinion is not that important"
>
>-1 means "I don't agree and I am offering an alternative that I am able
>to help implement"
>
>Many people will use fractions to indicate the strength of their
>feelings, e.g. "+0.5". Some will even indicate this is a "no brainer"
>with something like "+1000".
>
>The important thing is that this is not an exact science. It's just a
>shorthand way of communicating strength of feeling.
>
>Not everyone does this, but I do. the reasons I like it is because when
>someone wants to summarise a thread discussing the proposal they can
>mentally add up the strength of feeling of the community and decide if
>there is consensus.
>
>Once there is a consensus building people can proceed with the work
>under the lazy consensus model.
>
>## Stating Lazy Consensus
>
>Sometimes you will believe a specific action to be the correct one for
>the community but are not sure enough to proceed with the work under the
>lazy consensus model. In these circumstances you can state Lazy
>Consensus is in operation.
>
>What this means is that you make a proposal and state that you will
>start implementing it in 72hours unless someone objects.
>
>In this approach you are not requiring people to explicitly support your
>actions but are still allowing space for objections and corrections to
>the proposal. Again, most people are happy for you to do their work for
>them and thus in many cases there will be no objection.
>
>People may choose to indicate their willingness to help implement the
>proposal with a +1 mail - quick and easy to read and reassuring for the
>proposer, However, remember, in a lazy consensus world silence is
>support, noise is objection.
>
>## Voting
>
>Very occasionally a "feel" for consensus is not enough. Sometimes we
>need to have a measurable consensus. For example, when voting in new
>committers or releases. We use the same system of notation for this. the
>only difference is you can't use fractions or "+/-0".
>
>In a vote things mean:
>
>+1 - yes I agree
> 0 - I have no strong opinion
>-1 - I object on the following grounds
>
>If you object you must support your objection and provide an alternative
>course of action that you are willing and able to implement (where
>appropriate).
>
>## Putting it to the test
>
>I propose making this a "good practice" guide for the Rave project. I
>stress is different from a required behaviour - individuals will find
>their own way, but I suggest this practice has been shown to work in a
>great many ASF projects and thus is a model I will be using here.
>
>If nobody objects in the next 72 hours or so I will put an (edited)
>version of this mail on your website on a "consensus building" page.
+1
-Matt
>
>Ross
>
>On 07/04/2011 10:36, 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<at...@douma.nu> 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
>
Consensus Building (was Re: Bootstrapping Rave code: choice of build
engine)
Posted by Ross Gardler <rg...@apache.org>.
Every now and again I'll put my mentor hat on and attempt to communicate
some of the "good practice" stuff I've seen in other ASF projects.
Here's one such post on consensus building.
# Making Decisions
In ASF projects we don't like to vote. We reserve that for things that
need official approval for legal or process reasons (e.g. a release, a
new committer). Most of the time we work with consensus building.
## Lazy Consensus
What this means is that if you are convinced you know what the
communities consensus on an issue is you just assume that you already
have consensus and get on with the work. This is called "lazy
consensus." You don't have to call a vote to get approval you just
assume you have it unless someone says otherwise.
We have a time machine (SVN) so as long as you commit early and often
the community has plenty of opportunity to indicate that they do not
agree with the approach. When you believe you can operate on lazy
consensus just get on with it, but be prepared to roll back work if a
valid objection is raised.
The key thing about lazy consensus is that it's easier for people to
agree by doing nothing than it is for them to object by providing an
alternative. This has two effects, firstly people are less likely to
object just for the sake of it and secondly it cuts down on the amount
of unnecessary traffic.
Lazy consensus stops us waiting for a decision before proceeding.
However, it does require everyone who cares to watch what is happening.
Objecting to far down the road will cause upset, but objecting (or
asking for clarification of intent) early is likely to be greeted with
relief that someone is checking on our work.
People may choose to indicate their support for the actions taken with a
+1 mail - quick and easy to read and reassuring for the implementer,
However, remember, in a lazy consensus world silence is support, noise
is objection.
## Consensus Building
In some cases there is no obvious path to take, or you might be a new
community, or a new member of an existing community. In these cases
people will often need to build consensus by making proposals and
eliciting responses. This is just fine too.
The confusing thing in the ASF is that some people (like me) when given
one or more options will use the same notation to indicate their
preferences as they would use in a formal vote. Knowing when something
is a vote and when it is a preference is important. It's easy to tell
though, if the subject does not have "[Vote]" at the start then it's
just an opinion.
The notation used is "+1", "-1" and "0". It's also common to see "+0"
and "-0".
So, what do these notations mean?
+1 means "I agree with this and will help make it happen"
+0 means "I agree with this but probably won't make it happen, so my
opinion is not that important"
-0 means "I don't agree with this, but I'm offering no alternative so my
opinion is not that important"
-1 means "I don't agree and I am offering an alternative that I am able
to help implement"
Many people will use fractions to indicate the strength of their
feelings, e.g. "+0.5". Some will even indicate this is a "no brainer"
with something like "+1000".
The important thing is that this is not an exact science. It's just a
shorthand way of communicating strength of feeling.
Not everyone does this, but I do. the reasons I like it is because when
someone wants to summarise a thread discussing the proposal they can
mentally add up the strength of feeling of the community and decide if
there is consensus.
Once there is a consensus building people can proceed with the work
under the lazy consensus model.
## Stating Lazy Consensus
Sometimes you will believe a specific action to be the correct one for
the community but are not sure enough to proceed with the work under the
lazy consensus model. In these circumstances you can state Lazy
Consensus is in operation.
What this means is that you make a proposal and state that you will
start implementing it in 72hours unless someone objects.
In this approach you are not requiring people to explicitly support your
actions but are still allowing space for objections and corrections to
the proposal. Again, most people are happy for you to do their work for
them and thus in many cases there will be no objection.
People may choose to indicate their willingness to help implement the
proposal with a +1 mail - quick and easy to read and reassuring for the
proposer, However, remember, in a lazy consensus world silence is
support, noise is objection.
## Voting
Very occasionally a "feel" for consensus is not enough. Sometimes we
need to have a measurable consensus. For example, when voting in new
committers or releases. We use the same system of notation for this. the
only difference is you can't use fractions or "+/-0".
In a vote things mean:
+1 - yes I agree
0 - I have no strong opinion
-1 - I object on the following grounds
If you object you must support your objection and provide an alternative
course of action that you are willing and able to implement (where
appropriate).
## Putting it to the test
I propose making this a "good practice" guide for the Rave project. I
stress is different from a required behaviour - individuals will find
their own way, but I suggest this practice has been shown to work in a
great many ASF projects and thus is a model I will be using here.
If nobody objects in the next 72 hours or so I will put an (edited)
version of this mail on your website on a "consensus building" page.
Ross
On 07/04/2011 10:36, 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<at...@douma.nu> 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
Re: Bootstrapping Rave code: choice of build engine
Posted by Ross Gardler <rg...@apache.org>.
On 07/04/2011 14:21, Ate Douma wrote:
> On 04/07/2011 03:05 PM, Carlucci, Tony wrote:
>> -1000 Maven 1.0.2
> -1E1000
Oh dear. Geek one-upmanship
We're done for. I've seen this before. This community is starting off on
the wrong foot
(tongue firmly in cheek)
Ross
Re: Bootstrapping Rave code: choice of build engine
Posted by Ate Douma <at...@douma.nu>.
On 04/07/2011 03:05 PM, Carlucci, Tony wrote:
> -1000 Maven 1.0.2
-1E1000
>
> Tony
>
> ---
> Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development& Maint
> e: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
> The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
>
> -----Original Message-----
> From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
> Sent: Thursday, April 07, 2011 8:49 AM
> To: rave-dev@incubator.apache.org
> Subject: Re: Bootstrapping Rave code: choice of build engine
>
> I usually prefer to use ANT and though I haven't used it, Ivy looks to be
> a nice balance between Maven dependency management and ANT flexibility. I
> have also used Maven, and once things are setup, I usually don't have too
> much trouble with it.
>
> In the end, it doesn't matter that much to me, but I would be +1 to
> ANT/Ivy and +0 to Maven.
>
> -Matt
>
> On 4/7/11 8:11 AM, "Ross Gardler"<rg...@apache.org> wrote:
>
>> On 07/04/2011 12:30, 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;-)
>>
>> ...
>>
>>> 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.
>>
>> (I know ANT + Ivy quite well, so I'll only comment on that)
>>
>> I think IDE integration is a fair criticism of ANT + Ivy.
>>
>> It's one of the penalties of not having a single way of doing things.
>> It's a flexibility vs convenience trade off.
>>
>>> 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.
>>
>> From an ANT point of view it's easy to do pretty much anything you want
>> in ANT. It's more of a build programming environment than a way of doing
>> things.
>>
>> Maven works out of the box, ANT needs customising for specific
>> environments. EasyAnt (and by the sounds of it Gradle) aim to provide
>> the maven style "do it this way" recipes.
>>
>>> 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?
>>
>> Yes, Ivy uses maven repos (and thus I assume Gradle does).
>>
>> Ross
>
>
Re: Bootstrapping Rave code: choice of build engine
Posted by Ross Gardler <rg...@apache.org>.
On 07/04/2011 14:05, Carlucci, Tony wrote:
> -1000 Maven 1.0.2
:-))
Ross
RE: Bootstrapping Rave code: choice of build engine
Posted by "Carlucci, Tony" <ac...@mitre.org>.
+1 Ant/Ivy
+0 Maven 3
-1000 Maven 1.0.2
Tony
---
Anthony Carlucci | SW App Dev Eng, Sr. | R501 / KW App Development & Maint
e: acarlucci@mitre.org | v: 781.271.2432 | f: 781.271.3299
The MITRE Corporation | 202 Burlington Rd | Bedford, MA 01730-1420
-----Original Message-----
From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
Sent: Thursday, April 07, 2011 8:49 AM
To: rave-dev@incubator.apache.org
Subject: Re: Bootstrapping Rave code: choice of build engine
I usually prefer to use ANT and though I haven't used it, Ivy looks to be
a nice balance between Maven dependency management and ANT flexibility. I
have also used Maven, and once things are setup, I usually don't have too
much trouble with it.
In the end, it doesn't matter that much to me, but I would be +1 to
ANT/Ivy and +0 to Maven.
-Matt
On 4/7/11 8:11 AM, "Ross Gardler" <rg...@apache.org> wrote:
>On 07/04/2011 12:30, 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;-)
>
>...
>
>> 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.
>
>(I know ANT + Ivy quite well, so I'll only comment on that)
>
>I think IDE integration is a fair criticism of ANT + Ivy.
>
>It's one of the penalties of not having a single way of doing things.
>It's a flexibility vs convenience trade off.
>
>> 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.
>
> From an ANT point of view it's easy to do pretty much anything you want
>in ANT. It's more of a build programming environment than a way of doing
>things.
>
>Maven works out of the box, ANT needs customising for specific
>environments. EasyAnt (and by the sounds of it Gradle) aim to provide
>the maven style "do it this way" recipes.
>
>> 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?
>
>Yes, Ivy uses maven repos (and thus I assume Gradle does).
>
>Ross
Re: Bootstrapping Rave code: choice of build engine
Posted by Scott Wilson <sc...@gmail.com>.
On 7 Apr 2011, at 14:49, Franklin, Matthew B. wrote:
> I usually prefer to use ANT and though I haven't used it, Ivy looks to be
> a nice balance between Maven dependency management and ANT flexibility. I
> have also used Maven, and once things are setup, I usually don't have too
> much trouble with it.
>
> In the end, it doesn't matter that much to me, but I would be +1 to
> ANT/Ivy and +0 to Maven.
+1 Ant+Ivy as I'm familiar with it, but I've no major objections to any of the other options
>
> -Matt
>
> On 4/7/11 8:11 AM, "Ross Gardler" <rg...@apache.org> wrote:
>
>> On 07/04/2011 12:30, 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;-)
>>
>> ...
>>
>>> 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.
>>
>> (I know ANT + Ivy quite well, so I'll only comment on that)
>>
>> I think IDE integration is a fair criticism of ANT + Ivy.
>>
>> It's one of the penalties of not having a single way of doing things.
>> It's a flexibility vs convenience trade off.
>>
>>> 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.
>>
>> From an ANT point of view it's easy to do pretty much anything you want
>> in ANT. It's more of a build programming environment than a way of doing
>> things.
>>
>> Maven works out of the box, ANT needs customising for specific
>> environments. EasyAnt (and by the sounds of it Gradle) aim to provide
>> the maven style "do it this way" recipes.
>>
>>> 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?
>>
>> Yes, Ivy uses maven repos (and thus I assume Gradle does).
>>
>> Ross
>
Re: Bootstrapping Rave code: choice of build engine
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
I usually prefer to use ANT and though I haven't used it, Ivy looks to be
a nice balance between Maven dependency management and ANT flexibility. I
have also used Maven, and once things are setup, I usually don't have too
much trouble with it.
In the end, it doesn't matter that much to me, but I would be +1 to
ANT/Ivy and +0 to Maven.
-Matt
On 4/7/11 8:11 AM, "Ross Gardler" <rg...@apache.org> wrote:
>On 07/04/2011 12:30, 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;-)
>
>...
>
>> 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.
>
>(I know ANT + Ivy quite well, so I'll only comment on that)
>
>I think IDE integration is a fair criticism of ANT + Ivy.
>
>It's one of the penalties of not having a single way of doing things.
>It's a flexibility vs convenience trade off.
>
>> 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.
>
> From an ANT point of view it's easy to do pretty much anything you want
>in ANT. It's more of a build programming environment than a way of doing
>things.
>
>Maven works out of the box, ANT needs customising for specific
>environments. EasyAnt (and by the sounds of it Gradle) aim to provide
>the maven style "do it this way" recipes.
>
>> 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?
>
>Yes, Ivy uses maven repos (and thus I assume Gradle does).
>
>Ross
Re: Bootstrapping Rave code: choice of build engine
Posted by Ross Gardler <rg...@apache.org>.
On 07/04/2011 12:30, 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;-)
...
> 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.
(I know ANT + Ivy quite well, so I'll only comment on that)
I think IDE integration is a fair criticism of ANT + Ivy.
It's one of the penalties of not having a single way of doing things.
It's a flexibility vs convenience trade off.
> 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.
From an ANT point of view it's easy to do pretty much anything you want
in ANT. It's more of a build programming environment than a way of doing
things.
Maven works out of the box, ANT needs customising for specific
environments. EasyAnt (and by the sounds of it Gradle) aim to provide
the maven style "do it this way" recipes.
> 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?
Yes, Ivy uses maven repos (and thus I assume Gradle does).
Ross
Re: Bootstrapping Rave code: choice of build engine
Posted by Suresh Marru <sm...@cs.indiana.edu>.
+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<at...@douma.nu> 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
>>
>>
>>
>>
>>
Re: Bootstrapping Rave code: choice of build engine
Posted by Ate Douma <at...@douma.nu>.
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<at...@douma.nu> 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
>
>
>
>
>
Re: Bootstrapping Rave code: choice of build engine
Posted by Okke Harsta <oh...@zilverline.com>.
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;-)
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 <at...@douma.nu> 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
Re: Bootstrapping Rave code: choice of build engine
Posted by Ross Gardler <rg...@apache.org>.
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 <at...@douma.nu> 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
Re: Bootstrapping Rave code: choice of build engine
Posted by Sylvain Wallez <sy...@bluxte.net>.
Another very interesting option is Gradle : http://www.gradle.org/
It's Ant + Ivy with predefined build rules through plugins (java, war,
maven-deploy, etc).
The build script can be entirely declarative (and ultra-compact compared
to Maven) if you don't have specific needs, but it's actually a Groovy
script and is wide open to custom rules and plugin parameterization and
extension if there are specific build needs. It also has strong support
for multi-project builds.
I've been using Gradle for my recent projets and I'm quite happy with it
: simple and straightforward for standard needs, and doesn't make you
bang your head against the wall (i.e. write a Maven plugin) for specific
needs.
My 2 cents,
Sylvain
Le 07/04/11 10:50, Ate Douma a écrit :
> 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
--
Sylvain Wallez - http://bluxte.net
Re: Bootstrapping Rave code: choice of build engine
Posted by Niels van Dijk <ni...@surfnet.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 for maven, especially because Shindig is using it, making a
combined rollout much easier
On 04/07/2011 10:50 AM, Ate Douma 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNnYTKAAoJECCFeCvee7L1vjcP/31TO+Jh+PCMftVkV2y7GJaT
MqXGFgVYbphvH/6lyekHvtpHvPLcLmIeovbnShXpTfMOalhivdO5REari1otGwh4
oTXT1bwxwb5OwynuqOZsym66cHzjQwpJtC7MiODYsvDGlLupUtTW63iP8iQ2CXtA
KPlFHbZeoA8UEFKx7yvpeWcGcJhpd3gV7AqHbLE6w6Cc78hr8kej0x0VU//xvFtY
mM2Rqg+G2gZZKDA1TCpacuXi05/s+DEu2dVY/ONPDceHZc95Y2QgbL5WUw3Q2PFe
odcwqX/RNEivM4nuKmHSq++5xKJtCSnV50GG+eW6UclH0gpZmDOr2UXeFZNaCTQG
/Nj8yIObPrtL23UdVnQUczXyb4WfEadYFmo9EECOLPqUzw66t7P8SaPZ6/pIki+Q
DNshRKk0TtkYdeLcQY2BcoNE5wZ/gqW1bR5kLB6zWi/Y+Iq2Fv6T7aU+OFzZ6Vf2
K9QU5RO1I8qIKIgR87ynjtjIqRwyYnRHmbFQtkL78Ru1aFl35l6NRB6RCjVBwcRX
d/6KesK+4p52/biG9rG4/juWjVZ9Ny8ELbOV3qcbP5al9HGEUB+DEjNTB7hGbUUG
x1hgLi6nH3BCg2xQ7YYsPaupZ0b9WHnDm4MnD7V7SyyG8mHzroVuZjlEPxxjpXc6
qUOPEqi+JjVQwRfSB6oS
=vu9r
-----END PGP SIGNATURE-----
Re: Bootstrapping Rave code: choice of build engine
Posted by Jasha Joachimsthal <j....@onehippo.com>.
+1 for Maven because of all the available plugins, IDE support and most
important the dependency repositories.
-0 for Ant/Ivy because Ivy ends up using Maven repositories for the
dependencies so why not use Maven directly.
Jasha Joachimsthal
j.joachimsthal@onehippo.com - jasha@apache.org
Hippo
Europe • Amsterdam • Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20
522 4466
USA • Boston • 1 Broadway • Cambridge, MA 02142 • +1 877 414 4776
(toll free)
www.onehippo.com • www.onehippo.org • info@onehippo.com
On 7 April 2011 22:35, Woonsan Ko <wo...@yahoo.com> wrote:
> +1 Maven: I like its conventions and many built-in plugins such as antrun,
> rat, jetty, cargo, dependency plugins, etc.
> +0 Ant/Ivy: I would learn this if chosen.
>
> Woonsan
>
> --- On Thu, 4/7/11, Raminderjeet Singh <ra...@gmail.com> wrote:
>
> > From: Raminderjeet Singh <ra...@gmail.com>
> > Subject: Re: Bootstrapping Rave code: choice of build engine
> > To: rave-dev@incubator.apache.org
> > Date: Thursday, April 7, 2011, 4:00 PM
> > +1 Maven.. i like the IDE integration
> > of maven. WAR application build component is most tested one
> > :)
> >
> > +0 Ant/Ivy i would love to learn if we will end up with
> > this
> >
> > Raminder
> > On Apr 7, 2011, at 9:37 AM, Sander van der Waal wrote:
> >
> > > +1 Maven since that's what I'm most comfortable with
> > and find easiest to
> > > use.
> > >
> > > -0 Ant/Ivy I'm always struggling with Ivy integration
> > in my IDE and in my
> > > experience the maven-antrun-plugin is a good mechanism
> > for integrating
> > > things 'the Ant way' if Maven isn't up to it.
> > >
> > > Sander
> > >
> > > On Thu, Apr 7, 2011 at 2:30 PM, Ciancetta, Jesse E.
> > <jc...@mitre.org>
> > wrote:
> > >
> > >> +1 Ant/Ivy (as I'm already familiar with Ant and
> > like to try to keep things
> > >> as simple as possible - and my impression of Ant
> > is that it is much simpler
> > >> to deal with than Maven)
> > >>
> > >> +0 Maven (I'd be willing to learn it if that's the
> > group's overall
> > >> consensus)
> > >>
> > >> --Jesse
> > >>
> > >>> -----Original Message-----
> > >>> From: Ate Douma [mailto:ate@douma.nu]
> > >>> Sent: Thursday, April 07, 2011 4:51 AM
> > >>> To: rave-dev@incubator.apache.org
> > >>> Subject: Bootstrapping Rave code: choice of
> > build engine
> > >>>
> > >>> 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
> > >>
> >
> >
>
Re: Bootstrapping Rave code: choice of build engine
Posted by Woonsan Ko <wo...@yahoo.com>.
+1 Maven: I like its conventions and many built-in plugins such as antrun, rat, jetty, cargo, dependency plugins, etc.
+0 Ant/Ivy: I would learn this if chosen.
Woonsan
--- On Thu, 4/7/11, Raminderjeet Singh <ra...@gmail.com> wrote:
> From: Raminderjeet Singh <ra...@gmail.com>
> Subject: Re: Bootstrapping Rave code: choice of build engine
> To: rave-dev@incubator.apache.org
> Date: Thursday, April 7, 2011, 4:00 PM
> +1 Maven.. i like the IDE integration
> of maven. WAR application build component is most tested one
> :)
>
> +0 Ant/Ivy i would love to learn if we will end up with
> this
>
> Raminder
> On Apr 7, 2011, at 9:37 AM, Sander van der Waal wrote:
>
> > +1 Maven since that's what I'm most comfortable with
> and find easiest to
> > use.
> >
> > -0 Ant/Ivy I'm always struggling with Ivy integration
> in my IDE and in my
> > experience the maven-antrun-plugin is a good mechanism
> for integrating
> > things 'the Ant way' if Maven isn't up to it.
> >
> > Sander
> >
> > On Thu, Apr 7, 2011 at 2:30 PM, Ciancetta, Jesse E.
> <jc...@mitre.org>
> wrote:
> >
> >> +1 Ant/Ivy (as I'm already familiar with Ant and
> like to try to keep things
> >> as simple as possible - and my impression of Ant
> is that it is much simpler
> >> to deal with than Maven)
> >>
> >> +0 Maven (I'd be willing to learn it if that's the
> group's overall
> >> consensus)
> >>
> >> --Jesse
> >>
> >>> -----Original Message-----
> >>> From: Ate Douma [mailto:ate@douma.nu]
> >>> Sent: Thursday, April 07, 2011 4:51 AM
> >>> To: rave-dev@incubator.apache.org
> >>> Subject: Bootstrapping Rave code: choice of
> build engine
> >>>
> >>> 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
> >>
>
>
Re: Bootstrapping Rave code: choice of build engine
Posted by Raminderjeet Singh <ra...@gmail.com>.
+1 Maven.. i like the IDE integration of maven. WAR application build component is most tested one :)
+0 Ant/Ivy i would love to learn if we will end up with this
Raminder
On Apr 7, 2011, at 9:37 AM, Sander van der Waal wrote:
> +1 Maven since that's what I'm most comfortable with and find easiest to
> use.
>
> -0 Ant/Ivy I'm always struggling with Ivy integration in my IDE and in my
> experience the maven-antrun-plugin is a good mechanism for integrating
> things 'the Ant way' if Maven isn't up to it.
>
> Sander
>
> On Thu, Apr 7, 2011 at 2:30 PM, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
>
>> +1 Ant/Ivy (as I'm already familiar with Ant and like to try to keep things
>> as simple as possible - and my impression of Ant is that it is much simpler
>> to deal with than Maven)
>>
>> +0 Maven (I'd be willing to learn it if that's the group's overall
>> consensus)
>>
>> --Jesse
>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Thursday, April 07, 2011 4:51 AM
>>> To: rave-dev@incubator.apache.org
>>> Subject: Bootstrapping Rave code: choice of build engine
>>>
>>> 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
>>
Re: Bootstrapping Rave code: choice of build engine
Posted by Sander van der Waal <sa...@gmail.com>.
+1 Maven since that's what I'm most comfortable with and find easiest to
use.
-0 Ant/Ivy I'm always struggling with Ivy integration in my IDE and in my
experience the maven-antrun-plugin is a good mechanism for integrating
things 'the Ant way' if Maven isn't up to it.
Sander
On Thu, Apr 7, 2011 at 2:30 PM, Ciancetta, Jesse E. <jc...@mitre.org> wrote:
> +1 Ant/Ivy (as I'm already familiar with Ant and like to try to keep things
> as simple as possible - and my impression of Ant is that it is much simpler
> to deal with than Maven)
>
> +0 Maven (I'd be willing to learn it if that's the group's overall
> consensus)
>
> --Jesse
>
> >-----Original Message-----
> >From: Ate Douma [mailto:ate@douma.nu]
> >Sent: Thursday, April 07, 2011 4:51 AM
> >To: rave-dev@incubator.apache.org
> >Subject: Bootstrapping Rave code: choice of build engine
> >
> >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
>
RE: Bootstrapping Rave code: choice of build engine
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
+1 Ant/Ivy (as I'm already familiar with Ant and like to try to keep things as simple as possible - and my impression of Ant is that it is much simpler to deal with than Maven)
+0 Maven (I'd be willing to learn it if that's the group's overall consensus)
--Jesse
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Thursday, April 07, 2011 4:51 AM
>To: rave-dev@incubator.apache.org
>Subject: Bootstrapping Rave code: choice of build engine
>
>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
Re: Bootstrapping Rave code: choice of build engine
Posted by Unico Hommes <u....@onehippo.com>.
I really only know maven somewhat, it has been a long time since I
used Ant and haven't used any of the other build systems mentioned. So
if it comes to maintenance of the build system I would only be able to
contribute if we use that. Otherwise I don't have any strong opinion
on the matter.
+1 on maven
+0 on any of the other options
--
Unico
On Fri, Apr 8, 2011 at 9:58 AM, Ard Schrijvers
<a....@onehippo.com> wrote:
> On Thu, Apr 7, 2011 at 10:50 AM, Ate Douma <at...@douma.nu> 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
>
> +1 for maven because I am used to maven. Have no experience with Ant/Ivy
>
> Regards Ard
>
Re: Bootstrapping Rave code: choice of build engine
Posted by Ard Schrijvers <a....@onehippo.com>.
On Thu, Apr 7, 2011 at 10:50 AM, Ate Douma <at...@douma.nu> 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
+1 for maven because I am used to maven. Have no experience with Ant/Ivy
Regards Ard
RE: Bootstrapping Rave code: choice of build engine
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
I just did a quick tally based on where it seems people's overall preference was (some people didn't actually +1 any choice, but rather +0'd one and -0'd the other -- so I took the +0 as their preferred option) and it looks like Maven is clearly the winner. Here is what I came up with:
=====
Maven
=====
Ate, Niels, Okke, Suresh, Marlon, Sander, Raminder, Woonsan, Jasha, Ard, Unico
=======
Ant/Ivy
=======
Jesse, Ross, Matt, Tony, Scott
=======
Gradle
=======
Sylvain
--
As I understand it Maven has a very rigid project structure -- so if that's indeed the case (meaning there is really nothing we need to discuss as a group about how we structure things) then would it make sense to have one of the Maven experts in the group volunteer to go ahead and get the Maven based project all setup for us?
--Jesse
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Thursday, April 07, 2011 4:51 AM
>To: rave-dev@incubator.apache.org
>Subject: Bootstrapping Rave code: choice of build engine
>
>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
Re: Bootstrapping Rave code: choice of build engine
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I vote for Maven.
Marlon
On 4/7/11 4:50 AM, Ate Douma 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNnbpvAAoJEOEgD2XReDo5oewH/0k/cje9f3YEFUIuqH7SxvSF
4dmIluYz7EWieft1VVLJKoHsMvtJRr/lF52SLCY3M8EOfWCfL11GIKOiX+8+SBgw
iuIl3HJW4lm++w93FA8nsdV/HPeNqB8h9eYkQiS3qr3DfcEjJkVMmm8R9pDzbs+5
xBet0BaTC5+NqVEdGMbd9fjlqpPHqMlTqoJeDVCqdNrOAmj7KR303jdC1PhA4g+f
u24H8b9YJShgebaYBkpVskI428GiU5k4xZKSww0Ze8vUAKvE0T6NSUfTYJbu8CJV
CMa6fJ9R7r9uQLySaTv37PKUSt4bjOfizv0SYR1GC9J0gg/JUbkrXfaZcO4uqdU=
=zFu4
-----END PGP SIGNATURE-----