On Sat, Feb 5, 2022, 1:19 AM Stefan Bodewig wrote:
> On 2022-02-04, Matt Benson wrote:
>
> > I am working on a new antlib (discussed a couple of years ago on list),
> and
> > trying to figure out how to get antunit to run tests using Ivy's created
> > classpath.test from the common build
On Sat, 5 Feb 2022 at 08:19, Stefan Bodewig wrote:
> I must admit that I never tried to use things with Ivy at all. When I
> run tests I do so with several -lib arguments (and always need to figure
> out what is required as I don't do it often enough).
>
> If you figured things out it would
On 2022-02-04, Matt Benson wrote:
> I am working on a new antlib (discussed a couple of years ago on list), and
> trying to figure out how to get antunit to run tests using Ivy's created
> classpath.test from the common build framework. I have tried combinations
> of the (hidden) classloader task
Looks like I got it sorted by passing a path reference to Antunit and
executing typedef there.
Matt
On Fri, Feb 4, 2022, 12:07 PM Matt Benson wrote:
> I am working on a new antlib (discussed a couple of years ago on list),
> and trying to figure out how to get antunit to run tests using Ivy's
On 19/12/18 11:29 PM, Stefan Bodewig wrote:
> On 2018-12-18, Jaikiran Pai wrote:
>
>> One option in similar cases that we have employed in other jobs is to
>> configure the Java system property -Dhttps.protocols to "TLSv1.2". But
>> this version of TLS is only supported in a Java release after
On 2018-12-18, Jaikiran Pai wrote:
> One option in similar cases that we have employed in other jobs is to
> configure the Java system property -Dhttps.protocols to "TLSv1.2". But
> this version of TLS is only supported in a Java release after Java 1.5.
I'd be in favor of updating the jobs.
On Tue, 18 Dec 2018 at 10:44, Dominique Devienne
wrote:
> On Tue, Dec 18, 2018 at 9:21 AM Jaikiran Pai wrote:
>
> > [...] 2 jobs[1][2] which are for Antlib SVN and Antunit libraries.
>
> Both these jobs are configure for JDK 5 [...]
> > However, the Maven central repo [...[ has been configured
On Tue, Dec 18, 2018 at 9:21 AM Jaikiran Pai wrote:
> [...] 2 jobs[1][2] which are for Antlib SVN and Antunit libraries.
Both these jobs are configure for JDK 5 [...]
> However, the Maven central repo [...[ has been configured not to let
> clients with
> lower TLS versions (lesser than TLSv1.2)
On 2010-03-31, jan.mate...@rzf.fin-nrw.de wrote:
I found that the Antlib compress requires commons-compress
in version 1.1.
But where to that that?
Build it yourself, sorry I don't have any better idea.
I dont want to build all the transitive dependencies :-O
There shouldn't be any.
On 2010-03-28, Jan Matèrne j...@materne.de wrote:
I found that the Antlib compress requires commons-compress in version 1.1.
Right - and Christian vounteered to release that, so I decided to make
the Antlib's trunk depend on it. The plan is to release the Antlib ASAP
once commons-compress 1.1
I found that the Antlib compress requires commons-compress in version 1.1.
But where to that that? The last release was 1.0 and it is not built in
Hudson or Continuum.
And I cant access the created JAR in Gump
/srv/gump/public/workspace/apache-commons/compress/target/commons-compress-1
This is in the ant manual.
http://ant.apache.org/manual/CoreTypes/antlib.html#currentnamespace
There is a special xml namespace (ant:current) for typedefs defined
within an antlib.
The namespace is only active during the processing of the antlib.
Peter
On Thu, Apr 23, 2009 at 7:53 AM, Gilles
On 10/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
1)
the antlib.xml does not set the onerror attribute, this means
that all the definitions will be loaded when one is loaded,
using onerror=ignore should be used.
(ignore is a bit of a misnomer - it should be deferred, i.e.
the check will be
You can declare multiple taskdefs all
pointing to the same impl. class, or you can declare it once then
use presetdef (I think).
Jeffrey E. (Jeff) Care
[EMAIL PROTECTED]
IBM WebSphere
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 12 Sep 2005, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
1) How about collisions? Well, how about collisions between classes
in the classpath?
Putting antlibs into namespaces was supposed to resolve those
collisions, just
Stefan Bodewig wrote:
On Mon, 12 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote:
I hadnt thought about autoloading; I am happy with explicit loading
of stuff into their own namespaces, but want to make it easier for
projects to get access to my definitions (or even importable
libraries)
--- Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 12 Sep 2005, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
1) How about collisions? Well, how about
collisions between classes
in the classpath?
Putting antlibs
Matt Benson wrote:
:) Jose Alberto, it seems that you and I have each
contradicted ourselves during this discussion. On
issue (1) above, regarding collisions, your approach
is to assume the user knows exactly what he/she is
doing: e.g. the name of every task provided with every
third-party
From: Matt Benson [mailto:[EMAIL PROTECTED]
--- Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 12 Sep 2005, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
1) How about collisions? Well, how about
collisions
On Tue, 13 Sep 2005, Matt Benson [EMAIL PROTECTED] wrote:
:) Jose Alberto, it seems that you and I have each
contradicted ourselves during this discussion.
Me too.
On issue (1) above, regarding collisions,
I think Steve's argument about IDEs putting stuff into the CLASSPATH
is an important
On Tue, 13 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote:
I would assume that tools like websphere or the IDE are happily
sticking stuff in on the classpath, and that anything more we can do
for diagnostics helps
Sounds good.
Stefan
On Tue, 13 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote:
xmlns:foo=antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver;
this scaers me, as people will assume that we are doing a
download...
Of the descriptor. Why not? OK, they might expect we download the
lib itself as
Jeffrey E Care wrote:
I don't normally speak up on the developer list, but I thought this
discussion could benefit from the experience of a *very large* product
that uses Ant to build.
We use Ant + our own extensions (Mantis) to build WebSphere Application
Server (and a good number of the
simple, and all integrated.
Comments,
Jose Alberto
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 09 September 2005 22:57
To: Ant Developers List
Subject: Re: Antlib autoloading (was Re: cvs commit:
ant/src/testcases/org/apache/tools/ant/taskdefs
On Mon, 12 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote:
I hadnt thought about autoloading; I am happy with explicit loading
of stuff into their own namespaces, but want to make it easier for
projects to get access to my definitions (or even importable
libraries)
How do you like this
On Mon, 12 Sep 2005, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
1) How about collisions? Well, how about collisions between classes
in the classpath?
Putting antlibs into namespaces was supposed to resolve those
collisions, just like namesspaces in C++.
How about loading a task that
I don't normally speak up on the developer list, but I thought this
discussion could benefit from the experience of a *very large* product
that uses Ant to build.
We use Ant + our own extensions (Mantis) to build WebSphere Application
Server (and a good number of the stack products as well).
On Fri, 9 Sep 2005, Dominique Devienne [EMAIL PROTECTED] wrote:
On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
So, any ideas how this could be acomplished?
Load all resources from META-INF/antlib.xml at startup and process
them, I'd say.
But doesn't that go against Ant's tradition to
On Tue, 23 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote:
One change I have also checked in to Definer.java is some extra
logic for naming antlibs. Instead of just
antlib:org.example.package
you can go
antlib://org/example/package/file.xml
I don't like that antlib would
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On Fri, 26 Aug 2005, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Now, for backward compatibility and for
convinience in general, one
would like to be able to put in the -lib
directories a bunch of
antlib jars and that all their tasks
On Fri, 9 Sep 2005, Matt Benson [EMAIL PROTECTED] wrote:
Load all resources from META-INF/antlib.xml at startup and process
them, I'd say.
Sounds cool, but what do you do about e.g. collisions
among tasknames from 3rd-party distributions?
It was Jose Alberto who wanted them in the default
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On Fri, 9 Sep 2005, Matt Benson
[EMAIL PROTECTED] wrote:
Load all resources from META-INF/antlib.xml at
startup and process
them, I'd say.
Sounds cool, but what do you do about e.g.
collisions
among tasknames from 3rd-party
On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
So, any ideas how this could be acomplished?
Load all resources from META-INF/antlib.xml at startup and process
them, I'd say.
But doesn't that go against Ant's tradition to not have auto-magic
things, but instead spell things out explicitly,
I was thinking of having another attribute (like
antlib=antlib:org.smartfrog.tools.ant)
to set the uri and resource.
It may be a good idea however to do this by default with just the uri
attribute - if the user has not
specified the resource/filename.
Peter
Steve Loughran wrote:
Why do
From: Steve Loughran [mailto:[EMAIL PROTECTED]
One change I have also checked in to Definer.java is some extra logic
for naming antlibs. Instead of just
antlib:org.example.package
you can go
antlib://org/example/package/file.xml
and have that file's declarations read in.
Dominique Devienne wrote:
From: Steve Loughran [mailto:[EMAIL PROTECTED]
One change I have also checked in to Definer.java is some extra logic
for naming antlibs. Instead of just
antlib:org.example.package
you can go
antlib://org/example/package/file.xml
and have that file's
Stefan Bodewig wrote:
On Mon, 22 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote:
Why do you have to repeat the full path to an antlib in typedef,
when declaring into an antlib url.
antlib descriptor, you mean?
If so, I agree with you, we should magically provide a default for the
On Mon, 22 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote:
Why do you have to repeat the full path to an antlib in typedef,
when declaring into an antlib url.
antlib descriptor, you mean?
If so, I agree with you, we should magically provide a default for the
resource attribute if uri has
We could use org.apache.ant.kernel :-)
Isn't it the same thing?
JA
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 20 April 2005 16:24
To: Ant Developers List
Subject: RE: Antlib package names
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED
Developers List
Cc:
Subject:RE: Antlib package names
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
We shouldnt plan the name only for the svn-package.
Thats a general question for future extensions.
Von: Peter Reilly [mailto:[EMAIL PROTECTED]
Perhaps it could be just
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
We shouldnt plan the name only for the svn-package.
That´s a general question for future extensions.
Von: Peter Reilly [mailto:[EMAIL PROTECTED]
Perhaps it could be just org.apache.ant.svn - i.e. drop antlibs.
Actually, Peter might have
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
cheektongueUse of core as a package/directory name is mildly off
in
a UNIX environment as the directory might be confused with a core
dump!
;n)/tongue/cheek
Phil :n)
It would be a directory instead of a file though, so it wouldn't be
Dominique Devienne wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the
newer antunit I've used org.apache.ant.antlibs.antunit.
I'd like to drop the tools for antlibs and I think antlibs should be
somewhere in the package
wrote:
We could use org.apache.ant.kernel :-)
Isn't it the same thing?
JA
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: 20 April 2005 16:24
To: Ant Developers List
Subject: RE: Antlib package names
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED
From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
I also like core best, but maybe it isn't such a good idea indeed.
Let's just forget about org.apache.ant.core... --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the
newer antunit I've used org.apache.ant.antlibs.antunit.
I'd like to drop the tools for antlibs and I think antlibs should be
somewhere in the package names, so I'd turn
Dominique Devienne wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the
newer antunit I've used org.apache.ant.antlibs.antunit.
I'd like to drop the tools for antlibs and I think antlibs should be
somewhere in the package
Jose Alberto Fernandez wrote:
As the URI protocol antlib: provides a shortcut for the typedef/
above, I am just thinking on providing something similar for the
classpath declaration when needed.
classpath id=foo.bar./classpath
I have been doing a little thinking about this.
What about a
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
As the URI protocol antlib: provides a shortcut for the typedef/
above, I am just thinking on providing something similar for the
classpath declaration when needed.
classpath id=foo.bar./classpath
with its own
set of third party libraries.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 03 April 2004 00:02
To: Ant Developers List
Subject: RE: antlib and classloaders
So what's to say that we can't build up an ANTLIB_PATH just
like we build up
How about just supporting an equivalent of an LD_LIBRARY_PATH for antlibs,
called ANTLIB_PATH or some such?
didge
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 1:58 PM
To: Ant Developers List
Subject: Re: antlib and classloaders
I'm
to provide an in-buildfile alternative.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 01:16
To: Ant Developers List
Subject: RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH
for antlibs
Mariano's original question was why
was classpath ignored in an antlib definition.
antlib
typedef name=task classname=org.mytasks.Task loaderref=mytasks.ref
classpath
fileset dir=${env.MY_TASKS_HOME}/lib includes=**/*.jar/
/classpath
typedef name=task2
Hi,
This sounds nice but does it save that much on
project name=x xmlns:lib=antlib:foo.bar
typedef resource=foo/bar/antlib.xml uri=antlib:foo.bar
classpath./classpath
/typedef
lib:mytask / !-- The antlib loaded using the classloader for
foo.bar --
/project
Peter
Jose Alberto
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Mariano's original question was why
was classpath ignored in an antlib definition.
antlib
typedef name=task classname=org.mytasks.Task
loaderref=mytasks.ref
classpath
fileset dir=${env.MY_TASKS_HOME}/lib
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Hi,
This sounds nice but does it save that much on
project name=x xmlns:lib=antlib:foo.bar
typedef resource=foo/bar/antlib.xml uri=antlib:foo.bar
classpath./classpath
/typedef
lib:mytask / !-- The antlib loaded
The only problem with this is that the user build script
needs to set the correct property before the antlib is activated.
Which I think it is not much to ask.
I have a conceptual problem of usability on an antlib written like this,
remember, in the broader sense, the antlib is written by
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
The context in which I say this is: I have a big application
(www.fuego.com) that provides ant tasks to perform most of its admin
operation,
it is a requirement to have the application installed and
then define a
property
Jose Alberto Fernandez wrote:
From: Mariano Benitez [mailto:[EMAIL PROTECTED]
The context in which I say this is: I have a big application
(www.fuego.com) that provides ant tasks to perform most of its admin
operation,
it is a requirement to have the application installed and
then define
of the
project.
My aim is to try to provide an in-buildfile alternative.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 01:16
To: Ant Developers List
Subject: RE: antlib and classloaders
How about just supporting an equivalent
I'm not sure I followed your suggestion. As far as
allowing a way to automagically include stuff without
adding it to the base installation, Antoine added the
-lib option and Conor extended it to pull all jars
from directories on (looks like) a path-style argument
specified with that option (as
Sorry I lost the thread. And I'm still uncertain. It
seems to me that no matter what (to continue with the
earlier examples), this should be valid:
myns:mytask
myns:mytype /
/myns:mytask
but it doesn't work in beta2. Again, only:
myns:mytask
mytype /
/myns:mytask
works. I got the idea
On 17 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
patch: 7203 add ant-type
+1
A minor nit - please add an @author for yourself to
IntrospectionHelper 8-), there already is too much in it that I
shouldn't get credit (or blame ;-) for.
patch: 7204 add antlib (xml form for type/task
On Mon, 2003-07-21 at 15:47, Stefan Bodewig wrote:
On 17 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
patch: 7203 add ant-type
+1
A minor nit - please add an @author for yourself to
IntrospectionHelper 8-), there already is too much in it that I
shouldn't get credit (or blame ;-)
On Thu, 2003-07-17 at 20:23, Antoine Levy-Lambert wrote:
Hi Peter,
+1
could you add also somewhere in the manual an explanation what ant-type
means and which tasks or datatypes support it.
I will try. The other changes (new custom condition, filter
and selector type support in particular,
and
Hi Peter,
+1
could you add also somewhere in the manual an explanation what ant-type
means and which tasks or datatypes support it.
Antoine
- Original Message -
From: peter reilly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 17, 2003 7:34 PM
Subject: Antlib feedback
Hi
On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote:
Whatever we adopt, it definetly need to be written from scratch. :-)
Cool. All I had to go on was the code. If we agree that roles are based on the
interface implemented by the nested element, that is good. It was my main
concern. I
Stefan Bodewig wrote:
On 21 May 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I've seen that Costin and Conor prefer that antlibs specify their
URI themselves. Could anybody please explain why
OK, let me try to summarize your answers:
Peter says - letting the user chose the URI may
Conor MacNeill wrote:
On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote:
Whatever we adopt, it definetly need to be written from scratch. :-)
Cool. All I had to go on was the code. If we agree that roles are based on
the interface implemented by the nested element, that is good.
On Thu, 22 May 2003, Conor MacNeill [EMAIL PROTECTED]
I still don't really see the need for roles
I'm not convinced either.
Stefan
.
However, if , as it sounds, I am the only committer who expresses support
for roles, I will give up on that subject.
Antoine
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, May 22, 2003 7:02 AM
Subject: Re: antlib
Conor MacNeill wrote
Sounds great.
- Original Message -
From: peter reilly [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Thursday, May 22, 2003 10:56 AM
Subject: Re: antlib / proposal of Peter Reilly
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
My main concern is the same
On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
Reading this, and knowing that computearea and computeperimeter
accept shapes as nested element, a build file writer would know that
circle/ and square/ can be nested inside computearea/ and
computeperimeter/.
So roles make
On Thursday 22 May 2003 10:29, Stefan Bodewig wrote:
On Thu, 22 May 2003, peter reilly [EMAIL PROTECTED] wrote:
Ok I will chop it up into a sequence of patches.
Thanks.
The first patch adds the add(Type) introspection method and
implements this in condition, filterchain, tokenfilter,
Stefan Bodewig wrote :
With roles, would an arbitrary implementation of ShapeInterface that
was not bundled with the antlib and was not declared to be in role
shape be accepted as nested element in computearea/?
If the answer is yes, then roles would be optional and would mainly be
used to
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
Reading this, and knowing that computearea and computeperimeter
accept shapes as nested element, a build file writer would know that
circle/ and square/ can be nested
On Thu, 22 May 2003, Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
I'm not sure that the build file writer is going to read the antlib
descriptor, though.
But remember we want to be able to say this same things inside build files
so we can
On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote:
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
I've seen that Costin and Conor prefer that antlibs specify their URI
themselves. Could anybody please
On Wednesday 21 May 2003 08:21, Stefan Bodewig wrote:
On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote:
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
I've seen that Costin and Conor prefer that
From: Conor MacNeill [mailto:[EMAIL PROTECTED]
On Wed, 21 May 2003 06:58 pm, Antoine Levy-Lambert wrote:
I still think that the roles concept is good and I would
like to make a
separate proposal for roles. My idea would be along the
following lines,
supposing that ant is being used
Antoine,
Great job, I think you have sumarized alot of the discussion quite well.
Thanks,
Jose Alberto
-Original Message-
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent: 21 May 2003 09:58
To: Ant Developers List
Subject: antlib
I have prepared a few days ago some
On Wed, 21 May 2003 08:31 pm, Jose Alberto Fernandez wrote:
Well I have to say you are mistaken, in my proposal the task (container)
implemented the addConfigured(InterfaceRole) method. The interface was
for the thing being passed (the child element, after possibly some
adaptor).
Well I am
- Original Message -
From: Conor MacNeill [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Wednesday, May 21, 2003 1:54 PM
Subject: Re: antlib
On Wed, 21 May 2003 08:31 pm, Jose Alberto Fernandez wrote:
Well I have to say you are mistaken, in my proposal the task
Stefan Bodewig wrote:
On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote:
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
I've seen that Costin and Conor prefer that antlibs specify their URI
Costin Manolache wrote:
That's consistent with most of the current uses of XML namespaces - you
don't see users picking their favorite XHTML or XSLT namespace URI.
To elaborate on this: the original intention of namespaces
was to provide universal names for elements. This means
a:section
peter reilly wrote:
There are a number of issues here.
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
I agree - I also preffer URIs that are interpreted in a certain way (
package names ), however we could
Hi Costin,
I will reply to these e-mails separately, if this is ok.
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
Sorry for the late reply, I had almost no acces to internet ( or time )
last week.
My main concern is the same as Conor's - having this decoupled and done
in few steps.
On Saturday 17 May 2003 20:13, Costin Manolache wrote:
peter reilly wrote:
for example:
typedef resource=org/acme/mydefinitions.xml classpath=classes/
to allow loading of tasks/types from different 3rd party with some tasks
haveing the same name, I have added a prefix attribute.
From: peter reilly [mailto:[EMAIL PROTECTED]
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
I think taskdef should be treated as a special typedef
with TaskAdapter
as adapter.
( i.e. use typedef as the main definition mechanism, and
taskdef as
a shortcut for types with
On Saturday 17 May 2003 20:16, Costin Manolache wrote:
Antoine Levy-Lambert wrote:
I am having a look at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897
This proposal seems to address most of the points discussed in this
mailing list concerning the antlib thread of discussion.
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
Peter,
acme:hellp xmlns:acme=NSURI
This would allow arbitrary NSURIs ( for people who like
meaning-free URIs)
and allow the classpath association.
I do not want meaning-free URIs.
I want ant to ignore URIs that it
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
I don't quite see why it would be impossible to have
meaning-free URIs.
Nothing is impossible..., but it is difficult to have
meaning-free URIs and to
support (as in ignore) other
Yikes!!
There are a number of issues here.
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
2) what should ant do with URIs that it does not recognize?
a) use current method - unknown elements
b) ignore
Sorry for the late reply, I had almost no acces to internet ( or time )
last week.
My main concern is the same as Conor's - having this decoupled and done
in few steps.
peter reilly wrote:
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
I would prefer to use the XML schema attribute
peter reilly wrote:
for example:
typedef resource=org/acme/mydefinitions.xml classpath=classes/
to allow loading of tasks/types from different 3rd party with some tasks
haveing the same name, I have added a prefix attribute.
taskdef resource=net/sf/antcontrib/antcontrib.properties
Antoine Levy-Lambert wrote:
I am having a look at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897
This proposal seems to address most of the points discussed in this
mailing list concerning the antlib thread of discussion.
I was thinking maybe we do not need to look further and
On Thu, 15 May 2003 12:56 am, peter reilly wrote:
I have merged the ant-type code into my antlib code.
However it uses a magic attribute name ant-type to
achieve the effect and not as discussed before - the
namesspaced attribute name like - ant:type.
I can easily do a name-spaced attribute
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
On Thu, 15 May 2003 12:56 am, peter reilly wrote:
I have merged the ant-type code into my antlib code.
However it uses a magic attribute name ant-type to
achieve the effect and not as discussed before - the
namesspaced attribute name
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
I am having a look at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897
This proposal seems to address most of the points discussed
in this mailing list concerning the antlib thread of discussion.
I was thinking maybe we do
1 - 100 of 184 matches
Mail list logo
