lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3930) nuke jars from source tree and use ivy
Date Thu, 29 Mar 2012 03:04:24 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message