[jira] (MANT-65) Invalid check for junit
[
https://jira.codehaus.org/browse/MANT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MANT-65.
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Olivier Lamy
http://svn.apache.org/r1410606
Thanks !
> Invalid check for junit
> ---
>
> Key: MANT-65
> URL: https://jira.codehaus.org/browse/MANT-65
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: SebbASF
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: AntBuildWriter.java.patch, AntBuildWriter.java.patch
>
>
> The generated Ant build file adds junit to the build.test.classpath.
> However, the check for JUnit does not use the classpath:
> {code}
>
>
>
> {code}
> This should be changed to:
> {code}
>
>classpathref="build.test.classpath"/>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5245) upgrade default plugins versions
[ https://jira.codehaus.org/browse/MNG-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNG-5245. - Resolution: Fixed http://svn.apache.org/r1410570 > upgrade default plugins versions > > > Key: MNG-5245 > URL: https://jira.codehaus.org/browse/MNG-5245 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5245) upgrade default plugins versions
[ https://jira.codehaus.org/browse/MNG-5245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313780#comment-313780 ] Karl Heinz Marbaise commented on MNG-5245: -- upgrade done in r1410570 (by Kristian Rosenvold). - components.xml - maven-clean-plugin up to 2.5 - maven-site-plugin up to 3.1 - default-bindings.xml - maven-install-plugin up to 2.4 - maven-resources-plugin up to 2.6 - maven-compiler-plugin up to 2.5.1 - maven-surefire-plugin up to 2.12.4 - maven-jar-plugin up to 2.4 - maven-plugin-pugin up to 3.2 - maven-war-plugin up to 2.3 - maven-ear-plugin up to 2.8 > upgrade default plugins versions > > > Key: MNG-5245 > URL: https://jira.codehaus.org/browse/MNG-5245 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.
[ https://jira.codehaus.org/browse/MSITE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MSITE-665: Attachment: msp-3.2.log Output executing 'mvn package' with 'maven-site-plugin-3.2'. > Site plugin version 3.2 seems to modify a project's classpath. > -- > > Key: MSITE-665 > URL: https://jira.codehaus.org/browse/MSITE-665 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.2 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Java version: 1.7.0_03, vendor: Oracle Corporation >Reporter: Christian Schulte >Priority: Blocker > Attachments: MSITE-665.zip, msp-3.1.log, msp-3.2.log > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.
[ https://jira.codehaus.org/browse/MSITE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte updated MSITE-665: Attachment: msp-3.1.log Output executing 'mvn package' with 'maven-site-plugin-3.1'. > Site plugin version 3.2 seems to modify a project's classpath. > -- > > Key: MSITE-665 > URL: https://jira.codehaus.org/browse/MSITE-665 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.2 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Java version: 1.7.0_03, vendor: Oracle Corporation >Reporter: Christian Schulte >Priority: Blocker > Attachments: MSITE-665.zip, msp-3.1.log > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.
[
https://jira.codehaus.org/browse/MSITE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MSITE-665:
Attachment: MSITE-665.zip
Example project demonstrating the issue. Executing 'mvn package' produces the
following warnings during 'Generating "Test JavaDocs" report'.
{code}
10 warnings
[WARNING] Javadoc Warnings
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:3: error: package
org.junit does not exist
[WARNING] import org.junit.Test;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:4: error: package
org.junit does not exist
[WARNING] import static org.junit.Assert.assertTrue;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:4: error: static
import only from classes and interfaces
[WARNING] import static org.junit.Assert.assertTrue;
[WARNING] ^
[WARNING] /tmp/MSITE-665/src/test/java/msite665/AppTest.java:15: error: cannot
find symbol
[WARNING] @Test
[WARNING] ^
[WARNING] symbol: class Test
[WARNING] location: class AppTest
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
[WARNING] javadoc: warning - Class Test not found.
{code}
Downgrading the site plugin from 3.2 to 3.1 no such warnings are shown.
> Site plugin version 3.2 seems to modify a project's classpath.
> --
>
> Key: MSITE-665
> URL: https://jira.codehaus.org/browse/MSITE-665
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Java version: 1.7.0_03, vendor: Oracle Corporation
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MSITE-665.zip
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-665) Site plugin version 3.2 seems to modify a project's classpath.
Christian Schulte created MSITE-665: --- Summary: Site plugin version 3.2 seems to modify a project's classpath. Key: MSITE-665 URL: https://jira.codehaus.org/browse/MSITE-665 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.2 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Java version: 1.7.0_03, vendor: Oracle Corporation Reporter: Christian Schulte Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5379) Site plugin version 3.2 seems to modify a project's classpath.
[ https://jira.codehaus.org/browse/MNG-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schulte closed MNG-5379. -- Resolution: Won't Fix Accidentally reported against Maven itself. Issue belongs to Maven Site plugin. > Site plugin version 3.2 seems to modify a project's classpath. > -- > > Key: MNG-5379 > URL: https://jira.codehaus.org/browse/MNG-5379 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.2 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Java version: 1.7.0_03, vendor: Oracle Corporation >Reporter: Christian Schulte >Priority: Blocker > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5379) Site plugin version 3.2 seems to modify a project's classpath.
Christian Schulte created MNG-5379: -- Summary: Site plugin version 3.2 seems to modify a project's classpath. Key: MNG-5379 URL: https://jira.codehaus.org/browse/MNG-5379 Project: Maven 2 & 3 Issue Type: Bug Components: General Affects Versions: 3.2 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Java version: 1.7.0_03, vendor: Oracle Corporation Reporter: Christian Schulte Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5375) Document use of SLF4J
[ https://jira.codehaus.org/browse/MNG-5375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313759#comment-313759 ] Jason van Zyl commented on MNG-5375: Finished first version. > Document use of SLF4J > -- > > Key: MNG-5375 > URL: https://jira.codehaus.org/browse/MNG-5375 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5375) Document use of SLF4J
[ https://jira.codehaus.org/browse/MNG-5375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-5375. -- Resolution: Fixed > Document use of SLF4J > -- > > Key: MNG-5375 > URL: https://jira.codehaus.org/browse/MNG-5375 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANT-65) Invalid check for junit
[
https://jira.codehaus.org/browse/MANT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin O'Connor updated MANT-65:
Attachment: AntBuildWriter.java.patch
> Invalid check for junit
> ---
>
> Key: MANT-65
> URL: https://jira.codehaus.org/browse/MANT-65
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: SebbASF
> Attachments: AntBuildWriter.java.patch, AntBuildWriter.java.patch
>
>
> The generated Ant build file adds junit to the build.test.classpath.
> However, the check for JUnit does not use the classpath:
> {code}
>
>
>
> {code}
> This should be changed to:
> {code}
>
>classpathref="build.test.classpath"/>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MANT-65) Invalid check for junit
[
https://jira.codehaus.org/browse/MANT-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin O'Connor updated MANT-65:
Attachment: AntBuildWriter.java.patch
Patch as applied to trunk
> Invalid check for junit
> ---
>
> Key: MANT-65
> URL: https://jira.codehaus.org/browse/MANT-65
> Project: Maven 2.x Ant Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: SebbASF
> Attachments: AntBuildWriter.java.patch
>
>
> The generated Ant build file adds junit to the build.test.classpath.
> However, the check for JUnit does not use the classpath:
> {code}
>
>
>
> {code}
> This should be changed to:
> {code}
>
>classpathref="build.test.classpath"/>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use custom IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313752#comment-313752 ] Tamás Cservenák commented on MINDEXER-67: - scan method removed from new Indexer, returned it to deprecated NexusIndexer: http://svn.apache.org/viewvc?view=revision&revision=1410355 This is a followup from discussion on MINDEXER-65 > Provide means to make MI use custom IndexingContext implementations > --- > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant
[ https://jira.codehaus.org/browse/MINDEXER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313741#comment-313741 ] Tamás Cservenák commented on MINDEXER-39: - Example branch, where MI is "de-plexusized", and javax.inject annotations are applied: https://github.com/cstamas/maven-indexer/commits/javax-inject But still, as MI relies on some Maven components, it cannot be totally plexus-free. Actually, this change made it even more problematic, as it would run in container that supports (as SISU, or at least somehow bridges between) both, plexus and javax.inject components. This is work in progress, the build does not pass, as many UTs are still PlexusTestCase, so more changes needed. > study how to have maven-indexer non plexus/sisu dependant > - > > Key: MINDEXER-39 > URL: https://jira.codehaus.org/browse/MINDEXER-39 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Olivier Lamy > > The current impl is heavy container dependant (plexus/sisu). > It could be nice to have something using pure/standard injection (@Inject). > As it will be easy reusable in other DI container -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-65) Provide a way to scan directly to provided IndexingContext
[ https://jira.codehaus.org/browse/MINDEXER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313738#comment-313738 ] Igor Fedorenko commented on MINDEXER-65: I am not sure DefaultNexusIndexer#scan is useful at all. I would just deprecated it and suggest direct use of scanner instead. > Provide a way to scan directly to provided IndexingContext > -- > > Key: MINDEXER-65 > URL: https://jira.codehaus.org/browse/MINDEXER-65 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 5.0.0 >Reporter: Igor Fedorenko >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > Attachments: > 0001-MINDEXER-65-made-DefaultScannerListener-directly-usa.patch > > > Currently, DefaultNexusIndexer#scan(...) always perform scan to a temporary > indexing context first, then replace the target context with temporary. I > vaguely remember this was necessary to allow index queries while scan was > running in a background thread. With recent rework of indexer locking, the > temporary indexing context is no longer needed and in fact it is harmful when > host application requires tight control over IndexingContext status. > Maven indexer need to provide a way to request scan directly to the target > indexing context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-388) NPE in analyze-report
[
https://jira.codehaus.org/browse/MDEP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313731#comment-313731
]
René Reitmann commented on MDEP-388:
I am running into the same NPE. I am using a multi-module project with Maven
3.0.4 and maven-site-plugin 3.2. Is there any workaround?
> NPE in analyze-report
> -
>
> Key: MDEP-388
> URL: https://jira.codehaus.org/browse/MDEP-388
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 2.5.1
>Reporter: Benson Margulies
>
> Using Maven 3.0.4, and site plugin 3.2, and an execution of the
> analyze-report goal, I get the following NPE. I'm going to go try to make
> some sense and add notes here.
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MECLIPSE-459) missing artifact references with pde mode enabled
[ https://jira.codehaus.org/browse/MECLIPSE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313726#comment-313726 ] Christian Gossart commented on MECLIPSE-459: Same problem here with slf4j-api-1.6.1 which is an OSGi bundle: dependency is not in provided scope, and PDE mode is enabled. I used the patch against the 2.9 tagged source of the plugin, and it worked as expected: the .project and the .classpath contain now the slf4j-api reference. Is there any hope to see this issue fixed in future release? Either not skipping the OSGi artefacts or a config option as proposed by Eugene. Maintaining a custom MEP will not be easy in my current project context. > missing artifact references with pde mode enabled > - > > Key: MECLIPSE-459 > URL: https://jira.codehaus.org/browse/MECLIPSE-459 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath), PDE support >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_11 > OS name: "linux" version: "2.6.15-51-686" arch: "i386" Family: "unix" >Reporter: Benjamin Voigt >Priority: Critical > Attachments: pde_dep_missing.zip, pde.patch.txt > > > Some artifacts are not referenced after executing mvn eclipse:eclipse and > having pde mode enabled. The strange thing is, that this does only happen for > particluar versions of an artifact. > Two artifacts that I found with this problem are jetty (org.mortbay.jetty) > and slf4j-log4j12 (org.slf4j-log4j12). Jetty versions beyond 6.1.5 work with > pde enabled, higher versions do not. Same for slf4j-log4j12 versions =< 1.1.0. > Attached is an example project demonstrating the problem. Turn pde mode > on/off in the pom and execute mvn eclipse:eclipse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-21) Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and grouped search
[ https://jira.codehaus.org/browse/MINDEXER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313724#comment-313724 ] Tamás Cservenák commented on MINDEXER-21: - Fixed in http://svn.apache.org/viewvc?view=revision&revision=1410278 > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search > - > > Key: MINDEXER-21 > URL: https://jira.codehaus.org/browse/MINDEXER-21 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 3.1.0, 4.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search. > The filter and postprocessor is in AbstractSearchRequest class, but only > IteratorSearch "obeys" them, the flat and grouped does not, they simply > ignore it currently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-21) Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and grouped search
[ https://jira.codehaus.org/browse/MINDEXER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-21. --- Resolution: Fixed > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search > - > > Key: MINDEXER-21 > URL: https://jira.codehaus.org/browse/MINDEXER-21 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 3.1.0, 4.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search. > The filter and postprocessor is in AbstractSearchRequest class, but only > IteratorSearch "obeys" them, the flat and grouped does not, they simply > ignore it currently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
[
https://jira.codehaus.org/browse/MINDEXER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313722#comment-313722
]
Tamás Cservenák commented on MINDEXER-63:
-
Also, take a peek at MINDEXER-67
It makes plain simple to implement proper context synchronisation by "wrapping"
created contexts. In this case, the host app, NB in this case) would need to
take over the maintenance, the "registry" role too, but that's pretty straight,
and I believe you already have something similar.
Also, take a peek at nexus example (is still very involved, as it does NOT make
use of MINDEXER-67 yet):
https://github.com/sonatype/nexus/commit/cac960808436d3c1bd18d7ddb7a7587c725717f3#diff-4
> NullPointerException at
> org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
> --
>
> Key: MINDEXER-63
> URL: https://jira.codehaus.org/browse/MINDEXER-63
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
> Environment: netbeans 7.3 dev builds.
>Reporter: Milos Kleint
>Priority: Critical
>
> see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
> for some reason (unknown to me yet) the index files cannot be deleted. The
> codebase then gets into bad state.
> possibly wrong code in DefaultIndexingContext:
> {code:java}
> public synchronized void replace( Directory directory )
> throws IOException
> Â {
> Â Â Â Â final Date ts = IndexUtils.getTimestamp( directory );
> closeReaders();
> Â deleteIndexFiles( false );
> Â IndexUtils.copyDirectory( directory, indexDirectory );
> Â openAndWarmup();
> Â // reclaim the index as mine
> Â storeDescriptor();
> Â updateTimestamp( true, ts );
> Â optimize();
> }
> {code}
> when deleteIndexFiles(0 fails, openAndWarmup() is not called. also
> closeReaders() ignores indexWriter..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
[
https://jira.codehaus.org/browse/MINDEXER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313720#comment-313720
]
Tamás Cservenák commented on MINDEXER-63:
-
This stems from concurrent access improperly synchronised. As I see, you use MI
5, and starting with it, the concurrency and synchronisation should be
implemented by library consumer.
Here, I _guess_ what happens is that you have (what is suggested by stacktraces
in NB bugzilla at least) is that you have concurrent access on context: one
update (that will do IndecingContext#replace in one moment during it's
execution when _full remote update_ happens) and some search probably ("plain"
index read).
This is a known problem with MI (hit us in Nexus too), and Nexus uses following
trick from: _never_ perform full remote update, or (as it is now possible with
MI) exclusively lock the context being remotely updated. Meaning, you have to
ensure no "read" operation happens against it (like searches) in none of the
threads.
Also, see MINDEXER-65 as it actually addresses this same problem, with making
possible to scan() index _without_ hitting IndexingContext#replace method.
> NullPointerException at
> org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
> --
>
> Key: MINDEXER-63
> URL: https://jira.codehaus.org/browse/MINDEXER-63
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
> Environment: netbeans 7.3 dev builds.
>Reporter: Milos Kleint
>Priority: Critical
>
> see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
> for some reason (unknown to me yet) the index files cannot be deleted. The
> codebase then gets into bad state.
> possibly wrong code in DefaultIndexingContext:
> {code:java}
> public synchronized void replace( Directory directory )
> throws IOException
> Â {
> Â Â Â Â final Date ts = IndexUtils.getTimestamp( directory );
> closeReaders();
> Â deleteIndexFiles( false );
> Â IndexUtils.copyDirectory( directory, indexDirectory );
> Â openAndWarmup();
> Â // reclaim the index as mine
> Â storeDescriptor();
> Â updateTimestamp( true, ts );
> Â optimize();
> }
> {code}
> when deleteIndexFiles(0 fails, openAndWarmup() is not called. also
> closeReaders() ignores indexWriter..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-162) skinnyWars with wars without manifest Class-Path attribute
Laszlo Varadi created MEAR-162: -- Summary: skinnyWars with wars without manifest Class-Path attribute Key: MEAR-162 URL: https://jira.codehaus.org/browse/MEAR-162 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Laszlo Varadi Attachments: EarMojo.patch The classpath attribute should be set after populating with values, otherwise the classpath will be empty in the war manifest in case when the attribute is a newly created attribute. See patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-21) Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and grouped search
[ https://jira.codehaus.org/browse/MINDEXER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MINDEXER-21: Fix Version/s: 5.1.0 Assignee: Tamás Cservenák > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search > - > > Key: MINDEXER-21 > URL: https://jira.codehaus.org/browse/MINDEXER-21 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 3.1.0, 4.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Implement ArtifactInfoFilter and ArtifactInfoPostprocessor use in flat and > grouped search. > The filter and postprocessor is in AbstractSearchRequest class, but only > IteratorSearch "obeys" them, the flat and grouped does not, they simply > ignore it currently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed
[
https://jira.codehaus.org/browse/MINDEXER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milos Kleint closed MINDEXER-52.
Resolution: Fixed
Fix Version/s: 5.0.0
yup, I believe so.
> reentrant locking in DefaultIndexingContent flawed
> --
>
> Key: MINDEXER-52
> URL: https://jira.codehaus.org/browse/MINDEXER-52
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Milos Kleint
>Priority: Critical
> Fix For: 5.0.0
>
>
> DefaultIndexingContent.java contains the following pattern:
> {code:java}
> public IndexReader getIndexReader()
> throws IOException
> {
> lock();
> try
> {
> return indexReader;
> }
> finally
> {
> unlock();
> }
> }
> {code}
> together with installBottleWarmer() method that spawns a concurrent thread
> that performs "warmup" operations, it makes it impossible to access the
> indexReader instance safely. A correct approach would be to wrap the entire
> operation with the indexreader in the mutex lock, not the the accessor method.
> please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706 and
> http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples
> when this approach is failing. it's fairly rare but keeps on reoccuring, all
> access (searching, indexing) from netbeans is protected by a mutex and
> happens exclusively. I'm assuming that the installBottleWarmer() thread is
> the one iterfering with our access occasionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-52) reentrant locking in DefaultIndexingContent flawed
[
https://jira.codehaus.org/browse/MINDEXER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313717#comment-313717
]
Tamás Cservenák commented on MINDEXER-52:
-
I believe this issue is "not an issue" anymore with MI 5. Please close if
agreed.
> reentrant locking in DefaultIndexingContent flawed
> --
>
> Key: MINDEXER-52
> URL: https://jira.codehaus.org/browse/MINDEXER-52
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.2
>Reporter: Milos Kleint
>Priority: Critical
>
> DefaultIndexingContent.java contains the following pattern:
> {code:java}
> public IndexReader getIndexReader()
> throws IOException
> {
> lock();
> try
> {
> return indexReader;
> }
> finally
> {
> unlock();
> }
> }
> {code}
> together with installBottleWarmer() method that spawns a concurrent thread
> that performs "warmup" operations, it makes it impossible to access the
> indexReader instance safely. A correct approach would be to wrap the entire
> operation with the indexreader in the mutex lock, not the the accessor method.
> please see http://netbeans.org/bugzilla/show_bug.cgi?id=204706 and
> http://statistics.netbeans.org/exceptions/detail.do?id=180712 for examples
> when this approach is failing. it's fairly rare but keeps on reoccuring, all
> access (searching, indexing) from netbeans is protected by a mutex and
> happens exclusively. I'm assuming that the installBottleWarmer() thread is
> the one iterfering with our access occasionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-68) Align context behaviour in case of replace and merge methods
[
https://jira.codehaus.org/browse/MINDEXER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-68.
---
Resolution: Fixed
> Align context behaviour in case of replace and merge methods
>
>
> Key: MINDEXER-68
> URL: https://jira.codehaus.org/browse/MINDEXER-68
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Problem is in lack of {{rebuildGroups()}} call in the IndexingContext#replace
> method, while the IndexingContext#merge method invokes the method.
> The invocation in both cases are justified, even if it seems redundant, as in
> both cases after the operation index is modified and various other aspects of
> it are changed (timestamp, descriptor etc).
> The call is redundant in case of "full remote update" case, since the
> transport format does contain these two fields (that are rebuilt by this
> method).
> Still, the fix allows easier Lucene index preparation outside MI and handing
> it over to MI for consumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-68) Align context behaviour in case of replace and merge methods
[
https://jira.codehaus.org/browse/MINDEXER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MINDEXER-68:
Fix Version/s: 5.1.0
> Align context behaviour in case of replace and merge methods
>
>
> Key: MINDEXER-68
> URL: https://jira.codehaus.org/browse/MINDEXER-68
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Problem is in lack of {{rebuildGroups()}} call in the IndexingContext#replace
> method, while the IndexingContext#merge method invokes the method.
> The invocation in both cases are justified, even if it seems redundant, as in
> both cases after the operation index is modified and various other aspects of
> it are changed (timestamp, descriptor etc).
> The call is redundant in case of "full remote update" case, since the
> transport format does contain these two fields (that are rebuilt by this
> method).
> Still, the fix allows easier Lucene index preparation outside MI and handing
> it over to MI for consumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-68) Align context behaviour in case of replace and merge methods
[
https://jira.codehaus.org/browse/MINDEXER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313716#comment-313716
]
Tamás Cservenák commented on MINDEXER-68:
-
Fixed in
http://svn.apache.org/viewvc?view=revision&revision=1410266
> Align context behaviour in case of replace and merge methods
>
>
> Key: MINDEXER-68
> URL: https://jira.codehaus.org/browse/MINDEXER-68
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Problem is in lack of {{rebuildGroups()}} call in the IndexingContext#replace
> method, while the IndexingContext#merge method invokes the method.
> The invocation in both cases are justified, even if it seems redundant, as in
> both cases after the operation index is modified and various other aspects of
> it are changed (timestamp, descriptor etc).
> The call is redundant in case of "full remote update" case, since the
> transport format does contain these two fields (that are rebuilt by this
> method).
> Still, the fix allows easier Lucene index preparation outside MI and handing
> it over to MI for consumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-68) Align context behaviour in case of replace and merge methods
[
https://jira.codehaus.org/browse/MINDEXER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reassigned MINDEXER-68:
---
Assignee: Tamás Cservenák
> Align context behaviour in case of replace and merge methods
>
>
> Key: MINDEXER-68
> URL: https://jira.codehaus.org/browse/MINDEXER-68
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Problem is in lack of {{rebuildGroups()}} call in the IndexingContext#replace
> method, while the IndexingContext#merge method invokes the method.
> The invocation in both cases are justified, even if it seems redundant, as in
> both cases after the operation index is modified and various other aspects of
> it are changed (timestamp, descriptor etc).
> The call is redundant in case of "full remote update" case, since the
> transport format does contain these two fields (that are rebuilt by this
> method).
> Still, the fix allows easier Lucene index preparation outside MI and handing
> it over to MI for consumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use custom IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MINDEXER-67: Summary: Provide means to make MI use custom IndexingContext implementations (was: Provide means to make MI use own IndexingContext implementations) > Provide means to make MI use custom IndexingContext implementations > --- > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-68) Align context behaviour in case of replace and merge methods
Tamás Cservenák created MINDEXER-68:
---
Summary: Align context behaviour in case of replace and merge
methods
Key: MINDEXER-68
URL: https://jira.codehaus.org/browse/MINDEXER-68
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 5.0.0
Reporter: Tamás Cservenák
Problem is in lack of {{rebuildGroups()}} call in the IndexingContext#replace
method, while the IndexingContext#merge method invokes the method.
The invocation in both cases are justified, even if it seems redundant, as in
both cases after the operation index is modified and various other aspects of
it are changed (timestamp, descriptor etc).
The call is redundant in case of "full remote update" case, since the transport
format does contain these two fields (that are rebuilt by this method).
Still, the fix allows easier Lucene index preparation outside MI and handing it
over to MI for consumption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313715#comment-313715 ] Tamás Cservenák commented on MINDEXER-67: - Remark: it might be not obvious, but one of the major change (if you switch from NexusIndexer to Indexer use), is that latter _always requires_ to have contexts you act upon (like searching or such) be explicitly provided. Former was having opposite behaviour: when for example FlatSearchRequest#contexts list was empty, then _all registered_ contexts were used in search (this was the "un-targeted search"). Indexer is explicit in this, and as it is no "registry", it does not know anything about "all existing contexts". This allows you to make it use "normal" context implementations, but also to make MI use wrapped or even your own context implementations. > Provide means to make MI use own IndexingContext implementations > > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MINDEXER-67: --- Assignee: Tamás Cservenák > Provide means to make MI use own IndexingContext implementations > > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-67. --- Resolution: Fixed > Provide means to make MI use own IndexingContext implementations > > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313714#comment-313714 ] Tamás Cservenák commented on MINDEXER-67: - Fixed in: http://svn.apache.org/viewvc?view=revision&revision=1410262 > Provide means to make MI use own IndexingContext implementations > > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[
https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313713#comment-313713
]
Tamás Cservenák commented on MINDEXER-67:
-
Proposed solution: creation of a "focused" component, that will NOT hold any
context (simply, DefaultNexusIndexer without the {{indexingContexts}} map. This
component will be then "wrapped" by modified (and deprecated) NexusIndexer
component, that delegates all the calls to new component, while performs same
"registry"-like operations and maintains the {{indexingContexts}}.
This means two things:
* users of (deprecated) NexusIndexer component will not notice anything
(remains bw compat)
* users of new Indexer component will have full control of: indexing context
used in index operations.
This also makes us able to start "clean slate" with new component, and perform
gradual "cleanup" of the API.
> Provide means to make MI use own IndexingContext implementations
>
>
> Key: MINDEXER-67
> URL: https://jira.codehaus.org/browse/MINDEXER-67
> Project: Maven Indexer
> Issue Type: Improvement
>Affects Versions: 4.1.3, 5.0.0
>Reporter: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Current "main" component of MI (NexusIndexer) serves as main entry for
> indexing operations, but _also serves as context registry_. The latter is
> used in cases like "untargeted search", and happens as "side effect" of
> Indexing Context creations (when you create a context, it will be always
> added to contexts map).
> With latest changes, it becomes obvious to have the two functionalities
> (context/indexing/search manipulation and "context registry") have separated.
> It prevents use of "own" context implementations, but also might interfere
> with searches when a "temp" context is needed and created over Indexer API.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-159) generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements()
[
https://jira.codehaus.org/browse/MCOMPILER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reopened MCOMPILER-159:
not yet fixed.
> generatedSourcesDirectory should be included in list provided by
> org.apache.maven.project.MavenProject.getCompileClasspathElements()
>
>
> Key: MCOMPILER-159
> URL: https://jira.codehaus.org/browse/MCOMPILER-159
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Andrew Green
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1
>
>
> I'm using a plugin (gwt-maven-plugin) that needs to know where all of my
> project's source code is, including generated sources. The standard compiler
> plugin (maven-compiler-plugin, v2.3.2) generates the sources correctly (from
> anntotations) and uses the generated code fine when compiling my project. But
> to get the gwt-maven-plugin to find the generated sources, I have to use the
> build-helper-maven-plugin to add the generated sources directory, as shown
> here:
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
> ${project.build.directory}/generated-sources/apt
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.5
>
>
> add-source
> generate-sources
>
> add-source
>
>
>
>
> ${project.build.directory}/generated-sources/apt
>
>
>
>
>
> It shouldn't be necessary to use build-helper-maven-plugin here; the
> generated sources should automatically be on the classpath. As far as I can
> tell, this is a Maven issue, or perhaps a maven-compiler-plugin issue, and is
> not the fault of gwt-maven-plugin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-159) generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements()
[
https://jira.codehaus.org/browse/MCOMPILER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCOMPILER-159:
---
Fix Version/s: (was: 3.0)
3.1
> generatedSourcesDirectory should be included in list provided by
> org.apache.maven.project.MavenProject.getCompileClasspathElements()
>
>
> Key: MCOMPILER-159
> URL: https://jira.codehaus.org/browse/MCOMPILER-159
> Project: Maven 2.x Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.2
>Reporter: Andrew Green
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1
>
>
> I'm using a plugin (gwt-maven-plugin) that needs to know where all of my
> project's source code is, including generated sources. The standard compiler
> plugin (maven-compiler-plugin, v2.3.2) generates the sources correctly (from
> anntotations) and uses the generated code fine when compiling my project. But
> to get the gwt-maven-plugin to find the generated sources, I have to use the
> build-helper-maven-plugin to add the generated sources directory, as shown
> here:
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.3.2
>
> 1.6
> 1.6
>
> ${project.build.directory}/generated-sources/apt
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.5
>
>
> add-source
> generate-sources
>
> add-source
>
>
>
>
> ${project.build.directory}/generated-sources/apt
>
>
>
>
>
> It shouldn't be necessary to use build-helper-maven-plugin here; the
> generated sources should automatically be on the classpath. As far as I can
> tell, this is a Maven issue, or perhaps a maven-compiler-plugin issue, and is
> not the fault of gwt-maven-plugin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
[ https://jira.codehaus.org/browse/MINDEXER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MINDEXER-67: Fix Version/s: 5.1.0 > Provide means to make MI use own IndexingContext implementations > > > Key: MINDEXER-67 > URL: https://jira.codehaus.org/browse/MINDEXER-67 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.3, 5.0.0 >Reporter: Tamás Cservenák > Fix For: 5.1.0 > > > Current "main" component of MI (NexusIndexer) serves as main entry for > indexing operations, but _also serves as context registry_. The latter is > used in cases like "untargeted search", and happens as "side effect" of > Indexing Context creations (when you create a context, it will be always > added to contexts map). > With latest changes, it becomes obvious to have the two functionalities > (context/indexing/search manipulation and "context registry") have separated. > It prevents use of "own" context implementations, but also might interfere > with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-67) Provide means to make MI use own IndexingContext implementations
Tamás Cservenák created MINDEXER-67: --- Summary: Provide means to make MI use own IndexingContext implementations Key: MINDEXER-67 URL: https://jira.codehaus.org/browse/MINDEXER-67 Project: Maven Indexer Issue Type: Improvement Affects Versions: 5.0.0, 4.1.3 Reporter: Tamás Cservenák Current "main" component of MI (NexusIndexer) serves as main entry for indexing operations, but _also serves as context registry_. The latter is used in cases like "untargeted search", and happens as "side effect" of Indexing Context creations (when you create a context, it will be always added to contexts map). With latest changes, it becomes obvious to have the two functionalities (context/indexing/search manipulation and "context registry") have separated. It prevents use of "own" context implementations, but also might interfere with searches when a "temp" context is needed and created over Indexer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-66) significant increase in used open file handles
[ https://jira.codehaus.org/browse/MINDEXER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-66. --- Resolution: Fixed > significant increase in used open file handles > -- > > Key: MINDEXER-66 > URL: https://jira.codehaus.org/browse/MINDEXER-66 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.3, 5.0.0 >Reporter: Igor Fedorenko >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > Attachments: > 0001-MINDEXER-66-provided-a-way-to-customize-IndexWriterC.patch > > > There is a significant increase in number of open kept opened for each > IndexingContext between maven-indexer 4.1.2 and 5.0.0. The difference is the > most pronounced for empty contexts, for which the old version only kept two > (2) files opened, while the new version keeps eleven (11). > The root cause appears to be change in default behaviour between Lucene 3.0.3 > and 3.6.1 used by the old and new maven-indexer versions respectively. Lucene > 3.6.1 provides an API to control how aggressively it aggregates index > segments into so called "[compound > files|http://lucene.apache.org/core/3_6_1/fileformats.html#Compound%20Files]";. > So the solution is to either hardcode aggressive aggregation in > maven-indexer or provide a way to configure aggregation threshold (or just > all parameters) on for each IndexingContext. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-66) significant increase in used open file handles
[ https://jira.codehaus.org/browse/MINDEXER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313710#comment-313710 ] Tamás Cservenák commented on MINDEXER-66: - Fixed in http://svn.apache.org/viewvc?view=revision&revision=1410255 > significant increase in used open file handles > -- > > Key: MINDEXER-66 > URL: https://jira.codehaus.org/browse/MINDEXER-66 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.3, 5.0.0 >Reporter: Igor Fedorenko >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > Attachments: > 0001-MINDEXER-66-provided-a-way-to-customize-IndexWriterC.patch > > > There is a significant increase in number of open kept opened for each > IndexingContext between maven-indexer 4.1.2 and 5.0.0. The difference is the > most pronounced for empty contexts, for which the old version only kept two > (2) files opened, while the new version keeps eleven (11). > The root cause appears to be change in default behaviour between Lucene 3.0.3 > and 3.6.1 used by the old and new maven-indexer versions respectively. Lucene > 3.6.1 provides an API to control how aggressively it aggregates index > segments into so called "[compound > files|http://lucene.apache.org/core/3_6_1/fileformats.html#Compound%20Files]";. > So the solution is to either hardcode aggressive aggregation in > maven-indexer or provide a way to configure aggregation threshold (or just > all parameters) on for each IndexingContext. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-65) Provide a way to scan directly to provided IndexingContext
[ https://jira.codehaus.org/browse/MINDEXER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MINDEXER-65. --- Resolution: Fixed > Provide a way to scan directly to provided IndexingContext > -- > > Key: MINDEXER-65 > URL: https://jira.codehaus.org/browse/MINDEXER-65 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 5.0.0 >Reporter: Igor Fedorenko >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > Attachments: > 0001-MINDEXER-65-made-DefaultScannerListener-directly-usa.patch > > > Currently, DefaultNexusIndexer#scan(...) always perform scan to a temporary > indexing context first, then replace the target context with temporary. I > vaguely remember this was necessary to allow index queries while scan was > running in a background thread. With recent rework of indexer locking, the > temporary indexing context is no longer needed and in fact it is harmful when > host application requires tight control over IndexingContext status. > Maven indexer need to provide a way to request scan directly to the target > indexing context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-65) Provide a way to scan directly to provided IndexingContext
[ https://jira.codehaus.org/browse/MINDEXER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313708#comment-313708 ] Tamás Cservenák commented on MINDEXER-65: - Fixed in http://svn.apache.org/viewvc?view=revision&revision=1410252 Curious, why not modify the org.apache.maven.index.DefaultNexusIndexer#scan too? There is really no need to use tmpContext in there anymore... > Provide a way to scan directly to provided IndexingContext > -- > > Key: MINDEXER-65 > URL: https://jira.codehaus.org/browse/MINDEXER-65 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 5.0.0 >Reporter: Igor Fedorenko >Assignee: Tamás Cservenák > Fix For: 5.1.0 > > Attachments: > 0001-MINDEXER-65-made-DefaultScannerListener-directly-usa.patch > > > Currently, DefaultNexusIndexer#scan(...) always perform scan to a temporary > indexing context first, then replace the target context with temporary. I > vaguely remember this was necessary to allow index queries while scan was > running in a background thread. With recent rework of indexer locking, the > temporary indexing context is no longer needed and in fact it is harmful when > host application requires tight control over IndexingContext status. > Maven indexer need to provide a way to request scan directly to the target > indexing context. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-64) Update TrueZip deps to latest (or at least latest release in same series)
[
https://jira.codehaus.org/browse/MINDEXER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MINDEXER-64.
---
Resolution: Fixed
> Update TrueZip deps to latest (or at least latest release in same series)
> -
>
> Key: MINDEXER-64
> URL: https://jira.codehaus.org/browse/MINDEXER-64
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Jason Dillon
>Assignee: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Currently uses truezip 7.0-rc1, there are 7.0-rc2 and 7.0 releases of this
> dependency, as well as much newer (latest is 7.6.6).
> Updating to 7.0 all tests on trunk pass, with 7.6.6 a few failures:
> {noformat}
> Failed tests: testNoArgs(org.apache.maven.index.cli.NexusIndexerCliIT):
> Should print usage
> testRequiredArgs(org.apache.maven.index.cli.NexusIndexerCliIT): Exception
> in thread "main" java.lang.SecurityException: Invalid signature file digest
> for Manifest main attributes(..)
> testUnpack(org.apache.maven.index.cli.NexusIndexerCliIT): Exception in
> thread "main" java.lang.SecurityException: Invalid signature file digest for
> Manifest main attributes(..)
> testMissingArgs(org.apache.maven.index.cli.NexusIndexerCliIT): Should print
> bad usage
> testAbrvsRequiredArgs(org.apache.maven.index.cli.NexusIndexerCliIT):
> Exception in thread "main" java.lang.SecurityException: Invalid signature
> file digest for Manifest main attributes(..)
> testLoggingLevel(org.apache.maven.index.cli.NexusIndexerCliIT):...
> {noformat}
> Either using the latest version or the latest 7.0 is probably better than
> using a pre-release of 7.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-64) Update TrueZip deps to latest (or at least latest release in same series)
[
https://jira.codehaus.org/browse/MINDEXER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=313707#comment-313707
]
Tamás Cservenák commented on MINDEXER-64:
-
Done in
http://svn.apache.org/viewvc?view=revision&revision=1410244
> Update TrueZip deps to latest (or at least latest release in same series)
> -
>
> Key: MINDEXER-64
> URL: https://jira.codehaus.org/browse/MINDEXER-64
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Jason Dillon
>Assignee: Tamás Cservenák
> Fix For: 5.1.0
>
>
> Currently uses truezip 7.0-rc1, there are 7.0-rc2 and 7.0 releases of this
> dependency, as well as much newer (latest is 7.6.6).
> Updating to 7.0 all tests on trunk pass, with 7.6.6 a few failures:
> {noformat}
> Failed tests: testNoArgs(org.apache.maven.index.cli.NexusIndexerCliIT):
> Should print usage
> testRequiredArgs(org.apache.maven.index.cli.NexusIndexerCliIT): Exception
> in thread "main" java.lang.SecurityException: Invalid signature file digest
> for Manifest main attributes(..)
> testUnpack(org.apache.maven.index.cli.NexusIndexerCliIT): Exception in
> thread "main" java.lang.SecurityException: Invalid signature file digest for
> Manifest main attributes(..)
> testMissingArgs(org.apache.maven.index.cli.NexusIndexerCliIT): Should print
> bad usage
> testAbrvsRequiredArgs(org.apache.maven.index.cli.NexusIndexerCliIT):
> Exception in thread "main" java.lang.SecurityException: Invalid signature
> file digest for Manifest main attributes(..)
> testLoggingLevel(org.apache.maven.index.cli.NexusIndexerCliIT):...
> {noformat}
> Either using the latest version or the latest 7.0 is probably better than
> using a pre-release of 7.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
