You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jason Trump <Ja...@mantis-tgi.com> on 2008/01/04 22:15:42 UTC
On-server ivy settings?
New feature suggestion (obviously not for 2.0): allow some kind of optional ivy settings file on the ivy repository. This would allow for less configuration on the ivy client side, and make it easier to update the structure of your ivy repository. Things that could go in this file:
* artifact and ivy patterns for the repository
* repository-sensitive cache hints like changingPattern and changingMatcher
* pointers to other repositories where artifacts are stored (so that client doesn't have to know about these)
* lists of mirror or backup servers to improve availability
though maybe the last one is better handled in custom repository implementations. The client config would then look something like:
<ivysettings>
...
<resolvers>
<url settings="/server/path/to/ivysettings.xml"/>
</resolvers>
</ivysettings>
I know that you can do similar things with a remote ivysettings.xml file, but I liked the idea of putting information about the ivy repository in the repository itself. What do you think? Is it worth mentioning in a JIRA issue?
jason
________________________________
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Fri 1/4/2008 7:24 AM
To: dev@ant.apache.org
Subject: Consolidate cache related settings
On Dec 28, 2007 1:29 AM, Xavier Hanin <xa...@gmail.com> wrote:
> One thing I'd still like to change in this area besides the fix and
> improvement in flexibility is to make repository cache managers responsible
> for managing the useOrigin flag. It would be much more consistent IMO, and
> also more flexible, allowing to use one cache manager for one resolver with
> useOrigin=true, and another cache manager for another resolver with
> useOrigin=false.
>
> This would mean removing useOrigin flag from the tasks, and adding it to
> the cache settings (which will have to be improved to allow per resolver
> cache manager). Since this would be a task backward incompatibility (which
> we tend to avoid to ease 2.0 migration), I'd actually keep the useOrigin
> attribute on the related tasks, but deprecate it, and only set a property
> from the value set on the attribute. Then this property would be used as
> default value for the useOrigin flag on the default repository cache manager
> (used by all resolvers unless they specify another repository cache
> manager).
After more work on the cache management, I see other settings which
currently belongs to dependency resolvers and would better go in cache
manager IMO:
- check modified
- changing pattern and changing matcher
Indeed these settings are used to know if a module metadata or artifacts can
change, and this is useful only for caching purpose. So instead of putting
these settings on the resolvers, I think moving them to cache manager would
be more consistent. As for the useOrigin, we should still try to be backward
compatible. We could say that the default values for check modified and
changing patterns and matchers in a cache manager may depend on the context
in which they are being used (in other words let the dependency resolver
override the default when calling the cache manager).
Any objection?
Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: On-server ivy settings?
Posted by Jason Trump <Ja...@mantis-tgi.com>.
created issue 695 to cover further developments on the topic:
http://issues.apache.org/jira/browse/IVY-695
-jt
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Sun 1/6/2008 3:11 AM
To: Ant Developers List
Subject: Re: On-server ivy settings?
On Jan 5, 2008 11:29 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
> yeah, I think that using the resolver itself to retrieve the settings is
> elegant. another advantage is that the settings can be stored in the cache,
> so that building completely from cache remains possible with a remote
> settings file. offline builds are very important to the build system that I
> work in, because we have a lot of remote developers who don't have VPN
> access to our servers 100% of the time.
It makes sense. But to use the cache to store the settings you need to know
which cache to use, and to know which cache to use you need to configure the
resolver. Not really possible. So we'd need to use another cache for that
(probably the default cache), which means that could be achieved also for
the include directive. So the differences I see with current include feature
is:
1) allow to use any resolver mechanism to get the settings, instead of just
file and urls.
2) use cache mechanism for settings file
3) syntax
If I think about it more, you can implement something for #1 and #2 with
current Ivy implementation:
- create a bootstrap settings file, defining a resolver used only to load
the actual settings
<ivysettings>
<resolvers>
<url name="bootstrap" >
<ivy pattern="http://server/path/to/ivy-[revision].xml" />
<artifact pattern="
http://server/path/to/ivysettings-[revision].xml" />
</url>
</resolvers>
</ivysettings>
- the ivy-[revision].xml is a simple Ivy file for a module called
myorg#bootstrap, declaring one artifact publication, ivysettings.xml
- load these settings and resolve myorg#bootstrap;1.0 -> this will download
the ivysettings.xml, using cache mechanism to avoid the download if not
required
- load or include the downloaded settings to setup the real resolver to use
So I see the feature you suggest as a kind of pre packaged way to easily do
this without worrying about the different steps, and without the need to put
an ivy file for the settings "module". Shouldn't be that hard to implement
since every single piece of the puzzle already exists.
> also, I think that it makes sense to keep the resolver artifacts and a
> file that describes where the artifacts are stored "in the same place".
> kind of like the use of annotations or xdoclet to store information about
> java methods near the methods, so that if you update one, you are more
> likely to update the other.
Agreed.
I guess you can open an issue in JIRA, with a link to this conversation.
Xavier
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Fri 1/4/2008 5:00 PM
> To: Ant Developers List
> Subject: Re: On-server ivy settings?
>
> On Jan 4, 2008 10:15 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
>
> > New feature suggestion (obviously not for 2.0): allow some kind of
> > optional ivy settings file on the ivy repository. This would allow for
> less
> > configuration on the ivy client side, and make it easier to update the
> > structure of your ivy repository. Things that could go in this file:
> >
> > * artifact and ivy patterns for the repository
> > * repository-sensitive cache hints like changingPattern and
> > changingMatcher
> > * pointers to other repositories where artifacts are stored (so that
> > client doesn't have to know about these)
> > * lists of mirror or backup servers to improve availability
> >
> > though maybe the last one is better handled in custom repository
> > implementations. The client config would then look something like:
> >
> > <ivysettings>
> > ...
> > <resolvers>
> > <url settings="/server/path/to/ivysettings.xml"/>
> > </resolvers>
> > </ivysettings>
> >
> > I know that you can do similar things with a remote ivysettings.xmlfile,
> > but I liked the idea of putting information about the ivy repository in
> the
> > repository itself. What do you think? Is it worth mentioning in a JIRA
> > issue?
>
> I like the idea (I actually already thought about promoting this before)
> but I see only slight difference with the settings include mechanism. Or
> maybe you would like to use the provisionning mechanism of the resolver to
> fetch the settings (indlue only works with url and files, while we have
> resolvers for scp or other protocols). Is it what you are thinking about?
> Or
> is it just syntactic sugar above the include mechanism?
>
> Xavier
>
>
> >
> >
> > jason
> >
> > ________________________________
> >
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Fri 1/4/2008 7:24 AM
> > To: dev@ant.apache.org
> > Subject: Consolidate cache related settings
> >
> >
> >
> > On Dec 28, 2007 1:29 AM, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > > One thing I'd still like to change in this area besides the fix and
> > > improvement in flexibility is to make repository cache managers
> > responsible
> > > for managing the useOrigin flag. It would be much more consistent IMO,
> > and
> > > also more flexible, allowing to use one cache manager for one resolver
> > with
> > > useOrigin=true, and another cache manager for another resolver with
> > > useOrigin=false.
> > >
> > > This would mean removing useOrigin flag from the tasks, and adding it
> to
> > > the cache settings (which will have to be improved to allow per
> resolver
> > > cache manager). Since this would be a task backward incompatibility
> > (which
> > > we tend to avoid to ease 2.0 migration), I'd actually keep the
> useOrigin
> > > attribute on the related tasks, but deprecate it, and only set a
> > property
> > > from the value set on the attribute. Then this property would be used
> as
> > > default value for the useOrigin flag on the default repository cache
> > manager
> > > (used by all resolvers unless they specify another repository cache
> > > manager).
> >
> >
> > After more work on the cache management, I see other settings which
> > currently belongs to dependency resolvers and would better go in cache
> > manager IMO:
> > - check modified
> > - changing pattern and changing matcher
> >
> > Indeed these settings are used to know if a module metadata or artifacts
> > can
> > change, and this is useful only for caching purpose. So instead of
> putting
> > these settings on the resolvers, I think moving them to cache manager
> > would
> > be more consistent. As for the useOrigin, we should still try to be
> > backward
> > compatible. We could say that the default values for check modified and
> > changing patterns and matchers in a cache manager may depend on the
> > context
> > in which they are being used (in other words let the dependency resolver
> > override the default when calling the cache manager).
> >
> > Any objection?
> >
> > Xavier
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: On-server ivy settings?
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 5, 2008 11:29 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
> yeah, I think that using the resolver itself to retrieve the settings is
> elegant. another advantage is that the settings can be stored in the cache,
> so that building completely from cache remains possible with a remote
> settings file. offline builds are very important to the build system that I
> work in, because we have a lot of remote developers who don't have VPN
> access to our servers 100% of the time.
It makes sense. But to use the cache to store the settings you need to know
which cache to use, and to know which cache to use you need to configure the
resolver. Not really possible. So we'd need to use another cache for that
(probably the default cache), which means that could be achieved also for
the include directive. So the differences I see with current include feature
is:
1) allow to use any resolver mechanism to get the settings, instead of just
file and urls.
2) use cache mechanism for settings file
3) syntax
If I think about it more, you can implement something for #1 and #2 with
current Ivy implementation:
- create a bootstrap settings file, defining a resolver used only to load
the actual settings
<ivysettings>
<resolvers>
<url name="bootstrap" >
<ivy pattern="http://server/path/to/ivy-[revision].xml" />
<artifact pattern="
http://server/path/to/ivysettings-[revision].xml" />
</url>
</resolvers>
</ivysettings>
- the ivy-[revision].xml is a simple Ivy file for a module called
myorg#bootstrap, declaring one artifact publication, ivysettings.xml
- load these settings and resolve myorg#bootstrap;1.0 -> this will download
the ivysettings.xml, using cache mechanism to avoid the download if not
required
- load or include the downloaded settings to setup the real resolver to use
So I see the feature you suggest as a kind of pre packaged way to easily do
this without worrying about the different steps, and without the need to put
an ivy file for the settings "module". Shouldn't be that hard to implement
since every single piece of the puzzle already exists.
> also, I think that it makes sense to keep the resolver artifacts and a
> file that describes where the artifacts are stored "in the same place".
> kind of like the use of annotations or xdoclet to store information about
> java methods near the methods, so that if you update one, you are more
> likely to update the other.
Agreed.
I guess you can open an issue in JIRA, with a link to this conversation.
Xavier
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Fri 1/4/2008 5:00 PM
> To: Ant Developers List
> Subject: Re: On-server ivy settings?
>
> On Jan 4, 2008 10:15 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
>
> > New feature suggestion (obviously not for 2.0): allow some kind of
> > optional ivy settings file on the ivy repository. This would allow for
> less
> > configuration on the ivy client side, and make it easier to update the
> > structure of your ivy repository. Things that could go in this file:
> >
> > * artifact and ivy patterns for the repository
> > * repository-sensitive cache hints like changingPattern and
> > changingMatcher
> > * pointers to other repositories where artifacts are stored (so that
> > client doesn't have to know about these)
> > * lists of mirror or backup servers to improve availability
> >
> > though maybe the last one is better handled in custom repository
> > implementations. The client config would then look something like:
> >
> > <ivysettings>
> > ...
> > <resolvers>
> > <url settings="/server/path/to/ivysettings.xml"/>
> > </resolvers>
> > </ivysettings>
> >
> > I know that you can do similar things with a remote ivysettings.xmlfile,
> > but I liked the idea of putting information about the ivy repository in
> the
> > repository itself. What do you think? Is it worth mentioning in a JIRA
> > issue?
>
> I like the idea (I actually already thought about promoting this before)
> but I see only slight difference with the settings include mechanism. Or
> maybe you would like to use the provisionning mechanism of the resolver to
> fetch the settings (indlue only works with url and files, while we have
> resolvers for scp or other protocols). Is it what you are thinking about?
> Or
> is it just syntactic sugar above the include mechanism?
>
> Xavier
>
>
> >
> >
> > jason
> >
> > ________________________________
> >
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Fri 1/4/2008 7:24 AM
> > To: dev@ant.apache.org
> > Subject: Consolidate cache related settings
> >
> >
> >
> > On Dec 28, 2007 1:29 AM, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > > One thing I'd still like to change in this area besides the fix and
> > > improvement in flexibility is to make repository cache managers
> > responsible
> > > for managing the useOrigin flag. It would be much more consistent IMO,
> > and
> > > also more flexible, allowing to use one cache manager for one resolver
> > with
> > > useOrigin=true, and another cache manager for another resolver with
> > > useOrigin=false.
> > >
> > > This would mean removing useOrigin flag from the tasks, and adding it
> to
> > > the cache settings (which will have to be improved to allow per
> resolver
> > > cache manager). Since this would be a task backward incompatibility
> > (which
> > > we tend to avoid to ease 2.0 migration), I'd actually keep the
> useOrigin
> > > attribute on the related tasks, but deprecate it, and only set a
> > property
> > > from the value set on the attribute. Then this property would be used
> as
> > > default value for the useOrigin flag on the default repository cache
> > manager
> > > (used by all resolvers unless they specify another repository cache
> > > manager).
> >
> >
> > After more work on the cache management, I see other settings which
> > currently belongs to dependency resolvers and would better go in cache
> > manager IMO:
> > - check modified
> > - changing pattern and changing matcher
> >
> > Indeed these settings are used to know if a module metadata or artifacts
> > can
> > change, and this is useful only for caching purpose. So instead of
> putting
> > these settings on the resolvers, I think moving them to cache manager
> > would
> > be more consistent. As for the useOrigin, we should still try to be
> > backward
> > compatible. We could say that the default values for check modified and
> > changing patterns and matchers in a cache manager may depend on the
> > context
> > in which they are being used (in other words let the dependency resolver
> > override the default when calling the cache manager).
> >
> > Any objection?
> >
> > Xavier
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: On-server ivy settings?
Posted by Jason Trump <Ja...@mantis-tgi.com>.
yeah, I think that using the resolver itself to retrieve the settings is elegant. another advantage is that the settings can be stored in the cache, so that building completely from cache remains possible with a remote settings file. offline builds are very important to the build system that I work in, because we have a lot of remote developers who don't have VPN access to our servers 100% of the time.
also, I think that it makes sense to keep the resolver artifacts and a file that describes where the artifacts are stored "in the same place". kind of like the use of annotations or xdoclet to store information about java methods near the methods, so that if you update one, you are more likely to update the other.
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Fri 1/4/2008 5:00 PM
To: Ant Developers List
Subject: Re: On-server ivy settings?
On Jan 4, 2008 10:15 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
> New feature suggestion (obviously not for 2.0): allow some kind of
> optional ivy settings file on the ivy repository. This would allow for less
> configuration on the ivy client side, and make it easier to update the
> structure of your ivy repository. Things that could go in this file:
>
> * artifact and ivy patterns for the repository
> * repository-sensitive cache hints like changingPattern and
> changingMatcher
> * pointers to other repositories where artifacts are stored (so that
> client doesn't have to know about these)
> * lists of mirror or backup servers to improve availability
>
> though maybe the last one is better handled in custom repository
> implementations. The client config would then look something like:
>
> <ivysettings>
> ...
> <resolvers>
> <url settings="/server/path/to/ivysettings.xml"/>
> </resolvers>
> </ivysettings>
>
> I know that you can do similar things with a remote ivysettings.xml file,
> but I liked the idea of putting information about the ivy repository in the
> repository itself. What do you think? Is it worth mentioning in a JIRA
> issue?
I like the idea (I actually already thought about promoting this before)
but I see only slight difference with the settings include mechanism. Or
maybe you would like to use the provisionning mechanism of the resolver to
fetch the settings (indlue only works with url and files, while we have
resolvers for scp or other protocols). Is it what you are thinking about? Or
is it just syntactic sugar above the include mechanism?
Xavier
>
>
> jason
>
> ________________________________
>
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Fri 1/4/2008 7:24 AM
> To: dev@ant.apache.org
> Subject: Consolidate cache related settings
>
>
>
> On Dec 28, 2007 1:29 AM, Xavier Hanin <xa...@gmail.com> wrote:
>
> > One thing I'd still like to change in this area besides the fix and
> > improvement in flexibility is to make repository cache managers
> responsible
> > for managing the useOrigin flag. It would be much more consistent IMO,
> and
> > also more flexible, allowing to use one cache manager for one resolver
> with
> > useOrigin=true, and another cache manager for another resolver with
> > useOrigin=false.
> >
> > This would mean removing useOrigin flag from the tasks, and adding it to
> > the cache settings (which will have to be improved to allow per resolver
> > cache manager). Since this would be a task backward incompatibility
> (which
> > we tend to avoid to ease 2.0 migration), I'd actually keep the useOrigin
> > attribute on the related tasks, but deprecate it, and only set a
> property
> > from the value set on the attribute. Then this property would be used as
> > default value for the useOrigin flag on the default repository cache
> manager
> > (used by all resolvers unless they specify another repository cache
> > manager).
>
>
> After more work on the cache management, I see other settings which
> currently belongs to dependency resolvers and would better go in cache
> manager IMO:
> - check modified
> - changing pattern and changing matcher
>
> Indeed these settings are used to know if a module metadata or artifacts
> can
> change, and this is useful only for caching purpose. So instead of putting
> these settings on the resolvers, I think moving them to cache manager
> would
> be more consistent. As for the useOrigin, we should still try to be
> backward
> compatible. We could say that the default values for check modified and
> changing patterns and matchers in a cache manager may depend on the
> context
> in which they are being used (in other words let the dependency resolver
> override the default when calling the cache manager).
>
> Any objection?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: On-server ivy settings?
Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 4, 2008 10:15 PM, Jason Trump <Ja...@mantis-tgi.com> wrote:
> New feature suggestion (obviously not for 2.0): allow some kind of
> optional ivy settings file on the ivy repository. This would allow for less
> configuration on the ivy client side, and make it easier to update the
> structure of your ivy repository. Things that could go in this file:
>
> * artifact and ivy patterns for the repository
> * repository-sensitive cache hints like changingPattern and
> changingMatcher
> * pointers to other repositories where artifacts are stored (so that
> client doesn't have to know about these)
> * lists of mirror or backup servers to improve availability
>
> though maybe the last one is better handled in custom repository
> implementations. The client config would then look something like:
>
> <ivysettings>
> ...
> <resolvers>
> <url settings="/server/path/to/ivysettings.xml"/>
> </resolvers>
> </ivysettings>
>
> I know that you can do similar things with a remote ivysettings.xml file,
> but I liked the idea of putting information about the ivy repository in the
> repository itself. What do you think? Is it worth mentioning in a JIRA
> issue?
I like the idea (I actually already thought about promoting this before)
but I see only slight difference with the settings include mechanism. Or
maybe you would like to use the provisionning mechanism of the resolver to
fetch the settings (indlue only works with url and files, while we have
resolvers for scp or other protocols). Is it what you are thinking about? Or
is it just syntactic sugar above the include mechanism?
Xavier
>
>
> jason
>
> ________________________________
>
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Fri 1/4/2008 7:24 AM
> To: dev@ant.apache.org
> Subject: Consolidate cache related settings
>
>
>
> On Dec 28, 2007 1:29 AM, Xavier Hanin <xa...@gmail.com> wrote:
>
> > One thing I'd still like to change in this area besides the fix and
> > improvement in flexibility is to make repository cache managers
> responsible
> > for managing the useOrigin flag. It would be much more consistent IMO,
> and
> > also more flexible, allowing to use one cache manager for one resolver
> with
> > useOrigin=true, and another cache manager for another resolver with
> > useOrigin=false.
> >
> > This would mean removing useOrigin flag from the tasks, and adding it to
> > the cache settings (which will have to be improved to allow per resolver
> > cache manager). Since this would be a task backward incompatibility
> (which
> > we tend to avoid to ease 2.0 migration), I'd actually keep the useOrigin
> > attribute on the related tasks, but deprecate it, and only set a
> property
> > from the value set on the attribute. Then this property would be used as
> > default value for the useOrigin flag on the default repository cache
> manager
> > (used by all resolvers unless they specify another repository cache
> > manager).
>
>
> After more work on the cache management, I see other settings which
> currently belongs to dependency resolvers and would better go in cache
> manager IMO:
> - check modified
> - changing pattern and changing matcher
>
> Indeed these settings are used to know if a module metadata or artifacts
> can
> change, and this is useful only for caching purpose. So instead of putting
> these settings on the resolvers, I think moving them to cache manager
> would
> be more consistent. As for the useOrigin, we should still try to be
> backward
> compatible. We could say that the default values for check modified and
> changing patterns and matchers in a cache manager may depend on the
> context
> in which they are being used (in other words let the dependency resolver
> override the default when calling the cache manager).
>
> Any objection?
>
> Xavier
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/