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 framewor
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 proba
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 Ja
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. Nobod
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 n
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, 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.
Commons Compress h
On 2010-03-28, Jan Matèrne 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 is out.
> But
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
.1-SNAPSHOT.
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
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 Applicatio
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 itsel
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, 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 import
> 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, ho
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 dis
--- 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?
> >
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)
> 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
> collis
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
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 thi
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/
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 sta
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 t
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). Th
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 explic
--- 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 3r
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
--- 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
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 ant
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
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 d
> 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 declaration
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 ,
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 att
On Mon, 22 Aug 2005, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Why do you have to repeat the full path to an antlib in ,
> 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 been s
> 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 additi
rto Fernandez 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 [mailt
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 n
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>
> Use 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)
>
> Phil :n)
It would be a directory instead of a file though, so it wouldn't be
mistaken for long.
> 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
rs List
Cc:
Subject: RE: Antlib package names
> 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
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: Ph
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 n
> 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
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> >
> >As the URI protocol "antlib:" provides a shortcut for the
> >above, I am just thinking on providing something similar for the
> >classpath declaration when needed.
> >
> >.
> >
> >
> >
> I have bee
Jose Alberto Fernandez wrote:
As the URI protocol "antlib:" provides a shortcut for the
above, I am just thinking on providing something similar for the
classpath declaration when needed.
.
I have been doing a little thinking about this.
What about a task to specify the classpath to use if
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
So what's to say that we can't build up an ANTLIB_PATH just like we build up
CLASSPATHs using ?
didge
> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 02, 2004 2:46 AM
> To: Ant Developers List; [EMAIL PROTECTED]
--- Mariano Benitez <[EMAIL PROTECTED]> wrote:
> 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 "fuego.base
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
> 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
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 a
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
>
> Hi,
> This sounds nice but does it save that much on
>
>
>
>
> .
>
>
>
>
>
>
Well I could ask the same question about antlib's namespace.
Why having some magic URI when users could just write:
and make the loading
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
>
> Mariano's original question was why
> was classpath ignored in an antlib definition.
>
>
> loaderref="mytasks.ref">
>
>
>
> loaderref="mytasks.ref"/>
>
>
> This could be supported easily in the current code b
Hi,
This sounds nice but does it save that much on
.
Peter
Jose Alberto Fernandez wrote:
Hi, I have been giving some thought on ways to solve this nagging
issue of needing to put antlib jars on the lib directory.
We hear over and over people wanting to keep their third party
librar
Mariano's original question was why
was classpath ignored in an antlib definition.
This could be supported easily in the current code base.
-i.e. if an typedef/taskdef in an antlib sets the classpath, this classpath
will be used instead
of the antlibdefinition classp
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 a
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 a
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 we
I have this issue in mind:
Since I need to provide antlibs to my customers, I would like them to
have to manually configure as less as possible, that means that the
previous way of saying -b /antlib was quite cool.
The problem is that I do need to control the classloader where the tasks
are loa
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:
but it doesn't work in beta2. Again, only:
works. I got the idea about explicitly declaring the
local namespace so that the nested el
alent, except for the explicit association with a custom classpath
for a given AntLib (thru it's URI).
It's a detail, but it saves typing, and makes sense I think.
Thanks, --DD
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 06, 200
Opps,
The xmlns:axis NS mapping is not needed in the type def. It is needed
when the NS uri is used.
The NS prefix -> uri mapping may be of course be in any enclosing element.
Peter
On Monday 06 October 2003 09:04, peter reilly wrote:
> You need to add the resource attribute:
You need to add the resource attribute:
Peter
On Saturday 04 October 2003 06:15, Steve Loughran wrote:
> I am writing an antlib entry for axis; trying to understand the concept
> to use properly myself. Here is my q.
>
>
> I can declare stuff in the axis namespace automagically with
>
>
>
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
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 def
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,
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
On Thu, 22 May 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]>
wrote:
> It is perfectly possible to program ant so that roles are optional
> and just make things more explicit.
It certainly is. Peter's patch is half-way there (roles are not
optional but not there at all 8-) - roles can be plugged
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
>
> 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
> > and can be nested inside
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:
> > > On Thu, 22 May 2003 01:02 am, Jose Alb
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 ?
>
> If the answer is yes, then roles would be optional and would mainly be
> used to make thi
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, token
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
> and can be nested inside and
> .
So roles make the antlib descriptor more expressive,
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 w
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:
>
> >
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, selector and
> path.
I'm +1 for this patch, and only ha
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
>
> My main concern is the same as Conor's - having this decoupled and done
> in few steps.
Ok I will chop it up into a sequence of patches.
>
> That means you have to start with add(Type), then anttypdef, then onerror.
The first patch adds
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
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
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
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
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
http://www.w3.org/
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 create problems if we
want t
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
>
>
> Well I am glad to hear I am wrong. Until 7 days ago, the code
> in your proposal
> was this (Project.java)
>
> public Object createInRole(Object container, String type) {
> Class clz = container.getClass();
> String rol
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
- 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:
> >
>
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
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
> 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 i
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 by specialists of geometry :
>
>
> class="org.apache.
On Wed, 21 May 2003 05:21 pm, Stefan Bodewig wrote:
>
> I've seen that Costin and Conor prefer that antlibs specify their URI
> themselves. Could anybody please explain why - and at the same time
> please also explain why user choice would be bad here? I feel I must
> be missing something.
There
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 pre
Ok fair enough.
I still think that the URI specified at the "typedef"
task should be restricted, if only to allow
future versions of ant to support other forms
of processing based on URIs without affecting
build scripts that specify URIs using "typedef".
I do not see that this is a big restriction
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 pl
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 c
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 th
1 - 100 of 238 matches
Mail list logo
