You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2011/07/06 09:39:18 UTC
[VOTE] Continunuous integration and repository management
2011/7/5 Stefan Bodewig <bo...@apache.org>
> On 2011-07-04, Jean-Louis Boudart wrote:
>
> > We'll need to setup tons of jobs, one for core and then one for each
> plugins
> > as it could be released independently. I thought i was easier for all to
> > have one place for both apache-compatible and non compatible stuff.
>
> Understood.
>
> > I feel confortable if we choose to use builds.apache.org for
> easyant-core
> > and core plugins, but in any case we need to have a second CI server for
> > other plugins which could not be hosted @apache.org (such as
> checkstyle,
> > sonar etc...)
>
> Sounds good to me.
>
Let's turn this in a more formal vote :
Do we agree that we need one "repository" for both apache / non-apache
plugins ? see http://repository.easyant.org
[ ] YES
[ ] NO
Then for CI we have two options :
[ ] Option 1 : Have one CI server to build everything related to easyant
such as core, examples, plugins (including apache ones and non apache ones)
[ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
examples + apache plugins) could use http://builds.apache.org. For the rest
(plugins non compatible with apache license for example) could use
http://builds.easyant.org.
Things to take in consideration :
Easyant is builded with easyant itself, all plugins required to build
easyant will be fetched from a repository (http://repository.easyant.org ?)
this applies to both options.
When we release easyant we will create an easyant distribution this includes
ant + ivy + easyant-core + a set of common plugins for standard case. Like
for others apache deliverable the good host to make it accessible is
http://dist.apache.org.
If we choose Option 1 we will need to keep in mind that the easyant
distribution deliverable needs to be published on http://dist.apache.org.
Which option do you prefer ?
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter
http://incubator.apache.org/easyant/<http://incubat.apache.org/easyant/>
Re: [VOTE] Continunuous integration and repository management
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 6 juil. 2011 à 11:39, Jean-Louis Boudart a écrit :
> 2011/7/5 Stefan Bodewig <bo...@apache.org>
>
>> On 2011-07-04, Jean-Louis Boudart wrote:
>>
>>> We'll need to setup tons of jobs, one for core and then one for each
>> plugins
>>> as it could be released independently. I thought i was easier for all to
>>> have one place for both apache-compatible and non compatible stuff.
>>
>> Understood.
>>
>>> I feel confortable if we choose to use builds.apache.org for
>> easyant-core
>>> and core plugins, but in any case we need to have a second CI server for
>>> other plugins which could not be hosted @apache.org (such as
>> checkstyle,
>>> sonar etc...)
>>
>> Sounds good to me.
>>
>
> Let's turn this in a more formal vote :
>
> Do we agree that we need one "repository" for both apache / non-apache
> plugins ? see http://repository.easyant.org
> [ ] YES
> [ ] NO
+1
>
>
> Then for CI we have two options :
> [ ] Option 1 : Have one CI server to build everything related to easyant
> such as core, examples, plugins (including apache ones and non apache ones)
> [ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
> examples + apache plugins) could use http://builds.apache.org. For the rest
> (plugins non compatible with apache license for example) could use
> http://builds.easyant.org.
I tend to prefer Option 2.
Nicolas
Re: [VOTE] Continunuous integration and repository management
Posted by Jean-Louis Boudart <je...@gmail.com>.
2011/7/7 Siddhartha Purkayastha <kp...@gmail.com>
> Some additional thoughts:
>
> Single Repository will be less confusing to the user. Flip side of having a
> single repository will be that there will be nothing to prevent someone
> from
> injecting a dependency of the core on non-Apache compliant plug-ins
> inadvertently. Having a separate Apache repository will enforce this
> restriction.
>
We can limit this by having distinct internal repositories with different
roles to upload on them to limit this effect. See
http://wiki.jfrog.org/confluence/display/RTF/Managing+Repositories for more
details.
>
> As I understand, there is also the need to maintain the sources for
> plug-ins
> that are *non-apache*. For such plug-ins, separate source repositories will
> be needed. These will be outside the purview of Apache. So it may also be
> possible that in the future, rights to develop on and build such plug-ins
> may vest on people of the larger community independent of the Apache
> EasyAnt
> dev team. As such, it may be helpful to have a clear separation between
> Apache and non-Apache sources, builds and resultant artifacts.
>
Maybe we can let the community choose where they want to host their plugins
sources (on github? sourceforce ? googlecode? whatever...). Then if they
want to make it build and published on our online repository they could ask
us on the mailing list, we will setup a jenkins job on
builds.easyant.organd make the plugin published on
repository.easyant.org.
Does it sounds reasonable ?
>
> Just to point out - if we are to use builds.apache.org, we will need
> EasyAnt
> installed on the build machines. I think that should not be a problem
> though.
>
Hudson/Jenkins is not necessarily required as we can invoke a shell script.
About installing easyant itself i'm not sure this is required as we can
"bootstrap" the build with Apache Ant. We could then use easyant from the
bootstrap distribution.
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter
http://incubator.apache.org/easyant/<http://incubat.apache.org/easyant/>
Re: [VOTE] Continunuous integration and repository management
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
Some additional thoughts:
Single Repository will be less confusing to the user. Flip side of having a
single repository will be that there will be nothing to prevent someone from
injecting a dependency of the core on non-Apache compliant plug-ins
inadvertently. Having a separate Apache repository will enforce this
restriction.
For CI, I think we should follow Apache conventions to the extent possible.
In any case, non-apache compliant plug-ins such as checkstyle etc can not be
considered a part of 'Apache EasyAnt' offerings.
As I understand, there is also the need to maintain the sources for plug-ins
that are *non-apache*. For such plug-ins, separate source repositories will
be needed. These will be outside the purview of Apache. So it may also be
possible that in the future, rights to develop on and build such plug-ins
may vest on people of the larger community independent of the Apache EasyAnt
dev team. As such, it may be helpful to have a clear separation between
Apache and non-Apache sources, builds and resultant artifacts.
Just to point out - if we are to use builds.apache.org, we will need EasyAnt
installed on the build machines. I think that should not be a problem
though.
Thanks,
Siddhartha
On 6 July 2011 15:09, Jean-Louis Boudart <je...@gmail.com>wrote:
> 2011/7/5 Stefan Bodewig <bo...@apache.org>
>
> > On 2011-07-04, Jean-Louis Boudart wrote:
> >
> > > We'll need to setup tons of jobs, one for core and then one for each
> > plugins
> > > as it could be released independently. I thought i was easier for all
> to
> > > have one place for both apache-compatible and non compatible stuff.
> >
> > Understood.
> >
> > > I feel confortable if we choose to use builds.apache.org for
> > easyant-core
> > > and core plugins, but in any case we need to have a second CI server
> for
> > > other plugins which could not be hosted @apache.org (such as
> > checkstyle,
> > > sonar etc...)
> >
> > Sounds good to me.
> >
>
> Let's turn this in a more formal vote :
>
> Do we agree that we need one "repository" for both apache / non-apache
> plugins ? see http://repository.easyant.org
> [ ] YES
> [ ] NO
>
>
> Then for CI we have two options :
> [ ] Option 1 : Have one CI server to build everything related to easyant
> such as core, examples, plugins (including apache ones and non apache ones)
> [ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
> examples + apache plugins) could use http://builds.apache.org. For the
> rest
> (plugins non compatible with apache license for example) could use
> http://builds.easyant.org.
>
> Things to take in consideration :
> Easyant is builded with easyant itself, all plugins required to build
> easyant will be fetched from a repository (http://repository.easyant.org?)
> this applies to both options.
>
> When we release easyant we will create an easyant distribution this
> includes
> ant + ivy + easyant-core + a set of common plugins for standard case. Like
> for others apache deliverable the good host to make it accessible is
> http://dist.apache.org.
> If we choose Option 1 we will need to keep in mind that the easyant
> distribution deliverable needs to be published on http://dist.apache.org.
>
> Which option do you prefer ?
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter
> http://incubator.apache.org/easyant/<http://incubat.apache.org/easyant/>
>
Re: [VOTE] Continunuous integration and repository management
Posted by Bertrand Rousseau <sb...@gmail.com>.
>> My votes :
>
> Let's turn this in a more formal vote :
>
> Do we agree that we need one "repository" for both apache / non-apache
> plugins ? see http://repository.easyant.org
> [X ] YES
> [ ] NO
>
>
> Then for CI we have two options :
> [ X] Option 1 : Have one CI server to build everything related to easyant
> such as core, examples, plugins (including apache ones and non apache ones)
> [ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
> examples + apache plugins) could use http://builds.apache.org. For the rest
> (plugins non compatible with apache license for example) could use
> http://builds.easyant.org.
>
> Things to take in consideration :
> Easyant is builded with easyant itself, all plugins required to build
> easyant will be fetched from a repository (http://repository.easyant.org ?)
> this applies to both options.
>
> When we release easyant we will create an easyant distribution this includes
> ant + ivy + easyant-core + a set of common plugins for standard case. Like
> for others apache deliverable the good host to make it accessible is
> http://dist.apache.org.
> If we choose Option 1 we will need to keep in mind that the easyant
> distribution deliverable needs to be published on http://dist.apache.org.
>
> Which option do you prefer ?
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter
> http://incubator.apache.org/easyant/<http://incubat.apache.org/easyant/>
Re: [VOTE] Continunuous integration and repository management
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-07-06, Jean-Louis Boudart wrote:
> Let's turn this in a more formal vote :
Personally I don't intend to vote since I feel this is a decision of the
dev community which I certainly am not part of. With my mentor hat on I
can live with either decision and see value in either.
I might be a bit biased in that I think you should focus more on the
part of EasyAnt that are in scope of ASF releases than those that are
out of scope. Then again the not Apache License compatible plugins
could be a major factor for EasyAnt adoption, I don't know.
Stefan
Re: [VOTE] Continunuous integration and repository management
Posted by Siddhartha Purkayastha <kp...@gmail.com>.
My votes:
On 6 July 2011 15:09, Jean-Louis Boudart <je...@gmail.com>wrote:
>
> Do we agree that we need one "repository" for both apache / non-apache
> plugins ? see http://repository.easyant.org
> [ ] YES
> [ ] NO
>
Yes, single repository is convenient.
>
> Then for CI we have two options :
> [ ] Option 1 : Have one CI server to build everything related to easyant
> such as core, examples, plugins (including apache ones and non apache ones)
> [ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
> examples + apache plugins) could use http://builds.apache.org. For the
> rest
> (plugins non compatible with apache license for example) could use
> http://builds.easyant.org.
>
>
Option 2 looks better for me.
Re: [VOTE] Continunuous integration and repository management
Posted by Jean-Louis Boudart <je...@gmail.com>.
My votes:
2011/7/6 Jean-Louis Boudart <je...@gmail.com>
>
> Do we agree that we need one "repository" for both apache / non-apache
> plugins ? see http://repository.easyant.org
> [X] YES
> [ ] NO
>
> Having one repository to give to end users will make configuration more
easier for them. Then we're still able to make a clear separation in
artifactory's internal repository if we want to have one place for official
apache plugins and one other for the rest (including different role to
upload on them).
> Then for CI we have two options :
> [X] Option 1 : Have one CI server to build everything related to easyant
> such as core, examples, plugins (including apache ones and non apache ones)
> [ ] Option 2 : Have two distinct CI server. All Apache stuff (core +
> examples + apache plugins) could use http://builds.apache.org. For the
> rest (plugins non compatible with apache license for example) could use
> http://builds.easyant.org.
>
I'm for Option1 as is always simpler to have everything ine one place. But i
would feel confortable if we choose to have two distinct CI server to be
more closed to what other apache projects do.
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter
http://incubator.apache.org/easyant/<http://incubat.apache.org/easyant/>