[jira] (SUREFIRE-892) Surefire Report Plugin crashes on failsafe-summary.xml
Reinhard Handler created SUREFIRE-892: - Summary: Surefire Report Plugin crashes on failsafe-summary.xml Key: SUREFIRE-892 URL: https://jira.codehaus.org/browse/SUREFIRE-892 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 2.11 Reporter: Reinhard Handler Priority: Critical Attachments: failsafe-summary.xml Surefire Report Plugin crashes with a NullPointerException when executing the attached failsafe-summary.xml. The exception handling could be improved on this position. I've surrounded saxParser.parse( new File( xmlPath ), this ); in TestSuiteXmlParser.java with a try/catch. The NullPointerException happens in the characters method on currentElement. Here's the StackTrace: java.lang.NullPointerException at org.apache.maven.plugins.surefire.report.TestSuiteXmlParser.characters(TestSuiteXmlParser.java:226) at org.apache.xerces.parsers.AbstractSAXParser.characters(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(SAXParser.java:331) at org.apache.maven.plugins.surefire.report.TestSuiteXmlParser.parse(TestSuiteXmlParser.java:69) at org.apache.maven.plugins.surefire.report.SurefireReportParser.parseXMLReportFiles(SurefireReportParser.java:97) at org.apache.maven.plugins.surefire.report.SurefireReportGenerator.doGenerateReport(SurefireReportGenerator.java:62) at org.apache.maven.plugins.surefire.report.AbstractSurefireReportMojo.executeReport(AbstractSurefireReportMojo.java:168) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:317) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134) 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) -- 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] (MACR-4) true includes timestamp instead of the string "-SNAPSHOT" for SNAPSHOT dependencies
[ https://jira.codehaus.org/browse/MACR-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304953#comment-304953 ] Benjamin Cartereau commented on MACR-4: --- Same issue. The embedded jar (in the ear) is the "-SNAPSHOT" version but the one declared in the classpath of the MANIFEST.MF is the timestamped version... > true includes timestamp instead of the string > "-SNAPSHOT" for SNAPSHOT dependencies > > > Key: MACR-4 > URL: https://jira.codehaus.org/browse/MACR-4 > Project: Maven ACR Plugin > Issue Type: Bug >Affects Versions: 1.0 > Environment: Win 7 Pro SP1 (64 Bit), Maven 3.0.4, ACR 1.0 >Reporter: Markus KARG >Priority: Blocker > Attachments: pom.xml > > > To reduce the amount of JARs linked to a client application, it is necessary > to provide a Class-Path entry in the MANIFEST of the CAR archive. When > configuring the ACR to do so using true, the > created MANIFEST.MF will include the timestamp of a SNAPSHOT dependency, > instead of simply the word "-SNAPSHOT". Unfortunately, the EAR plugin is > unable to rename the packaged dependencies in the same way, but simply keeps > the string "-SNAPSHOT". Effectively this leads to the fact that the > Class-Path will not contain the needed JARs at runtime, so the client will > except with ClassNotFoundException for any class inside of the SNAPSHOT > dependencies. > Attached you will find a sample POM which produces this problem on my laptop. > The sole dependency will be found in the EAR later as > "quipsy-defaultgui-4.32.-12-SNAPSHOT.jar", while the MANIFEST.MF of the CAR > will have a MANIFEST containing "Class-Path: > quipsy-defaultgui-4.32.12-20120312.074725-4.jar". > Obviously the behaviour of the ACR and EAR plugings are inconsistent, > effectively preventing use of the snapshot mechanism of Maven with Jave EE > projects. -- 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-53) Typo: "updating indexes" should be "updating indices" or "updating index"
[ https://jira.codehaus.org/browse/MINDEXER-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-53. Resolution: Not A Bug Assignee: Olivier Lamy try with m2 the message is not generated by maven indexer. > Typo: "updating indexes" should be "updating indices" or "updating index" > - > > Key: MINDEXER-53 > URL: https://jira.codehaus.org/browse/MINDEXER-53 > Project: Maven Indexer > Issue Type: Improvement > Environment: Eclipse 3.7, Springsource Tool Suite 2.9, M2e 1.0 >Reporter: MiB >Assignee: Olivier Lamy >Priority: Trivial > > When updating index central Eclipsebase Springsource Tool Suite 2.9 the > plugin states it's "updating indexes" which I believe is a typo. Either it > should be "updating indices" if several indices are being updated or > "updating index" if it's just a one. > I'm not sure where this string comes from, but Maven indexer felt the most > appropriate. If it's the m2e JIRA I should direct this to, please kill it > here and I'll post there instead. -- 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-44) NPE from DefaultSearchEngine.doSearchWithCeiling
[
https://jira.codehaus.org/browse/MINDEXER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MINDEXER-44:
-
Fix Version/s: (was: 4.1.3)
4.1.4
Assignee: (was: Olivier Lamy)
> NPE from DefaultSearchEngine.doSearchWithCeiling
>
>
> Key: MINDEXER-44
> URL: https://jira.codehaus.org/browse/MINDEXER-44
> Project: Maven Indexer
> Issue Type: Bug
>Affects Versions: 4.1.1
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 4.1.4
>
>
> http://netbeans.org/bugzilla/show_bug.cgi?id=202138 reports
> http://statistics.netbeans.org/exceptions/messageslog?id=533660 which shows
> {code}
> java.lang.NullPointerException
> at
> org.apache.maven.index.DefaultSearchEngine.doSearchWithCeiling(DefaultSearchEngine.java:316)
> at
> org.apache.maven.index.DefaultSearchEngine.searchFlat(DefaultSearchEngine.java:169)
> at
> org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:102)
> at
> org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:77)
> {code}
> This comes after some index download problems like
> {code}
> java.io.FileNotFoundException: Resource nexus-maven-repository-index.gz does
> not exist
> at
> org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:196)
> at
> org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:166)
> at
> org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:191)
> at
> org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
> at
> org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
> at
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:861)
> at
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
> {code}
> It seems that the {{DefaultIndexingContext.indexSearcher}} is null, for
> whatever reason, and {{searchFlatPaged}} is not verifying that it has been
> passed a valid context and does not attempt to fix an invalid context,
> perhaps using {{openAndWarmupReaders}}.
> Probably the caller is at fault for attempting a search on a context with no
> valid index, but this ought to be reported more clearly than with an NPE
> several calls down the stack, and there should be some documented method for
> checking that a context is somehow complete and ready for use.
--
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] (SUREFIRE-831) Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the groupName of an excludedGroup contains a '-' sign
[
https://jira.codehaus.org/browse/SUREFIRE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304975#comment-304975
]
Alex T commented on SUREFIRE-831:
-
This also happens when trying to include groups, and the only workaround seems
to be to rename the test group.
> Lexical error in surefire-plugin (TestNGExecutor.applyGroupMatching()) if the
> groupName of an excludedGroup contains a '-' sign
> ---
>
> Key: SUREFIRE-831
> URL: https://jira.codehaus.org/browse/SUREFIRE-831
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.11, 2.12
> Environment: Tested with maven-surefire-plugin-2.13-20120207.212404-8
>Reporter: Andreas Kuhtz
>
> This occurs even with the current SNAPSHOT release. The issue might be
> related to SUREFIRE-828.
> {code:title=pom.xml}
>
>org.apache.maven.plugins
>maven-surefire-plugin
>
> ui-test
>
>
> {code}
> {code}
> Running TestSuite
> org.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exceptio
> n is java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: org.apache.maven.surefire.testset.TestSetFailedException: null;
> nested exception is java.lang.reflect.Invocat
> ionTargetException: null
> at
> org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:164)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:65)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:161)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:101)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:115)
> ... 9 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.applyGroupMatching(TestNGExecutor.java:140)
> ... 13 more
> Caused by: org.apache.maven.surefire.group.parse.TokenMgrError: Lexical error
> at line 1, column 3. Encountered: "-" (45
> ), after : ""
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParserTokenManager.getNextToken(GroupMatcherParserTokenMana
> ger.java:468)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_scan_token(GroupMatcherParser.java:527)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_7(GroupMatcherParser.java:274)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_3(GroupMatcherParser.java:287)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_3(GroupMatcherParser.java:279)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3R_1(GroupMatcherParser.java:320)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_3_1(GroupMatcherParser.java:335)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.jj_2_1(GroupMatcherParser.java:179)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.expr(GroupMatcherParser.java:63)
> at
> org.apache.maven.surefire.group.parse.GroupMatcherParser.parse(GroupMatcherParser.java:56)
> at
> org.apache.maven.surefire.testng.utils.GroupMatcherMethodSelector.setGroups(GroupMatcherMethodSelector.java:7
> 6)
> ... 18 more
> {code}
--
This messag
[jira] (MINDEXER-50) Logging of parsing exceptions should be handled consistently in org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator
[ https://jira.codehaus.org/browse/MINDEXER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-50. Resolution: Fixed Fix Version/s: 4.1.3 Assignee: Olivier Lamy Patch applied. Thanks! > Logging of parsing exceptions should be handled consistently in > org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator > -- > > Key: MINDEXER-50 > URL: https://jira.codehaus.org/browse/MINDEXER-50 > Project: Maven Indexer > Issue Type: Bug >Affects Versions: 4.1.2 >Reporter: Peter Lynch >Assignee: Olivier Lamy > Fix For: 4.1.3 > > > This patch makes the logging of artifact parsing exceptions consistent > between org.apache.maven.index.creator.MavenPluginArtifactInfoIndexCreator > and org.apache.maven.index.creator.MavenArchetypeArtifactInfoIndexCreator > https://github.com/apache/maven-indexer/pull/2.diff -- 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-31) Bump Lucene to latest 3.2.0 version
[ https://jira.codehaus.org/browse/MINDEXER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-31. Resolution: Fixed Fix Version/s: (was: 4.2.0) 4.1.3 Assignee: Olivier Lamy lucene 3.6.1 is now used. > Bump Lucene to latest 3.2.0 version > --- > > Key: MINDEXER-31 > URL: https://jira.codehaus.org/browse/MINDEXER-31 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.0 >Reporter: Tamás Cservenák >Assignee: Olivier Lamy > Fix For: 4.1.3 > > > Bump Lucene to latest 3.2.0 version. > This would need small effort, since the "big work" was done by going from > lucene 2.x API over to 3.x with indexer version 4.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] (MAVENUPLOAD-2822) Sync'ing the Ujorm framework to the central repository
Pavel Ponec created MAVENUPLOAD-2822: Summary: Sync'ing the Ujorm framework to the central repository Key: MAVENUPLOAD-2822 URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2822 Project: Maven Upload Requests Issue Type: Wish Reporter: Pavel Ponec "org.ujorm","mavens...@web.sourceforge.net:/home/groups/u/uj/ujoframework/htdocs/m2repo","rsync_ssh","Pavel Ponec","ppo...@gmail.com",, Hallo, add the project 'Ujorm' to the list of automatically synced repositories, please. Thank you, Reguards, Pavel -- 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-31) Bump Lucene to latest 3.6.1 version
[ https://jira.codehaus.org/browse/MINDEXER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINDEXER-31: - Summary: Bump Lucene to latest 3.6.1 version (was: Bump Lucene to latest 3.2.0 version) > Bump Lucene to latest 3.6.1 version > --- > > Key: MINDEXER-31 > URL: https://jira.codehaus.org/browse/MINDEXER-31 > Project: Maven Indexer > Issue Type: Improvement >Affects Versions: 4.1.0 >Reporter: Tamás Cservenák >Assignee: Olivier Lamy > Fix For: 4.1.3 > > > Bump Lucene to latest 3.2.0 version. > This would need small effort, since the "big work" was done by going from > lucene 2.x API over to 3.x with indexer version 4.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] (MRELEASE-784) SNAPSHOT version in Dependency in DependencyManagement with scope import and type pom is not replaced
Michael Niedermaier created MRELEASE-784: Summary: SNAPSHOT version in Dependency in DependencyManagement with scope import and type pom is not replaced Key: MRELEASE-784 URL: https://jira.codehaus.org/browse/MRELEASE-784 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.3.2 Environment: Maven 3.0.4 Reporter: Michael Niedermaier Attachments: console.out, internal-managed-snapshot-dependency.zip, remote-repository.zip In the test case he asks for the external:artifactId version on console, but it should only ask and change for the import dependencyManagement dependency external:parent-artifactid-withimport-dm which's version is not changed by the release plugin I attached my sample repository, the project in tryed to release (including the created pom for tag, which still contains the SNAPSHOT version) and the console output -- 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=304992#comment-304992
]
Tamás Cservenák commented on MINDEXER-52:
-
Jesse got it: it intention was to warm and preload indexes, and true, this made
sense in Nexus-like applications (that's from where Maven Indexer comes
actually).
I'd say just remove from call chain, but expose this method (as warmpUp() or
whatever) on the Context itself and let the integrating software decide should
it use it or use some other stuff or not use it at all.
> 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] (MSHADE-112) New property to enable shading the java text inside the sources artifact (not just shading the java source file locations)
[ https://jira.codehaus.org/browse/MSHADE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MSHADE-112: --- Assignee: Olivier Lamy > New property to enable shading the java text inside the sources artifact (not > just shading the java source file locations) > -- > > Key: MSHADE-112 > URL: https://jira.codehaus.org/browse/MSHADE-112 > Project: Maven 2.x Shade Plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Trask Stalnaker >Assignee: Olivier Lamy > Attachments: shade-sources-content.patch, > shade-sources-content-v2.patch > > > The existing createSourcesJar property shades the source file locations, but > it doesn't shade their content. > This makes debugging (when using a shaded artifact) a little painful (at > least in Eclipse) since the source files that Eclipse finds don't match up > with the package names in the runtime environment. > The attached patch performs a rather naive regular expression search/replace > throughout the java source files when building the shaded sources artifact. > The patch also makes the assumption that the source files are all UTF-8 > encoded. This latter issue seems especially problematic, and for this reason > I have made this feature a new option (shadeSourcesContent) as opposed to > making it the default behavior when createSourcesJar=true. > It looks like there are a couple of java libraries that attempt to do > encoding detection, if something like this is required to get this patch > committed I can investigate this further, or if anyone has other ideas how to > handle this please let me know. Thanks. -- 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] (MSHADE-112) New property to enable shading the java text inside the sources artifact (not just shading the java source file locations)
[ https://jira.codehaus.org/browse/MSHADE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHADE-112: Fix Version/s: 2.0 > New property to enable shading the java text inside the sources artifact (not > just shading the java source file locations) > -- > > Key: MSHADE-112 > URL: https://jira.codehaus.org/browse/MSHADE-112 > Project: Maven 2.x Shade Plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Trask Stalnaker >Assignee: Olivier Lamy > Fix For: 2.0 > > Attachments: shade-sources-content.patch, > shade-sources-content-v2.patch > > > The existing createSourcesJar property shades the source file locations, but > it doesn't shade their content. > This makes debugging (when using a shaded artifact) a little painful (at > least in Eclipse) since the source files that Eclipse finds don't match up > with the package names in the runtime environment. > The attached patch performs a rather naive regular expression search/replace > throughout the java source files when building the shaded sources artifact. > The patch also makes the assumption that the source files are all UTF-8 > encoded. This latter issue seems especially problematic, and for this reason > I have made this feature a new option (shadeSourcesContent) as opposed to > making it the default behavior when createSourcesJar=true. > It looks like there are a couple of java libraries that attempt to do > encoding detection, if something like this is required to get this patch > committed I can investigate this further, or if anyone has other ideas how to > handle this please let me know. Thanks. -- 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] (MSHADE-112) New property to enable shading the java text inside the sources artifact (not just shading the java source file locations)
[ https://jira.codehaus.org/browse/MSHADE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-112. --- Resolution: Fixed applied. Thanks! > New property to enable shading the java text inside the sources artifact (not > just shading the java source file locations) > -- > > Key: MSHADE-112 > URL: https://jira.codehaus.org/browse/MSHADE-112 > Project: Maven 2.x Shade Plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Trask Stalnaker >Assignee: Olivier Lamy > Fix For: 2.0 > > Attachments: shade-sources-content.patch, > shade-sources-content-v2.patch > > > The existing createSourcesJar property shades the source file locations, but > it doesn't shade their content. > This makes debugging (when using a shaded artifact) a little painful (at > least in Eclipse) since the source files that Eclipse finds don't match up > with the package names in the runtime environment. > The attached patch performs a rather naive regular expression search/replace > throughout the java source files when building the shaded sources artifact. > The patch also makes the assumption that the source files are all UTF-8 > encoded. This latter issue seems especially problematic, and for this reason > I have made this feature a new option (shadeSourcesContent) as opposed to > making it the default behavior when createSourcesJar=true. > It looks like there are a couple of java libraries that attempt to do > encoding detection, if something like this is required to get this patch > committed I can investigate this further, or if anyone has other ideas how to > handle this please let me know. Thanks. -- 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] (MPLUGIN-222) 'Since' information is not shown on generated site (ANT Mojos)
[ https://jira.codehaus.org/browse/MPLUGIN-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MPLUGIN-222. Resolution: Fixed Fix Version/s: 3.1.1 Assignee: Olivier Lamy patch applied. Thanks! > 'Since' information is not shown on generated site (ANT Mojos) > -- > > Key: MPLUGIN-222 > URL: https://jira.codehaus.org/browse/MPLUGIN-222 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model >Affects Versions: 2.5.1, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1 > Environment: Any. >Reporter: Tinguaro Barreno >Assignee: Olivier Lamy >Priority: Minor > Fix For: 3.1.1 > > Attachments: fix-since-samples-v2.zip, fix-since-samples-v3.zip, > maven-plugin-tools.patch > > > Hi, > The plugin site for an ANT Mojo doesn't shows the 'since' information for > goals and parameters. > The problem seems to be in the 'PluginMetadataParser.java'; this class gets > the Mojo data object and convert it to a MojoDescriptor. Just two lines are > enough to pass the 'since' data to the descriptor (and then, include it on > the site). > I attach the patch and two tests cases for Maven 2.2.1 and Maven 3.0. I've > test the patch with maven-plugin-plugin v2.5.1, v2.9 and 3.1. > Best wishes. -- 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-5125) Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies
[
https://jira.codehaus.org/browse/MNG-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MNG-5125.
-
Resolution: Fixed
Fix Version/s: 3.0.4
Assignee: Olivier Lamy
fixed with aether upgrade.
> Regression: mvn 3.0.3 is extreemly slow with a large number of dependencies
> ---
>
> Key: MNG-5125
> URL: https://jira.codehaus.org/browse/MNG-5125
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Inheritance and
> Interpolation, Performance
>Affects Versions: 3.0.3
> Environment: Java: 1.6.0_24-b07
> Maven: 3.0.3
> RHEL6: 2.6.32-131.2.1.el6.x86_64
>Reporter: Patrick Staton
>Assignee: Olivier Lamy
> Fix For: 3.0.4
>
> Attachments: 302tree.out, 303tree.out, mvn302profile.html,
> mvn303profile.html
>
>
> I am pretty sure that
> [AETHER-82|https://issues.sonatype.org/browse/AETHER-82] / rev
> [a537899308f3d22df5509e33628a0012ba912293|https://github.com/sonatype/sonatype-aether/commit/a537899308f3d22df5509e33628a0012ba912293]
> has caused maven 3.0.3 to be extremely slow in our build.
> Profiling shows that when we build one of our projects with many
> dependencies,
> org.sonatype.aether.impl.internal.DefaultDependencyCollector.process is being
> called >5 times in maven 3.0.3 whereas it is called 335 times in maven
> 3.0.2.
> Attached is the html output from a netbeans profiling session of the same
> build with maven 3.0.2 and maven 3.0.3. I stopped the maven 3.0.3 build after
> ~5 mins of being stuck at the "[INFO] Building many-deps-project
> 1.2.3.4-SNAPSHOT" step.
> A 'mvn dependency:tree' is identical between the two except that it takes
> about 10 mins to run in 3.0.3. I have attached the output. If you need me to
> do a better job censoring the output, ie make the project names unique, let
> me know.
> "webapp-jar" type dependencies are a custom artifact handler:
> {code}
>
> org.apache.maven.artifact.handler.ArtifactHandler
> webapp-jar
>
> org.apache.maven.artifact.handler.DefaultArtifactHandler
>
> webapp
> webapp-jar
> jar
> java
> false
>
>
> {code}
> We have "java-source" dependencies because we use GWT.
> I cannot send you the actual pom files.
--
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] (MSHARED-231) upgrade groovy version used to 2.0.1
[ https://jira.codehaus.org/browse/MSHARED-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-231: - Fix Version/s: maven-script-interpreter-1.1 Assignee: Olivier Lamy > upgrade groovy version used to 2.0.1 > > > Key: MSHARED-231 > URL: https://jira.codehaus.org/browse/MSHARED-231 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-script-interpreter >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-script-interpreter-1.1 > > -- 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] (MSHARED-231) upgrade groovy version used to 2.0.1
Olivier Lamy created MSHARED-231: Summary: upgrade groovy version used to 2.0.1 Key: MSHARED-231 URL: https://jira.codehaus.org/browse/MSHARED-231 Project: Maven Shared Components Issue Type: Bug Components: maven-script-interpreter Reporter: Olivier Lamy -- 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] (MSHARED-231) upgrade groovy version used to 2.0.1
[ https://jira.codehaus.org/browse/MSHARED-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-231. Resolution: Fixed > upgrade groovy version used to 2.0.1 > > > Key: MSHARED-231 > URL: https://jira.codehaus.org/browse/MSHARED-231 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-script-interpreter >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-script-interpreter-1.1 > > -- 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] (MSHARED-232) upgrade groovy version used to 2.0.1
Olivier Lamy created MSHARED-232: Summary: upgrade groovy version used to 2.0.1 Key: MSHARED-232 URL: https://jira.codehaus.org/browse/MSHARED-232 Project: Maven Shared Components Issue Type: Bug Components: maven-script-interpreter Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: maven-script-interpreter-1.1 -- 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] (MSHARED-231) upgrade groovy version used to 2.0.1
[ https://jira.codehaus.org/browse/MSHARED-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-231: - Issue Type: Improvement (was: Bug) > upgrade groovy version used to 2.0.1 > > > Key: MSHARED-231 > URL: https://jira.codehaus.org/browse/MSHARED-231 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-script-interpreter >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-script-interpreter-1.1 > > -- 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] (MINVOKER-136) upgrade groovy version used to 2.0.1
[ https://jira.codehaus.org/browse/MINVOKER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MSHARED-232 to MINVOKER-136: --- Fix Version/s: (was: maven-script-interpreter-1.1) 1.7 Component/s: (was: maven-script-interpreter) Attachment Licence (Apache) : Grant license to ASF for inclusion in ASF works (as per the http://www.apache.org/licenses/LICENSE-2.0";>Apache License §5) Issue Type: Improvement (was: Bug) Key: MINVOKER-136 (was: MSHARED-232) Project: Maven 2.x Invoker Plugin (was: Maven Shared Components) > upgrade groovy version used to 2.0.1 > > > Key: MINVOKER-136 > URL: https://jira.codehaus.org/browse/MINVOKER-136 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.7 > > -- 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] (MINVOKER-136) upgrade groovy version used to 2.0.1
[ https://jira.codehaus.org/browse/MINVOKER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-136. - Resolution: Fixed > upgrade groovy version used to 2.0.1 > > > Key: MINVOKER-136 > URL: https://jira.codehaus.org/browse/MINVOKER-136 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.7 > > -- 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] (MINSTALL-87) Install:install-file on missing file should fail, not indicate success with bogus jar file message
[
https://jira.codehaus.org/browse/MINSTALL-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MINSTALL-87:
Assignee: Olivier Lamy
> Install:install-file on missing file should fail, not indicate success with
> bogus jar file message
> --
>
> Key: MINSTALL-87
> URL: https://jira.codehaus.org/browse/MINSTALL-87
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
> Components: install:install-file
>Affects Versions: 2.3.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: /home/user/Programs/apache-maven-3.0.4
> Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
> Java home: /usr/java/jdk1.6.0_30/jre
> Default locale: en_US, platform encoding: UTF-8
> RHEL 6.1
>Reporter: Chris Lott
>Assignee: Olivier Lamy
>Priority: Minor
>
> I had to install a third-party jar into my local repository and used maven to
> do so. But I botched the file name, and confusingly the plugin did not
> complain; in fact it reported total success. It creates a pom file but no
> jar file. I think the build should fail if the file to be installed is not
> found.
> Reproduce with the following invocation:
> {{mvn install:install-file -DgroupId=foo -DartifactId=foo -Dversion=1
> -Dfile=/tmp/doesnotexit-comma-trust-me -Dpackaging=jar -DgeneratePom=true}}
> Below is the log from running this operation. Despite the message, it did
> NOT create a jar file.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
> standalone-pom ---
> [INFO] Installing /tmp/doesnotexit-comma-trust-me to
> /home/user/.m2/repository/foo/foo/1/foo-1.jar
> [INFO] Installing /tmp/mvninstall4193497156837259347.pom to
> /home/user/.m2/repository/foo/foo/1/foo-1.pom
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.422s
> [INFO] Finished at: Mon May 21 11:04:30 EDT 2012
> [INFO] Final Memory: 4M/359M
> [INFO]
>
> {noformat}
> Thanks for listening.
--
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] (MINSTALL-87) Install:install-file on missing file should fail, not indicate success with bogus jar file message
[
https://jira.codehaus.org/browse/MINSTALL-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MINSTALL-87.
Resolution: Fixed
Fix Version/s: 2.4
> Install:install-file on missing file should fail, not indicate success with
> bogus jar file message
> --
>
> Key: MINSTALL-87
> URL: https://jira.codehaus.org/browse/MINSTALL-87
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
> Components: install:install-file
>Affects Versions: 2.3.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: /home/user/Programs/apache-maven-3.0.4
> Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
> Java home: /usr/java/jdk1.6.0_30/jre
> Default locale: en_US, platform encoding: UTF-8
> RHEL 6.1
>Reporter: Chris Lott
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 2.4
>
>
> I had to install a third-party jar into my local repository and used maven to
> do so. But I botched the file name, and confusingly the plugin did not
> complain; in fact it reported total success. It creates a pom file but no
> jar file. I think the build should fail if the file to be installed is not
> found.
> Reproduce with the following invocation:
> {{mvn install:install-file -DgroupId=foo -DartifactId=foo -Dversion=1
> -Dfile=/tmp/doesnotexit-comma-trust-me -Dpackaging=jar -DgeneratePom=true}}
> Below is the log from running this operation. Despite the message, it did
> NOT create a jar file.
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @
> standalone-pom ---
> [INFO] Installing /tmp/doesnotexit-comma-trust-me to
> /home/user/.m2/repository/foo/foo/1/foo-1.jar
> [INFO] Installing /tmp/mvninstall4193497156837259347.pom to
> /home/user/.m2/repository/foo/foo/1/foo-1.pom
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.422s
> [INFO] Finished at: Mon May 21 11:04:30 EDT 2012
> [INFO] Final Memory: 4M/359M
> [INFO]
>
> {noformat}
> Thanks for listening.
--
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-124) Dependency incorrectly reported as "Unused declared"
[
https://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-124:
---
Fix Version/s: (was: 2.5)
2.6
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: https://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
> Fix For: 2.6
>
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
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-166) runtime-scoped dependencies should be specially handled
[ https://jira.codehaus.org/browse/MDEP-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MDEP-166: --- Fix Version/s: (was: 2.5) 2.6 > runtime-scoped dependencies should be specially handled > --- > > Key: MDEP-166 > URL: https://jira.codehaus.org/browse/MDEP-166 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0 >Reporter: Max Bowsher >Assignee: Brian Fox > Fix For: 2.6 > > > Currently the plugin warns that runtime-scope dependencies are unused. > It should understand that the correct status for a runtime-scoped dependency > is to *not* be discoverable in the bytecode. -- 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] (MWAR-281) Allow Synapse extensions (.xar files) to be imported into WEB-INF/extensions
[ https://jira.codehaus.org/browse/MWAR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MWAR-281. - Resolution: Fixed Fix Version/s: 2.2 Assignee: Olivier Lamy patch applied. Thanks! > Allow Synapse extensions (.xar files) to be imported into WEB-INF/extensions > > > Key: MWAR-281 > URL: https://jira.codehaus.org/browse/MWAR-281 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Auke Schrijnen >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.2 > > Attachments: > 0001-MWAR-281-Allow-Synapse-extensions-.xar-files-to-be-i.patch > > > The maven war plugin supports Axis2 modules (.mar MWAR-193) and services > (.aar MWAR-76) and it would be nice to have Synapse extensions (.xar) support. > Apache Synapse (built on top of Axis2) has extensions (basically a jar with a > .xar file extension) similar to Axis2 modules and services. The expected > directory for Synapse extensions is WEB-INF/extensions and the maven > packaging type is xar. -- 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] (SUREFIRE-887) Do not hold forked surefire for debug if there are no tests
[
https://jira.codehaus.org/browse/SUREFIRE-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305001#comment-305001
]
Olivier Lamy commented on SUREFIRE-887:
---
a workaround is to use -DforkMode=always
> Do not hold forked surefire for debug if there are no tests
> ---
>
> Key: SUREFIRE-887
> URL: https://jira.codehaus.org/browse/SUREFIRE-887
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.12
>Reporter: Marvin Froeder
>
> This is something a bit annoying.
> When I enable debug (by either using -Dmaven.surefire.debug=true or
> -Dmaven.failsafe.debug=true) surefire will hold maven execution until a
> debugger is connected to the forked process.
> The problem is that time to time there are no tests to be executed!
> So my patch just skips launching the forked VM if there are no tests to be
> executed!
> {noformat}
> Index:
> maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
> ===
> ---
> maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
> (revision 1361154)
> +++
> maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
> (working copy)
> @@ -31,6 +31,7 @@
> import java.util.concurrent.Future;
> import java.util.concurrent.ThreadPoolExecutor;
> import java.util.concurrent.TimeUnit;
> +
> import org.apache.maven.plugin.surefire.CommonReflector;
> import org.apache.maven.plugin.surefire.StartupReportConfiguration;
> import org.apache.maven.plugin.surefire.booterclient.output.ForkClient;
> @@ -47,6 +48,8 @@
> import org.apache.maven.surefire.providerapi.SurefireProvider;
> import org.apache.maven.surefire.report.RunStatistics;
> import org.apache.maven.surefire.suite.RunResult;
> +import org.apache.maven.surefire.testset.DirectoryScannerParameters;
> +import org.apache.maven.surefire.util.DefaultDirectoryScanner;
> import org.codehaus.plexus.util.cli.CommandLineException;
> import org.codehaus.plexus.util.cli.CommandLineTimeOutException;
> import org.codehaus.plexus.util.cli.CommandLineUtils;
> @@ -66,6 +69,7 @@
> * @author Dan Fabulich
> * @author Carlos Sanchez
> * @author Kristian Rosenvold
> + * @author Marvin
> Froeder
> * @version $Id$
> */
> public class ForkStarter
> @@ -106,6 +110,12 @@
> final String requestedForkMode = forkConfiguration.getForkMode();
> try
> {
> +
> +if ( Boolean.FALSE.equals( hasTestToRun() ) )
> +{
> +return new RunResult( 0, 0, 0, 0 );
> +}
> +
> if ( ForkConfiguration.FORK_ONCE.equals( requestedForkMode ) )
> {
> final ForkClient forkClient =
> @@ -134,6 +144,24 @@
> return result;
> }
>
> +private Boolean hasTestToRun()
> +{
> +// verify if there are tests to be executed
> +DirectoryScannerParameters params =
> providerConfiguration.getDirScannerParams();
> +if ( params == null )
> +{
> +//unknow
> +return null;
> +}
> +
> +DefaultDirectoryScanner scanner =
> +new DefaultDirectoryScanner( params.getTestClassesDirectory(),
> params.getIncludes(), params.getExcludes(),
> + params.getSpecificTests() );
> +
> +String[] tests = scanner.collectTests();
> +return tests.length != 0;
> +}
> +
> private RunResult runSuitesForkPerTestSet( final Properties properties,
> int forkCount )
> throws SurefireBooterForkException
> {
> Index:
> surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
> ===
> ---
> surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
> (revision 1361154)
> +++
> surefire-api/src/main/java/org/apache/maven/surefire/util/DefaultDirectoryScanner.java
> (working copy)
> @@ -108,7 +108,7 @@
> return testClass;
> }
>
> -String[] collectTests()
> +public String[] collectTests()
> {
> String[] tests = EMPTY_STRING_ARRAY;
> if ( basedir.exists() )
> Index:
> surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java
> ===
> ---
> surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java
> (revision 1361154)
> +++
> surefire-integration-tests/src/test/java/org/apache/m
[jira] (MJAVADOC-334) Patch to make easier
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305005#comment-305005
]
Olivier Lamy commented on MJAVADOC-334:
---
@Joseph sure but not for maven 2.x users :-)
> Patch to make easier
> -
>
> Key: MJAVADOC-334
> URL: https://jira.codehaus.org/browse/MJAVADOC-334
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Ben Speakmon
> Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
>
>
> This patch corrects the spelling of {{}} and adds the
> wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
> allows us to declare {{}} without also requiring us to
> use the {{implementation}} attribute to manually specify
> {{org.apache.maven.model.Dependency}}.
--
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] (MJAVADOC-334) Patch to make easier
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305006#comment-305006
]
Olivier Lamy commented on MJAVADOC-334:
---
@Ben which maven version are you using to have issues ??
> Patch to make easier
> -
>
> Key: MJAVADOC-334
> URL: https://jira.codehaus.org/browse/MJAVADOC-334
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Ben Speakmon
> Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
>
>
> This patch corrects the spelling of {{}} and adds the
> wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
> allows us to declare {{}} without also requiring us to
> use the {{implementation}} attribute to manually specify
> {{org.apache.maven.model.Dependency}}.
--
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] (MJAVADOC-334) Patch to make easier
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305007#comment-305007
]
Ben Speakmon commented on MJAVADOC-334:
---
We had it on 2.1.0 and 2.2.1. (Internal issues make moving to 3.x impossible
for the time being.)
> Patch to make easier
> -
>
> Key: MJAVADOC-334
> URL: https://jira.codehaus.org/browse/MJAVADOC-334
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Ben Speakmon
> Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
>
>
> This patch corrects the spelling of {{}} and adds the
> wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
> allows us to declare {{}} without also requiring us to
> use the {{implementation}} attribute to manually specify
> {{org.apache.maven.model.Dependency}}.
--
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] (MJAVADOC-334) Patch to make easier and fix typo on field name
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MJAVADOC-334:
--
Summary: Patch to make easier and fix typo on
field name (was: Patch to make easier)
> Patch to make easier and fix typo on field name
>
>
> Key: MJAVADOC-334
> URL: https://jira.codehaus.org/browse/MJAVADOC-334
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Ben Speakmon
> Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
>
>
> This patch corrects the spelling of {{}} and adds the
> wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
> allows us to declare {{}} without also requiring us to
> use the {{implementation}} attribute to manually specify
> {{org.apache.maven.model.Dependency}}.
--
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] (MJAVADOC-334) Patch to make easier and fix typo on field name
[
https://jira.codehaus.org/browse/MJAVADOC-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MJAVADOC-334.
-
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Olivier Lamy
Patch applied.
Thanks!
> Patch to make easier and fix typo on field name
>
>
> Key: MJAVADOC-334
> URL: https://jira.codehaus.org/browse/MJAVADOC-334
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Ben Speakmon
>Assignee: Olivier Lamy
> Fix For: 2.9
>
> Attachments: maven-javadoc-plugin.diff, MJAVADOC-334.patch
>
>
> This patch corrects the spelling of {{}} and adds the
> wrapper class {{org.apache.maven.plugin.javadoc.AdditionalDependency}}. This
> allows us to declare {{}} without also requiring us to
> use the {{implementation}} attribute to manually specify
> {{org.apache.maven.model.Dependency}}.
--
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-4715) version expression constant
[
https://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305017#comment-305017
]
Cameron Rochester commented on MNG-4715:
We are also using a centralised list of version properties for managing our
multi-module build. At last count we have about 50 modules each with
independent versions. There doesn't seem to be anyway to manage versions in a
centralised manner beyond this approach. I also think Maven needs to reconsider
where they are going with this approach.
> version expression constant
> ---
>
> Key: MNG-4715
> URL: https://jira.codehaus.org/browse/MNG-4715
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies, POM
>Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
> Environment: eclipse linux xp
>Reporter: Faruk
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: untitled.JPG
>
>
> early versions, we define modules versions with expressions, and set them to
> the parent pom,
> simply;
>
> 1.0.1
> 1.0.1
>
> and then, we give this property to modules pom as expression ,
> ik-plug
> jar
> ${ibb-core-util.versionn}
> but know , it gives an error you know like this,
> "[WARNING] Some problems were encountered while building the effective model
> for ibb-parent:ibb-modules-parent:pom:1.0.0
> [WARNING] 'version' contains an expression but should be a constant. @
> ibb-parent:ibb-modules-parent:${ibb-core-jars.version},
> C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
> "
> but I think that, this enhancement is causes wrong result,
> think that , if we have i project already developing about 3 years, this
> project has a lot of modules, and this modules have sub modules , and this
> sub modules already bound to some other modules not define in your pom, but
> your updates must be affect them, at this situation, developer want to write
> the existing version numbers with properties to parent pom, and want to
> manage them like this. at the attach file below , the close projects are
> belongs to open projects, but they are the different team developing this. I
> cant force the other developers to cache their versions, I must use this
> versions as initial step
--
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] (MJAR-61) Manifest classpath ignores the "real" JAR filenames specified in
[
https://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305031#comment-305031
]
Peter Coder commented on MJAR-61:
-
I don't have a fix for this - there is a workaround though.
Version 2.4 of the Maven archiver (maven-archiver) uses by default a different
approach to generating the classpath vs version 2.2.
maven-archiver version 2.2: uses artifact file name
maven-archiver version 2.4: uses a pattern that looks a bit like this:
${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
.. which would give a classpath entry like this: TheJarFile-3.4-SNAPSHOT.jar
(N.B. maven-archiver version 2.2 is used by e.g. maven-ejb-plugin 2.1;
maven-archiver 2.4 is used by e.g. maven-ejb-plugin 2.2 and 2.3)
The easiest way to construct your classpath entries using the
is to use the following configuration:
{code}
maven-ejb-plugin
3.0
true
custom
$${artifact.file.name}
{code}
The workaround for maven-jar-plugin and maven-war-plugin is the same.
> Manifest classpath ignores the "real" JAR filenames specified in
>
>
> Key: MJAR-61
> URL: https://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Martin Desruisseaux
> Attachments: MJAR-61.zip
>
>
> The manifest classpath generated by Maven ignores the "real" JAR name as
> specified in {{}}. For example the Geotools project tried the
> following configuration:
> {code:xml}
>
> gt-${artifactId}-${version}
> {code}
> but the manifest classpath generated by Maven contains only
> {{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
> *Note:* this problem happen only when the JAR dependencis come from the
> repository. The manifest classpath is correct if all dependencies were
> compiled in the same "{{mvn install}}" cycle. However this workaround is
> applicable only to Geotools developpers (in our case), because users of the
> Geotools library usually download the dependencies from a repository.
> This bug may be related to MJAR-28.
--
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] (MJAR-61) Manifest classpath ignores the "real" JAR filenames specified in
[
https://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305031#comment-305031
]
Peter Coder edited comment on MJAR-61 at 7/31/12 12:41 AM:
---
I don't have a fix for this - there is a workaround though.
Version 2.4 of the Maven archiver (maven-archiver) uses by default a different
approach to generating the classpath vs version 2.2.
*maven-archiver version 2.2:* uses artifact file name
*maven-archiver version 2.4:* uses a pattern that looks a bit like this:
{code}${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}{code}
.. which would give a classpath entry like this: TheJarFile-3.4-SNAPSHOT.jar
(N.B. maven-archiver version 2.2 is used by e.g. maven-ejb-plugin 2.1;
maven-archiver 2.4 is used by e.g. maven-ejb-plugin 2.2 and 2.3)
The easiest way to construct your classpath entries using the
is to use the following configuration:
{code}
maven-ejb-plugin
true
custom
$${artifact.file.name}
{code}
The workaround for maven-jar-plugin and maven-war-plugin is the same.
was (Author: petercoder):
I don't have a fix for this - there is a workaround though.
Version 2.4 of the Maven archiver (maven-archiver) uses by default a different
approach to generating the classpath vs version 2.2.
maven-archiver version 2.2: uses artifact file name
maven-archiver version 2.4: uses a pattern that looks a bit like this:
${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}
.. which would give a classpath entry like this: TheJarFile-3.4-SNAPSHOT.jar
(N.B. maven-archiver version 2.2 is used by e.g. maven-ejb-plugin 2.1;
maven-archiver 2.4 is used by e.g. maven-ejb-plugin 2.2 and 2.3)
The easiest way to construct your classpath entries using the
is to use the following configuration:
{code}
maven-ejb-plugin
3.0
true
custom
$${artifact.file.name}
{code}
The workaround for maven-jar-plugin and maven-war-plugin is the same.
> Manifest classpath ignores the "real" JAR filenames specified in
>
>
> Key: MJAR-61
> URL: https://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Martin Desruisseaux
> Attachments: MJAR-61.zip
>
>
> The manifest classpath generated by Maven ignores the "real" JAR name as
> specified in {{}}. For example the Geotools project tried the
> following configuration:
> {code:xml}
>
> gt-${artifactId}-${version}
> {code}
> but the manifest classpath generated by Maven contains only
> {{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
> *Note:* this problem happen only when the JAR dependencis come from the
> repository. The manifest classpath is correct if all dependencies were
> compiled in the same "{{mvn install}}" cycle. However this workaround is
> applicable only to Geotools developpers (in our case), because users of the
> Geotools library usually download the dependencies from a repository.
> This bug may be related to MJAR-28.
--
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] (MSKINS-55) Website layout broken when browser width is small.
Edward J. Yoon created MSKINS-55: Summary: Website layout broken when browser width is small. Key: MSKINS-55 URL: https://jira.codehaus.org/browse/MSKINS-55 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Reporter: Edward J. Yoon I use new fluido skin for http://hama.apache.org/ But, there's small layout problem when browser width is small. Please fix this, and let me know how can I fix this problem urgently. -- 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] (WAGON-375) wagon-http-lightweight must try to use persistent connection from the jdk
[ https://jira.codehaus.org/browse/WAGON-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened WAGON-375: not fixed so reopen as need more work. > wagon-http-lightweight must try to use persistent connection from the jdk > -- > > Key: WAGON-375 > URL: https://jira.codehaus.org/browse/WAGON-375 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http-lightweight >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.3 > > -- 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
