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 Nicolas Lalevée <ni...@hibnet.org> on 2011/11/12 14:36:47 UTC
Re: Easyant bootstrap doesn't build
I have fixed the bootstrap build. Unless somebody objects, I'll setup a build job on the Jenkins hosted at the ASF and get build failure sent to easyant-notification@.
So for the bootstrap build, there is a specific ivysettings because we need to compute a classpath to compile and just that. We cannot have an ivysettings which is referencing some repository in easyant's classpath, since easyant isn't yet build. Once compiled and jared, easyant is launched and then the ivysettings used is the nominal one. Note that there is an ivysettings-bootstrap.xml just because we're using Ivy trunk. Once Ivy 2.3 will be released, it could just rely on Ivy's default settings which is just referencing maven central.
Nicolas
Le 27 sept. 2011 à 11:49, Jean-Louis Boudart a écrit :
> Hum good catch, commons-cli was retrieved from my cache.
>
> This raise the question : Should we have two different ivysettings, one for
> easyant boostrap / build, and a second one shipped in easyant distribution
> and used end user ?
>
> Supposing we have the following chain of resollution in ivysettings.xml :
>
> - a localrepository (~/.easyant/repository by default)
> - an embedded resolver (using the new implementation of jar resolver)
> - an online repository accessible through http accessible at
> repository.easyant.org
> - an http resolver using maven central repository (if we decide to not
> use repository.easyant.org as a proxy of other online maven repository)
>
> We'll probably use artifactory as a repository manager on
> repository.easyant.org to host all our stuff (plugins, buildtypes, tasks,
> skeletons). Artifactory can acts as a proxy of other online repository see
> http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositories for
> further details.
>
> Here is how i imagine things :
>
> - Plugins, buildtypes, and additionnal tasks are published on
> repository.easyant.org. This includes both Apache and non Apache plugins
> (i guess those not compatible with Apache policy such as checkstyle, sonar
> etc....)
> - Easyant is built with easyant. When building easyant itself we use the
> *same* ivysettings as the one used by default by end users (the one
> described above).
> - Nothing will be found in local repository
> - embedded resolver will probably be empty as were in bootstrap mode
> - it will fetch plugins from our online repository
> repository.easyant.org
> - How could we build the embedded repository ? We will probably ship one
> or many version of "core plugins" in easyant distribution as plugins can be
> updated but still be compatible with easyant-core. How could we maintain
> this ?
> - We could use <ivy:install> ant task to copy explicit version of core
> plugins from our official repository (repository.easyant.org) to a
> filesystem structure that will be shipped in the jar. This can
> be done as
> an intial step when creating easyant distribution.
>
> If we use this flow we could use the same ivysettings as the one shipped by
> default in easyant distribution and leverage maintenance of this file.
>
> Any feedback would be really appreciated.
>
>
> Le 26 septembre 2011 10:12, Nicolas Lalevée <ni...@hibnet.org> a
> écrit :
>
>>
>> Le 25 sept. 2011 à 22:41, Jean-Louis Boudart a écrit :
>>
>>> On my computer, commons-cli is retrived from maven central repo. When you
>>> tried the bootstrap build did you have access to internet ?
>>
>> In the bootstrap build (with ant, with the build.xml), it is hard coded to
>> use repository/third-party-lib/third-party-ivysettings.xml. And it doesn't
>> reference maven. So I guess it is wrong ?
>>
>> Nicolas
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Easyant bootstrap doesn't build
Posted by Jean-Louis Boudart <je...@gmail.com>.
Le 12 novembre 2011 15:36, Nicolas Lalevée <ni...@hibnet.org> a
écrit :
> I have fixed the bootstrap build. Unless somebody objects, I'll setup a
> build job on the Jenkins hosted at the ASF and get build failure sent to
> easyant-notification@.
>
Great. As it was already discussed before, easyant-core and all apache
plugins will be build from Jenkins hosted at ASF, so no objection for me.
> So for the bootstrap build, there is a specific ivysettings because we
> need to compute a classpath to compile and just that. We cannot have an
> ivysettings which is referencing some repository in easyant's classpath,
> since easyant isn't yet build. Once compiled and jared, easyant is launched
> and then the ivysettings used is the nominal one. Note that there is an
> ivysettings-bootstrap.xml just because we're using Ivy trunk. Once Ivy 2.3
> will be released, it could just rely on Ivy's default settings which is
> just referencing maven central.
>
Make sense! I hadn't thought about how ivy can react with non existing
repository in easyant's classpath.
>
> Nicolas
>
> Le 27 sept. 2011 à 11:49, Jean-Louis Boudart a écrit :
>
> > Hum good catch, commons-cli was retrieved from my cache.
> >
> > This raise the question : Should we have two different ivysettings, one
> for
> > easyant boostrap / build, and a second one shipped in easyant
> distribution
> > and used end user ?
> >
> > Supposing we have the following chain of resollution in ivysettings.xml :
> >
> > - a localrepository (~/.easyant/repository by default)
> > - an embedded resolver (using the new implementation of jar resolver)
> > - an online repository accessible through http accessible at
> > repository.easyant.org
> > - an http resolver using maven central repository (if we decide to not
> > use repository.easyant.org as a proxy of other online maven
> repository)
> >
> > We'll probably use artifactory as a repository manager on
> > repository.easyant.org to host all our stuff (plugins, buildtypes,
> tasks,
> > skeletons). Artifactory can acts as a proxy of other online repository
> see
> > http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositoriesfor
> > further details.
> >
> > Here is how i imagine things :
> >
> > - Plugins, buildtypes, and additionnal tasks are published on
> > repository.easyant.org. This includes both Apache and non Apache
> plugins
> > (i guess those not compatible with Apache policy such as checkstyle,
> sonar
> > etc....)
> > - Easyant is built with easyant. When building easyant itself we use
> the
> > *same* ivysettings as the one used by default by end users (the one
> > described above).
> > - Nothing will be found in local repository
> > - embedded resolver will probably be empty as were in bootstrap mode
> > - it will fetch plugins from our online repository
> > repository.easyant.org
> > - How could we build the embedded repository ? We will probably ship
> one
> > or many version of "core plugins" in easyant distribution as plugins
> can be
> > updated but still be compatible with easyant-core. How could we
> maintain
> > this ?
> > - We could use <ivy:install> ant task to copy explicit version of
> core
> > plugins from our official repository (repository.easyant.org) to a
> > filesystem structure that will be shipped in the jar. This can
> > be done as
> > an intial step when creating easyant distribution.
> >
> > If we use this flow we could use the same ivysettings as the one shipped
> by
> > default in easyant distribution and leverage maintenance of this file.
> >
> > Any feedback would be really appreciated.
> >
> >
> > Le 26 septembre 2011 10:12, Nicolas Lalevée <ni...@hibnet.org>
> a
> > écrit :
> >
> >>
> >> Le 25 sept. 2011 à 22:41, Jean-Louis Boudart a écrit :
> >>
> >>> On my computer, commons-cli is retrived from maven central repo. When
> you
> >>> tried the bootstrap build did you have access to internet ?
> >>
> >> In the bootstrap build (with ant, with the build.xml), it is hard coded
> to
> >> use repository/third-party-lib/third-party-ivysettings.xml. And it
> doesn't
> >> reference maven. So I guess it is wrong ?
> >>
> >> Nicolas
> >>
> >>
> >
> >
> > --
> > Jean Louis Boudart
> > Independent consultant
> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Easyant bootstrap doesn't build
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 12 nov. 2011 à 15:36, Nicolas Lalevée a écrit :
> I have fixed the bootstrap build. Unless somebody objects, I'll setup a build job on the Jenkins hosted at the ASF and get build failure sent to easyant-notification@.
done.
https://builds.apache.org/job/EasyAnt/
Nicolas
>
> So for the bootstrap build, there is a specific ivysettings because we need to compute a classpath to compile and just that. We cannot have an ivysettings which is referencing some repository in easyant's classpath, since easyant isn't yet build. Once compiled and jared, easyant is launched and then the ivysettings used is the nominal one. Note that there is an ivysettings-bootstrap.xml just because we're using Ivy trunk. Once Ivy 2.3 will be released, it could just rely on Ivy's default settings which is just referencing maven central.
>
> Nicolas
>
> Le 27 sept. 2011 à 11:49, Jean-Louis Boudart a écrit :
>
>> Hum good catch, commons-cli was retrieved from my cache.
>>
>> This raise the question : Should we have two different ivysettings, one for
>> easyant boostrap / build, and a second one shipped in easyant distribution
>> and used end user ?
>>
>> Supposing we have the following chain of resollution in ivysettings.xml :
>>
>> - a localrepository (~/.easyant/repository by default)
>> - an embedded resolver (using the new implementation of jar resolver)
>> - an online repository accessible through http accessible at
>> repository.easyant.org
>> - an http resolver using maven central repository (if we decide to not
>> use repository.easyant.org as a proxy of other online maven repository)
>>
>> We'll probably use artifactory as a repository manager on
>> repository.easyant.org to host all our stuff (plugins, buildtypes, tasks,
>> skeletons). Artifactory can acts as a proxy of other online repository see
>> http://wiki.jfrog.org/confluence/display/RTF/Understanding+Repositories for
>> further details.
>>
>> Here is how i imagine things :
>>
>> - Plugins, buildtypes, and additionnal tasks are published on
>> repository.easyant.org. This includes both Apache and non Apache plugins
>> (i guess those not compatible with Apache policy such as checkstyle, sonar
>> etc....)
>> - Easyant is built with easyant. When building easyant itself we use the
>> *same* ivysettings as the one used by default by end users (the one
>> described above).
>> - Nothing will be found in local repository
>> - embedded resolver will probably be empty as were in bootstrap mode
>> - it will fetch plugins from our online repository
>> repository.easyant.org
>> - How could we build the embedded repository ? We will probably ship one
>> or many version of "core plugins" in easyant distribution as plugins can be
>> updated but still be compatible with easyant-core. How could we maintain
>> this ?
>> - We could use <ivy:install> ant task to copy explicit version of core
>> plugins from our official repository (repository.easyant.org) to a
>> filesystem structure that will be shipped in the jar. This can
>> be done as
>> an intial step when creating easyant distribution.
>>
>> If we use this flow we could use the same ivysettings as the one shipped by
>> default in easyant distribution and leverage maintenance of this file.
>>
>> Any feedback would be really appreciated.
>>
>>
>> Le 26 septembre 2011 10:12, Nicolas Lalevée <ni...@hibnet.org> a
>> écrit :
>>
>>>
>>> Le 25 sept. 2011 à 22:41, Jean-Louis Boudart a écrit :
>>>
>>>> On my computer, commons-cli is retrived from maven central repo. When you
>>>> tried the bootstrap build did you have access to internet ?
>>>
>>> In the bootstrap build (with ant, with the build.xml), it is hard coded to
>>> use repository/third-party-lib/third-party-ivysettings.xml. And it doesn't
>>> reference maven. So I guess it is wrong ?
>>>
>>> Nicolas
>>>
>>>
>>
>>
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>