Re: import task from a resource
--- Mariano Benitez [EMAIL PROTECTED] wrote: In order to solve a problem related to classloaders, I need to bundle an include file (include.xml) so I can define the task in a classpath different from the antlib classpath. [SNIP] I can implement this and provide the patch, is this valid or am I talking nonsense. I don't know, couldn't you just use a separate antlib? -Matt __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import task from a resource
there was a long thread with this issue, you can check it , the last
mail is below:
bottomline is that I cannot put a lot of jars in the antlib directory
(-lib ...) and I need them for the tasks, so we come out with this solution.
MAriano
--
do you imply here that when you use typedef with an already defined
uri, being that an antlib uri, that it will add those definitions to the
antlib uri?
in your sample you are adding definitions to the antlib you are defining
there, is that correct?
MAriano
Peter Reilly wrote:
Hi Mariano,
You are right that one can specify the classpath within an antlib,
and it is incorrectly silently ignored.
There would be a problem with using properties as one would need
to be very carefull to specify them before the antlib auto reading
is triggered.
With the current ant implementation you can achieve most of what you want
by using an typedef/ with the resource and uri attributes, and hide
this
in an imported file:
project xmlns:nytask=antlib:net.sf.nytasker
property name=nytasker.dir
location=${user.home}/apps/nytasker/dist/
import file=${nytasker.dir}/nytasker.xml/
nytask:jmessage message=Press Yes to continue/
/project
Where nytasker.xml looks something like this:
project name=nytasker
typedef resource=net/sf/nytasker/antlib.xml
uri=antlib:net.sf.nytasker
classpath
fileset dir=${nytasker.dir}/lib includes=*.jar/
/classpath
/typedef
/project
Peter
Mariano Benitez wrote:
would it be very crazy to add a classpath atlibdefinition that would
add jars to the antlib classpath instead of getting ALL the jars from
a directory.
My problem is that I would like to keep only the task definitions in
the antlib directory and the other dependent jars in a common lib
directory with other jars that should not be loaded by the antlib
class loader. Besides, the files location is defined based on
properties, I cannot know that location when ant starts.
I will investigate a bit on that to see if it is easy to implement
another antlibdefinition class for this.
MAriano
Mariano Benitez wrote:
Hi!
Is it possible to define another classpath for a task definition
inside an antlib?
I've read the Definer class and if it is inside an antlib, it uses
that classloader instead of creating a new one with the additional
jars.
Is this desired behaviour? if it is, you should log a warning saying
that whatever you define as classpath in an antlib.xml is not
considered.
Otherwise, I will report the bug
MAriano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Matt Benson wrote:
--- Mariano Benitez [EMAIL PROTECTED] wrote:
In order to solve a problem related to classloaders,
I need to bundle an
include file (include.xml) so I can define the task
in a classpath
different from the antlib classpath.
[SNIP]
I can implement this and provide the patch, is this
valid or am I
talking nonsense.
I don't know, couldn't you just use a separate antlib?
-Matt
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: import task from a resource
From: Mariano Benitez [mailto:[EMAIL PROTECTED] In order to solve a problem related to classloaders, I need to bundle an include file (include.xml) so I can define the task in a classpath different from the antlib classpath. At this moment the only way is to put the file in the FS, but it would be very convenient to obtain that import from a resource in the antlib jar. I can implement this and provide the patch, is this valid or am I talking nonsense. This was considered during the discussions on import, but didn't make it, I don't recall why. Maybe had to do with keeping import simple, and problems extracting the basedir of the imported file!? You can always get the URL before import. Oops, you need a custom resource: protocol handler for that... I posted one, but it requires additional setup so the JVM knows about it. You can always write a little script to dump the URL on disk before the import still. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import task from a resource
that is way too much, I wanted a simpler solution FOR ME, not for the import task. Anyway, the basedir attribute, isn't inherited from the importing build? MAriano Dominique Devienne wrote: From: Mariano Benitez [mailto:[EMAIL PROTECTED] In order to solve a problem related to classloaders, I need to bundle an include file (include.xml) so I can define the task in a classpath different from the antlib classpath. At this moment the only way is to put the file in the FS, but it would be very convenient to obtain that import from a resource in the antlib jar. I can implement this and provide the patch, is this valid or am I talking nonsense. This was considered during the discussions on import, but didn't make it, I don't recall why. Maybe had to do with keeping import simple, and problems extracting the basedir of the imported file!? You can always get the URL before import. Oops, you need a custom resource: protocol handler for that... I posted one, but it requires additional setup so the JVM knows about it. You can always write a little script to dump the URL on disk before the import still. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import task from a resource
--- Mariano Benitez [EMAIL PROTECTED] wrote: that is way too much, I wanted a simpler solution FOR ME, not for the import task. Anyway, the basedir attribute, isn't inherited from the importing build? No, see import's manual page... -Matt __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: import task from a resource
if you mean this: quote Imported files are treated as they are present in the main buildfile. This makes it easy to understand, but it makes it impossible for them to reference files and resources relative to their path. Because of this, for every imported file, Ant adds a property that contains the path to the imported buildfile. With this path, the imported buildfile can keep resources and be able to reference them relative to its position. I can live without it, I mean, if you import a file from a resource, don't add the ant.imported.file property that and make all references to the original basedir. MAriano Matt Benson wrote: --- Mariano Benitez [EMAIL PROTECTED] wrote: that is way too much, I wanted a simpler solution FOR ME, not for the import task. Anyway, the basedir attribute, isn't inherited from the importing build? No, see import's manual page... -Matt __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
