You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Maarten Coene <ma...@yahoo.com> on 2008/10/15 22:32:38 UTC
Next step in Ivy 2.0 release process
Hi,
Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
- create a new RC2 release containing some (or all) of the bugfixes which have been committed into SVN trunk and maybe some open issues which aren't fixed yet
- create a 2.0.0 final release based on RC1
I'm in favor for a new RC2 containing everything from SVN trunk. What do others think?
Maarten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Next step in Ivy 2.0 release process
Posted by rednix <ze...@gmx.de>.
Maarten Coene wrote:
>
> ...
> I'm in favor for a new RC2 containing everything from SVN trunk. What do
> others think?
>
> Maarten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
+1
--
View this message in context: http://www.nabble.com/Next-step-in-Ivy-2.0-release-process-tp20001770p20029083.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ivy settings classpath always creates new classloader when used
with subant
Posted by Derek Baum <de...@paremus.com>.
Hi Gilles,
I have been unsuccessful in changing my buildscript in order to have the
ivysettings defined only once.
Am I doing something wrong, or should I raise Jira to change the
behaviour of ivysetting/classpath?
Thanks,
Derek
Derek Baum wrote:
> Hi,
>
> Thanks for your response.
>
> Are you suggesting:
>
> 1) if I satisfy the prerequisite, then I won't need my suggested
> patch, or
> 2) my patch will only work if the prerequisite is satisfied?
>
> Assuming 1), I tried this, but when I didn't explicitly load
> ivysettings, a default was loaded instead and the build failed.
>
> Here's my subant target for the example multi-project/build.xml:
>> <target name="publish-all" depends="buildlist"
>> description="compile, jar and publish all projects in the
>> right order">
>> <subant target="publish" buildpathref="build-list">
>> <propertyset>
>> <propertyref name="ivy.loaded" />
>> </propertyset>
>> </subant>
>> </target>
>
> Here's the Ivy taskdef:
>
>> <target name="load-ivy" unless="ivy.loaded">
>> <property name="ivy.loaded" value="true"/>
>> <echo message="Loading Ivy ..."/>
>> <taskdef resource="org/apache/ivy/ant/antlib.xml"
>> uri="antlib:org.apache.ivy.ant"
>> loaderRef="ivyLoader"
>> classpath="${ivy.jar.file}"/>
>> <ivy:settings file="${common.dir}/ivysettings.xml" />
>> </target>
>
> and here's the build output, notice the loading of default settings in
> new-ivy-version:
>
>> [multi-project]$ ant publish-all
>> Buildfile: build.xml
>>
>> load-ivy:
>> [echo] Loading Ivy ...
>>
>> buildlist:
>> [ivy:buildlist] :: Ivy 2.0.0-rc1 - 20080916082609 ::
>> http://ant.apache.org/ivy/ ::
>> :: loading settings :: file =
>> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/common/ivysettings.xml
>>
>>
>> publish-all:
>>
>> clean-build:
>> [delete] Deleting directory
>> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build
>>
>>
>> load-ivy:
>>
>> ivy-new-version:
>> No ivy:settings found for the default reference 'ivy.instance'. A
>> default instance will be used
>> no settings file found, using default...
>> :: loading settings :: url =
>> jar:file:/opt/apache-ivy-2.0.0-rc1/ivy-2.0.0-rc1.jar!/org/apache/ivy/core/settings/ivysettings.xml
>>
>>
>> version:
>> [mkdir] Created dir:
>> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build/classes
>>
>
> I therefore had to change the load-ivy target to always define
> ivysettings:
>
> <target name="load-ivy" depends="ivy-taskdef">
> <ivy:settings file="${common.dir}/ivysettings.xml" />
> </target>
>
> which is why I concluded that a change to the ivysettings/classpath
> command was needed.
>
> Thanks,
>
> Derek
>
>
>
> Gilles Scokart wrote:
>> There will be a prerequisite for that to work : You must be sure that
>> that ivy itself is not loaded in two ClassLoader. For that, your
>> taskdef for ivy should itself use a loaderRef, and the subant must
>> have the right options that make the id shared accross the projects.
>>
>> And if that prerequisite is valid, in most case you can arrange your
>> buildscript in order to have the ivysettings defined only once.
>>
>>
>>
>> 2008/10/16 Derek Baum <de...@paremus.com>:
>>
>>> Hi,
>>>
>>> I have a custom Ivy resolver that keeps a static cache because it is
>>> time-consuming to initialise.
>>>
>>> However, this cache doesn't work in a multi-project build, because the
>>> ivysettings/classpath command is creating a new URLClassLoader for each
>>> subant iteration, so all static class fields are reset.
>>>
>>> <ivysettings>
>>>
>>> <classpath file="${ivy.settings.dir}/sigil-ivy-plugin.jar" />
>>>
>>> <typedef name="sigil"
>>> classname="org.cauldron.bld.ivy.SigilResolver" />
>>>
>>> ...
>>>
>>> </ivysettings>
>>>
>>>
>>> I'm building multiple projects, using ivy:buildlist and subant, as
>>> in the
>>> Ivy multi-project example.
>>>
>>> Each iteration of subant, causes IvySettings to reload.
>>> IvySettings.classloader is thus null and so a new URLClassLoader is
>>> created.
>>>
>>> I temporarily worked around this by loading my plugin at the same
>>> time as
>>> Ivy (i.e. not using settings/classpath), but I'd really like the
>>> setting/classpath method to work too.
>>>
>>> One possible solution would be to add a "loaderRef" attribute to
>>> settings/classpath, similar to the Ant taskdef/typedef tasks, to
>>> make it use
>>> the same ClassLoader.
>>>
>>> Alternatively, IvySettings could simply be changed to only create a new
>>> URLClassLoader if the list of URLs has changed. I attach a simple
>>> patch to
>>> IvySettings.java that does this and seems to work OK.
>>>
>>> If this is valid and useful, let me know and I'll raise it in Jira.
>>>
>>> Thanks,
>>>
>>> Derek
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Index: src/java/org/apache/ivy/core/settings/IvySettings.java
>>> ===================================================================
>>> --- src/java/org/apache/ivy/core/settings/IvySettings.java
>>> (revision
>>> 705243)
>>> +++ src/java/org/apache/ivy/core/settings/IvySettings.java
>>> (working
>>> copy)
>>> @@ -644,13 +644,19 @@
>>> }
>>> }
>>>
>>> + private static Map loaderCache = new HashMap();
>>> +
>>> private ClassLoader getClassLoader() {
>>> if (classloader == null) {
>>> if (classpathURLs.isEmpty()) {
>>> classloader = Ivy.class.getClassLoader();
>>> } else {
>>> - classloader = new URLClassLoader((URL[]) classpathURLs
>>> + classloader = (ClassLoader)
>>> loaderCache.get(classpathURLs);
>>> + if (classloader == null) {
>>> + classloader = new URLClassLoader((URL[])
>>> classpathURLs
>>> .toArray(new URL[classpathURLs.size()]),
>>> Ivy.class.getClassLoader());
>>> + loaderCache.put(classpathURLs, classloader);
>>> + }
>>> }
>>> }
>>> return classloader;
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ivy settings classpath always creates new classloader when used
with subant
Posted by Derek Baum <de...@paremus.com>.
Hi,
Thanks for your response.
Are you suggesting:
1) if I satisfy the prerequisite, then I won't need my suggested patch, or
2) my patch will only work if the prerequisite is satisfied?
Assuming 1), I tried this, but when I didn't explicitly load
ivysettings, a default was loaded instead and the build failed.
Here's my subant target for the example multi-project/build.xml:
> <target name="publish-all" depends="buildlist"
> description="compile, jar and publish all projects in the
> right order">
> <subant target="publish" buildpathref="build-list">
> <propertyset>
> <propertyref name="ivy.loaded" />
> </propertyset>
> </subant>
> </target>
Here's the Ivy taskdef:
> <target name="load-ivy" unless="ivy.loaded">
> <property name="ivy.loaded" value="true"/>
> <echo message="Loading Ivy ..."/>
> <taskdef resource="org/apache/ivy/ant/antlib.xml"
> uri="antlib:org.apache.ivy.ant"
> loaderRef="ivyLoader"
> classpath="${ivy.jar.file}"/>
> <ivy:settings file="${common.dir}/ivysettings.xml" />
> </target>
and here's the build output, notice the loading of default settings in
new-ivy-version:
> [multi-project]$ ant publish-all
> Buildfile: build.xml
>
> load-ivy:
> [echo] Loading Ivy ...
>
> buildlist:
> [ivy:buildlist] :: Ivy 2.0.0-rc1 - 20080916082609 ::
> http://ant.apache.org/ivy/ ::
> :: loading settings :: file =
> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/common/ivysettings.xml
>
> publish-all:
>
> clean-build:
> [delete] Deleting directory
> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build
>
> load-ivy:
>
> ivy-new-version:
> No ivy:settings found for the default reference 'ivy.instance'. A
> default instance will be used
> no settings file found, using default...
> :: loading settings :: url =
> jar:file:/opt/apache-ivy-2.0.0-rc1/ivy-2.0.0-rc1.jar!/org/apache/ivy/core/settings/ivysettings.xml
>
> version:
> [mkdir] Created dir:
> /Volumes/Users/derek/eclipse/Sigil/bld-ivy/test/multi-project/projects/version/build/classes
I therefore had to change the load-ivy target to always define ivysettings:
<target name="load-ivy" depends="ivy-taskdef">
<ivy:settings file="${common.dir}/ivysettings.xml" />
</target>
which is why I concluded that a change to the ivysettings/classpath
command was needed.
Thanks,
Derek
Gilles Scokart wrote:
> There will be a prerequisite for that to work : You must be sure that
> that ivy itself is not loaded in two ClassLoader. For that, your
> taskdef for ivy should itself use a loaderRef, and the subant must
> have the right options that make the id shared accross the projects.
>
> And if that prerequisite is valid, in most case you can arrange your
> buildscript in order to have the ivysettings defined only once.
>
>
>
> 2008/10/16 Derek Baum <de...@paremus.com>:
>
>> Hi,
>>
>> I have a custom Ivy resolver that keeps a static cache because it is
>> time-consuming to initialise.
>>
>> However, this cache doesn't work in a multi-project build, because the
>> ivysettings/classpath command is creating a new URLClassLoader for each
>> subant iteration, so all static class fields are reset.
>>
>> <ivysettings>
>>
>> <classpath file="${ivy.settings.dir}/sigil-ivy-plugin.jar" />
>>
>> <typedef name="sigil" classname="org.cauldron.bld.ivy.SigilResolver" />
>>
>> ...
>>
>> </ivysettings>
>>
>>
>> I'm building multiple projects, using ivy:buildlist and subant, as in the
>> Ivy multi-project example.
>>
>> Each iteration of subant, causes IvySettings to reload.
>> IvySettings.classloader is thus null and so a new URLClassLoader is created.
>>
>> I temporarily worked around this by loading my plugin at the same time as
>> Ivy (i.e. not using settings/classpath), but I'd really like the
>> setting/classpath method to work too.
>>
>> One possible solution would be to add a "loaderRef" attribute to
>> settings/classpath, similar to the Ant taskdef/typedef tasks, to make it use
>> the same ClassLoader.
>>
>> Alternatively, IvySettings could simply be changed to only create a new
>> URLClassLoader if the list of URLs has changed. I attach a simple patch to
>> IvySettings.java that does this and seems to work OK.
>>
>> If this is valid and useful, let me know and I'll raise it in Jira.
>>
>> Thanks,
>>
>> Derek
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Index: src/java/org/apache/ivy/core/settings/IvySettings.java
>> ===================================================================
>> --- src/java/org/apache/ivy/core/settings/IvySettings.java (revision
>> 705243)
>> +++ src/java/org/apache/ivy/core/settings/IvySettings.java (working
>> copy)
>> @@ -644,13 +644,19 @@
>> }
>> }
>>
>> + private static Map loaderCache = new HashMap();
>> +
>> private ClassLoader getClassLoader() {
>> if (classloader == null) {
>> if (classpathURLs.isEmpty()) {
>> classloader = Ivy.class.getClassLoader();
>> } else {
>> - classloader = new URLClassLoader((URL[]) classpathURLs
>> + classloader = (ClassLoader) loaderCache.get(classpathURLs);
>> + if (classloader == null) {
>> + classloader = new URLClassLoader((URL[]) classpathURLs
>> .toArray(new URL[classpathURLs.size()]),
>> Ivy.class.getClassLoader());
>> + loaderCache.put(classpathURLs, classloader);
>> + }
>> }
>> }
>> return classloader;
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ivy settings classpath always creates new classloader when used with subant
Posted by Gilles Scokart <gs...@gmail.com>.
There will be a prerequisite for that to work : You must be sure that
that ivy itself is not loaded in two ClassLoader. For that, your
taskdef for ivy should itself use a loaderRef, and the subant must
have the right options that make the id shared accross the projects.
And if that prerequisite is valid, in most case you can arrange your
buildscript in order to have the ivysettings defined only once.
2008/10/16 Derek Baum <de...@paremus.com>:
> Hi,
>
> I have a custom Ivy resolver that keeps a static cache because it is
> time-consuming to initialise.
>
> However, this cache doesn't work in a multi-project build, because the
> ivysettings/classpath command is creating a new URLClassLoader for each
> subant iteration, so all static class fields are reset.
>
> <ivysettings>
>
> <classpath file="${ivy.settings.dir}/sigil-ivy-plugin.jar" />
>
> <typedef name="sigil" classname="org.cauldron.bld.ivy.SigilResolver" />
>
> ...
>
> </ivysettings>
>
>
> I'm building multiple projects, using ivy:buildlist and subant, as in the
> Ivy multi-project example.
>
> Each iteration of subant, causes IvySettings to reload.
> IvySettings.classloader is thus null and so a new URLClassLoader is created.
>
> I temporarily worked around this by loading my plugin at the same time as
> Ivy (i.e. not using settings/classpath), but I'd really like the
> setting/classpath method to work too.
>
> One possible solution would be to add a "loaderRef" attribute to
> settings/classpath, similar to the Ant taskdef/typedef tasks, to make it use
> the same ClassLoader.
>
> Alternatively, IvySettings could simply be changed to only create a new
> URLClassLoader if the list of URLs has changed. I attach a simple patch to
> IvySettings.java that does this and seems to work OK.
>
> If this is valid and useful, let me know and I'll raise it in Jira.
>
> Thanks,
>
> Derek
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Index: src/java/org/apache/ivy/core/settings/IvySettings.java
> ===================================================================
> --- src/java/org/apache/ivy/core/settings/IvySettings.java (revision
> 705243)
> +++ src/java/org/apache/ivy/core/settings/IvySettings.java (working
> copy)
> @@ -644,13 +644,19 @@
> }
> }
>
> + private static Map loaderCache = new HashMap();
> +
> private ClassLoader getClassLoader() {
> if (classloader == null) {
> if (classpathURLs.isEmpty()) {
> classloader = Ivy.class.getClassLoader();
> } else {
> - classloader = new URLClassLoader((URL[]) classpathURLs
> + classloader = (ClassLoader) loaderCache.get(classpathURLs);
> + if (classloader == null) {
> + classloader = new URLClassLoader((URL[]) classpathURLs
> .toArray(new URL[classpathURLs.size()]),
> Ivy.class.getClassLoader());
> + loaderCache.put(classpathURLs, classloader);
> + }
> }
> }
> return classloader;
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
ivy settings classpath always creates new classloader when used with
subant
Posted by Derek Baum <de...@paremus.com>.
Hi,
I have a custom Ivy resolver that keeps a static cache because it is
time-consuming to initialise.
However, this cache doesn't work in a multi-project build, because the
ivysettings/classpath command is creating a new URLClassLoader for each
subant iteration, so all static class fields are reset.
<ivysettings>
<classpath file="${ivy.settings.dir}/sigil-ivy-plugin.jar" />
<typedef name="sigil" classname="org.cauldron.bld.ivy.SigilResolver" />
...
</ivysettings>
I'm building multiple projects, using ivy:buildlist and subant, as in
the Ivy multi-project example.
Each iteration of subant, causes IvySettings to reload.
IvySettings.classloader is thus null and so a new URLClassLoader is created.
I temporarily worked around this by loading my plugin at the same time
as Ivy (i.e. not using settings/classpath), but I'd really like the
setting/classpath method to work too.
One possible solution would be to add a "loaderRef" attribute to
settings/classpath, similar to the Ant taskdef/typedef tasks, to make it
use the same ClassLoader.
Alternatively, IvySettings could simply be changed to only create a new
URLClassLoader if the list of URLs has changed. I attach a simple patch
to IvySettings.java that does this and seems to work OK.
If this is valid and useful, let me know and I'll raise it in Jira.
Thanks,
Derek
Re: Next step in Ivy 2.0 release process
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Oct 16, 2008 at 10:39 AM, Gilles Scokart <gs...@gmail.com> wrote:
> 2008/10/15 Maarten Coene <ma...@yahoo.com>:
> > Hi,
> >
> > Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
> >
> > - create a new RC2 release containing some (or all) of the bugfixes which
> have been committed into SVN trunk and maybe some open issues which aren't
> fixed yet
> > - create a 2.0.0 final release based on RC1
> >
> > I'm in favor for a new RC2 containing everything from SVN trunk. What do
> others think?
>
> +1. Only bug fixing have been commited to the trunk. And I think
> some justify a second RC.
+1
Xavier
>
>
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: Next step in Ivy 2.0 release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le jeudi 16 octobre 2008, Gilles Scokart a écrit :
> 2008/10/15 Maarten Coene <ma...@yahoo.com>:
> > Hi,
> >
> > Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
> >
> > - create a new RC2 release containing some (or all) of the bugfixes which
> > have been committed into SVN trunk and maybe some open issues which
> > aren't fixed yet - create a 2.0.0 final release based on RC1
> >
> > I'm in favor for a new RC2 containing everything from SVN trunk. What do
> > others think?
>
> +1. Only bug fixing have been commited to the trunk. And I think
> some justify a second RC.
+1
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Next step in Ivy 2.0 release process
Posted by Gilles Scokart <gs...@gmail.com>.
2008/10/15 Maarten Coene <ma...@yahoo.com>:
> Hi,
>
> Ivy-2.0.0-RC1 is out for some time now. What will be the next step?
>
> - create a new RC2 release containing some (or all) of the bugfixes which have been committed into SVN trunk and maybe some open issues which aren't fixed yet
> - create a 2.0.0 final release based on RC1
>
> I'm in favor for a new RC2 containing everything from SVN trunk. What do others think?
+1. Only bug fixing have been commited to the trunk. And I think
some justify a second RC.
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org