ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer Noack" <rai...@noacks.net>
Subject RE: DO NOT REPLY [Bug 28228] - <classloader> task
Date Mon, 06 Jun 2005 19:22:13 GMT
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, <bugzilla@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


Mime
View raw message