Re: Alias names for imported targets
Jose Alberto Fernandez wrote: Looks like spaguetti buildfiles to me. No ofence, but if the build have this kinds of fragile dependencies, will anyone else understan what is going on 6 month from now? That is what is wrong with spaguetti code. All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but... Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing. Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance? Ant import is *different* from other mechanisms, so analogies can help but are not the same thing. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alias names for imported targets
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: Looks like spaguetti buildfiles to me. No ofence, but if the build have this kinds of fragile dependencies, will anyone else understan what is going on 6 month from now? That is what is wrong with spaguetti code. All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but... Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing. Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance? Ant import is *different* from other mechanisms, so analogies can help but are not the same thing. Hmmm... I've recently read quite a bit about dependency injection and IoC on the Spring, HiveMind, and MartinFowler sites, and I don't think Ant's import/target override mechanism has anything to do with it. I think you must be meaning something else that what this term has recently been used to describe... The closest cousin to Ant I can think of is XSL. XSL has a proper include/import model, and also the Java equivalent to super., where an overriding matching template can explicitly invoke the overridden template. But that's it! You can never otherwise distinguish what comes from the main stylesheet from what comes from included or imported stylesheets, directly or not. Having this access just break encapsulation and would lead to spaguetti buildfiles, as Jose Alberto puts it. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Ant Wiki] Updated: FrontPage
Date: 2004-06-05T11:03:02 Editor: 24.130.17.70 Wiki: Ant Wiki Page: FrontPage URL: http://wiki.apache.org/ant/FrontPage no comment Change Log: -- @@ -1,42 +1,3 @@ ##language:en #pragma section-numbers off - -= Welcome to the Ant Wiki = - -The Ant Wiki has been migrated from its old home on nagoya.apache.org to part of the Apache Wiki Farm. If you find any issues, feel free to fix them up. - -http://ant.apache.org/images/ant_logo_large.gif - -Project Page: http://ant.apache.org/ - - - - * ExternalResources - - * AntModules - - * AntTutorials - - * AntUsageGuides - - * AntSampleFiles - - * AntInternals - - * AntProgrammingGuides - - * AntDesignIssues - - * AntTasks - - * AntOddities - - * NewAntFeaturesInDetail - - * [Proposals] - - * [AntManualPDF] - - * AntNewbies - - * ANT = [A]nother [N]eat [T]ool (as described in the [http://ant.apache.org/faq.html#ant-name FAQ]) +this is stupid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Ant Wiki] Updated: FrontPage
Date: 2004-06-05T11:43:08 Editor: 213.237.111.174 Wiki: Ant Wiki Page: FrontPage URL: http://wiki.apache.org/ant/FrontPage Some jerk deleted the contents... Change Log: -- @@ -1,3 +1,41 @@ ##language:en #pragma section-numbers off -this is stupid. += Welcome to the Ant Wiki = + +The Ant Wiki has been migrated from its old home on nagoya.apache.org to part of the Apache Wiki Farm. If you find any issues, feel free to fix them up. + +http://ant.apache.org/images/ant_logo_large.gif + +Project Page: http://ant.apache.org/ + + + + * ExternalResources + + * AntModules + + * AntTutorials + + * AntUsageGuides + + * AntSampleFiles + + * AntInternals + + * AntProgrammingGuides + + * AntDesignIssues + + * AntTasks + + * AntOddities + + * NewAntFeaturesInDetail + + * [Proposals] + + * [AntManualPDF] + + * AntNewbies + + * ANT = [A]nother [N]eat [T]ool (as described in the [http://ant.apache.org/faq.html#ant-name FAQ]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alias names for imported targets
Dominique Devienne wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: ... All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but... Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing. Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance? Ant import is *different* from other mechanisms, so analogies can help but are not the same thing. Hmmm... I've recently read quite a bit about dependency injection and IoC on the Spring, HiveMind, and MartinFowler sites, and I don't think Ant's import/target override mechanism has anything to do with it. I think you must be meaning something else that what this term has recently been used to describe... :-)) Yes, I mean something different, and it's funny to see this misunderstanding. What I was trying to say is that importing targets one gets new target dependencies, not only new targets. Namespaced Antlibs do not do this: what I get are extra tasks, which do not do things automatically. When importing instead I get targets that can automatically get wired to others, thus getting called in the existing dependency resolution. The closest cousin to Ant I can think of is XSL. Again, another analogy! :-) XSL has a proper include/import model, and also the Java equivalent to super., where an overriding matching template can explicitly invoke the overridden template. But that's it! You can never otherwise distinguish what comes from the main stylesheet from what comes from included or imported stylesheets, directly or not. It's still different... Having this access just break encapsulation and would lead to spaguetti buildfiles, as Jose Alberto puts it. I see that you two are particularly firm in this, and to be honest I'm just trying to play the other side for the sake of discussion. On the pther hand, I am not convinced by your reasoning, as it's subjective, not objective (mine is too). Let me try to take a step back and ask you a question: what is import for? Originally it was to do all sort of things for extending builds, but then some very clever coder came up with macrodef and typedef, and most of the reasons of import fell. If I want a particular target to be called, I should not want a target, but a macrodef. When import was first put in there, some really wanted it to work like a sort of macrodef, and most, including myself, are using it for this purpose. In *this* case, having the feature discussed here makes sense. In *this* case, using the inheritance analogy does *not* make sense. IMHO this is the reason why we are not understanding wach other, as we think of different use cases. Could it be that we should simply hint that in this case one should use a macrodef instead of a target? I start to think that this 'feature' should not be allowed because of this. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29085] - Timestamps in jar-Manifest
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29085.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29085
Timestamps in jar-Manifest
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
Component|Core|Core tasks
--- Additional Comments From [EMAIL PROTECTED] 2004-06-05 19:50 ---
This would be useful. netbeans.org has a generic script that uses something like
tstamp
format property=buildnumber .../
/tstamp
jar jarfile=... manifest=${some-basic-manifest}
manifest
!-- various important fixed attributes... then: --
attribute name=Impl-Version value=${buildnumber}/
/manifest
fileset .../
/jar
Currently the JAR is always rebuilt, which is annoying and slows down the build.
Possible workaround would be to create a temporary manifest somewhere using
manifest with everything but the Impl-Version set to @BUILD-NUMBER@, then
copy with a filter, then make the JAR; cumbersome.
I could probably supply a patch for this if committers would be interested in
applying it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
