is threatening the
foundation - perhaps it needs better lawyers.
Letting fear to drive an open source project is IMO a very bad management.
Costin
Dirk-Willem van Gulik wrote:
On Mar 15, 2004, at 11:49 PM, Conor MacNeill wrote:
As a result, I would like to open a discussion on the ant-dev l
costin 2004/03/13 00:29:26
Modified:.CONTRIBUTORS
Log:
Removing my name
Revision ChangesPath
1.2 +0 -1 ant/CONTRIBUTORS
Index: CONTRIBUTORS
===
RCS file: /home/cvs/ant
I can do is make sure the board won't be bothered with
contributions with my name in an @author tags.
Costin
The following name/e-mails I could not find names for:
gg at grtmail dot com
miha at softhome dot net
rhanderson
skanthak at muehlheim dot de
slo
Peter
Stefan Bodewig wrote:
On W
[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
n the core, so we can unpack antlibs with it :-)
( a better target would be CDC - not JDK1.2 :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
eature and existing users who can't benefit
from them, and eventually the standard itself, since alternative
solutions supporting current VMs are more likely to be adopted instead.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
n know about it - who reads
all the manuals ? ). If the behavior is "warn" - with maybe an option to
silence it - people could avoid a lot of errors and it would be easier
to debug.
Costin
-
To unsubscribe, e-mail: [EMA
do we want to integrate this with ant, or have some more standalone
tool that can be used to keep a component repository up to date, a tool
with an ant task for use in a build file. A sort of apt-get for apache
stuff...
I think having this bundled/integrated with ant would be an excelent idea
( I had similar problems many
times ).
I would preffer a warning for undefined properties outside echo/fail
instead of the option to fail - since in the second case it may fail in
too many build.xml files, forcing people to just disa
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
ctober 30th.
>
> Cheers,
>
> Antoine
+1
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think the last thing we need is a new syntax for "macrodef
variables".
Costin
> No context, no unnecessary brain cycles to figure out what is what.
>
> I'll be just as glad as the next guy to use , I just don't want
> that
&g
enough testing - might just be my own need to kick the
> tyres. Are we planning to antlib Ant's own optional jars? In 1.7 I think
> we need to look at removing antlibs from the root loader when their
> dependent jars are not available in ANT_HOME/lib.
+0
> 3. and
>
>
my experience this "fine tunned" debug is needed the most in
few tasks ( javac, exec, copy, antcall and maybe few others )
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+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.c
calls.
Costin
Nicola Ken Barozzi wrote:
>
> Sending this to ant-dev too.
>
> Vadim Gritsenko wrote, On 15/08/2003 23.28:
>> Just ran Cocoon build under optimize it. Not the clean build, but second
>> one, when there is nothing to do. It took 6 minutes on 1.6GHz P4 desktop
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
interceptors is already an object, but the code that does property
replacement doesn't know how to deal with "${prop}".
Costin
> Cheers,
>
> --
> knut
>
> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
&g
parameter to "ignore", this will make available the
> antcontrib's definitions.
> ComponentHelper stores the fact that it has implicitly loaded in
> these definitions so that it does not do this again.
> 3) This will override the antcontribs' uris definitio
are style
> changes.
>
> Please vote for/against these archives as the 1.5.4 release. Here's
> my +1 for starters.
+1
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
root loader. This would allow them to be
> taskdef'd in later in a build.
What's the status on that ? Any decision on how to deal with the loaders ?
I'll have some time next week, I wanted to finish the classloader t
comfortable understanding xslt files where the precedence rules are used.
IMHO ant should try to be a bit easier to use than XSLT.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rride-target tag depends=cvsbuild.tag
I'm starting to like override-target :-)
> Anyway, it seems that all this discussion has brought us back to what I
> had proposed after Conor pointing out the issue:
>
> "
> Nicola Ken B
that can be
> reused but do not define a full build process.
Why not ? It just requires you to use them with a qualified name or make
their names unique.
What it prevents is confusion if you have 2 fragments using the same name.
>> > And most of all: how to solve the last two points while keeping it
>> > possible for me to retain the use-cases?
>>
>> By adding specialized tasks for your use case ?
>>
> That is what we were trying to do.
I'm confused, I tought we are discussing import :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
uild files and deal with the
name conflicts in a clear way, without becoming a very hacky solution
that nobody understand - and to be honest I have a lot of trouble
understanding most of the overriding - even in the simple examples
on the thread, I can't imagine what will happen when people s
t;default" one, ie the one without renaming?
None, if 2 targets with the same name are found, you must
use qualified names for both ( when calling from outside - all dependencies
and calls from inside an imported build.xml file would use the short name ).
> Second question: how do we deal with the fact that targets that are not
> even used have crosstalk between themselves?
I don't think you can have crosstalk if you follow the rule that everything
is qualified if it has the same name.
> And most of all: how to solve the last two points while keeping it
> possible for me to retain the use-cases?
By adding specialized tasks for your use case ?
> As you see, for this usecase, is not strong enough, as I
> cannot override, and complete namespacing prevents me from overriding
> the dependency chain.
It's like saying is not strong enough to compile java code :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
me targets from one file with targets from other file - but if there is a
real need for that i have no problem with a python-like mechanism where
you can add/replace methods in an object at runtime. As long as it's
not disguised as :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
w define the import in a much simpler
way. Maybe I'm missing too much of the context, I'm still trying to get
updated with the mailing lists.
Costin
> On a project-fragment, any target dependency not defined in the fragment
> will be picked up from the visible targets, followi
r is complete.
There are other possible enhancements to create arbitrary loaders
or support reloading which are not yet implemented.
Costin
>>
>>Peter
>>
>>On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
>>
>>
>>>peter reilly wrote:
>>>
&
ng a flat loader where classes are added dynamically - and
seems to be fine in most cases ( or at least more reliable than other
alternative ). The scheme is actually much safer than what
jboss is using.
I'm sure there will be some combination of loaders where
+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
&
the
majority stands. I think most people are willing to accept a range of
solutions, and a lot is a matter of taste and prefference.
So far I've heard the strong opinion of Jose on roles - and I'm not sure
on the other's opinions. There are 2 negative opinions so far. If we decide
to add roles, I would like to be clear where other committers stand.
Costin
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:
>
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 Cos
unctionality in ProjectHelper2,
but operate on the tree. PH2 should just create the tree.
Costin
f you wish
> to vote -1 because you don't believe the bylaws include all they should,
> that's OK, of course, but please give me details on what changes are
> required.
>
> Thanks
> Conor
+1
Costin
mespace support for xml defintions (antlib:)
> So one can do
>
>
>
>
>
+1
We should also support the
This would allow arbitrary NSURIs ( for people who like meaning-free URIs)
and allow the classpath association.
Costin
the standard mechanism to resolve name conflicts, which in XML is
the namespaces.
It would be confusing to have "another" way to solve name conflicts.
Costin
), and the unit tests contain an adapter for Runnable
> objects. The code in CM does not treat TaskAdapter as a special case.
I think should be treated as a special with TaskAdapter
as adapter.
( i.e. use as the main definition mechanism, and taskdef as
a shortcut for types with optional TaskAdapter adapters ).
>> For the most part it looks OK to me. I'd need to look more closely to
>> fully comprehend it but thought you might like some feedback.
>>
Same here. If it can be split into smaller pieces - you have my +1 on the
overal proposal ( each piece will be reviewed separately and may need some
changes based on the review ).
Costin
> I would propose a root element of "antdef" and nested elements of
>> > "typedef" and "taskdef" and a possible "description" nested element
>> > and/or attribute.
>>
>> Or "antlib" as root element ?
>
> As I said above my implemation uses an ant task for this, using the same
> name for the root element of the descriptor and for a different task would
> cause interesting problems for the implementation.
Ok.
>> > 4: Implement the XML ns changes to use the xml definition file possibly
>> >using a predefined filename and using a package name.
>>
>> Not sure I understand - which part are you talking about ?
>
> I mean that I am making no assumtions on the location of the
> definition file, in the class path, or in the jar or in the meta-data
> part of the jar or meta inf attribute pointing to the xml file or having
> two xml files one pointing to the other
Ok. Well - even if the NS is not used to load the descriptor, I still think
it would be good to at least recommend the package to be used as ns.
( and certainly not http:// or file:// :-)
Costin
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
ge. What you are suggesting is equivalent in letting users
pick whatever package they want for a java class, at runtime.
BTW, if we are still talking about java programmers using ant - I doubt
we'll have that many users who don't understand how package work and
have a big shock learning about XML namespaces.
Costin
rary.
Regarding use of the core namespace if no name conflicts: +1
> So if I say:
>
>
>
> I will be able to use: , , etc. But is I do:
>
>
Again - the URI is not under user control, but under the antlib author
control. Just like the "if" and the other task
: 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
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
) won't make things better for the user.
is not easier than
Costin
Jose Alberto Fernandez wrote:
> Hi guys,
>
> I was away on vacation so hasn't been around to make comments about the
> entire discussion. I will try to sumarize here some comments that go
&
costin 2003/05/05 06:59:24
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Last part of component helper merge ( including the fix contains ->
containsKey for the test case )
Revision ChangesPath
1.9 +16 -7 ant/src/main/org/apache/tools/
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
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
costin 2003/05/04 19:20:26
Modified:src/main/org/apache/tools/ant Project.java
Log:
ComponentHelper has been checked in for some time - and I don't know
any -1 or major complain.
This removes the duplicated code and switches the component creation
to component h
costin 2003/05/04 19:17:28
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Remove one method - it wasn't used, and it seems it's not powerfull enough for
all cases discussed. The method that takes UnknownElement, ns, tag should
be able to cover every
costin 2003/05/03 07:30:26
Modified:src/main/org/apache/tools/ant UnknownElement.java
src/main/org/apache/tools/ant/helper ProjectHelper2.java
Log:
Plug the namespace uri. One way or another - we'll need it.
Also fix the qname - we need to use the loca
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
costin 2003/05/02 23:27:00
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
The ctor takes Project as param.
Revision ChangesPath
1.7 +1 -1 ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
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
costin 2003/05/02 22:59:35
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Update with the changes in Project.
This makes ComponentHelper the almost exact duplication of the task creation
code in Project.
Revision ChangesPath
1.6 +12 -4
s/types (ComponentHelper) receives the
namespace and the name. CH allows plugins - i.e. any task can hook
into the component creation and provide it's own mechanism, so you
should be able to implement whatever namespace policy you want.
Costin
utoloading.
>>
>>
>> A lot of people ( myself included ) seem to like a "repository" that
>> is shared by multiple projects - instead of having all the jars in CVS
>> or managed manually.
>>
>> We must keep in mind this use case - and the fact that the file
>> names may change ( versioning ) and the repository may have more than
>> we need ( startup time, etc ).
>>
>
> I see no problem, just point to the repository as the dir for the fileset.
> And you can use includes if you do not want to load everything.
Not that simple. Startup time problem, need to maintain the include
manually ( either the dir name or the jar name needs to include the version ),
etc.
I think this kind of "detail" needs to be taken into consideration, even
if it doesn't matter for you personally.
Costin
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
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.
>> >
>>
tring) now.
Can you explain again what's wrong with create ? I think I missed it...
My understanding was that whatever is in use today will continue to work
the same, we just add a new pattern at the end.
Costin
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
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
&
>> In principle this was designed just for loading the core at load time,
>> we could expand it to allow loading all jars (antlibs) in the classpath,
>> which means all antlibs in the ANT/lib directory.
>
> This I really liked but Costin IIRC put it down in favor of compul
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,
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
mespaces
Style is a matter of taste :-)
There are working and valid systems ( Axis, Xslt ) that use the namespace
with associated meaning.
Costin
erstand
> what this means?
As I said above, this is a valid case - but it's not the simple or common
case.
For jboss - you actually need to express that the child name
will have different implementations based on the parent ( or some
other condition ).
Not sure I understand how you would resolve this with your proposal -
by defining different roles of jboss ? I can live with having
such extra syntax for the non-common case, but not to require it for
the common case.
BTW, one alternative solution for associating the name with an
implementation class is the use of namespaces. Axis does that quite
extensively, and seems to work very well.
or something similar.
> Still we need this if we want to be able to send the responsability for
> maintaining vendor specific code back to the vendors.
>
> Roles came up from the need to achieve exactly that.
> Adaptor came from looking at the actual mess we have in our type system
> and try to put some standarized mechanism that can dealt wih it.
I think the type system is not that bad ( or at least it's cleaner than the
mess you propose :-)
Costin
resolved separately - let's just add the extra introspection pattern.
Costin
nyway - and so the name, but the roles will
>> be available as soon as you have the impl. class. You only need an
>> additional attribute if you want to wrap.
>>
>
> As explined above this assumes the same name used everywhere, which it is
> not the case.
In general - context-sensitive languages are trickier, but you can even
today use different names for the same class.
You can also have the same name associated with multiple classes in
different contexts- by the addFoo() pattern - but I wouldn't want to
go in this direction.
>> I think we should either use / - with the additional
>> attribute for the adapter - or use a new element
>> ( or even
>> - but I don't find this very intuitive ) that will replace both
>> and .
>>
>> For example:
>>
>>
>
> I do not mind having a but with the syntax:
>
>
>
>
>
> could be just but I think is less
> clear.
Ok, that's something we stand on totally oposed positions.
It just doesn't make sense to me having the adapter associated with the
role.
BTW, my prefference would be to actually just use as the
definer ( with the additional optional adapter attribute ). But I'm
fine with a new element name.
Costin
ent somehow.
> It is also clear that we should provide tasks to define roles
> and declare members of roles direclty on the build.
>
>
> Ok, this is it. If you have any strong opinons about it, let me know.
You already know my strong opinion.
I think we should either use / - wi
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
&
that's probably the only
way if we want to use META-INF/antlib.xml.
The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e.
descriptor in a package ), and use "antlib:net.sf.antcontrib" as namespace.
Then getResource() can be used, and we don't have to worry about
multiple
ar from now we may find it
usefull. Of course, we could change the parser then - but we'll accumulate
a lot of behaviors that would make this difficult.
Costin
in ProjectHelper long evolution. This way we maintain a
single parser - and a single behavior.
- all the wonderful features that may be easily enabled ( if they prove to
not be very bad ideas ).
I can add more to the list.
Costin
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
maybe we'll want to allow antlib to declare targets - that could be used
in depends or antcall ( ).
Again - those are just examples, there are a lot of things that could be
done easily. Even if you don't need any of this - it would be nice to
not have to repeat the long and painfull evolution of the main xml
processor.
Costin
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
ate a CodeBase
with the loaded classes.
I also had problems with Jasper - when starting tomcat from ant.
Since we are now JDK1.2, I would like to make our class loader extend
URLClassLoader.
I'll have some free time next week, and if nobody objects I'll make the
change.
Costin
t all components as components at the low level.
An unified way to treat all the sub-types should be defined and implemented
as part of the core.
We can wait with antlib ( the part that loads whatever-things-ant-supports)
until polymorphism is defined, but I would preffer having antlib included
ent whatever interface you need. You can define any role
you want by having an interface and classes implementing this interface.
Costin
> 2) supercedes / (which remain for backward
> compatibility), adding extensibility to other types (within Ant or not)!
>
> Why are you getting han
ice filters, selectors, etc can only be used
if loaded by antlib ?
You can define a task with in a regular ant file - why wouldn't
you be able to define the condition without using an antlib ?
Costin
t roles".
I just don't want roles implemented this way, and I want the antlib
to do one thing well,
When roles are added to ant, in one form or another, we can add them
to antlib.
Are you saying that those roles can't be used without antlib ?
> Sounds like you have never needed to
But the current one does not support adding other components like
> conditions, mappers, filters, and selectors.
Does ant support this ?
And what do you mean "does not support adding" ? It can add any component
( as datatype for example), and nothing stops you from using any datatype as
anything you want ( condition, mapper, filter or selector ).
Costin
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
>
Again, lets not get hung up on the descriptor syntax. Working
> implementation first - then we can debate the details. We can make it
> the defining goal for an Ant 1.6 release when all the fiddly details
> have been ironed out! :)
We have had working implementation(s) for quite a while.
It's the fiddly details that are the problem.
Costin
long as it is not a completely new
format. Using a subset of ant is IMO a very good solution, and it would
allow us to easily enhance it later on.
Mixing roles with antlib proposal - that's where I'm strongly -1.
Costin
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
st ).
>>
>> Why would we want to invent our own ?
>>
>
> JDK only defines a mechanism to indicate which other jars are need to be
> loaded to find additional classes (which are located relatively to the
> current jar)
I assume you're talking about the ClassPath, which is just a way to specify
the CLASSPATH, and has nothing to do with dependencies.
I was talking about the "real" dependency part - with Requires-XXX.
> This is not dependency declarations.
Costin
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
sed, he can get a proxy that implements the desired
interface. ( I think it can be done for JDK1.2 as well, but a bit harder ).
Costin
the descriptor automatically.
We can start simple with that, then add more as we need it ( from antlib
or elsewhere )
> * use a variation of dynamictag or dynamicelement to
> allow the datatypes to be used in supporting tasks / datatypes
Costin
act without
implementing the interface. In JDK1.3+ ( and JMX1.2+) you can use a proxy
that implement the interface - but what really matters is the contract,
not the syntactic detail.
Ant ( and JMX ) have allways had a "loose coupling" aproach. You can write a
lot of tasks without having a
don't need to change much in ant to achieve that.
We can say it's almost already available.
> At least for task I'd expect some strong opposition against an
> interface that marks them up. Hi Costin ;-)
Of course. There is no need to have a Task interface, or even require Task
nd types and see if/how that flies.
>
> If we want to extend the plugability to mappers or selectors or
> whatever (I do), the solution in the end may be a flat namespace
> (everything is a type) as Costin seems to hint at when he wants to
> drop the difference between task and type.
At
re "project components" - and the "role" is given by how
they are used. Not having an "execute" method is the only special
thing about a typedef.
> currently two distinct namespaces, one for tasks, and one for types, and
> Costin says I'd like to merge the
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
costin 2003/04/10 12:14:03
Modified:proposal/embed build.xml
proposal/embed/src/java/org/apache/tools/ant
RuntimeConfigurable2.java
Log:
Patch from Loïc Péron <[EMAIL PROTECTED]> to compile against ant153
Revision ChangesPath
for Ant 1.6, this is no issue as long as no core Ant classes
> calling Class.forName can also be loaded via the parent.
You are right that Class.forName should be changed. The "right" way is
to first try with the thread class loader ( this would allow ant to be used
in a webapp for example ).
Costin
with
Class.forName not finding something.
I would also add the JBoss class loading scheme - which is also adding jars,
with few twists to support reloading - is also working fine with
Class.forName.
( yes, I know I need to write the docs for the loader task - this is the
first thing I'll do after I finish with the current tasks ).
Costin
1 - 100 of 127 matches
Mail list logo
