[
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240943#comment-13240943
]
Hoss Man commented on LUCENE-3930:
----------------------------------
as far as the PermGen OOM goes, the -verbose logs show repeated instances of
"Trying to override old definition of task antlib:org.apache.ivy.ant:..."
suggesting that rmuir's {{unless="ivy.uptodate"}} isn't working the way we
think it should (possibly because of the way the various build files are
included in one another?)
If we can't keep the {{<taskdef/}} from running multiple times, we _might_ be
able to force it to use the same class loader each time, per the ant docs...
https://ant.apache.org/manual/Tasks/typedef.html
{quote}
If you are defining tasks or types that share the same classpath with multiple
taskdef or typedef tasks, the corresponding classes will be loaded by different
Java ClassLoaders. Two classes with the same name loaded via different
ClassLoaders are not the same class from the point of view of the Java VM, they
don't share static variables and instances of these classes can't access
private methods or attributes of instances defined by "the other class" of the
same name. They don't even belong to the same Java package and can't access
package private code, either.
The best way to load several tasks/types that are supposed to cooperate with
each other via shared Java code is to use the resource attribute and an antlib
descriptor. If this is not possible, the second best option is to use the
loaderref attribute and specify the same name for each and every
typedef/taskdef - this way the classes will share the same ClassLoader. Note
that the typedef/taskdef tasks must use identical classpath defintions (this
includes the order of path components) for the loaderref attribute to work.
{quote}
...it appears it's just some unique string key to name the classloader? (no
idea if it whatever is causing hte current problem will still plague by
creating multiple loaders with the same name)...
https://svn.apache.org/viewvc/ant/core/tags/ANT_171/src/etc/testcases/core/loaderref/
> nuke jars from source tree and use ivy
> --------------------------------------
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
> Reporter: Robert Muir
> Assignee: Robert Muir
> Priority: Blocker
> Fix For: 3.6
>
> Attachments: LUCENE-3930-solr-example.patch,
> LUCENE-3930-solr-example.patch, LUCENE-3930.patch, LUCENE-3930.patch,
> LUCENE-3930.patch, ant_-verbose_clean_test.out.txt
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
