You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/06/06 09:43:41 UTC
Re: DO NOT REPLY [Bug 28228] - task
On Thu, 2 Jun 2005, <bu...@apache.org> wrote:
> 1) the task import sun.import sun.misc.Launcher and import
> sun.misc.URLClassPath. It would be better not to import sun.*
> classes in non-optional tasks.
Well, at least it compiles on Kaffe, so those classes seem to get used
by others as well.
> A solution to this would be make the report function a seperate
> optional task.
If we really only use them for reporting, then splitting the task is
the best option, I agree.
> 2) the task could check if a jar or directort is already in a in the
> classpath
Yep.
> 3) the doc could state that use of this task in ides that do not
> have a separate jvm for a run of ant will cause issues
The should state that this task will cause many issues no matter how
you run Ant - unless you really know what you do ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: DO NOT REPLY [Bug 28228] - task
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 6 Jun 2005, Rainer Noack <ra...@noacks.net> wrote:
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>> Well, at least it compiles on Kaffe, so those classes seem to
>> get used by others as well.
>
> Do they work?
No idea. The Kaffe Gump runs (currently disabled) used to build them,
but don't have any unit tests so it's hard to tell.
> However, referring sun.* classes is not a good practice in general.
Absolutely.
>> > 2) the task could check if a jar or directort is already in
>> > a in the
>> > classpath
>>
>> Yep.
>
> +1 but IMHO this behaviour should be switchable as there a
> imaginable cases
> where it is not desired.
> However, if we want to have this feature, we should use the
> getBootstrapClasspathUrls-functionality (see 1) for this
> feature too.
I see. On Sun VMs using sun.boot.classpath is probably as reliable as
using the sun.* classes.
>> The should state that this task will cause many issues no
>> matter how you run Ant - unless you really know what you do ;-)
>
> "... sometimes it is helpful to know what you do ..." (A former
> collegue) ;-)
Let me stretch the "really" in my sentence above. 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: DO NOT REPLY [Bug 28228] - task
Posted by Rainer Noack <ra...@noacks.net>.
Peter, Stefan,
sounds reasonable.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Monday, June 06, 2005 9:44 AM
> To: dev@ant.apache.org
> Subject: Re: DO NOT REPLY [Bug 28228] - <classloader> task
>
>
> On Thu, 2 Jun 2005, <bu...@apache.org> wrote:
>
> > 1) the task import sun.import sun.misc.Launcher and import
> > sun.misc.URLClassPath. It would be better not to import
> sun.* classes
> > in non-optional tasks.
>
> Well, at least it compiles on Kaffe, so those classes seem to
> get used by others as well.
Do they work?
I've not much experience with non-Sun jvms/jres.
However, referring sun.* classes is not a good practice in general.
> > A solution to this would be make the report function a seperate
> > optional task.
But isn't moving report-function to the optional category just a cosmetic
operation?
What do you think about moving the functionality "getBootstrapClasspathUrls"
into JavaEnvUtils and do it there via reflection. If it fails, the
util-method should return null. The calling application has to check this
and log it as warning.
We can also add tests for the both classes in
JavaEnvUtils.getJrePackageTestCases.
Or is there a better location for this functionality?
> If we really only use them for reporting, then splitting the
> task is the best option, I agree.
see next comment.
> > 2) the task could check if a jar or directort is already in
> a in the
> > classpath
>
> Yep.
+1 but IMHO this behaviour should be switchable as there a imaginable cases
where it is not desired.
However, if we want to have this feature, we should use the
getBootstrapClasspathUrls-functionality (see 1) for this
feature too.
> > 3) the doc could state that use of this task in ides that do not
> > have a separate jvm for a run of ant will cause issues
Absolutely!
> The should state that this task will cause many issues no
> matter how you run Ant - unless you really know what you do ;-)
"... sometimes it is helpful to know what you do ..." (A former collegue)
;-)
Rainer
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org