Conor MacNeill wrote:
> Also, I'm a little concerned about violating the classloading hierarchy -
> it leads to Linkage errors in my experience. I have the same concern with
> the ClassLoader task.
The ClassLoader task is no longer using the classloading hierarchy - the
initial version did, and i
Nicola Ken Barozzi wrote:
>
> Nicola Ken Barozzi wrote, On 06/03/2003 9.49:
> ...
>>> If you think this plan is workable let's put this to a PMC vote.
>>
>> Yes, let's start with Ruper, and work our way one thing at a time.
>
> Oh, one more thing.
>
> Krysalis Version is active in our sandbox,
Does anyone else use konqueror ? It seems the margin on ant.apache.org is
too small and it looks really. It looks ok on other browsers.
Is it a browser bug or something we can fix ?
Costin
Tasks
Resources
Frequently
Asked
Questions
Having
Problems?
It looks fine in galeon and other browsers.
I'll try a different version of konqueror, maybe this one has a bug.
Costin
>
>
> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
Stefan Bodewig wrote:
> On Fri, 7 Mar 2003, Steve Cohen <[EMAIL PROTECTED]> wrote:
>
>> For those who have not been following the traffic on this bug can
>> someone please have a capsule summary about what breaks when you use
>> it? Is it the only which is affected, or are things
>> like affec
Dominique Devienne wrote:
> Not directly related, but I recently read that Maven similarly moved away
> from relative path to use absolute paths. They apparently prefix
> ${basedir} explicitly everywhere. I'm not following the dev forum, but
> thought the parallel was worth mentioning. --DD
Well
Hi,
Do we have any plan or idea on when we'll start distributing 1.6 milestone
builds ?
Tomcat5 is getting stable, and the next milestone will probably include an
"embeded" profile that will be controlled by ant and jmx tasks. It would
really help to have a matching ant1.6M1 instead of requiring
Steve Loughran wrote:
> That's the task that doesnt have any documentation, right?
:-)
It'll have documentation after it is reviewed by more people and we
know it's going to be stable.
> Maybe the thing to do is look at what major changes still need to go in to
> ant. Now that we have explo
Conor MacNeill wrote:
> I'd like to throw this up again. What are peoples thoughts on the
> following
>
> 1. Make Ant 1.6.x the last JDK 1.1 release. This would be clearly
> documented
+1
( I would be +1 on making ant1.5 the last JDK1.1 release :-)
> 2. Make the subsequent release require JDK
Steve Loughran wrote:
>> I'm +1 to maintaining support for 1.1 if at least one committer is
>> willing to volunteer to support it ( and does it ).
>
> 1. what do we gain from dropping 1.1 support at this stage in ant1.6?
Few things. Using URLClassLoader would simplify a lot of code - to me
that
Adam Murdoch wrote:
> It would also be a perfect time for a bit of selective
> backwards-compatibility breaking at the code level: eg sort out the
> classloader heirarchy, ditch deprecated methods, separate the core into
> public api and private internals, split up project's responsibilities,
> se
Stefan Bodewig wrote:
> Fine with me.
>
> I'd like to keep 1.6 compatible to JDK 1.1, though. When we make 1.2
> a requirement, we'd better start using collections and URLClassloader
> consistently - and doing this for 1.6 would push 1.6 even further down
> the timeline.
There are 3 issues:
1.
Stefan Bodewig wrote:
> On Thu, 13 Mar 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
>
>> Is there any active committer that uses JDK1.1 ?
>
> Me, from time to time. I still have to maintain a library that has
> a strong requirement of compiling against 1.1.
7199 :-)
>> > 3) add if and unless attributes for some tasks
>> > e.g. in one can set os = whatever to enable
>> > running this task. But normally one would have set a property
>> > that would have depended on more conditions than the os.
>
Stefan Bodewig wrote:
>> Most likely a "fix" will be more introspection magic...
>
> Not in this case. The code that is JDK 1.2 dependent in Diagnostics
> can be replaced by 1.1 code without too much pain (it can be stolen
> from the JUnit task, for example).
Maybe in this case - but more cod
ing in
rt.jar"), but I think it would be better to have more flexibility.
Costin
>
> Jose Alberto
>
>> -Original Message-
>> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>> Sent: 14 March 2003 15:47
>> To: [EMAIL PROTECTED]
>> Subject: R
Steve Loughran wrote:
>> If this turns out to not work with JDK 1.1, it is another case for
>> those of us proposing to leave JDK 1.1 support behind. This meant our
>> binaries don't work with JDK 1.1 and nobody has complained so far 8-)
>>
>
> It's a very good metric. Like how the memory setti
Conor MacNeill wrote:
> On Wed, 19 Mar 2003 05:17 am, Costin Manolache wrote:
>>
>> Ok - last week we had a proposal, discussions on ant-user and ant-dev,
>> and apparently an almost general consensus.
>>
>> What's next ? Should we wait a bit more before maki
Conor MacNeill wrote:
> Hi,
>
> This is to formalize the discussions which have gone on on the dev and
> user lists. Please indicate your vote. Everyone is free to vote but only
> committer votes are binding.
>
> Ant 1.6 will require JDK 1.2 to compile and build. Releases from the 1.5
> branch w
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
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
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
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
>
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 )
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
>>
>
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
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
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
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
>
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 ?
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
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
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
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
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
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
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
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
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"/>
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
Wannheden, Knut wrote:
>>
>><.. init properies .../>
>>> xmlns:antelope="antlib:${antelope.jar}">
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Or even:
In any case - if ComponentHelper is used, it'll get
"antl
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
&
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
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
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
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
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
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
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,
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
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
&
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
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
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.
>> >
>>
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
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
peter reilly wrote:
\>> > example:
>> >
>> >
>> > > > newattribute="MyFileSet attribute"/>
>> >
>> >
>> >
>> > > > newattribute="MyPath attribute"/>
>> >
>>
>> I assume you meant to write "ant:type" instead of "ant-type"...
>
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
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
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
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
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
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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
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
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
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
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,
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
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
1 - 100 of 119 matches
Mail list logo
