> -----Original Message-----
> From: Erskine, Chris [mailto:[EMAIL PROTECTED]
> Sent: 05 January 2005 15:20
> To: Ant Users List
> Subject: RE: Ant should have an ext directory
>
> I do not think that we are saying to use Maven. I am asking for a way
to
> support different versions of third party jars from the same instance
of
> ant. Maven is being used as an example of one way to do it. I do not
> need
> the auto-download functionality of Maven or the automatic repository.
I
> would like to see a way to define in the build file, the list of
dependent
> jars with versions or a relative path to the a needed jar file so I do
not
> have to update the functionality of 30 projects at one time to support
the
> update of a single support jar.
Chris:
You may want to consider something like the Magic antlib [1].
It includes a plugin task that enables the dynamic loading of antlibs
using a versioned plugin descriptor. The descriptor contains logical
identifiers [2] of the complete set of versioned jar files that are
required for tasks and types packaged with the plugin.
For example - the following project definition used the magic antlib
(installed in .ant/lib) polugin task to load a plugin defined by the
artifact uri "artifact:meta:aaa/bbb/my-special-plugin#1.6". This uri
references a plugin descriptor which includes information about all
plugin dependencies, the antlib definition, and namespace binding. A
component helper handles late binding of task classes which ensures that
you can easily reference custom task as shown in the line following the
plugin statement.
<project name="demo" xmlns:magic="antlib:net.dpml.magic">
<magic:plugin uri="artifact:meta:aaa/bbb/my-special-plugin#1.6"/>
<demo xmlns="plugin:aaa/bbb/my-special-plugin"/>
</project>
Task and type dependencies are declared under the plugin descriptor
using artifact uris. Each artifact uri describes a group, name,
artifact type and version. The underlying Transit system [3] provides
support for the automatic retrieval of these jars from local file and/or
remote http or https repositories and the maintenance of a local cache.
The Transit system can be configured with multiple repositories with
different characteristics and the repository configuration can be
maintained locally or centralized.
In addition to the above project based handling of plugins, Magic [4]
also provides a framework for centralized resource management using
module definitions. Each module definition (also referencable as an
artifact) contains the declaration of available resources and the group,
name and version information. This allows the coordination of large
numbers of jar files across complex projects. In addition the resource
declarations include information about build, test and runtime
dependencies (and full support for transitive dependency handling).
Cheers, Stephen.
[1] Magic Antlib
http://www.dpml.net/central/products/magic/antlib/index.html
[2] Artifact URI
http://www.dpml.net/central/products/transit/protocol/index.html
[3] Transit Overview
http://www.dpml.net/central/products/transit/index.html
[4] Magic Overview
http://www.dpml.net/central/products/magic/index.html
>
> Chris Erskine
>
> EDS Consulting Services
> F5-EDS-001
> 2424 Garden of the Gods Rd
> Colorado Springs, CO 80919
>
> Phone: 719-265-5962
>
>
> > -----Original Message-----
> > From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, January 04, 2005 7:16 AM
> > To: 'Ant Users List'
> > Subject: RE: Ant should have an ext directory
> >
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: 04 January 2005 23:26
> > > To: Ant Users List
> > > Subject: Re: Ant should have an ext directory
> > >
> > > "Robert r. Sanders" <[EMAIL PROTECTED]> writes:
> > >
> > > > Yeah, but I don't think this is what the question was about.
> > >
> > > I understood that.
> > >
> > > > It would be nice to have a place to put the (global) ant
> > extensions
> > > > you are using to keep them separate from the main/default ant
> > > > libraries to help with file management, etc... The best I can
> > think
> > > > of: Create an ext directory in a central location, then use a
> > build
> > > > process to merge it with a base ANT install; then copy the
results
> > > > out to everyone in your department. Not as nice as if ANT
> > supported
> > > > this directly, but it might help.
> > >
> > > This is seemingly what Maven offers, was my point. I guess one
could
> > > say ant should offer it, but the impetus of the Maven project is
ant.
> > > Maven (from what I've read and talked to others about) offers a
way to
> > > have a server host all of a project's libraries, with different
> > > versions, and then an xml file describes what libraries they want.
No
> > > sticking the libs in source control for checkout, no shared
folders of
> > > libraries without control over their sources. No worrys of which
> > > versions you might have. Instead, describe your needs in an xml
file
> > > ant let Maven take care of putting them where they should be.
> >
> > However - the maven support for ant is not so up-to-date. From what
I
> > understand Maven does not support the 1.6 series.
> >
> > Stephen.
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
