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 list to
see the
impact
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
it in 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]
and VB ( Sam Ruby may know - he was there :-), it should be about the
same time.
It seems like yet another broad patent on common technology...
Maybe Conor could ask the board ?
Costin
Jan
[1]
http://cvs.apache.org/viewcvs.cgi/ant/docs/manual/OptionalTasks/script.html
[2]
http://cvs.apache.org
had a hard time debugging this ( 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 disable it.
Costin
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 !
Costin
? ). 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 macrodef, I just don't want
that
power to come of the expanse of Ant's simplicitly and user-friendliness
)
Costin
Comments?
Conor
-
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.cgi?id=6323 and
http
, antcall and maybe few others )
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
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
box. Guess where all this time has
. 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 task - is
it still usefull ?
Costin
) This will override the antcontribs' uris definition of shellscript.
4) This will execute the new definition.
All this overriding may create some bad maintaince problems. I wish we
wouldn't support this feature...
Costin
I have changed this to ant:*,
Hmm, what will be the replacement
to deal with ${prop}.
Costin
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able
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]
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 start using this
with dozens of targets.
Costin
-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
appreciate :-)
Sorry for repeating what has been discussed, I was very concerned about
mixing import with OO and complex name resolution rules ( like in XSLT
import :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED
at runtime. As long as it's
not disguised as import :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
, include is not strong enough, as I
cannot override, and complete namespacing prevents me from overriding
the dependency chain.
It's like saying copy is not strong enough to compile java code :-)
Costin
-
To unsubscribe, e
to a flexibility
syndrome.
One think I don't understand is why the import should be used as a OO
substitute. Most languages I know 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
reliable than other
alternative ). The classloader scheme is actually much safer than what
jboss is using.
I'm sure there will be some combination of loaders where classloader may
generate an error, but it's better than any other scheme that I know or
tried so far.
Costin
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:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file
Stefan Bodewig wrote:
On 21 May 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I've seen that Costin and Conor prefer that antlibs specify their
URI themselves. Could anybody please explain why
OK, let me try to summarize your answers:
Peter says - letting the user chose the URI may
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
+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 required
Stefan Bodewig wrote:
On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote:
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
I've seen that Costin and Conor prefer that antlibs specify their URI
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
.
Costin
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
place all
elements in the default NS ( i.e. no ns is used ). If name conflicts -
use 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
.
Costin
to at least recommend the package to be used as ns.
( and certainly not http:// or file:// :-)
Costin
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
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 (main) package name. There are other options
better for the user.
antlib location=antcontrib.jar prefix=myxyz- /
myxyx-if ...
is not easier than
project xmlns:myxyz=ant:net.sf.antcontrib
myxyz:if ...
Costin
Jose Alberto Fernandez wrote:
Hi guys,
I was away on vacation so hasn't been around to make comments about the
entire
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 naming scheme
used in his/her buildfile.
Let's
using a predefined filename and using a package name.
Not sure I understand - which part are you talking about ?
Costin
Peter
On Wednesday 07 May 2003 06:14, Costin Manolache wrote:
Let's not reinvent the wheel here.
The solution for names conflicts is namespaces - not rewriting.
If we
to copy, then import few files - and figure out what the build file is
actually doing ).
antlib location=antcontrib.jar usens=cont/
/project
then I can use cont:if/, cont:switch/, etc.
Costin
Which means that the default value for the 'usens' attribute is which
assumes some implicit
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 everything
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 helper
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
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 identical with the one
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/ant
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
the JMXComponentHelper would use the JMX metadata to create the
task ( no ant table ). That's clearly outside the scope of antlib or ant (
it's just a custom task ).
Costin
Peter
On Friday 02 May 2003 15:42, Costin Manolache wrote:
peter reilly wrote:
\ example:
typedef myfileset
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
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 localname
Stefan Bodewig wrote:
On Tue, 29 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
Stefan Bodewig wrote:
- Should we use (parent, child) tuple to find the class?
Should we use (ParentClass, parent, child) tuple ?
I'm not sure what the difference is, here.
In the second case
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 problems start if someone
associates
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
myChild.
OK, well, maybe, see below for an alterbative view.
We'll
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 compulsory
explicit loading.
loader ( which is a wrapper around AntClassLoader ) allows adding to
the core loader
.
component name=elementName className= [ adapter= ] /
BTW, my prefference would be to actually just use typedef as the
definer ( with the additional optional adapter attribute ). But I'm
fine with a new element name.
Costin
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
for the adapter - or use a new element component ( or even
role - but I don't find this very intuitive ) that will replace both
taskdef and typdef.
For example:
component name=elementName className= [adapter=] /
Costin
Jose Alberto
-Original Message-
From: peter reilly [mailto
.
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
in ant sooner.
Costin
In an ideal world, we should
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 I ask is to do the changes in the core separately
to
not be very bad ideas ).
I can add more to the list.
Costin
. Of course, we could change the parser then - but we'll accumulate
a lot of behaviors that would make this difficult.
Costin
multiple jars providing META-INF/antlib.xml - which forces us to use the
.jar file directly.
Costin
That is almost the same thing as I had in mind. Although I've been
thinking about some slight variations to this, where no top-level element
like use/
would be necessary. The Jelly
to do with dependencies.
I was talking about the real dependency part - with Requires-XXX.
This is not dependency declarations.
Costin
- that's where I'm strongly -1.
Costin
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
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
people who need to declare more than tasks
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 write anything but custom tasks and
types Costin
ant file - why wouldn't
you be able to define the condition without using an antlib ?
Costin
) - and
have class implement whatever interface you need. You can define any role
you want by having an interface and classes implementing this interface.
Costin
2) antlib supercedes taskdef/typedef (which remain for backward
compatibility), adding extensibility to other types (within Ant
.
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
to be extended. Ant's strength (IMHO) comes from the lightness of the
framework. Just add an execute method
+ ( 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 any dependency on ant.
I agree with Costin, all tasks/types
it ( from antlib
or elsewhere )
* use a variation of dynamictag or dynamicelement to
allow the datatypes to be used in supporting tasks / datatypes
Costin
for JDK1.2 as well, but a bit harder ).
Costin
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 two, when I actually would prefer to
have N namespaces, each indexed/keyed by a 'role' string. When a task
Maybe something
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's
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
1.9
the new metadata :)
Also he's been a long standing contributor to bits of the project, does
all the due diligence on bugzilla and ant-user support, those being the
things that matter as much as new code. The quality of the code is
Here's my vote:
+1
-steve
+1
Costin
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
is to add the
attributes to the tasks where it is needed.
Should we add it to copy ? I don't know :-) But XSLT is a good candidate.
Costin
() method, and nothing else,
and taskdef loades both kinds.
That would be simpler than the current syntax that also require you to
do a:
typedef resource=... classpathref=... /
Costin
And what about the junit task? I'd like to not have setup my classpath
outside of Ant and build.xml, and avoid
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 )
.
Costin
are used.
Hashtable is still part of JDK1.2 AFAIK ( and implements Map), so
we are already using Java2 Collections :-)
Costin
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 making it official by a
[VOTE], or just forget
for the improvements in
startup time )
Costin
files in the source tree - but I for target files
I thing it's far better to use prefixes.
Costin
of tasks.
The classloader task can be extended to deal with hierarchies and
direct/reverse delegation - but the most common use will be to extend the
main ant loader.
Costin
87 matches
Mail list logo
