You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matt Benson <gu...@yahoo.com> on 2007/03/02 16:50:45 UTC
archivefileset resources
I noticed that in order to pick the archivefileset
parameters on e.g. <tar> (I'm assuming zip and family
work this way as well) the archivefileset has to be a
direct child of the archive task. This means that
specifying e.g.
<resources id="archiveResources">
<fileset dir="foo" excludes="bar" />
<tarfileset file="bar" fullpath="special/bar" />
</resources>
doesn't work as I would expect. Is it agreed that
<tar>'s ignoring the fullpath of bar is undesirable?
If so it would seem we'd need perhaps an
ArchiveResource interface to carry along the
parameters from the parent ArchiveFileSet, etc., etc?
-Matt
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 22 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
>> On Wed, 21 Mar 2007, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > Surely we can't go there... maybe we'd better rethink the
>> > "instanceof FileResource" idiom instead, e.g.
>> > isFilesystemResource()?
>>
>> Or throw in an interface that contains getFile() and is implemented
>> by FileRessource - and modify the "instanceof FileResource" idiom
>> to "instanceof that new interface".
>
> That gives me a nice comfy feeling.
Good.
> If we simply mandate that this type of Resource classification
> should always be interface-defined (we probably should have done
> this from the beginning
+1
> ), we can use JDK1.3 proxies and avoid cglib,
+1 again.
> Another cool thing seems to be that we could provide
> some kind of ResourceCollection that could proxy the
> resources from another collection but provide their
> content in files even for non-file resources
Yes, that sounds interesting. We could throw in similar things to
attach permission bits to ressources that are not archiveressources
and so on.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Matt Benson <gu...@yahoo.com>.
whew, I'll try this: :)
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 21 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> We would want to have a FileRessource remain a
> FileRessource even
> >> when mapping them - same for the other subclasses
> of Ressource.
> >> Some kind of factory would be needed and using an
> intferface
> >> instead of creating yet another subclass of
> Ressource (or a couple
> >> of them) might help.
> >
> > Are you suggesting dynamic proxies here?
>
> Well, at least I thought about them, even though I
> don't have any
> experience with cglib or any other existing library.
Yep, me neither, but as I think I wrote and you
snipped from what I've seen you earn what you get from
cglib. In case that doesn't come across well to
non-native speakers (or otherwise; sometimes nobody
understands me) I am saying I think cglib deserves
respect from a functional standpoint and it can and
will do a lot for you (as evidenced by Spring and
Hibernate), but it would take a lot of research on
your part to understand how to make cglib do what you
want it to do. Maybe I don't have a firm enough
grounding in class structures, etc. though and it's
not as bad as I think, or maybe I'm just an idiot.
Plus it's been awhile. In any event, when I looked at
it I ran. ;)
>
> > I think this implicit RC mapping question does
> after
> > all differ from Alexey's request;
>
> I don't remember Alexey's request in detail, so you
> are probably
> right.
>
Basically a mapped fileset... I think we could
extrapolate mapped resource collection, and I think
the string resource representation could take this a
long way.
[SNIP]
> I'll cut the rest of this and respond to it
> separately in a fresh
> thread (tomorrow, I guess, need to make breakfast
> for my kids now).
As you say, another discussion. Hope your kids were
nutritiously fed and I look forward to your separate
email... ;)
>
> > Back to our regularly scheduled content...
> >>
> >> > But to do this with an interface means its
> consumers would have
> >> > to check for it explicitly; put another way,
> that all resource
> >> > consumers would not immediately benefit. If we
> implemented the
> >> > name-mapping behavior such that it simple
> overrode getName(), the
> >> > consequent question is why have an interface at
> all?
> >>
> >> The interface could provide access to the
> original name and
> >> override getName().
> >
> > I think I knew that's what you meant... again, to
> > implement MappedResource while remaining a
> > FileResource, dynamic... subclasses? Eek!
>
> Or just have a factory that returns
> static/anonymous? subclasses of
> FileRessource and others. I want to avoid that we
> add more concrete
> classes to the ressource mix to make things worse.
>
> > Surely we can't go there... maybe we'd better
> rethink the
> > "instanceof FileResource" idiom instead, e.g.
> > isFilesystemResource()?
>
> Or throw in an interface that contains getFile() and
> is implemented by
> FileRessource - and modify the "instanceof
> FileResource" idiom to
> "instanceof that new interface".
That gives me a nice comfy feeling. If we simply
mandate that this type of Resource classification
should always be interface-defined (we probably should
have done this from the beginning and I'll accept at
least 70% of the responsibility for that), we can use
JDK1.3 proxies and avoid cglib, the very mention of
which made me whimper in fear due to its high learning
curve and the fact that it would be a dependency that
would probably have been mandatory, at least for all
practical purposes.
>
> > But if we simply added isFilesystemResource() to
> Resource, couldn't
> > a MappedResource just delegate to the original?
> Might that be
> > enough?
>
> You'd also need to delegate getFile if that was
> possible. Or
> getArchive in case of an ArchiveRessource or ...
All moot I think simply by saying that getFile() is
defined in an interface. Ahh...
Another cool thing seems to be that we could provide
some kind of ResourceCollection that could proxy the
resources from another collection but provide their
content in files even for non-file resources for
compatibility with things that required files. This
would probably take some doing to make it actually
useful, but might be interesting.
>
> >> But before you dare to override getName, better
> check usage
> >> patterns in existing tasks. I wouldn't be
> surprised if we still
> >> had tasks that used "new File(parentDir,
> ressource.getName())" or
> >> something similar and expected the file to exist.
> >
> > I don't know. I don't think Resources were in
> extremely wide use
> > until the 1.7 branch,
>
> Probably not.
>
> > and again, this is the type of problem that is
> extremely unlikely to
> > simply arise at runtime--the build writer should
> have plenty of time
> > to figure out "doh, <foo> doesn't seem to support
> X resource...". I
> > think adequate disclaimers and warnings should
> suffice in these
> > cases.
>
> Yes, this might work. Let's be careful, still.
Okay. :)
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 21 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> We would want to have a FileRessource remain a FileRessource even
>> when mapping them - same for the other subclasses of Ressource.
>> Some kind of factory would be needed and using an intferface
>> instead of creating yet another subclass of Ressource (or a couple
>> of them) might help.
>
> Are you suggesting dynamic proxies here?
Well, at least I thought about them, even though I don't have any
experience with cglib or any other existing library.
> I think this implicit RC mapping question does after
> all differ from Alexey's request;
I don't remember Alexey's request in detail, so you are probably
right.
> however I let myself misunderstand the direction of this thread and
> be led down the path of composing a large diatribe on THAT suject,
OK.
> Wrt explicitly mapped resourcecollections I think what is needed is
> a well-known syntax specification for specifying a string
> representation of [resource-type][String to pass to constructor]
> e.g. "file?/foo/bar.baz", "url?http://www.apache.org", "string?blah
> blah blah".
Ahh, that discussion 8-)
> One may recall this as something I've been after for awhile--I
> consider it the "next step" for resource handling in Ant. For code
> compartmentalization we could probably add the code to generate a
> Resource from a String to ResourceUtils, but IH would know how to
> use e.g. RU.getResource(Project, String) to set Resource attributes
> (for BC, FileResource would be the default).
I don't think there is anything wrong with that. We deferred it until
after Ant 1.7.0 but I don't see any reason to not implement it now.
I'll cut the rest of this and respond to it separately in a fresh
thread (tomorrow, I guess, need to make breakfast for my kids now).
> Back to our regularly scheduled content...
>>
>> > But to do this with an interface means its consumers would have
>> > to check for it explicitly; put another way, that all resource
>> > consumers would not immediately benefit. If we implemented the
>> > name-mapping behavior such that it simple overrode getName(), the
>> > consequent question is why have an interface at all?
>>
>> The interface could provide access to the original name and
>> override getName().
>
> I think I knew that's what you meant... again, to
> implement MappedResource while remaining a
> FileResource, dynamic... subclasses? Eek!
Or just have a factory that returns static/anonymous? subclasses of
FileRessource and others. I want to avoid that we add more concrete
classes to the ressource mix to make things worse.
> Surely we can't go there... maybe we'd better rethink the
> "instanceof FileResource" idiom instead, e.g.
> isFilesystemResource()?
Or throw in an interface that contains getFile() and is implemented by
FileRessource - and modify the "instanceof FileResource" idiom to
"instanceof that new interface".
> But if we simply added isFilesystemResource() to Resource, couldn't
> a MappedResource just delegate to the original? Might that be
> enough?
You'd also need to delegate getFile if that was possible. Or
getArchive in case of an ArchiveRessource or ...
>> But before you dare to override getName, better check usage
>> patterns in existing tasks. I wouldn't be surprised if we still
>> had tasks that used "new File(parentDir, ressource.getName())" or
>> something similar and expected the file to exist.
>
> I don't know. I don't think Resources were in extremely wide use
> until the 1.7 branch,
Probably not.
> and again, this is the type of problem that is extremely unlikely to
> simply arise at runtime--the build writer should have plenty of time
> to figure out "doh, <foo> doesn't seem to support X resource...". I
> think adequate disclaimers and warnings should suffice in these
> cases.
Yes, this might work. Let's be careful, still.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Dominique Devienne <dd...@gmail.com>.
> > --- Steve Loughran <st...@apache.org> wrote:
> rule 1 of xml: nobody understands XML namespaces
> rule 2: anybody who says they do. still doesnt.
>
> so there are the following categories
>
> -ignorant of xmlns
> -vaguely aware, but doesnt understand
> -think they understand, but doesnt really
> -knows xmlns enough to know it doesnt make sense, and doesnt understand
Maybe I'm being naive Steve, but the rules for XML NS are *NOT* that complex.
It's fairly easy to know which NS an element or attribute belongs to,
and the parser tells you anyway.
> if you meet someone who thinks they do understand it, ask them if, in
> xml schema, the ##local namespace is in ##other, or not.
How namespaces are used in XSDs for validations is not really part of XML NS.
Here's my limited understanding of XML NS which is enough to know AFAIK:
1) attributes are in no namespace, unless they have an explicit
namespace prefix, which of course must have been declared and be in
scope.
2) elements with an explicit namespace prefix, which of course must
have been declared and be in scope, belong to that explicit namespace.
Sure, the prefix can be remapped to another namespace anywhere in the
document, but people rarely do that, and the parser keeps track of
that for you.
3) elements with no explicit namespace prefix either are not in a
namespace at all, or belong to the namespace mapped to the "default"
namespace in scope, i.e. the one declared with a xmlns="..."
declaration, as opposed to a xmlns:prefix="..." one.
Again, people rarely remap the "default" (missing) namespace prefix in
their documents to differing namespaces.
And that's IT. How can you say that it's THAT complicated ;-)
I consider it unfriendly to map a given NS prefix to more than one NS
in a given file, and to not declare all namespaces in the root
element, especially if there is a "default" namespace.
Stop spreading false information about namespaces Steve ;-))) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Steve Loughran <st...@apache.org>.
Matt Benson wrote:
> --- Steve Loughran <st...@apache.org> wrote:
> Maybe. :) But really, I appreciate your input. I
> have no problem admitting how clueless I am wrt xml in
> general and ns in particular. :|
rule 1 of xml: nobody understands XML namespaces
rule 2: anybody who says they do. still doesnt.
so there are the following categories
-ignorant of xmlns
-vaguely aware, but doesnt understand
-think they understand, but doesnt really
-knows xmlns enough to know it doesnt make sense, and doesnt understand
if you meet someone who thinks they do understand it, ask them if, in
xml schema, the ##local namespace is in ##other, or not.
For the record, I know enough for them to scare me, that's it.
>
>> have had to deal with
>> exactly this kind of problem in the past, where we
>> really did have to
>> extract and maintain the xmlns list. And believe me,
>> Xom does not go out
>> of its way to make that easy
>>
>
> Can we mitigate any of this with usage guidelines?
> Three ways to resolve a type, the first two of which
> are easy:
>
> - use a type in a globally defined ns
> - use e.g antlib:org.foo/type
1.
> - use a type in a globally defined ns
kind of breaks some of the xmlns rules
2.
> - use e.g antlib:org.foo/type
this is somewhat similar to how XPath lets you insert new XMLNS
declarations. If you were do it, I'd prefer
{http://example.org}type as that is equivalent to how
javax.xml.QName.toString() works
3.
> third option would require awareness of available
> namespaces at the time of resolution, so if you
> defined
>
> <property name="resource" value="myns:type?blah" />
>
> you'd have to say:
>
> <echo output="${resource}"
> xmlns:myns="antlib:org.myorg" />
>
> or whatever... does that solve and/or accomplish
> anything?
it would certainly work, but be unduly painful. Your task would need to
know which namespace declarations to put i for a resource, which then
becomes something you can't change.
Other options
-make a QName an official Ant type. When you set it, the XMLNS gets
expanded. This is a good idea anyway; too bad QNAme is only built in to
java5, though javax.xml.namespace is available as an add-on for older code.
you could create one in the qname task
<qname ns="http://org.example/" local="local" > ==
{http://org.example/}local
<qname local="local" > == {}local
<qname ns="something" > == BuildException no local
<qname value="prefix:value" > == {lookup(prefix)}value ... xmlns:prefix
would have to be up the tree
Of course, this doesnt help you with the problem of defining resource
destinations in a string, or a properties file...
-Make an xmlns context something else that is a datatype
<namespaces id="here" /> //cache all defined xmlns in this element's
scope
<namespaces refid="here" /> //extract the namespaces and add them to the
parent node (i.e. the target)
<echo output="${resource}" />
Not sure whether I like that one.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Matt Benson <gu...@yahoo.com>.
--- Steve Loughran <st...@apache.org> wrote:
> Stefan Bodewig wrote:
> > On Wed, 21 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> >
> >> I think what is needed is a well-known syntax
> specification for
> >> specifying a string representation of
> [resource-type][String to pass
> >> to constructor] e.g. "file?/foo/bar.baz",
> >> "url?http://www.apache.org", "string?blah blah
> blah".
> >
> > This is so I can say
> >
> > <unzip
> >
>
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> >
> > instead of
> >
> > <unzip>
> > <url
>
url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> > </unzip>
> >
> > right?
> >
> > Sounds right.
>
>
> >
> >> This is to all intents and purposes the only way,
> IMHO, to seriously
> >> take advantage in Ant tasks of our early decision
> to design
> >> getOutputStream() into the Resource contract.
> You'll notice my use
> >> of the "?" character above to indicate the
> preceding text was the
> >> name of a currently available type. I used "?"
> because for xmlns as
> >> well as fs reasons I'm pretty sure this character
> should NOT be a
> >> colon.
> >
> > I agree that a colon would be a bad choice, at
> least if we allow file
> > ressources to be specified without a prefix. I
> don't really see any
> > conflict with xmlns.
>
> ah, this is starting to scare me.
Then my work is done! ;)
>
> you'd need qname resolution in string to support
> custom resources
>
> <unzip
>
>
src="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> I hate those because they only resolve relative to
> where they are defined
>
> <property name="url"
>
value="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"
> xmlns:tns="http://example.org" />
>
> this defines the url property with the tns namespace
> in scope
>
> but where it is used, it may be absent
>
> <unzip
> src="${url}">
>
> or defined to something else
>
> <unzip
> src="${url}" xmlns:tns="http://something-else"/>
>
> So you're going to have to retaiin the entire list
> of in-scope XMLNS
> declarations in every property you define. Now, what
> if its a custom
> task that creates the string? is
> Project.setNewProperty() going to have
> to take a reference to the node in the DOM graph
> where the current task
> is working?
>
>
> You may think I'm being a troublemaker here, but I
Maybe. :) But really, I appreciate your input. I
have no problem admitting how clueless I am wrt xml in
general and ns in particular. :|
> have had to deal with
> exactly this kind of problem in the past, where we
> really did have to
> extract and maintain the xmlns list. And believe me,
> Xom does not go out
> of its way to make that easy
>
Can we mitigate any of this with usage guidelines?
Three ways to resolve a type, the first two of which
are easy:
- use a type in a globally defined ns
- use e.g antlib:org.foo/type
third option would require awareness of available
namespaces at the time of resolution, so if you
defined
<property name="resource" value="myns:type?blah" />
you'd have to say:
<echo output="${resource}"
xmlns:myns="antlib:org.myorg" />
or whatever... does that solve and/or accomplish
anything?
br,
Matt
> >
> >> However I'm not sure what the RIGHT "trigger
> character" is and IMO
> >> this is the only outstanding question stopping us
> from adding this
> >> feature to Ant.
>
> that and how to correctly handle xml namespaces.
>
> -steve
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Steve Loughran <st...@apache.org>.
Stefan Bodewig wrote:
> On Wed, 21 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
>
>> I think what is needed is a well-known syntax specification for
>> specifying a string representation of [resource-type][String to pass
>> to constructor] e.g. "file?/foo/bar.baz",
>> "url?http://www.apache.org", "string?blah blah blah".
>
> This is so I can say
>
> <unzip
> src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> instead of
>
> <unzip>
> <url url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> </unzip>
>
> right?
>
> Sounds right.
>
>> This is to all intents and purposes the only way, IMHO, to seriously
>> take advantage in Ant tasks of our early decision to design
>> getOutputStream() into the Resource contract. You'll notice my use
>> of the "?" character above to indicate the preceding text was the
>> name of a currently available type. I used "?" because for xmlns as
>> well as fs reasons I'm pretty sure this character should NOT be a
>> colon.
>
> I agree that a colon would be a bad choice, at least if we allow file
> ressources to be specified without a prefix. I don't really see any
> conflict with xmlns.
ah, this is starting to scare me.
you'd need qname resolution in string to support custom resources
<unzip
src="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
I hate those because they only resolve relative to where they are defined
<property name="url"
value="tns:url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"
xmlns:tns="http://example.org" />
this defines the url property with the tns namespace in scope
but where it is used, it may be absent
<unzip
src="${url}">
or defined to something else
<unzip
src="${url}" xmlns:tns="http://something-else"/>
So you're going to have to retaiin the entire list of in-scope XMLNS
declarations in every property you define. Now, what if its a custom
task that creates the string? is Project.setNewProperty() going to have
to take a reference to the node in the DOM graph where the current task
is working?
You may think I'm being a troublemaker here, but I have had to deal with
exactly this kind of problem in the past, where we really did have to
extract and maintain the xmlns list. And believe me, Xom does not go out
of its way to make that easy
>
>> However I'm not sure what the RIGHT "trigger character" is and IMO
>> this is the only outstanding question stopping us from adding this
>> feature to Ant.
that and how to correctly handle xml namespaces.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Stefan Bodewig <bo...@apache.org>.
On Sat, 24 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
>> On Fri, 23 Mar 2007, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > --- Stefan Bodewig <bo...@apache.org> wrote:
>> Not that bad. IH already favor setters for anything that's not a
>> string over a plain String setter. But IH already is a pretty
>> complex beast ...
>
> Right, the whole thing is it favors those non-String
> setters once, for good and all, at construction. So
> by the time you're actually using it, under the
> current implementation, your IH instance has already
> made up its mind what type "src" is, and it would be
> random if we don't at least go in and say Resource
> trumps File. It would take more surgery to make IH
> store e.g. a map of property names to (map of types to
> AttributeSetters); currently it maps name directly to
> AttributeSetter.
Later in my post I already agreed it would be simpler to do it that
way than try to resolve a ressource and fall back to File at the time
we want to execute the setter. We agree by now.
>> >> bikeshedding? 8-)
> <http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
>
> I've read that one. So I wonder what's the one I
> said,
You said:
>> >> > However I'm not sure what the RIGHT "trigger character" is and
>> >> > IMO this is the only outstanding question stopping us from adding
>> >> > this feature to Ant.
Which I read as "I'm, not sure what the right color of the bikeshed is
and IMO this is the only outstanding question stopping us from
building the bike".
Again, I was joking.
>> >> OK, what is left? "#", "="? Or
>> >> "url(http://www.apache.org/)"?
>> >
>> > I kind of liked the parentheses thing when I saw it...
>> > I wonder if it looks too much like a method call.
>>
>> parens might look strange when use in a regexp mapper, curly braces
>> might be better and they don't even look like a method call.
>
> For arguments' sake :) {} appear to be used at least
> in the java1.4 regexp package. But we're talking
> about mapper RESULTS ("to" attr) so that narrows
> things considerably. Maybe the choice of character(s)
> will be a necessary evil in some contexts.
8-)
So simply go ahead, implement the Ressource as an attribute stuff
using your preferred trigger and maybe have a vote if anybody objects.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 23 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> I guess we'd need something dynamic, i.e. there
> has to be a way to
> >> register a ressource prefix with RU so that I can
> have string
> >> representations for my own ressource types.
> >
> > I had assumed we could specify things in such a
> way as
> > to specify the resource type simply by its
> typedef,
>
> For some reason I never made that connection, even
> though it is
> obvious. That's why I didn't see a conflict with
> XML namespaces
> either.
>
> > but I suppose a shortcoming of doing it this way
> is
> > that for types from antlibs they must be
> explicitly
> > typedef'd or have their ns mapped. Well, I
> suppose
> > e.g.
> >
> > antlib:org.foo/customResource?bar
> >
> > wouldn't be the end of the world,
>
> I don't think it would be too much to simply require
> ressources to be
> typedef'ed if you want to use the String ->
> Ressource magic.
>
> >> For BC we'd have to keep the File-argument
> setters anyway. IH
> >> could be changed to use setSrc(Ressource) in
> favor of setSrc(File)
> >> and use the later if no ressource mapping was
> found. No real need
> >> to have a default in RU. OTOH it might be
> convenient for users
> >> when they can simply omit the "file?" prefix for
> files.
> >>
> >
> > That'd be quite a bit of IH modification to make
> it
> > preserve > 1 type for a given property.
>
> Not that bad. IH already favor setters for anything
> that's not a
> string over a plain String setter. But IH already
> is a pretty complex
> beast ...
Right, the whole thing is it favors those non-String
setters once, for good and all, at construction. So
by the time you're actually using it, under the
current implementation, your IH instance has already
made up its mind what type "src" is, and it would be
random if we don't at least go in and say Resource
trumps File. It would take more surgery to make IH
store e.g. a map of property names to (map of types to
AttributeSetters); currently it maps name directly to
AttributeSetter. Not impossible, but modifies the
original design enough that it really no longer makes
sense to throw out String either in that case. You
see?
>
> > I can't decide what would be the best all-around
> solution, but it
> > does seem that if we overloaded the same property
> setters with File
> > and Resource, it might be easiest overall to add
> explicit code that
> > setSrc(File) won't override setSrc(Resource) in IH
> (maybe no type
> > can override a Resource),
>
> would be easy, similar code already exists in IH.
>
> > then default to FileResources as planned.
>
> OK.
>
> >> > However I'm not sure what the RIGHT "trigger
> character" is and
> >> > IMO this is the only outstanding question
> stopping us from adding
> >> > this feature to Ant.
> >>
> >> bikeshedding? 8-)
> >
> > I get those little allegories mixed up. Is that
> the
> > one where we can blab back and forth forever, but
> > ultimately whoever is doing the work can make the
> > choice?
>
> Not really. It means we might be spending too much
> energy on
> discussing minor details (the color of the bike
> shed) while there are
> bigger problems to tackle.
>
>
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
>
I've read that one. So I wonder what's the one I
said, or did I make it up or put a few together? ;)
> Even though you sounded as if the choice of
> character was the only
> thing that prevented us from implementing the
> feature, I was not
> accusing anybody of wasting our time. I was joking.
>
> > Actually, globmapper doesn't seem to support ?.
> ;)
>
> Ack, I should have known that. The regexp mapper
> does, though ;-)
>
Right, though for optional expression components
rather than as a single-character wildcard. :)
> >> OK, what is left? "#", "="? Or
> >> "url(http://www.apache.org/)"?
> >
> > I kind of liked the parentheses thing when I saw
> it...
> > I wonder if it looks too much like a method call.
>
> parens might look strange when use in a regexp
> mapper, curly braces
> might be better and they don't even look like a
> method call.
>
For arguments' sake :) {} appear to be used at least
in the java1.4 regexp package. But we're talking
about mapper RESULTS ("to" attr) so that narrows
things considerably. Maybe the choice of character(s)
will be a necessary evil in some contexts.
-Matt
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 23 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> I guess we'd need something dynamic, i.e. there has to be a way to
>> register a ressource prefix with RU so that I can have string
>> representations for my own ressource types.
>
> I had assumed we could specify things in such a way as
> to specify the resource type simply by its typedef,
For some reason I never made that connection, even though it is
obvious. That's why I didn't see a conflict with XML namespaces
either.
> but I suppose a shortcoming of doing it this way is
> that for types from antlibs they must be explicitly
> typedef'd or have their ns mapped. Well, I suppose
> e.g.
>
> antlib:org.foo/customResource?bar
>
> wouldn't be the end of the world,
I don't think it would be too much to simply require ressources to be
typedef'ed if you want to use the String -> Ressource magic.
>> For BC we'd have to keep the File-argument setters anyway. IH
>> could be changed to use setSrc(Ressource) in favor of setSrc(File)
>> and use the later if no ressource mapping was found. No real need
>> to have a default in RU. OTOH it might be convenient for users
>> when they can simply omit the "file?" prefix for files.
>>
>
> That'd be quite a bit of IH modification to make it
> preserve > 1 type for a given property.
Not that bad. IH already favor setters for anything that's not a
string over a plain String setter. But IH already is a pretty complex
beast ...
> I can't decide what would be the best all-around solution, but it
> does seem that if we overloaded the same property setters with File
> and Resource, it might be easiest overall to add explicit code that
> setSrc(File) won't override setSrc(Resource) in IH (maybe no type
> can override a Resource),
would be easy, similar code already exists in IH.
> then default to FileResources as planned.
OK.
>> > However I'm not sure what the RIGHT "trigger character" is and
>> > IMO this is the only outstanding question stopping us from adding
>> > this feature to Ant.
>>
>> bikeshedding? 8-)
>
> I get those little allegories mixed up. Is that the
> one where we can blab back and forth forever, but
> ultimately whoever is doing the work can make the
> choice?
Not really. It means we might be spending too much energy on
discussing minor details (the color of the bike shed) while there are
bigger problems to tackle.
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>
Even though you sounded as if the choice of character was the only
thing that prevented us from implementing the feature, I was not
accusing anybody of wasting our time. I was joking.
> Actually, globmapper doesn't seem to support ?. ;)
Ack, I should have known that. The regexp mapper does, though ;-)
>> OK, what is left? "#", "="? Or
>> "url(http://www.apache.org/)"?
>
> I kind of liked the parentheses thing when I saw it...
> I wonder if it looks too much like a method call.
parens might look strange when use in a regexp mapper, curly braces
might be better and they don't even look like a method call.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: String -> Ressource (was Re: archivefileset resources)
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 21 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > I think what is needed is a well-known syntax
> specification for
> > specifying a string representation of
> [resource-type][String to pass
> > to constructor] e.g. "file?/foo/bar.baz",
> > "url?http://www.apache.org", "string?blah blah
> blah".
>
> This is so I can say
>
> <unzip
>
>
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
>
> instead of
>
> <unzip>
> <url
>
url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
> </unzip>
>
> right?
Yes; additionally, and more usefully perhaps:
<echo output="file?foo">foo</echo>
as a replacement for
<echo file="foo">foo</echo>
In general I suppose I have always seen this concept
as being most useful for specifying output either with
tasks' attributes/properties or with mappers. Then
again, anyplace the resource could be specified in
this inline fashion suggests higher ease-of-use;
overriding a property from the command line could use
an entirely different resource as source, destination,
etc. for a given operation.
>
> Sounds right.
>
> > One may recall this as something I've been after
> for awhile--I
> > consider it the "next step" for resource handling
> in Ant. For code
> > compartmentalization we could probably add the
> code to generate a
> > Resource from a String to ResourceUtils, but IH
> would know how to
> > use e.g. RU.getResource(Project, String) to set
> Resource attributes
>
> I guess we'd need something dynamic, i.e. there has
> to be a way to
> register a ressource prefix with RU so that I can
> have string
> representations for my own ressource types.
>
I had assumed we could specify things in such a way as
to specify the resource type simply by its typedef,
but I suppose a shortcoming of doing it this way is
that for types from antlibs they must be explicitly
typedef'd or have their ns mapped. Well, I suppose
e.g.
antlib:org.foo/customResource?bar
wouldn't be the end of the world, and of course
xmlns:foo="antlib:org.foo"
+
foo:customResource?bar
would be the preferred way of doing this; also having
the long form available would mean one could add an
antlib with -lib, set a property with the long form,
and now custom resources from a given antlib can be
injected into a build that has no knowledge
of/dependency on that antlib. Weird. :)
> > (for BC, FileResource would be the default).
>
> For BC we'd have to keep the File-argument setters
> anyway. IH could
> be changed to use setSrc(Ressource) in favor of
> setSrc(File) and use
> the later if no ressource mapping was found. No
> real need to have a
> default in RU. OTOH it might be convenient for
> users when they can
> simply omit the "file?" prefix for files.
>
That'd be quite a bit of IH modification to make it
preserve > 1 type for a given property. I can't
decide what would be the best all-around solution, but
it does seem that if we overloaded the same property
setters with File and Resource, it might be easiest
overall to add explicit code that setSrc(File) won't
override setSrc(Resource) in IH (maybe no type can
override a Resource), then default to FileResources as
planned. Otherwise IH will have to have its internals
changed quite a bit to maintain knowledge of multiple
potential property types.
> > This is to all intents and purposes the only way,
> IMHO, to seriously
> > take advantage in Ant tasks of our early decision
> to design
> > getOutputStream() into the Resource contract.
> You'll notice my use
> > of the "?" character above to indicate the
> preceding text was the
> > name of a currently available type. I used "?"
> because for xmlns as
> > well as fs reasons I'm pretty sure this character
> should NOT be a
> > colon.
>
> I agree that a colon would be a bad choice, at least
> if we allow file
> ressources to be specified without a prefix. I
> don't really see any
> conflict with xmlns.
This goes back to my idea of simply using the
registered type name to denote the resource desired,
hence the conflict with xmlns if a user were to use a
custom resource in a namespaced antlib. :)
>
> > However I'm not sure what the RIGHT "trigger
> character" is and IMO
> > this is the only outstanding question stopping us
> from adding this
> > feature to Ant.
>
> bikeshedding? 8-)
I get those little allegories mixed up. Is that the
one where we can blab back and forth forever, but
ultimately whoever is doing the work can make the
choice?
>
> "?" isn't pretty but works for me. "@" would
> probably work nicely
> (file@/usr/local/bin/xemacs) but may get unwieldy if
> you use constant
> ressource specifications inside of macrodefs (you'd
> have to double the
> "@"). No obvious choice IMHO, I'd take whatever you
> pick.
>
Agreed wrt @.
> > Aside from allowing IH to transform a String into
> a given Resource,
> > you'll see that tasks using mappers can choose to
> pass the mapped
> > names to this same factory code and work with
> resources, or they can
> > behave as normal and they will break if a user
> tries to map to an
> > arbitrary resource type
>
> Sounds good.
>
> > (assuming its string representation can't be
> misinterpreted as a
> > file, a situation I hope we'll be able to prevent
> esp. by choosing
> > the right "trigger character").
>
> There won't be any such character. AFAIK the only
> forbidden character
> in Unix filenames is a / and this obviously is a
> very bad choice for
> the "trigger". "?" and "*" are unlikely in
> filenames, but both are
> used as wildcards in patterns - now that you mention
> using the string
> representation in mappers:
>
> <globmapper from="file?*.xml"
> to="url?http://home/*.html"/>
>
> Here the "?" might look ambiguos.
Actually, globmapper doesn't seem to support ?. ;)
Also, remember that mapping would ordinarily be
undertaken by passing in getName(), e.g. the part of a
filename beyond the basedir. So ordinarily the full
resource representation wouldn't include the resource
type and all. Really mappers are kind of kludgy as
they require a lot of implicit knowledge on how to use
them--I'm pretty sure there are places in Ant that use
mappers slightly differently anyway. :|
>
> OK, what is left? "#", "="? Or
> "url(http://www.apache.org/)"?
I kind of liked the parentheses thing when I saw it...
I wonder if it looks too much like a method call.
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
String -> Ressource (was Re: archivefileset resources)
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 21 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> I think what is needed is a well-known syntax specification for
> specifying a string representation of [resource-type][String to pass
> to constructor] e.g. "file?/foo/bar.baz",
> "url?http://www.apache.org", "string?blah blah blah".
This is so I can say
<unzip
src="url?http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
instead of
<unzip>
<url url="http://www.apache.org/dist/ant/.../ant-bin-current.zip"/>
</unzip>
right?
Sounds right.
> One may recall this as something I've been after for awhile--I
> consider it the "next step" for resource handling in Ant. For code
> compartmentalization we could probably add the code to generate a
> Resource from a String to ResourceUtils, but IH would know how to
> use e.g. RU.getResource(Project, String) to set Resource attributes
I guess we'd need something dynamic, i.e. there has to be a way to
register a ressource prefix with RU so that I can have string
representations for my own ressource types.
> (for BC, FileResource would be the default).
For BC we'd have to keep the File-argument setters anyway. IH could
be changed to use setSrc(Ressource) in favor of setSrc(File) and use
the later if no ressource mapping was found. No real need to have a
default in RU. OTOH it might be convenient for users when they can
simply omit the "file?" prefix for files.
> This is to all intents and purposes the only way, IMHO, to seriously
> take advantage in Ant tasks of our early decision to design
> getOutputStream() into the Resource contract. You'll notice my use
> of the "?" character above to indicate the preceding text was the
> name of a currently available type. I used "?" because for xmlns as
> well as fs reasons I'm pretty sure this character should NOT be a
> colon.
I agree that a colon would be a bad choice, at least if we allow file
ressources to be specified without a prefix. I don't really see any
conflict with xmlns.
> However I'm not sure what the RIGHT "trigger character" is and IMO
> this is the only outstanding question stopping us from adding this
> feature to Ant.
bikeshedding? 8-)
"?" isn't pretty but works for me. "@" would probably work nicely
(file@/usr/local/bin/xemacs) but may get unwieldy if you use constant
ressource specifications inside of macrodefs (you'd have to double the
"@"). No obvious choice IMHO, I'd take whatever you pick.
> Aside from allowing IH to transform a String into a given Resource,
> you'll see that tasks using mappers can choose to pass the mapped
> names to this same factory code and work with resources, or they can
> behave as normal and they will break if a user tries to map to an
> arbitrary resource type
Sounds good.
> (assuming its string representation can't be misinterpreted as a
> file, a situation I hope we'll be able to prevent esp. by choosing
> the right "trigger character").
There won't be any such character. AFAIK the only forbidden character
in Unix filenames is a / and this obviously is a very bad choice for
the "trigger". "?" and "*" are unlikely in filenames, but both are
used as wildcards in patterns - now that you mention using the string
representation in mappers:
<globmapper from="file?*.xml" to="url?http://home/*.html"/>
Here the "?" might look ambiguos.
OK, what is left? "#", "="? Or "url(http://www.apache.org/)"?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> Sorry for dropping the ball.
>
Not a problem. To add another metaphor to the
conversation, my plate's been so full lately I seem to
be dropping various balls... ;)
> On Tue, 6 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
> > --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> If you go that route, could you please extract
> the supporting
> >> methods into an interface that would allow other
> implementations to
> >> return ressources that change their names when
> used? Something
> >> like
> >>
> >> <mappedressource>
> >> <fileset refid="foo"/>
> >> <globmapper from="*.java" to="*.class"/>
> >> </mappedressource>
> >>
> >> which would return all files from the fileset and
> map the names of
> >> them (by returning Ressources that implement the
> new interface).
> >
> > This sounds like the feature Alexey has been
> demanding
> > all these years. ;)
>
> Possibly. But it is a bit tricky, I'm afraid.
>
> We would want to have a FileRessource remain a
> FileRessource even when
> mapping them - same for the other subclasses of
> Ressource. Some kind
> of factory would be needed and using an intferface
> instead of creating
> yet another subclass of Ressource (or a couple of
> them) might help.
Are you suggesting dynamic proxies here?
I think this implicit RC mapping question does after
all differ from Alexey's request; however I let myself
misunderstand the direction of this thread and be led
down the path of composing a large diatribe on THAT
suject, which follows: Wrt explicitly mapped
resourcecollections I think what is needed is a
well-known syntax specification for specifying a
string representation of [resource-type][String to
pass to constructor] e.g. "file?/foo/bar.baz",
"url?http://www.apache.org", "string?blah blah blah".
One may recall this as something I've been after for
awhile--I consider it the "next step" for resource
handling in Ant. For code compartmentalization we
could probably add the code to generate a Resource
from a String to ResourceUtils, but IH would know how
to use e.g. RU.getResource(Project, String) to set
Resource attributes (for BC, FileResource would be the
default). This is to all intents and purposes the
only way, IMHO, to seriously take advantage in Ant
tasks of our early decision to design
getOutputStream() into the Resource contract. You'll
notice my use of the "?" character above to indicate
the preceding text was the name of a currently
available type. I used "?" because for xmlns as well
as fs reasons I'm pretty sure this character should
NOT be a colon. However I'm not sure what the RIGHT
"trigger character" is and IMO this is the only
outstanding question stopping us from adding this
feature to Ant. Aside from allowing IH to transform a
String into a given Resource, you'll see that tasks
using mappers can choose to pass the mapped names to
this same factory code and work with resources, or
they can behave as normal and they will break if a
user tries to map to an arbitrary resource type
(assuming its string representation can't be
misinterpreted as a file, a situation I hope we'll be
able to prevent esp. by choosing the right "trigger
character").
Back to our regularly scheduled content...
>
> > But to do this with an interface means its
> consumers would have to
> > check for it explicitly; put another way, that all
> resource
> > consumers would not immediately benefit. If we
> implemented the
> > name-mapping behavior such that it simple overrode
> getName(), the
> > consequent question is why have an interface at
> all?
>
> The interface could provide access to the original
> name and override
> getName().
I think I knew that's what you meant... again, to
implement MappedResource while remaining a
FileResource, dynamic... subclasses? Eek! Surely we
can't go there... maybe we'd better rethink the
"instanceof FileResource" idiom instead, e.g.
isFilesystemResource()? Fortunately Resource is a
class instead of an interface which greatly increases
our freedom. Then again, because Resource is a class
we pretty much have no choice but to use dynamic
subclasses if we must go this route. cglib
dependencies, plus have you seen cglib? There's no
javadoc--obviously the lib works but I certainly
wasn't able to fathom it. But if we simply added
isFilesystemResource() to Resource, couldn't a
MappedResource just delegate to the original? Might
that be enough?
>
> But before you dare to override getName, better
> check usage patterns
> in existing tasks. I wouldn't be surprised if we
> still had tasks that
> used "new File(parentDir, ressource.getName())" or
> something similar
> and expected the file to exist.
I don't know. I don't think Resources were in
extremely wide use until the 1.7 branch, and again,
this is the type of problem that is extremely unlikely
to simply arise at runtime--the build writer should
have plenty of time to figure out "doh, <foo> doesn't
seem to support X resource...". I think adequate
disclaimers and warnings should suffice in these
cases.
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Stefan Bodewig <bo...@apache.org>.
Sorry for dropping the ball.
On Tue, 6 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> If you go that route, could you please extract the supporting
>> methods into an interface that would allow other implementations to
>> return ressources that change their names when used? Something
>> like
>>
>> <mappedressource>
>> <fileset refid="foo"/>
>> <globmapper from="*.java" to="*.class"/>
>> </mappedressource>
>>
>> which would return all files from the fileset and map the names of
>> them (by returning Ressources that implement the new interface).
>
> This sounds like the feature Alexey has been demanding
> all these years. ;)
Possibly. But it is a bit tricky, I'm afraid.
We would want to have a FileRessource remain a FileRessource even when
mapping them - same for the other subclasses of Ressource. Some kind
of factory would be needed and using an intferface instead of creating
yet another subclass of Ressource (or a couple of them) might help.
> But to do this with an interface means its consumers would have to
> check for it explicitly; put another way, that all resource
> consumers would not immediately benefit. If we implemented the
> name-mapping behavior such that it simple overrode getName(), the
> consequent question is why have an interface at all?
The interface could provide access to the original name and override
getName().
But before you dare to override getName, better check usage patterns
in existing tasks. I wouldn't be surprised if we still had tasks that
used "new File(parentDir, ressource.getName())" or something similar
and expected the file to exist.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Javac return status
Posted by Steve Loughran <st...@apache.org>.
euge wrote:
> May be it's not the place to write my question. If yes, I'm sorry.
>
> Why is it not allowed to put javac in condition tag? Is there any reason
> why it was not developed? or the developers did not just get to it yet?
>
> Asking just out of curiosity.
Ant has a very simple view of the world. Either things compile, or they
dont. Not compiling is an error and the build halts. Most tasks are like
this, though a fair few have a failonerror to say "ignore failures".
<junit> does save its outcome, not because you want to ignore the
failures, but to let you create <junitreport> output before failing.
If you go to ant-contrib on sourceforge.net, you can pick up their
try/catch tasks that let you catch a task failure.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Javac return status
Posted by euge <m4...@gmail.com>.
May be it's not the place to write my question. If yes, I'm sorry.
Why is it not allowed to put javac in condition tag? Is there any reason why
it was not developed? or the developers did not just get to it yet?
Asking just out of curiosity.
thank you
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 2 Mar 2007, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > I noticed that in order to pick the archivefileset
> parameters on
> > e.g. <tar> (I'm assuming zip and family work this
> way as well) the
> > archivefileset has to be a direct child of the
> archive task. This
> > means that specifying e.g.
> >
> > <resources id="archiveResources">
> > <fileset dir="foo" excludes="bar" />
> > <tarfileset file="bar" fullpath="special/bar" />
> > </resources>
> >
> > doesn't work as I would expect.
>
> True. The prefix and fullpath attributes only work
> in tasks that have
> special handling for ArchiveFileSets and those in
> turn need to know
> there is a ArchiveFileSet somewhere nested in them -
> which they don't
> if you wrap the fileset.
>
> > Is it agreed that <tar>'s ignoring the fullpath of
> bar is
> > undesirable?
>
> +1
>
> > If so it would seem we'd need perhaps an
> ArchiveResource interface
> > to carry along the parameters from the parent
> ArchiveFileSet, etc.,
> > etc?
>
> They already carry the permission bits so adding the
> prefix and
> fullpath stuff seems logical (don't know why I
> didn't add them right
> away).
>
> Maybe a single method would even be enough and we
> don't need to have
> separate accessors for fullpath and prefix. Just a
> different getName
> method (don't know how to call it) that returned the
> name after
> fullpath or prefix has been applied.
>
> If you go that route, could you please extract the
> supporting methods
> into an interface that would allow other
> implementations to return
> ressources that change their names when used?
> Something like
>
> <mappedressource>
> <fileset refid="foo"/>
> <globmapper from="*.java" to="*.class"/>
> </mappedressource>
>
> which would return all files from the fileset and
> map the names of
> them (by returning Ressources that implement the new
> interface).
This sounds like the feature Alexey has been demanding
all these years. ;) But to do this with an interface
means its consumers would have to check for it
explicitly; put another way, that all resource
consumers would not immediately benefit. If we
implemented the name-mapping behavior such that it
simple overrode getName(), the consequent question is
why have an interface at all? Possibly to provide
access to the original resource name? WDYT?
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: archivefileset resources
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 2 Mar 2007, Matt Benson <gu...@yahoo.com> wrote:
> I noticed that in order to pick the archivefileset parameters on
> e.g. <tar> (I'm assuming zip and family work this way as well) the
> archivefileset has to be a direct child of the archive task. This
> means that specifying e.g.
>
> <resources id="archiveResources">
> <fileset dir="foo" excludes="bar" />
> <tarfileset file="bar" fullpath="special/bar" />
> </resources>
>
> doesn't work as I would expect.
True. The prefix and fullpath attributes only work in tasks that have
special handling for ArchiveFileSets and those in turn need to know
there is a ArchiveFileSet somewhere nested in them - which they don't
if you wrap the fileset.
> Is it agreed that <tar>'s ignoring the fullpath of bar is
> undesirable?
+1
> If so it would seem we'd need perhaps an ArchiveResource interface
> to carry along the parameters from the parent ArchiveFileSet, etc.,
> etc?
They already carry the permission bits so adding the prefix and
fullpath stuff seems logical (don't know why I didn't add them right
away).
Maybe a single method would even be enough and we don't need to have
separate accessors for fullpath and prefix. Just a different getName
method (don't know how to call it) that returned the name after
fullpath or prefix has been applied.
If you go that route, could you please extract the supporting methods
into an interface that would allow other implementations to return
ressources that change their names when used? Something like
<mappedressource>
<fileset refid="foo"/>
<globmapper from="*.java" to="*.class"/>
</mappedressource>
which would return all files from the fileset and map the names of
them (by returning Ressources that implement the new interface).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org