You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2012/09/28 12:01:07 UTC
[jira] [Created] (LUCENE-4445) Fix clover to correcty instrument
all packages, improve permgen
Uwe Schindler created LUCENE-4445:
-------------------------------------
Summary: Fix clover to correcty instrument all packages, improve permgen
Key: LUCENE-4445
URL: https://issues.apache.org/jira/browse/LUCENE-4445
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Affects Versions: 4.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.1, 5.0
Attachments: LUCENE-4445.patch
This is a very stupid problem, but after a long time sitting in fornt of the build.xml's I found it:
1. The biggest problem was: the target "-clover.init" was made in a way that it used the clover.loaded sysprop to avoid permgen issues. Unfortunatley it not only loaded clover, it also set it up in this task (setting the java source file folders). If the taskdef was then loaded for the first time, it had its source folders set up with the module it was called first. The later coming compilation of another module did not run clover.setup anymore, so no new source folders were configured. I splitted the IVY-Load+Taskdef from the clover setup.
2. I also improved the code duplication for compile in test-framework. I made it inherit from common-build, but disable clover instrumentation for test-framework by overriding -clover.setup target in the test-frameworks (Lucene+Solr).
3. I fixed some permgen issues, so -clover.load is only executed onec. I had to use a trick to pass the classpath to ivy's cachepath down to the subants, because we don't inherit refs. The trick was to make the clover.loaded property contain a stringified version of the clover classpath instead of a simple "true". By that it is automatically passed down using the propertyset.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
[jira] [Resolved] (LUCENE-4445) Fix clover to correcty instrument
all packages, improve permgen
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler resolved LUCENE-4445.
-----------------------------------
Resolution: Fixed
Committed trunk revision: 1391382
Committed 4.x revision: 1391383
I did not commit to 4.0 branch. We can backport this once we setup jenkins runs before a 4.0.1 release (if we want clover).
> Fix clover to correcty instrument all packages, improve permgen
> ---------------------------------------------------------------
>
> Key: LUCENE-4445
> URL: https://issues.apache.org/jira/browse/LUCENE-4445
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/test
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4445.patch
>
>
> This is a very stupid problem, but after a long time sitting in fornt of the build.xml's I found it:
> 1. The biggest problem was: the target "-clover.init" was made in a way that it used the clover.loaded sysprop to avoid permgen issues. Unfortunatley it not only loaded clover, it also set it up in this task (setting the java source file folders). If the taskdef was then loaded for the first time, it had its source folders set up with the module it was called first. The later coming compilation of another module did not run clover.setup anymore, so no new source folders were configured. I splitted the IVY-Load+Taskdef from the clover setup.
> 2. I also improved the code duplication for compile in test-framework. I made it inherit from common-build, but disable clover instrumentation for test-framework by overriding -clover.setup target in the test-frameworks (Lucene+Solr).
> 3. I fixed some permgen issues, so -clover.load is only executed onec. I had to use a trick to pass the classpath to ivy's cachepath down to the subants, because we don't inherit refs. The trick was to make the clover.loaded property contain a stringified version of the clover classpath instead of a simple "true". By that it is automatically passed down using the propertyset.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
[jira] [Updated] (LUCENE-4445) Fix clover to correcty instrument
all packages, improve permgen
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-4445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-4445:
----------------------------------
Attachment: LUCENE-4445.patch
> Fix clover to correcty instrument all packages, improve permgen
> ---------------------------------------------------------------
>
> Key: LUCENE-4445
> URL: https://issues.apache.org/jira/browse/LUCENE-4445
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/test
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 4.1, 5.0
>
> Attachments: LUCENE-4445.patch
>
>
> This is a very stupid problem, but after a long time sitting in fornt of the build.xml's I found it:
> 1. The biggest problem was: the target "-clover.init" was made in a way that it used the clover.loaded sysprop to avoid permgen issues. Unfortunatley it not only loaded clover, it also set it up in this task (setting the java source file folders). If the taskdef was then loaded for the first time, it had its source folders set up with the module it was called first. The later coming compilation of another module did not run clover.setup anymore, so no new source folders were configured. I splitted the IVY-Load+Taskdef from the clover setup.
> 2. I also improved the code duplication for compile in test-framework. I made it inherit from common-build, but disable clover instrumentation for test-framework by overriding -clover.setup target in the test-frameworks (Lucene+Solr).
> 3. I fixed some permgen issues, so -clover.load is only executed onec. I had to use a trick to pass the classpath to ivy's cachepath down to the subants, because we don't inherit refs. The trick was to make the clover.loaded property contain a stringified version of the clover classpath instead of a simple "true". By that it is automatically passed down using the propertyset.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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