Re: @author tag recommendation

To put things in a different perspective - Software is written by people. We donate our work and time to ASF, but I don't think that owning the copyright and all the rights on the code gives ASF the right to remove the author names from their work. As for the "legal" argument that is constantly us

Re: Authors tag

Peter Reilly wrote: I have commited the removal of authors patch. I made a CONTRIBUTORS file at the top level containing the authors names - without corresponding e-mail addresses. I suppose it's too late for a -1 on removing the @author tags based on the board recommendation... Well, all I can

Re: Microsoft XML scripting patent

[EMAIL PROTECTED] wrote: Not only . You can do the same (storing) with ]]>
Exactly, the patent descibes the contents of the ant "script" manual page: http://ant.apache.org/manual/OptionalTasks/script.html Peter And on [1] you can see, that´s

Re: Task for the new Pack200 format

Jose Alberto Fernandez wrote: What do people think? I will wait to see what are we interested on doing before aproaching Bill. I know him from my time at Maryland, hope he still remembers me. I'm very interested. If we do get an implementation for JDK1.2 - then it makes sense to have it in the cor

Re: Task for the new Pack200 format

[EMAIL PROTECTED] wrote: Java 1.5 comes with support for a new archive format Pack200[1] which basically works by using a special compression algorithm that is very effective on Java class files. The way to create such an archive is to create a plain old jar first and then turn ot into a Pack200 a

Re: Ant 2.0

Steve Loughran wrote: I suppose the problem was that undefined properties were just ignored, and you had a hard time debugging this ( I had similar problems many times ). you can get those messages if you crank up the verbosity, but you still need to go through the lines and look at them. I sup

Re: auto download of antlibs

Steve Loughran wrote: OK, now that Ant1.6 has antlibs, it is time to think of the next step: auto download of antlibs and (perhaps) dependencies. 1. Possible requirements -allow users to specify the URLs of dependent antlibs -allow teams to provide an override point that specifies their location

Re: Ant 2.0

Steve Loughran wrote: I know Ant2.0-the-rewrite is essentially dead (and essentially obsolete through evolution in the codebase), but I still think we ought to consider using the name as and when the time is appropriate. If we add enough interesting stuff to 1.7, it could be the time. Please, no

Re: [VOTE] Include the Apache 2.0 License in ant 1.6.1

Antoine Lévy-Lambert wrote: Antoine Lévy-Lambert wrote: Do you want to include the Apache 2.0 license in ant 1.6.1 Yes [x] No [ ] Antoine I need another Yes from a PMC member to do it. Antoine +1 Costin - To unsubscribe, e-mail:

Re: [vote] Ant 1.6 : further release plan

Antoine Lévy-Lambert wrote: > There have been some bugs fixed since the first ant1.6beta. > > Thanks Stefan particularly. > > I am thinking about preparing a second beta on Thursday evening (October > 16th). > > I would also like to make the 1.6 release on October 30th. > > Cheers, > > Antoin

RE: Getting 1.6 out the door

Dominique Devienne wrote: > As I've been saying all along, lets just introduce a new (unique) notion > for attribute/variable expansion (at use time rather than definition > time), which > is something new in Ant anyhow. No (or less?) backward compatibility > issues, and makes it plain and obvio

Re: Getting 1.6 out the door

Conor MacNeill wrote: > What I'd suggest is that soon we branch 1.6 and remove anything that is > still settling down. I think we have a few ideas that need to be kicked > around before we feel comfortable with them. This work can continue on the > HEAD (1.7) while we prepare a release. +1 > I'

Re: [OT] Build Time

Stefan Bodewig wrote: > On Mon, 18 Aug 2003, <[EMAIL PROTECTED]> wrote: > >> Something like log4j would allow us to enable debug on a particular >> target or task. > > solves this. Thanks, didn't know about it. >> Most of the time the debug messages are not logged by anyone > > IIRC XmlLogg

Re: [VOTE] Adding Permissions / Security Manager to Java task and JUnit task

+1 Costin Antoine Levy-Lambert wrote: > See : > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22533 > > I am quoting Martijn Kruithof : > > The following bug reports are associated with Security Manager issues: > http://issues.apache.org/bugzilla/show_bug.cgi?id=6323 and > http://issues.a

Re: [OT] Build Time

Nice work ! Regarding ant logging system - I think we should eventually reopen the subject and pick a logger API ( I preffer commons-logging, but I won't -1 any other choice ), then start using the normal if( log.isDebugEnabled()) log() that prevents useless string concatenations and calls. Co

Re: [Patch] namespace and antlib

Stefan Bodewig wrote: > On Wed, 13 Aug 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > >> All this overriding may create some bad maintaince problems. > > I agree for overriding in arbitrary namespaces, but we have to keep > supporting it for the default namespac

Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)

Knut Wannheden wrote: > Sounds great! > > In anticipation of this feature I have used a few namespaced properties > for > my custom tasks. And since Ant 1.5 doesn't have any value for these, I've > just made the tasks resolve them explicitly. > > This raises a question: Are properties whose val

Re: [Patch] namespace and antlib

peter reilly wrote: > On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote: >> On Tue, 12 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote: >> > On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote: >> >> On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote: >> >> > > >> >uri

Re: [PMC-VOTE] Ant 1.5.4

Stefan Bodewig wrote: > [It is the PMC's responsibility to ensure that our releases are OK, so > only PMC member votes are binding, that shouldn't stop anybody else > from speking her/his mind.] > > Conor has created the 1.5.4 distribution, it can be found at >

Re: beating the dead Ant 1.6 horse

Conor MacNeill wrote: > The others are antlib/namespace/polymorph stuff. I'm wondering if we can > get to the point where the ant optional tasks are packaged as antlibs and > potentially not added to the root loader if their supporting libraries are > not also available to the root loader. This w

RE: override

Jose Alberto Fernandez wrote: > From the XSLT bible by Michael Kay (2nd edition page 232): > "Like inheritance un object-oriented languajes, is designed > to allow the creation of a library or reusable components, only in this > case, the components are modules of stylesheets. And the mechanism w

Re: override

Nicola Ken Barozzi wrote: >> Yes, most build files have a target named "build" - but I don't know why >> would you think about inheritance and OO instead of just qualified names. >> >> I don't know _any_ programming language where import is used for >> inheritance. > > Well, I pointed out xslt,

RE: override

Jose Alberto Fernandez wrote: >> I don't know _any_ programming language where import is used for >> inheritance. > Believe it or not, XSLT is a programming language. :-) > And it uses the term import for inheritance. I know XSLT is a programming language, I don't remember it beeing an "OO" lan

RE: override

Jose Alberto Fernandez wrote: > One of the problems I have with the "rewriting" approach is that target > names get rewritten y the caller which means that two independent > importers may decide to use the same prefix and hence you get a clash. > Namespaces or java-style fully-qualified-names are

Re: override

Nicola Ken Barozzi wrote: >> Thanks for the overview, Nicola ! >> >>>Just to get you up to speed, the current issue is about multiple >>>inheritance, and how the current system allows cross-import (unwanted?) >>>side-effects, as Conor has brilliantly shown. >> >> What I'm not sure I understand

Re: override

Thanks for the overview, Nicola ! > Just to get you up to speed, the current issue is about multiple > inheritance, and how the current system allows cross-import (unwanted?) > side-effects, as Conor has brilliantly shown. What I'm not sure I understand is what import has to do with multiple inhe

RE: override

Jose Alberto Fernandez wrote: > First I do not think I have all the answers, just to keep things in > perspective. What I think I have is a set of principles that I think any > viable solution should provide. Lets see if I can put them into words: ;-| > > 1) I should be able to determine the corr

Re: Using classloader for Junit

Nick Chalko wrote: > After I slept on it, I thought of how I could extend the antclassloader > to handle the situations I need. > I am considering a > That will explicitly allow the optional ant task to be loaded in the > child classloader. > I may even go so far as automatically adding this fi

Re: Using classloader for Junit

Conor MacNeill wrote: >> >BTW, I don;t really agree with the task being used to >> >modify >> > the effective classpath of running ClassLoaders. I'm sure this will >> > cause trouble too. >> >> Seems to break some of the "properties are immutable" philosophy of ant. > > No - not really an Ant

Re: [VOTE] Peter Reilly as committer

+1 Costin Conor MacNeill wrote: > Hi, > > I would like to propose Peter Reilly as an Ant committer. He has submitted > a number of patches that advance the Ant core fanctions as well as helping > out answering questions on the user list. I think we've all seen that he > has the persistence req

Re: antlib

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

Re: antlib / proposal of Peter Reilly

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

Re: antlib / proposal of Peter Reilly

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

Re: antlib / proposal of Peter Reilly

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

Re: [PMC VOTE] Adoption of Bylaws

Conor MacNeill wrote: > PMC members, > > I'd like to move towards adoption of the bylaws draft. > http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/ant-site/anakia/docs/bylaws.html?rev=1.16 > > Could you please view this and vote indicating your position. If you wish > to vote -1 because

Re: antlib / proposal of Peter Reilly

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

Re: antlib / proposal of Peter Reilly

peter reilly wrote: > for example: > > > > to allow loading of tasks/types from different 3rd party with some tasks > haveing the same name, I have added a "prefix" attribute. > >prefix="antcontrib."/> > What is the prefix doing ? Is it related with NS, or are you using it wi

Re: antlib / proposal of Peter Reilly

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 attrib

Re: Roles (was: antlib)

peter reilly wrote: > Using property files is nice but with new attributes > to typedef (adaptor for example) it would be better to > use an xml file/resource. I think we already agreed on XML - there is no reason to continue adding arguments. > This should be independent of using antlibs/jars

Re: Roles (was: antlib)

Conor MacNeill wrote: > On Thu, 8 May 2003 12:30 am, Costin Manolache wrote: >> >> The URI however should be chosen by the antlib author ( maybe based on >> some rules specific to ant ), and should serve as an ID of the library. >> >> My proposal is to use the (ma

RE: Roles (was: antlib)

Jose Alberto Fernandez wrote: >> As someone already said, it's about "not reinventing the >> wheel", not about >> enabling the use of fancy tools. But as ubiquitous and >> accepted as XML >> namespaces are, I see many things that could be gained from using >> namespaces. Also, I suspect most us

RE: Roles (was: antlib)

Jose Alberto Fernandez wrote: >> From: Wannheden, Knut [mailto:[EMAIL PROTECTED] >> >> > >> > Let's not reinvent the wheel here. >> > >> > The solution for names conflicts is namespaces - not rewriting. >> > >> >> I agree. With the new ProjectHelper2 everything should be in >> place to start

Re: Roles (was: antlib)

: either extend the task to use the definition file in the > same way as property files are deal with at the moment or provide > a task - and nested elements from typedef/> Again - :-) > 3: release/document the task to manipulate the classpath. Sorry - tomcat t

Re: Roles (was: antlib)

Stefan Bodewig wrote: > On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: >> Jose Alberto Fernandez wrote: >> >>> The important point is for the user (which is the one who has to >>> deal with name clashes) to have control of the final nami

RE: Roles (was: antlib)

Let's not reinvent the wheel here. The solution for names conflicts is namespaces - not rewriting. If we use a prefix, let's stick with what everyone else is using. Inventing some "original" solution ( that may or may not be easier or more flexible than the W3C solution ) won't make things bett

Re: Tomcat-connectors 1.1M1

Ops, wrong group - sorry. Costin Costin Manolache wrote: > I did the JTC_1_1_M1 tag and build for tomcat-connectors-1.1M1. > The main purpose is to be able to use the same connector across all tomcat > versions - that was one of the goals of tomcat-connectors. > The code is identi

Tomcat-connectors 1.1M1

I did the JTC_1_1_M1 tag and build for tomcat-connectors-1.1M1. The main purpose is to be able to use the same connector across all tomcat versions - that was one of the goals of tomcat-connectors. The code is identical with the one in tomcat5.0.2 - except the build procedure and packaging. I trie

Re: Namespaces in Ant

Nicola Ken Barozzi wrote: > > Costin Manolache wrote, On 03/05/2003 8.22: > ... >> One use case I had in mind for CH was a namespace like "jmx:...", >> where the JMXComponentHelper would use the JMX metadata to create the >> task ( no ant table ). That

Re: Roles (was: antlib)

le per URI - or you can have one CH per URI ( I preffer the first option ). One use case I had in mind for CH was a namespace like "jmx:...", where the JMXComponentHelper would use the JMX metadata to create the task ( no ant table ). That's clearly outside the scope of antlib

Re: Roles (was: antlib)

peter reilly wrote: \>> > example: >> > >> > >> > > > newattribute="MyFileSet attribute"/> >> > >> > >> > >> > > > newattribute="MyPath attribute"/> >> > >> >> I assume you meant to write "ant:type" instead of "ant-type"... >

RE: NameSpace & antlib was (Re: polymorphism)

Jose Alberto Fernandez wrote: >> That means more filesystem specific code. You can't use >> getResource() to >> get META-INF/antlib.xml from a specific jar - unless you're >> sure that's >> the only jar with that res. in the classloader. So you either >> operate on the >> jar with Zip, or you hav

Re: NameSpace & antlib was (Re: polymorphism)

ib proposal) > that implements the above. I will try to get it in a form ready > for upload to-nite. Good. My feeling is that if you wait few more days - we can reach an agreement and the code should be committed to the main tree. I think we are pretty close (at least to a majority if not

Re: Roles (was: antlib)

peter reilly wrote: > On Wednesday 30 April 2003 17:54, Costin Manolache wrote: >> Stefan Bodewig wrote: >> > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote: >> >> We are still left the problem of the Type create() pattern. >> > >>

Re: Roles (was: antlib)

Stefan Bodewig wrote: > On Tue, 29 Apr 2003, peter reilly <[EMAIL PROTECTED]> wrote: > >> We are still left the problem of the Type create() pattern. > > I don't think that it was solvable. Almost any soltion world require > cooperation of the classes implementing the create method. > > What w

Re: Roles (was: antlib)

Stefan Bodewig wrote: > On Tue, 29 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: >> Stefan Bodewig wrote: > >>>> - Should we use (, ) tuple to find the class? >>>> Should we use (ParentClass, , ) tuple ? >>> >>> I'm not

RE: NameSpace & antlib was (Re: polymorphism)

Jose Alberto Fernandez wrote: >> From: Costin Manolache [mailto:[EMAIL PROTECTED] >> >> >> My concerns with getResources() as oposed to >> getResource( PACKAGE/antlib.xml): >> >> 1. startup time. In order to load one library you need to process all &

Re: NameSpace & antlib was (Re: polymorphism)

Nicola Ken Barozzi wrote: > ... >> The proposal provides a task which can be used to >> load libraries manually. Al the same time there are hooks on the code >> for an autoloading mechanism to be supported. In escence, it would >> allow ANT's main() to do something like: >> >> - get all antlib

Re: Roles (was: antlib)

Stefan Bodewig wrote: > On Mon, 28 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > >> If ParentClass has no addMyChild()/createMyChild() method, we'll >> need to look up in some table and find a class associated with >> . > > OK, well,

Re: NameSpace & antlib was (Re: polymorphism)

J.Pietschmann wrote: > Costin Manolache wrote: >> There are working and valid systems ( Axis, Xslt ) that use the namespace >> with associated meaning. > > The expanded XML element/attribute names get a meaning through an > processing model, nobody denies this. The p

Re: NameSpace & antlib was (Re: polymorphism)

J.Pietschmann wrote: > peter reilly wrote: >> True. It seems quite difficult to use namespaces in a nice way. > > You are not supposed to "use namespaces in a nice way". That's a matter of taste. Some people like "nice way", some people like UUIDs. There is nothing in the namespace definition th

RE: Roles (was: antlib)

Jose Alberto Fernandez wrote: > Assume class C implements role intrefaces P, Q, and R then > > > > > will cause two definitions for "P" and "Q" each. There is no way to > assign different names separately. On the other approach: > > > > > > > > here you can get different names for diffe

RE: Roles (was: antlib)

To keep things simple and make it easier to get an agreement - let's let adapters out, and focus on the core issue. IMO it seems what everything leads to is the need to extend the introspection patterns with another case. Let's agree on this pattern first. Assuming: If ParentClas

RE: Roles (was: antlib)

Jose Alberto Fernandez wrote: >> You'll have a task TaskA, with a method "addRoleB". >> And in XML: >> >> >> >> >> >> TaskA doesn't know anything about the implementation - it >> will only use an >> interface ( or base class ) "RoleB" as parameter. >> >> >> I assume you will need

Re: Roles (was: antlib)

Jose Alberto Fernandez wrote: > What does it all mean? It means we can now write a task, well typed, which > can be accept different XML subelements depending on the declarations of > other objects present on the build. The vendor specific elements of > , and others are typical examples of where

RE: polymorphism (was Re: antlib)

nt to load all the libraries. Again, using the filesystem directly is not perfect. Costin > >> -Original Message- >> From: Costin Manolache [mailto:[EMAIL PROTECTED] >> >> I don't like passing the .jar very much - but that's probably the only &

RE: polymorphism (was Re: antlib)

Wannheden, Knut wrote: >> >><.. init properies .../> >>> xmlns:antelope="antlib:${antelope.jar}"> >> >> >> >> >> >> >> >> >> >> Or even: In any case - if ComponentHelper is used, it'll get "antl

RE: Antlib descriptor

Jose Alberto Fernandez wrote: > I am not too keen on having alive ANTS roaming in my classpath. > > Jar files are passive things, in general having too many in your > classpath does not mean you will execute more stuff. I think that is nice > and autoinitializing jars (antlibs) sound way too scar

Re: Antlib descriptor

Erik Hatcher wrote: >> - maybe we want antlibs to have some initialization. This can be >> easily done >> by allowing more ant elements in the descriptor >> - maybe we'll want to allow antlib to declare targets - that could be >> used >> in depends or antcall ( > depends="myAntLib:antlibTarget"/>

Re: antlib

peter reilly wrote: > On Friday 25 April 2003 18:32, Erik Hatcher wrote: >> On Friday, April 25, 2003, at 01:25 PM, Costin Manolache wrote: >> > All I ask is to do the changes in the core separately. >> >> +1 >> > +1 >> I'm in agreement with

Antlib descriptor

New thread. Ok, I thought about it - and I will agree with the majority that XML should be used. However I'm more convinced than ever that the XML should use a subset of ant, and reuse the same processing infrastructure. I.e. not another parser or rules. Erik and few others seem to believe tha

RE: antlib

Jose Alberto Fernandez wrote: >> From: Costin Manolache [mailto:[EMAIL PROTECTED] >> >> >> Fine - but do this in core, not in antlib. >> > > But this are changes to core. Granted they are comming as part of the > bundle but they are not in antlib. All

class loader

I was looking at eclipse ant integration, and discovered on interesting bug. It seems eclipse has a security manager enabled. That means tasks that have security checks will perform them - and if they are loaded by ant class loader, the test will fail, since our loader doesn't associate a CodeBase

RE: antlib

gt; To: Ant Developers List >> Subject: Re: antlib >> >> >> On Friday 25 April 2003 08:31, Stefan Bodewig wrote: >> > On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: >> > > Look - adding "roles" concept to ant, and adding a

RE: antlib

Dominique Devienne wrote: > Because: > 1) Having an for every single one adds new elements for nothing, > and is not extensible to custom types (like ) to define its own > new typed role/interface (). You only need a ( or just use the existing typedef ) - and have class implement whatever inter

Re: antlib

Erik Hatcher wrote: >> So you believe that anything can go in the XML tags, no design >> or thinking is needed - because you could translate it with XSL or some >> tools will process it ? > > This is getting a bit exaggerated but I don't feel the syntax of an XML > descriptor is that relevant rig

RE: antlib

Dominique Devienne wrote: > Tell me what's the point of AntLib if it's just to define tasks/types? That's what currently supports tasks and types. There is no notion of role at this moment in ant. I don't know how you twisted my words into "I don't want roles". I just don't want roles implemen

Re: antlib

Erik Hatcher wrote: >> I think the syntax of the descriptor is pretty important. > > Obviously I disagree, but ngot terribly strongly. So you believe that anything can go in the XML tags, no design or thinking is needed - because you could translate it with XSL or some tools will process it ?

RE: antlib

Dominique Devienne wrote: >> From: Costin Manolache [mailto:[EMAIL PROTECTED] >> Sent: Thursday, April 24, 2003 12:23 PM >> >> The common use case is defining tasks and datatypes. > > So you -1 roles because you don't need them, at the expense of all the >

Re: antlib

Erik Hatcher wrote: > We don't really need to get hung up on the syntax of a descriptor at > this stage. Let's get something working in HEAD and work with it. > XDoclet can be used to generate these descriptors anyway, and it likely > be considered the best practice way to do it anyway. I think

Re: antlib

Antoine Levy-Lambert wrote: > Can you give us some pointers so that we can learn about these > Extension-Name and Extension-List elements and understand how they help > out for antlib ? http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html#Main%20Attributes http://java.sun.com/j2se/1.4.1/docs/g

Re: antlib

Stefan Bodewig wrote: > On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > >> J2SDK1.2 + defines a mechanism for declaring dependencies. > > As I stated in a different mail, this is not what I meant. Sorry, I may have missed that. To avoid other missu

RE: antlib

Jose Alberto Fernandez wrote: >> If we are to use XML, let's at least use ant syntax - i.e. >> >> >> >> >> >> Things people already know and understand, we have all the code to >> process it, and if we want to extend - it's quite easy. >> >> Please, don't invent a new language. >> >

Re: antlib

Stefan Bodewig wrote: > In the end we are not that far apart at all. Let's get the things > together then. > > * antlib needs a way to define mappings between names and classes. > > Costin prefers a properties file. Most others prefer XML. I can live with XML. What I hate is us inventing y

RE: antlib

Jose Alberto Fernandez wrote: > This is exactly the point, we should try to type things. Roles Why ? We have components that can be used in any role. Metadata can be extracted and used in a variety of ways - descriptors, interfaces, runtime calls ( like in the 3 kinds of mbeans ). But in the end

Re: antlib

peter reilly wrote: > On Wednesday 23 April 2003 17:57, Dominique Devienne wrote: >> Yes, it could be a problem. But running the risk of speaking yet another >> anathema, I'm starting to believe the Jelly approach of using XML >> namespaces is the right one... > +1 > Seems simple to implement and

RE: antlib

Dominique Devienne wrote: > Let's turn around your question: Tell me of a (string) role (beside the > special task/type cases) that would not be an interface? What good a bean > is, if it's not of an expected Java type? What method or field are you > going to use/call on it? Any role. Just like y

Re: antlib

Stefan Bodewig wrote: > On Wed, 23 Apr 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote: > >> If everything is defined as a component at a low level, then they >> can be easily introspected to find out what interfaces components >> implement. > > This breaks down if there is no specific interf

Re: antlib

Stefan Bodewig wrote: >> Regarding AntLib itself, XML descriptor or not, I'm more interested >> in being able to partition the namespace used by Ant to perform the >> name to class mapping currently restricted to tasks/types. > > Let's start with tasks and types and see if/how that flies. > > If

RE: DynamicTag

Dominique Devienne wrote: > 2) DynamicTag is lazy, thanks to UnknownElement. Your rewrite is creating > the element at parse-time, my implementation does it only at runtime. > Again, I favor delaying the instantiation and configuration. Ant should > never have mingled parsing of the XML and instan

Re: [VOTE] Antoine Levy-Lambert as committer

Stefan Bodewig wrote: > Hi all, > > Antoine has continuously been sending in patches since months now, > he's played an important role in the zip refactoring and is answering > more question on the user list than most of us here. Furthermore > Antoine has access to a perforce installation, so he

Re: [Patch] trying solve w2k command line length limitations

Stefan Bodewig wrote: > On Mon, 7 Apr 2003, Ignacio J. Ortega <[EMAIL PROTECTED]> wrote: >> "Stefan Bodewig" <[EMAIL PROTECTED]> escribió en el mensaje > >>> Class.forName will use the system classloader and not the nice >>> little >> >> IMHO This contradicts my experience of CLs, i think some p

Re: [Patch] trying solve w2k command line length limitations

Stefan Bodewig wrote: > On Mon, 7 Apr 2003, Ignacio J. Ortega <[EMAIL PROTECTED]> wrote: > >>> Which also implies that we'll need to go through Ant's codebase and >>> replace all Class.forName() calls (we better do that anyway 8-). >> >> I didnt understand this, why? > > Class.forName will use

Re: VOTE: new committer: Jesse Stockall

Steve Loughran wrote: > > I nominate Jesse Stockall as a committer as he likes spending time fixing > up and refactoring some of the neglected bits of the optional tasks, and > if we commit his new patch to the xdocs stuff, we need somebody to go > through all the attributes of all the tasks and

Re: [Patch] trying solve w2k command line length limitations

The problem seems to be that we need a way to pass a CLASSPATH but without using the env variable. And this needs to have the override properties of the CLASSPATH that are used in gump. Wouldn't be simpler to just add a bit of code to set java.class.path from a file or property ? If you go with a

Re: Using files in classpath in task file=""

Stefan Bodewig wrote: >> org.apache.tools.vfs.File extends java.io.File > > But this version cannot be the argument for the (existing) setters. > For this to work, IntrospectionHelper will need to take special care > (i.e. if setXYZ(java.io.File) is found, actually pass it an instance > of org.

Re: Artima SuiteRunner Task

peter reilly wrote: > I would include filters, mappers, conditions and selectors to > the list. I would exclude them :-) Taks, types, mappers, filters, whatever are just ant components - and they shouldn't need a special syntax from user perspective. We shouldn't treat them ( or types, tasks )

RE: Artima SuiteRunner Task

Dominique Devienne wrote: > Hu, not totally. If the AntLib also uses types, you need another > , which should also probably needs a loaderref. Since you now use > twice the classpath, if needs to be outside and refid'd. > > And what about the task? I'd like to not have setup my classpath >

RE: Artima SuiteRunner Task

Dominique Devienne wrote: > Hu, not totally. If the AntLib also uses types, you need another > , which should also probably needs a loaderref. Since you now use > twice the classpath, if needs to be outside and refid'd. In ant1.6 the difference between tasks and types is very small. It would

RE: [VOTE] JDK 1.1 support

Dominique Devienne wrote: > Given the above, there are no reasons to limit the 1.6 code base from > *any* change that's JDK 1.2 (Java 2) compatible. That includes moving > everything to the Java 2 Collections. As long as you don't break the public API. There are quite a few places where Hashtabl

Re: [VOTE] JDK 1.1 support

Steve Loughran wrote: > > +1 > > At the same time, I dont see a need to run into refactoring everything we > have today to move up to 1.2 support, 'just because we can'. It'll make it > that much harder to back port patches to the 1.5.x codebase +1 on your comment ( and a preemptive -1 on chang

  1   2   >