Re: Antlib descriptor
On Fri, 25 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote: - we can restrict the set of elements under antlib to taskdef, typdef or role ( after role is added to ant ), or we can allow more description looks important as well. Stefan
RE: Antlib descriptor
So we add this then. I am not closed to progress and change but let start small. Jose Alberto -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: 25 April 2003 20:10 To: [EMAIL PROTECTED] Subject: 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 scary at this point. AFAIK the proposal doesn't implement autodiscovery - and we don't know if we will get getResources(META-INF/antlib.xml ) or require explicit antlib In any case - it is easy to give user explicit control. In many systems libraries have a initialization mechanism. We may only allow conditions for example - but I don't see anything fundamentally wrong with this, that would guarantee we'll never want to do this. Same for allowing libraries to define fragments and targets - maybe today most people thing it is a crazy idea, but one year 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib descriptor
(Boy, you fall behind a couple of days on your email and suddenly an avalanche breaks loose) At 10:39 AM 4/25/2003 -0700, Costin Manolache wrote: 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. I really do not like this idea. I am -0.9. This descriptor is a deployment descriptor for an existing ant type (currently task or data type) into an Ant container. As such, it is exactly like the EJB, WAR, and EAR descriptors. It describes the information that the container needs in order to put the new type into a context from which it can be used. Trying to overload the meaning of Ant's existing build-oriented XML onto a language that defines how to deploy into an Ant container seems wrong to me for a lot of reasons. Yes, it will be more familiar to people who use Ant. Yes, it will allow reuse of some portions of code. But both of these are downsides as well. The needs for describing a deployment into the Ant container are often similar but sometimes subtly different from the needs for describing a build. Code specific to antlib would inevitably end up in the code for all builds. And the principle of least surprise would be violated when people expected a certain type of behaviour in antlib based on their experience writing build files that wasn't appropriate or reasonable for a deployment descriptor (like scripting the initialization using ant tasks, to use your example). If it had been available at the time, do you think anyone would have thought that requiring a subset of JSTL-only syntax in web.xml was a good idea? To my mind, that is somewhat equivalent to what you are proposing. If this is the case - then using ant syntax in the antlib descriptor would be as good as another syntax. Clearly I'm not in agreement with that statement. :-)
Re: Antlib descriptor
On Friday, April 25, 2003, at 01:39 PM, Costin Manolache wrote: New thread. +1 :) 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. I'll defer commenting on this until I ponder it more and see what others say about it. Erik and few others seem to believe that the XML vocabulary doesn't matter, and anything can be generated by xdoclet and processed. If this is the case - then using ant syntax in the antlib descriptor would be as good as another syntax. Well, again, don't stretch my thoughts on this too far. I meant it didn't matter *now*, in terms of getting it migrated to HEAD and having it in a place handy for all of us to work with and evolve it. It does matter though. - 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 ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering 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. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. Erik
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 ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Please - don't take this as we should do this. It may be the worst idea ever. What I'm trying to say is that a lot of things we might want later will be simpler, and we won't have to bloat the antlib SAX processor to implement such features. I'm sure there are some valid uses cases and extensions that we may add - even if those 2 use cases are completely wrong. It is very unlikely antlib will never change. 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. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. - consistency. I think it would be a bad idea to use Digester in antlib and another mechanism in ProjectHelper. Plus digester would add dependencies on beanutils, collections - we already have introspection code. I can accept replacing ProjectHelper with Digester - but I would like we use the same mechanism. - same kind of extensibility as ant. It may not be perfect - but at least will be consistent and most people understand it. - We can just use the same ( or almost ) code for taskdef, roles and whatever else we want to allow to be defined in antlib. - very easy to implement ( minor changes in ProjectHelper to parse antlib at top and restrict the childs ). Actually, antlib could be a task ( so antlib elements could be used in a build file - another stupid idea ), and we can just change PH to start with a different root. - easier to maintain. I know we're all SAX experts, but we've seen a lot of tricky aspects 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
RE: Antlib descriptor
From: Erik Hatcher [mailto:[EMAIL PROTECTED] - 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 ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering 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. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. 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 scary at this point. Jose Alberto
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 scary at this point. AFAIK the proposal doesn't implement autodiscovery - and we don't know if we will get getResources(META-INF/antlib.xml ) or require explicit antlib In any case - it is easy to give user explicit control. In many systems libraries have a initialization mechanism. We may only allow conditions for example - but I don't see anything fundamentally wrong with this, that would guarantee we'll never want to do this. Same for allowing libraries to define fragments and targets - maybe today most people thing it is a crazy idea, but one year 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
