[jira] Commented: (SCM-294) CVS commits are gathered as filesets, CVS changelog parsing bug fixed
[ http://jira.codehaus.org/browse/SCM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91867 ] Emmanuel Venisse commented on SCM-294: -- Please, rework your patch, based on trunk and without all your pom modifications. I'd like to see a test too. > CVS commits are gathered as filesets, CVS changelog parsing bug fixed > - > > Key: SCM-294 > URL: http://jira.codehaus.org/browse/SCM-294 > Project: Maven SCM > Issue Type: Improvement >Affects Versions: 1.0-beta-4 >Reporter: Roland Asmann > Attachments: maven-scm-1.0-beta-4-CFC-20070330.patch > > > Several changes on the CVS-part of the SCM modules: > - CVS-changes that have been committed in one 'pass' are collected when the > author, comment and date are equal. This means a file-list can be build > (similar to SVN) instead of generating an entry 'per commit'. If the dates > are different by only a second however, they are not merged! > - String-parsing of CVS didn't consider the possibility of a timezone -- fixed > Also, made some changes that reflect in my changes to the changelog-plugin: > - Some changes have been made to work with version-tags as well as dates in > the changelogset -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
Mojo executed using preparationGoals does not get its parameters populated on
execution
---
Key: MRELEASE-212
URL: http://jira.codehaus.org/browse/MRELEASE-212
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: William Ferguson
I have a Mojo with a single String parameter
/**
* @parameter expression="${myProp}"
*/
private String myProp;
If this Mojo is executed directly, eg
mvn myplugin:mygoal -DmyProp=foo
then the Mojo receives the value of myProp at runtime.
If my Mojo is executed via maven-release-plugin preparationGoals eg
org.apache.maven.plugins
maven-release-plugin
clean integration-test
myplugin:mygoal
the the Mojo is not injected with the value of MyProp at runtime.
Now this could just be because there is some extra config that I need to do
that I have missed. I am a Maven newbie.
But I've followed all the doco for maven-release-plugin as well as anything I
could find on building plugins.
So if its my bad, please point me in the right direction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-79) ConcurrentModificationException : TransferEventSupport needs synchronization
ConcurrentModificationException : TransferEventSupport needs synchronization Key: WAGON-79 URL: http://jira.codehaus.org/browse/WAGON-79 Project: wagon Issue Type: Bug Components: wagon-provider-api Affects Versions: 1.0 Environment: archiva Snapshot Reporter: nicolas de loof I get some thraead-safety issues with maven archiva : 2007-04-02 10:11:25,392 [http--1] ERROR [RepositoryServlet]- "Servlet.service()" pour la servlet RepositoryServlet a généré une exception java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(Unknown Source) at java.util.AbstractList$Itr.next(Unknown Source) at org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress (TransferEventSupport.java:117) at org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:350) There is a thread-safety issue in Wagon TransferEventSupport The listeners list is an ArrayList and add/remove/fireEvent methods are not synchronized. This requires either synchronization or use of a CopyOnWriteArrayList (java5 or backport). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element Key: MRELEASE-213 URL: http://jira.codehaus.org/browse/MRELEASE-213 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: William Ferguson I have a plugin containing a Mojo that needs to be executed as part of the maven-release-plugin's preparationGoals phase. The Mojo needs access to some of the information gathered by the maven-release-plugin. Namely it needs access to the SCM release tag specified by the user. The aim of the plugin is to update the subclipse:tags property of the project being released in a similar manner that the Eclipse/Subversion Subclipse plugin does. So the information that I need to gather from the maven-release-plugin is 1) SCM release tag specified by the user. 2) Any other SCM details that have been modified for the release plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-79) ConcurrentModificationException : TransferEventSupport needs synchronization
[ http://jira.codehaus.org/browse/WAGON-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated WAGON-79: - Attachment: WAGON-79.patch synchronized acces to listeners ArrayList > ConcurrentModificationException : TransferEventSupport needs synchronization > > > Key: WAGON-79 > URL: http://jira.codehaus.org/browse/WAGON-79 > Project: wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0 > Environment: archiva Snapshot >Reporter: nicolas de loof > Attachments: WAGON-79.patch > > > I get some thraead-safety issues with maven archiva : > 2007-04-02 10:11:25,392 [http--1] ERROR [RepositoryServlet]- > "Servlet.service()" pour la servlet RepositoryServlet a généré une exception > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(Unknown Source) > at java.util.AbstractList$Itr.next(Unknown Source) > at > org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress > (TransferEventSupport.java:117) > at > org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:350) > There is a thread-safety issue in Wagon TransferEventSupport > The listeners list is an ArrayList and add/remove/fireEvent methods are not > synchronized. > This requires either synchronization or use of a CopyOnWriteArrayList (java5 > or backport). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
[
http://jira.codehaus.org/browse/MRELEASE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91871
]
Emmanuel Venisse commented on MRELEASE-212:
---
You can try that:
{noformat}
org.apache.maven.plugins
maven-release-plugin
clean integration-test myplugin:mygoal
-DmyProp=${myProp}
{noformat}
> Mojo executed using preparationGoals does not get its parameters populated on
> execution
> ---
>
> Key: MRELEASE-212
> URL: http://jira.codehaus.org/browse/MRELEASE-212
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: William Ferguson
>
> I have a Mojo with a single String parameter
> /**
>* @parameter expression="${myProp}"
>*/
> private String myProp;
> If this Mojo is executed directly, eg
> mvn myplugin:mygoal -DmyProp=foo
> then the Mojo receives the value of myProp at runtime.
> If my Mojo is executed via maven-release-plugin preparationGoals eg
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
> clean integration-test
> myplugin:mygoal
>
>
>
> the the Mojo is not injected with the value of MyProp at runtime.
> Now this could just be because there is some extra config that I need to do
> that I have missed. I am a Maven newbie.
> But I've followed all the doco for maven-release-plugin as well as anything I
> could find on building plugins.
> So if its my bad, please point me in the right direction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-96) WebResource not filtered with system properties.
[
http://jira.codehaus.org/browse/MWAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
KlaasJan Elzinga updated MWAR-96:
-
Attachment: patch-junit-test.txt
Patch for junit test (patch-junit-test.txt). It shows that the java.version is
not filtered.
I investigated a little further and found the following:
CompositeMap uses a dominant map and a recessive map. The dominant map is the
pom (basically). It uses reflection to locate for example java.version. This
value is found in the project since the ReflectionExtractor is stripping any
root comments (java. in this case). So for java.version the pom.version value
is found.
I tried calling ReflectionValueExtractor with trimToken = false, but then no
dominant values were found.
> WebResource not filtered with system properties.
>
>
> Key: MWAR-96
> URL: http://jira.codehaus.org/browse/MWAR-96
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: java 5.0, Windows XP
>Reporter: KlaasJan Elzinga
> Attachments: patch-junit-test.txt
>
>
> When filtering a resource:
>
>
> ${basedir}/src/main/resources/
> true
>
> index.jsp
>
>
>
> The index.jsp contains:
> java version${java.version}
> Project${pom.name}
> Version${pom.version}
> After mvn clean install the filtered index.jsp looks like:
> java version1.0.0.SNAPSHOT
> ProjectFrieslandBank TMS TNS WebApp
> Version1.0.0.SNAPSHOT
> The value java.version is filtered to the version of the pom and not the
> system property. The same goes for os.name which is translated to pom.name.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-243) SVN provider reports a warning for 'X' status as unknown, but it's an external link
[ http://jira.codehaus.org/browse/SCM-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-243. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: future) 1.0 > SVN provider reports a warning for 'X' status as unknown, but it's an > external link > --- > > Key: SCM-243 > URL: http://jira.codehaus.org/browse/SCM-243 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0-beta-3 > Environment: Windows XP SP2, Sun JDK 1.4.2_12, Maven 2.0.4, SVN 1.4.0 >Reporter: Nathan Beyer (Cerner) > Assigned To: Emmanuel Venisse >Priority: Minor > Fix For: 1.0 > > > When performing a 'release:prepare' on a project that contains an > 'svn:externals' linked folder, the following warnings and messages are > produced. > [INFO] Unknown file status: 'X'. > [WARNING] Unexpected input, the line must be at least seven characters long. > Line: ''. > [INFO] Unknown file status: 'P'. > I'm not sure what's causing the "unexpected input" and "P" message, but the > "X" message is from a folder in the project that is pulled into the working > copy via the svn:externals property [1]. This is an SVN property that's set > on a folder and makes the SVN client perform an additional "unversioned" > checkout of a URL. The externals will only exist in the working copy. When > the "svn status" is run on a project an external item is given the status > "X". As such, the status X can safely be ignored and treated as either "no > modification" or "ignored" would be. > Here's a dump of the help from svn status for more information. > C:\temp>svn help status > status (stat, st): Print the status of working copy files and directories. > usage: status [PATH...] > With no args, print only locally modified items (no network access). > With -u, add working revision and server out-of-date information. > With -v, print full revision information on every item. > The first six columns in the output are each one character wide: > First column: Says if item was added, deleted, or otherwise changed > ' ' no modifications > 'A' Added > 'C' Conflicted > 'D' Deleted > 'I' Ignored > 'M' Modified > 'R' Replaced > 'X' item is unversioned, but is used by an externals definition > '?' item is not under version control > > [1] > http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.externals -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-96) WebResource not filtered with system properties.
[
http://jira.codehaus.org/browse/MWAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
KlaasJan Elzinga updated MWAR-96:
-
Attachment: patch-CompositeMapa.txt
Attached fix. I'm not sure if the original preferences regarding the dominant
and the recessive are still there. With the patch applied the recessive Map
gains preference if a conflict in propertynames is signalled. A better solution
is probably to enhance the call to ReflectionValueExtractor in the dominant Map.
> WebResource not filtered with system properties.
>
>
> Key: MWAR-96
> URL: http://jira.codehaus.org/browse/MWAR-96
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: java 5.0, Windows XP
>Reporter: KlaasJan Elzinga
> Attachments: patch-CompositeMapa.txt, patch-junit-test.txt
>
>
> When filtering a resource:
>
>
> ${basedir}/src/main/resources/
> true
>
> index.jsp
>
>
>
> The index.jsp contains:
> java version${java.version}
> Project${pom.name}
> Version${pom.version}
> After mvn clean install the filtered index.jsp looks like:
> java version1.0.0.SNAPSHOT
> ProjectFrieslandBank TMS TNS WebApp
> Version1.0.0.SNAPSHOT
> The value java.version is filtered to the version of the pom and not the
> system property. The same goes for os.name which is translated to pom.name.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-2) Create POJO facade
[ http://jira.codehaus.org/browse/SCM-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-2. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: future) 1.0 > Create POJO facade > -- > > Key: SCM-2 > URL: http://jira.codehaus.org/browse/SCM-2 > Project: Maven SCM > Issue Type: Task >Affects Versions: 1.0-alpha-1 >Reporter: Jason van Zyl > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > > Make an easy to use POJO facade for maven-scm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-80) Attempt to use proxySettings even when nonProxyHosts is defined
Attempt to use proxySettings even when nonProxyHosts is defined --- Key: WAGON-80 URL: http://jira.codehaus.org/browse/WAGON-80 Project: wagon Issue Type: Bug Components: wagon-file, wagon-ftp, wagon-http, wagon-provider-api, wagon-provider-test, wagon-scm, wagon-ssh, wagon-ssh-external, wagon-webdav Environment: Maven 2.0.5 or maven 2.0.6, this report is based on 2.0.6 Reporter: David J. M. Karlsen site-deploy hangs because of proxy-settings: [INFO] Generate "Project Team" report. [DEBUG] Generating /tmp/mobilebank/mobilebank-ear/target/site/project-info.html [DEBUG] Generating /tmp/mobilebank/mobilebank-ear/target/site/project-reports.html [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:deploy' --> [DEBUG] (f) inputDirectory = /tmp/mobilebank/mobilebank-ear/target/site [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) settings = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [site:deploy] If I remove the proxies/proxy element[s] from my settings.xml it works. Scp is used for deployment. mvn -X site-deply|grep -i wagon gives: [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected for runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-80) Attempt to use proxySettings even when nonProxyHosts is defined
[ http://jira.codehaus.org/browse/WAGON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91885 ] Kenney Westerhof commented on WAGON-80: --- According to 'grep -ri nonProxyHosts wagon/' only the lightweight http wagon provider honors the nonproxyhosts. > Attempt to use proxySettings even when nonProxyHosts is defined > --- > > Key: WAGON-80 > URL: http://jira.codehaus.org/browse/WAGON-80 > Project: wagon > Issue Type: Bug > Components: wagon-file, wagon-ftp, wagon-http, wagon-provider-api, > wagon-provider-test, wagon-scm, wagon-ssh, wagon-ssh-external, wagon-webdav > Environment: Maven 2.0.5 or maven 2.0.6, this report is based on 2.0.6 >Reporter: David J. M. Karlsen > > site-deploy hangs because of proxy-settings: > [INFO] Generate "Project Team" report. > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-info.html > [DEBUG] Generating > /tmp/mobilebank/mobilebank-ear/target/site/project-reports.html > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:deploy' --> > [DEBUG] (f) inputDirectory = /tmp/mobilebank/mobilebank-ear/target/site > [DEBUG] (f) project = [EMAIL PROTECTED] > [DEBUG] (f) settings = [EMAIL PROTECTED] > [DEBUG] -- end configuration -- > [INFO] [site:deploy] > If I remove the proxies/proxy element[s] from my settings.xml it works. > Scp is used for deployment. > mvn -X site-deply|grep -i wagon gives: > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-5 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) > [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-ssh-external:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-file:jar:1.0-alpha-6 > [DEBUG] org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-alpha-6 > [DEBUG] > org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5:runtime (selected > for runtime) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2921) ejb-client dependency no longer working
ejb-client dependency no longer working --- Key: MNG-2921 URL: http://jira.codehaus.org/browse/MNG-2921 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: Fedora Core 6 Reporter: Frank Cornelis Priority: Blocker Attachments: test.zip When running 'mvn clean install' on the test project (see attachment) under Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. On Maven 2.0.5 I get in the log: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) Under Maven 2.0.6 I get: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT (selected for null) and an error message saying it cannot find the required interfaces defined in Model. When I remove type:ejb-client in the Client pom.xml it compiles again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (MSOURCES-14) Replace maven-verifier with maven-plugin-testing-harness
[ http://jira.codehaus.org/browse/MSOURCES-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MSOURCES-14 stopped by Maria Odea Ching. > Replace maven-verifier with maven-plugin-testing-harness > > > Key: MSOURCES-14 > URL: http://jira.codehaus.org/browse/MSOURCES-14 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Jochen Wiedmann > Assigned To: Maria Odea Ching > Attachments: maven-source-plugin-harness.patch > > > The test suite of the maven-sources-plugin is currently based on the > maven-verifier. This has the undesirable consequence, that the test uses the > *installed* version of the maven-sources-plugin, as opposed to the local > version. > The attached patch replaces the maven-verifier with the > maven-plugin-testing-harness, which doesn't suffer from the same problem. > Additionally, the speed of the test suite is drastically improved. > For reviewers: When considering the patches quality, keep in mind that the > actual Mojo classes and the concrete test classes are almost unchanged. (For > the latter, there is the required addition of a protected method getGoal().) > For reviewers: Note the following comment in AbstractSourcePluginTestCase: > * I don't know, why revision 518116 of this class had the parameters > * "properties" and "expectNoErrors". The following checks > demonstrate, > * that the parameters aren't actually used and may safely be removed. > * This should be done by the patch reviewer. > I recommend that the reviewer follows my suggestion by applying a refactoring > method after applying my patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSOURCES-14) Replace maven-verifier with maven-plugin-testing-harness
[ http://jira.codehaus.org/browse/MSOURCES-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91886 ] Maria Odea Ching commented on MSOURCES-14: -- Applied the submitted patch and made some refactoring in the tests (-r525146 ) Also removed some of the parameters and methods that were no longer used. > Replace maven-verifier with maven-plugin-testing-harness > > > Key: MSOURCES-14 > URL: http://jira.codehaus.org/browse/MSOURCES-14 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.3 >Reporter: Jochen Wiedmann > Assigned To: Maria Odea Ching > Attachments: maven-source-plugin-harness.patch > > > The test suite of the maven-sources-plugin is currently based on the > maven-verifier. This has the undesirable consequence, that the test uses the > *installed* version of the maven-sources-plugin, as opposed to the local > version. > The attached patch replaces the maven-verifier with the > maven-plugin-testing-harness, which doesn't suffer from the same problem. > Additionally, the speed of the test suite is drastically improved. > For reviewers: When considering the patches quality, keep in mind that the > actual Mojo classes and the concrete test classes are almost unchanged. (For > the latter, there is the required addition of a protected method getGoal().) > For reviewers: Note the following comment in AbstractSourcePluginTestCase: > * I don't know, why revision 518116 of this class had the parameters > * "properties" and "expectNoErrors". The following checks > demonstrate, > * that the parameters aren't actually used and may safely be removed. > * This should be done by the patch reviewer. > I recommend that the reviewer follows my suggestion by applying a refactoring > method after applying my patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1458) new version of XINS for Maven2 repository
new version of XINS for Maven2 repository - Key: MAVENUPLOAD-1458 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1458 Project: maven-upload-requests Issue Type: Task Reporter: Anthony Goubard Hi, Here are new JAR file that I'd like to have uploaded in Maven: http://xins.sourceforge.net/maven/xins-server-1.5.2.jar http://xins.sourceforge.net/maven/xins-common-1.5.2.jar http://xins.sourceforge.net/maven/xins-client-1.5.2.jar http://xins.sourceforge.net/maven/logdoc-1.5.2.jar Kind regards, Anthony -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2922) M2 website: broken section links on pom.html, settings.html and others
M2 website: broken section links on pom.html, settings.html and others
--
Key: MNG-2922
URL: http://jira.codehaus.org/browse/MNG-2922
Project: Maven 2
Issue Type: Bug
Components: Documentation: General
Reporter: Petr Kozelka
Priority: Minor
Following pages contain TOC which does not work at all:
http://maven.apache.org/pom.html
http://maven.apache.org/settings.html
The reason is that the TOC items refer to anchors incorrectly. For instance, in
settings.html, there is reference
bq.{{Quick Overview}}
but the corresponding anchor is
bq.{{Quick Overview}}
Manual conversion of letters to lowercase and replacing spaces with underscores
is too annoying to be considered workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2923) Having any active profiles causes the build to fail
Having any active profiles causes the build to fail --- Key: MNG-2923 URL: http://jira.codehaus.org/browse/MNG-2923 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Reporter: Matthew Beermann Priority: Blocker Attachments: pom.xml (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I have any active profiles when building certain projects in Maven 2.0.6, the build will fail. For example, adding something as simple as: foo true ...to my ~/.m2/settings.xml file will cause the stack trace below, but the build will succeed once I remove it. I'm attaching my POM for reference. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2924) Properties in surefire reports are no longer escaped
Properties in surefire reports are no longer escaped Key: MNG-2924 URL: http://jira.codehaus.org/browse/MNG-2924 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.6 Environment: Mac OS X, JVM 1.5 Reporter: Jacob Bay Hansen In version 2.0.4 the properties section of the surefire reports would look like this: in version 2.0.6 it look like this: So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2924) Properties in surefire reports are no longer escaped
[ http://jira.codehaus.org/browse/MNG-2924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91897 ] Jacob Bay Hansen commented on MNG-2924: --- Hmm, looks like my escaped version and unescaped version looks the same in JIRA; it should read: In version 2.0.4 the properties section of the surefire reports would look like this: > Properties in surefire reports are no longer escaped > > > Key: MNG-2924 > URL: http://jira.codehaus.org/browse/MNG-2924 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.6 > Environment: Mac OS X, JVM 1.5 >Reporter: Jacob Bay Hansen > > In version 2.0.4 the properties section of the surefire reports would look > like this: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-79) ConcurrentModificationException : TransferEventSupport needs synchronization
[ http://jira.codehaus.org/browse/WAGON-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91903 ] Carlos Sanchez commented on WAGON-79: - only the methods that modify the array should be inside a synchronized(this), no? > ConcurrentModificationException : TransferEventSupport needs synchronization > > > Key: WAGON-79 > URL: http://jira.codehaus.org/browse/WAGON-79 > Project: wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0 > Environment: archiva Snapshot >Reporter: nicolas de loof > Attachments: WAGON-79.patch > > > I get some thraead-safety issues with maven archiva : > 2007-04-02 10:11:25,392 [http--1] ERROR [RepositoryServlet]- > "Servlet.service()" pour la servlet RepositoryServlet a généré une exception > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(Unknown Source) > at java.util.AbstractList$Itr.next(Unknown Source) > at > org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress > (TransferEventSupport.java:117) > at > org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:350) > There is a thread-safety issue in Wagon TransferEventSupport > The listeners list is an ArrayList and add/remove/fireEvent methods are not > synchronized. > This requires either synchronization or use of a CopyOnWriteArrayList (java5 > or backport). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2922) M2 website: broken section links on pom.html, settings.html and others
[
http://jira.codehaus.org/browse/MNG-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91907
]
Petr Kozelka commented on MNG-2922:
---
same issue at http://maven.apache.org/guides/getting-started/index.html
> M2 website: broken section links on pom.html, settings.html and others
> --
>
> Key: MNG-2922
> URL: http://jira.codehaus.org/browse/MNG-2922
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: General
>Reporter: Petr Kozelka
>Priority: Minor
>
> Following pages contain TOC which does not work at all:
> http://maven.apache.org/pom.html
> http://maven.apache.org/settings.html
> The reason is that the TOC items refer to anchors incorrectly. For instance,
> in settings.html, there is reference
> bq.{{Quick Overview}}
> but the corresponding anchor is
> bq.{{Quick Overview}}
> Manual conversion of letters to lowercase and replacing spaces with
> underscores is too annoying to be considered workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (SUREFIRE-317) Properties in surefire reports are no longer escaped
[ http://jira.codehaus.org/browse/SUREFIRE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez moved MNG-2924 to SUREFIRE-317: -- Affects Version/s: (was: 2.0.6) Component/s: (was: Plugins and Lifecycle) xml generation Key: SUREFIRE-317 (was: MNG-2924) Project: Maven Surefire (was: Maven 2) > Properties in surefire reports are no longer escaped > > > Key: SUREFIRE-317 > URL: http://jira.codehaus.org/browse/SUREFIRE-317 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation > Environment: Mac OS X, JVM 1.5 >Reporter: Jacob Bay Hansen > > In version 2.0.4 the properties section of the surefire reports would look > like this: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-317) Properties in surefire reports are no longer escaped
[ http://jira.codehaus.org/browse/SUREFIRE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91902 ] Carlos Sanchez commented on SUREFIRE-317: - what version of the surefire plugin are you using? > Properties in surefire reports are no longer escaped > > > Key: SUREFIRE-317 > URL: http://jira.codehaus.org/browse/SUREFIRE-317 > Project: Maven Surefire > Issue Type: Bug > Components: xml generation > Environment: Mac OS X, JVM 1.5 >Reporter: Jacob Bay Hansen > > In version 2.0.4 the properties section of the surefire reports would look > like this: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-79) ConcurrentModificationException : TransferEventSupport needs synchronization
[ http://jira.codehaus.org/browse/WAGON-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91905 ] nicolas de loof commented on WAGON-79: -- The methods that iterates on the List will throw a ConcurrentModificationException if the list is modified during iteration. Synchronizing only the add/remove will not avoid another thread to fire an event and acces the list for iteration. An alternative to synchronized methods is to use a CopyOnWriteArrayList. For java 1.4 compatibilty this requires to add backport-util-concurrent as a dependency. > ConcurrentModificationException : TransferEventSupport needs synchronization > > > Key: WAGON-79 > URL: http://jira.codehaus.org/browse/WAGON-79 > Project: wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0 > Environment: archiva Snapshot >Reporter: nicolas de loof > Attachments: WAGON-79.patch > > > I get some thraead-safety issues with maven archiva : > 2007-04-02 10:11:25,392 [http--1] ERROR [RepositoryServlet]- > "Servlet.service()" pour la servlet RepositoryServlet a généré une exception > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(Unknown Source) > at java.util.AbstractList$Itr.next(Unknown Source) > at > org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress > (TransferEventSupport.java:117) > at > org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:350) > There is a thread-safety issue in Wagon TransferEventSupport > The listeners list is an ArrayList and add/remove/fireEvent methods are not > synchronized. > This requires either synchronization or use of a CopyOnWriteArrayList (java5 > or backport). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-311) incorrectly displayed groupId for dependencies
incorrectly displayed groupId for dependencies
--
Key: MRM-311
URL: http://jira.codehaus.org/browse/MRM-311
Project: Archiva
Issue Type: Bug
Components: web application
Reporter: Petr Kozelka
the list in the "Dependencies" tab contains correct artifacts, but with groupId
taken from the library being explored, not from the dependency itself.
Example:
library {{org.hibernate:hibernate:3.2.1.ga}} depends on
- {{*net.sf.ehcache*:ehcache:1.2.3}}
- {{*javax.transaction*:jta:1.0.1B}}
- etc
but the page displays this information:
- {{{color:red}org.hibernate{color}:ehcache:1.2.3}}
- {{{color:red}org.hibernate{color}:jta:1.0.1B}}
- etc
The same bug appears on tabs "*Dependency tree*" and "*Used by*".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91910
]
Antonio Petrelli commented on MJAVADOC-116:
---
The same problem appears during the use of the release plugin: the release
fails and I have to install the checked-out code locally before retrying the
release.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-194. Assignee: John Casey Resolution: Fixed Fix Version/s: 2.2-beta-1 I've added a flag to the that is set to false by default. This restores backward compatibility with 2.1 on this point, where the transitive path of an artifact will not be considered when looking at includes/excludes patterns. If this flag is set to true, it allows you to filter the entire subgraph based on one pattern...so that when you exclude one dependency, you also exclude all of its dependencies (which is more correct). In fact, this "feature" is a bug in the 2.1 code. The more correct way to fix this, given your example, would be to create a build extension that supplies an artifact handler for tar.gz artifacts. Doing this, you could specify true, which is really what you're trying to accomplish here. In any case, I've included a new unit test to check this flag (both directions using that and an existing test), and re-deployed the patched code as a new RC for 2.2-beta-1. > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter > Assigned To: John Casey > Fix For: 2.2-beta-1 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-194) unnecessary dependency expansion regression
[ http://jira.codehaus.org/browse/MASSEMBLY-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91914 ] John Casey commented on MASSEMBLY-194: -- BTW, I was unable to build Continuum from trunk. Something about a compilation error having to do with maven-scm in the configuration module. > unnecessary dependency expansion regression > --- > > Key: MASSEMBLY-194 > URL: http://jira.codehaus.org/browse/MASSEMBLY-194 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Brett Porter > Assigned To: John Casey > Fix For: 2.2-beta-1 > > Attachments: assembly-test.tar.gz > > > See the attached test project. It requires that you've run mvn clean install > for continuum previously so there is a sizable dependency in the repo to play > with. > If you build with assembly 2.1, only the tarball is expanded and included in > the final distribution (about 27mb) > With 2.2-beta-1, all the transitive dependencies are also expanded and > included (about 65mb). > This is a functionality change, but also consumes a very large amount of > memory and CPU. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPPLUGIN-37) The plugin:xdoc produce a null pointer exception when no parameter is provided
The plugin:xdoc produce a null pointer exception when no parameter is provided
--
Key: MPPLUGIN-37
URL: http://jira.codehaus.org/browse/MPPLUGIN-37
Project: maven-plugin-plugin
Issue Type: Bug
Affects Versions: 1.7.1
Environment: Group Id: org.apache.maven.plugins
Artifact Id: maven-plugin-plugin
Version: 2.2
Goal Prefix: plugin
version of plugin-plugin : 2.2
Reporter: Clement Soullard
The pluggin:xdoc return a mojo MojoDescriptor with a null parameter list when
the mojo has no parameter.
That causes a null pointer exception when converted to xdoc.
The folowing patch applied to maven-plugin-tools-2.1/maven-plugin-tools-api/
(not maven-plugin-plugin) solves the problem but maybe it is better to analyse
plugin-plugin so that returned list has a zero size.
Index:
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
===
---
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
(revision 525213)
+++
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
(working copy)
@@ -106,7 +106,7 @@
assertNotNull( mojoDescriptor.isDependencyResolutionRequired() );
// check the parameter.
-checkParameter( (Parameter) mojoDescriptor.getParameters().get( 0 ) );
+// checkParameter( (Parameter) mojoDescriptor.getParameters().get( 0 )
);
}
private void checkParameter( Parameter parameter )
Index:
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
===
---
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
(revision 525213)
+++
C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
(working copy)
@@ -50,54 +50,90 @@
}
public void testGenerator()
-throws Exception
-{
-setupGenerator();
+throws Exception
+{
+setupGenerator();
-MojoDescriptor mojoDescriptor = new MojoDescriptor();
-mojoDescriptor.setGoal( "testGoal" );
-mojoDescriptor.setImplementation(
"org.apache.maven.tools.plugin.generator.TestMojo" );
-mojoDescriptor.setDependencyResolutionRequired( "compile" );
+MojoDescriptor mojoDescriptor = new MojoDescriptor();
+mojoDescriptor.setGoal( "testGoal" );
+mojoDescriptor.setImplementation(
"org.apache.maven.tools.plugin.generator.TestMojo" );
+mojoDescriptor.setDependencyResolutionRequired( "compile" );
-List params = new ArrayList();
+List params = new ArrayList();
-Parameter param = new Parameter();
-param.setExpression( "${project.build.directory}" );
-param.setName( "dir" );
-param.setRequired( true );
-param.setType( "java.lang.String" );
-param.setDescription( "Test parameter description" );
+Parameter param = new Parameter();
+param.setExpression( "${project.build.directory}" );
+param.setName( "dir" );
+param.setRequired( true );
+param.setType( "java.lang.String" );
+param.setDescription( "Test parameter description" );
-params.add( param );
+params.add( param );
-mojoDescriptor.setParameters( params );
+mojoDescriptor.setParameters( params );
-PluginDescriptor pluginDescriptor = new PluginDescriptor();
-mojoDescriptor.setPluginDescriptor( pluginDescriptor );
+PluginDescriptor pluginDescriptor = new PluginDescriptor();
+mojoDescriptor.setPluginDescriptor( pluginDescriptor );
-pluginDescriptor.addMojo( mojoDescriptor );
+pluginDescriptor.addMojo( mojoDescriptor );
-pluginDescriptor.setArtifactId( "maven-unitTesting-plugin" );
-pluginDescriptor.setGoalPrefix( "test" );
+pluginDescriptor.setArtifactId( "maven-unitTesting-plugin" );
+pluginDescriptor.setGoalPrefix( "test" );
-ComponentDependency dependency = new ComponentDependency();
-dependency.setGroupId( "testGroup" );
-dependency.setArtifactId( "testArtifact" );
-dependency.setVersion( "0.0.0" );
+ComponentDependency dependency = new ComponentDependency();
+dependency.setGroupId( "testGroup" );
+dependency.setArtifactId( "testArtifact" );
+dependency.setVersion( "0.0.0" );
-pluginDescriptor.setDependencies( Collections.singletonList(
dependency ) );
+pluginDescriptor.setDependen
[jira] Moved: (MPLUGIN-31) The plugin:xdoc produce a null pointer exception when no parameter is provided
[
http://jira.codehaus.org/browse/MPLUGIN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl moved MPPLUGIN-37 to MPLUGIN-31:
--
Affects Version/s: (was: 1.7.1)
Workflow: Maven New (was: jira)
Key: MPLUGIN-31 (was: MPPLUGIN-37)
Project: Maven 2.x Plugin Plugin (was: maven-plugin-plugin)
> The plugin:xdoc produce a null pointer exception when no parameter is provided
> --
>
> Key: MPLUGIN-31
> URL: http://jira.codehaus.org/browse/MPLUGIN-31
> Project: Maven 2.x Plugin Plugin
> Issue Type: Bug
> Environment: Group Id: org.apache.maven.plugins
> Artifact Id: maven-plugin-plugin
> Version: 2.2
> Goal Prefix: plugin
> version of plugin-plugin : 2.2
>Reporter: Clement Soullard
>
> The pluggin:xdoc return a mojo MojoDescriptor with a null parameter list
> when the mojo has no parameter.
> That causes a null pointer exception when converted to xdoc.
> The folowing patch applied to maven-plugin-tools-2.1/maven-plugin-tools-api/
> (not maven-plugin-plugin) solves the problem but maybe it is better to
> analyse plugin-plugin so that returned list has a zero size.
> Index:
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
> ===
> ---
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
> (revision 525213)
> +++
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGeneratorTest.java
> (working copy)
> @@ -106,7 +106,7 @@
> assertNotNull( mojoDescriptor.isDependencyResolutionRequired() );
>
> // check the parameter.
> -checkParameter( (Parameter) mojoDescriptor.getParameters().get( 0 )
> );
> +// checkParameter( (Parameter) mojoDescriptor.getParameters().get( 0
> ) );
> }
>
> private void checkParameter( Parameter parameter )
> Index:
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
> ===
> ---
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
> (revision 525213)
> +++
> C:/maven-plugin-tools-2.1/maven-plugin-tools-api/src/test/java/org/apache/maven/tools/plugin/generator/AbstractGeneratorTestCase.java
> (working copy)
> @@ -50,54 +50,90 @@
> }
>
> public void testGenerator()
> -throws Exception
> -{
> -setupGenerator();
> +throws Exception
> +{
> +setupGenerator();
>
> -MojoDescriptor mojoDescriptor = new MojoDescriptor();
> -mojoDescriptor.setGoal( "testGoal" );
> -mojoDescriptor.setImplementation(
> "org.apache.maven.tools.plugin.generator.TestMojo" );
> -mojoDescriptor.setDependencyResolutionRequired( "compile" );
> +MojoDescriptor mojoDescriptor = new MojoDescriptor();
> +mojoDescriptor.setGoal( "testGoal" );
> +mojoDescriptor.setImplementation(
> "org.apache.maven.tools.plugin.generator.TestMojo" );
> +mojoDescriptor.setDependencyResolutionRequired( "compile" );
>
> -List params = new ArrayList();
> +List params = new ArrayList();
>
> -Parameter param = new Parameter();
> -param.setExpression( "${project.build.directory}" );
> -param.setName( "dir" );
> -param.setRequired( true );
> -param.setType( "java.lang.String" );
> -param.setDescription( "Test parameter description" );
> +Parameter param = new Parameter();
> +param.setExpression( "${project.build.directory}" );
> +param.setName( "dir" );
> +param.setRequired( true );
> +param.setType( "java.lang.String" );
> +param.setDescription( "Test parameter description" );
>
> -params.add( param );
> +params.add( param );
>
> -mojoDescriptor.setParameters( params );
> +mojoDescriptor.setParameters( params );
>
> -PluginDescriptor pluginDescriptor = new PluginDescriptor();
> -mojoDescriptor.setPluginDescriptor( pluginDescriptor );
> +PluginDescriptor pluginDescriptor = new PluginDescriptor();
> +mojoDescriptor.setPluginDescriptor( pluginDescriptor );
>
> -pluginDescriptor.addMojo( mojoDescriptor );
> +pluginDescriptor.addMojo( mojoDescriptor );
>
> -pluginDescriptor.setArtifactId( "maven-unitTesting-plugin" );
> -pluginDescriptor.setGoalPrefix( "test" );
> +pluginDescriptor.setArtifactId( "maven-unitTes
[jira] Closed: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MIDEA-39. Resolution: Fixed Fix Version/s: 2.1 > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91933 ] Andrew Perepelytsya commented on MIDEA-39: -- I don't understand the point of the last comment. That is exactly what this issue is about, and that behavior is a problem. I've rebuild the plugin from trunk, but no, nothing is fixed. In fact, the only difference between having useFullNames on and off is the linkage of sources jar (?!). I'm attaching 2 outputs from idea:module run with the above setting on and off, it always generates links to jars from inside the module. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch, mule-module-ognl.iml_false, > mule-module-ognl.iml_true > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Perepelytsya updated MIDEA-39: - Attachment: mule-module-ognl.iml_false mule-module-ognl.iml_true SVN revision tested: 525253 > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch, mule-module-ognl.iml_false, > mule-module-ognl.iml_true > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[
http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91936
]
Dennis Lundberg commented on MIDEA-39:
--
Andrew,
I think you are trying to use the wrong parameter here. The configuration
parameter to switch between module dependencies and libraries is called
"linkModules". That is what this issue is about. See snippet from the source of
the plugin below:
{code}
/**
* Whether to link the reactor projects as dependency modules or as
libraries.
*
* @parameter expression="${linkModules}" default-value="true"
*/
private boolean linkModules;
{code}
Here's the corresponding source for "useFullNames":
{code}
/**
* Whether to use full artifact names when referencing libraries.
*
* @parameter expression="${useFullNames}" default-value="false"
*/
private boolean useFullNames;
{code}
> In a multi-module project, idea plugin should generate module dependencies
> instead of creating libs with references to the repository
> -
>
> Key: MIDEA-39
> URL: http://jira.codehaus.org/browse/MIDEA-39
> Project: Maven 2.x Idea Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
> Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2
>Reporter: Vikash Ramanlal
> Assigned To: Brett Porter
>Priority: Minor
> Fix For: 2.1
>
> Attachments: module-dependencies.patch, mule-module-ognl.iml_false,
> mule-module-ognl.iml_true
>
>
> When I generate my idea files using "mvn idea:idea", all works fine.
> However if I have module a and module b (both jar packaging) and b depends on
> a, then I expected the idea plugin to generate the project files such that
> for module b, a is a dependent module. However what I get is a library entry
> for a that points to a jar in the local repository.
> Maven 1.0.2 idea plugin did not work this way. I created the module
> dependencies in correctly in the idea project.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2925) NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml
NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml
Key: MNG-2925
URL: http://jira.codehaus.org/browse/MNG-2925
Project: Maven 2
Issue Type: Bug
Components: Plugin API
Affects Versions: 2.0.5
Reporter: Kohsuke Kawaguchi
The getMojo method fails with NPE because getMojos() method returns null. This
happens when there's no mojo in the plugin.
The code should be modified to check for this situation, like this:
{code}
public MojoDescriptor getMojo( String goal )
{
List mojos = getMojos();
if(mojos==null) return null; // no mojo in this POM
MojoDescriptor mojoDescriptor = null;
for ( Iterator i = mojos.iterator(); i.hasNext() && mojoDescriptor ==
null; )
{
MojoDescriptor desc = (MojoDescriptor) i.next();
if ( goal.equals( desc.getGoal() ) )
{
mojoDescriptor = desc;
}
}
return mojoDescriptor;
}
{/code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-32) Make it an error for a plugin to have no mojo
Make it an error for a plugin to have no mojo - Key: MPLUGIN-32 URL: http://jira.codehaus.org/browse/MPLUGIN-32 Project: Maven 2.x Plugin Plugin Issue Type: Improvement Reporter: Kohsuke Kawaguchi Maven plugins must have mojos to be useful, and not having a mojo causes a problem down the line like MNG-2925. Therefore it would be desirable for the plugin plugin to check for this and issue an error, so that errors will be caught early, not later. A silly pom mistake (such as not setting build/sourceDirectory right) causes this kind of problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2925) NullPointerException in PluginDescriptor.getMojo() if there's no mojo in pom.xml
[
http://jira.codehaus.org/browse/MNG-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91937
]
Kohsuke Kawaguchi commented on MNG-2925:
Also see MPLUGIN-32 for a relevant RFE.
> NullPointerException in PluginDescriptor.getMojo() if there's no mojo in
> pom.xml
>
>
> Key: MNG-2925
> URL: http://jira.codehaus.org/browse/MNG-2925
> Project: Maven 2
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 2.0.5
>Reporter: Kohsuke Kawaguchi
>
> The getMojo method fails with NPE because getMojos() method returns null.
> This happens when there's no mojo in the plugin.
> The code should be modified to check for this situation, like this:
> {code}
> public MojoDescriptor getMojo( String goal )
> {
> List mojos = getMojos();
> if(mojos==null) return null; // no mojo in this POM
> MojoDescriptor mojoDescriptor = null;
> for ( Iterator i = mojos.iterator(); i.hasNext() && mojoDescriptor ==
> null; )
> {
> MojoDescriptor desc = (MojoDescriptor) i.next();
> if ( goal.equals( desc.getGoal() ) )
> {
> mojoDescriptor = desc;
> }
> }
> return mojoDescriptor;
> }
> {/code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91939 ] Andrew Perepelytsya commented on MIDEA-39: -- Thanks for the clarification, Dennis. Then, l saw this linkModules and it was true by default, which haven't generated the desired output. Why do I think it should? E.g. consider a reactor project where your CWD is somewhere down the path in a child. If I modify the root pom to use a different version of e.g. plugin, the project I'm currently in properly resolves all poms upwards to the root (they are all available on the disk), and actually picks up the change. I don't have to run from the root. This leads me to the conclusion that similar behavior should be made available to the IDEA plugin. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch, mule-module-ognl.iml_false, > mule-module-ognl.iml_true > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91943 ] Dennis Lundberg commented on MIDEA-39: -- So if I understand you correctly, you want to be able to run "mvn idea:module" somewhere below the parent pom. That should then update the IDEA module regarding dependencies that have been modified in the parent pom. If that is not working for you I suggest that you open another issue for that. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch, mule-module-ognl.iml_false, > mule-module-ognl.iml_true > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91944 ] Andrew Perepelytsya commented on MIDEA-39: -- Almost ;) The above behavior might be a step forward, but for now just being able to resolve the reactor projects and linking to them is all that is needed. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 >Reporter: Vikash Ramanlal > Assigned To: Brett Porter >Priority: Minor > Fix For: 2.1 > > Attachments: module-dependencies.patch, mule-module-ognl.iml_false, > mule-module-ognl.iml_true > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1908) snapshots not deployed using m2, or deployed with uniqueVersion = false are not updated if present locally
[ http://jira.codehaus.org/browse/MNG-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1908. - Assignee: Brett Porter (was: Jason van Zyl) Resolution: Fixed Fix Version/s: (was: 2.0.7) 2.0.5 this was fixed in several scenarios in 2.0.5. Any related problems are being filed as new issues. > snapshots not deployed using m2, or deployed with uniqueVersion = false are > not updated if present locally > -- > > Key: MNG-1908 > URL: http://jira.codehaus.org/browse/MNG-1908 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.1 >Reporter: Guillaume Nodet > Assigned To: Brett Porter >Priority: Blocker > Fix For: 2.0.5 > > Original Estimate: 30 minutes > Time Spent: 2 hours, 30 minutes > Remaining Estimate: 0 minutes > > It seems from the log info that m2 is trying to locate the artifact metadata > on the repository. > SInce this artifact has been generated from m1, there is no metadata. > So whatever repository settings are configured, m2 will never update snapsots. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-29) Can't use maven-install-plugin with install-file in POM
[
http://jira.codehaus.org/browse/MINSTALL-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91950
]
Jason Dillon commented on MINSTALL-29:
--
The latest {{2.2-SNAPSHOT}} resolves this problem. To use add this to your pom:
{code}
apache-snapshots
Apache Snapshots Repository
http://people.apache.org/repo/m2-snapshot-repository
default
true
daily
ignore
false
org.apache.maven.plugins
maven-install-plugin
2.2-SNAPSHOT
{code}
> Can't use maven-install-plugin with install-file in POM
>
>
> Key: MINSTALL-29
> URL: http://jira.codehaus.org/browse/MINSTALL-29
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: WinXP, running M2 in Cygwin
>Reporter: Brad Harper
>Priority: Minor
>
> This issue is related to another I submitted recently. In fact, the earlier
> issue was encounted
> in an earlier attempt to get the same results. (see bottom, below.)
> Consider the POM descriptor containing
>
>
> snapshots
> http://svn.apache.org/maven-snapshot-repository
>
>
>
>
>
> maven-install-plugin
> 2.2-SNAPSHOT
>
>
> install-library
> install
>
> install-file
>
>
> com.epsiia.dxr.third-party
>
> dxr-third-party-WINDOWS-X86-com-emc-centera-fplibrary-lib
> 2.0SP1
> lib
> FPLibrary.lib
>
>
>
>
>
>
> M2 fails to build in this project because all elements are
> read-only. [I'm attempting
> to use the 2.2-SNAPSHOT because I get the same error in stable versions. ]
> Shouldn't this execution be allowable and equivalent to the CLI invocation
>% mvn install:install-file -DgroupId=com.epsiia.dxr.third-party ..
> I'm trying to create a mind-numbingly simple environment, so that other
> less-experienced developers
> aren't required to know which of the third-party libraries need to be
> manually installed via once-only
> occurances should the local repository need to be re-constructed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGROOVY-25) Groovy scripts compiled by the maven groovy plugin does not have the org.apache.maven.plugin package on its classpath
[
http://jira.codehaus.org/browse/MGROOVY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91958
]
Jesse Eichar commented on MGROOVY-25:
-
Do you know the plugin for this. I've been scouring the maven website and have
come up empty so far... I would request that in the future at some point (no
big hurry) that certain plugins are on the class path by default. I would
expect the same ones as are available when developing a java-based groovy
plugin since this is similar.
Let me know if I am off track.
FYI I've had great luck with this plugin.
> Groovy scripts compiled by the maven groovy plugin does not have the
> org.apache.maven.plugin package on its classpath
> -
>
> Key: MGROOVY-25
> URL: http://jira.codehaus.org/browse/MGROOVY-25
> Project: Maven 2.x Groovy Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
> Environment: all
>Reporter: Jesse Eichar
> Assigned To: Jason Dillon
>Priority: Minor
>
> consider the following script:
> class ScriptClass{
> def testRequirements(){
> def requiredFile=new File("/requiredFile")
> if( !requiredFile.exists ){
> throw new org.apache.maven.plugin.MojoFailureException( "RequiredFile
> does not exist" )
> }
> }
> }
> This script will not compile correctly using the compile plugin because the
> MojoFailureException is not on the classpath. As a work around you can throw
> an AssertionError or a RuntimeException but in both cases you get a big ugly
> stacktrace. If you can throw a MojoFailureException the maven build will
> fail cleaning reporting the error and the stack trace can be shown using the
> -e stack trace.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGROOVY-25) Groovy scripts compiled by the maven groovy plugin does not have the org.apache.maven.plugin package on its classpath
[
http://jira.codehaus.org/browse/MGROOVY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91959
]
Jason Dillon commented on MGROOVY-25:
-
To get {{org.apache.maven.plugin.MojoFailureException}} you need to include:
* org.apache.maven:maven-plugin-api
Though I'm not sure that just by throwing a {{MojoFailureException}} that ugly
stack traces will be omitted when using {{groovy:execute}}. But I've not tired
it either ;-)
> Groovy scripts compiled by the maven groovy plugin does not have the
> org.apache.maven.plugin package on its classpath
> -
>
> Key: MGROOVY-25
> URL: http://jira.codehaus.org/browse/MGROOVY-25
> Project: Maven 2.x Groovy Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
> Environment: all
>Reporter: Jesse Eichar
> Assigned To: Jason Dillon
>Priority: Minor
>
> consider the following script:
> class ScriptClass{
> def testRequirements(){
> def requiredFile=new File("/requiredFile")
> if( !requiredFile.exists ){
> throw new org.apache.maven.plugin.MojoFailureException( "RequiredFile
> does not exist" )
> }
> }
> }
> This script will not compile correctly using the compile plugin because the
> MojoFailureException is not on the classpath. As a work around you can throw
> an AssertionError or a RuntimeException but in both cases you get a big ugly
> stacktrace. If you can throw a MojoFailureException the maven build will
> fail cleaning reporting the error and the stack trace can be shown using the
> -e stack trace.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
[
http://jira.codehaus.org/browse/MRELEASE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91963
]
William Ferguson commented on MRELEASE-212:
---
Thanks Emmanuel - that does allow the property to get passed in.
I was trying to get hold of the value of the dryRun parameter that can be
passed to the maven-release-plugin as I will need to perform different
behaviour depending on whether its a dry run or not - which I expect is typical.
But I think development of my plugin will have to go on hold until
http://jira.codehaus.org/browse/MRELEASE-213 is resolved in some form. I really
need access to the SCM Release tag specified by the user. Is there no way to
retrieve this value via a MavenProject property?
> Mojo executed using preparationGoals does not get its parameters populated on
> execution
> ---
>
> Key: MRELEASE-212
> URL: http://jira.codehaus.org/browse/MRELEASE-212
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: William Ferguson
>
> I have a Mojo with a single String parameter
> /**
>* @parameter expression="${myProp}"
>*/
> private String myProp;
> If this Mojo is executed directly, eg
> mvn myplugin:mygoal -DmyProp=foo
> then the Mojo receives the value of myProp at runtime.
> If my Mojo is executed via maven-release-plugin preparationGoals eg
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
> clean integration-test
> myplugin:mygoal
>
>
>
> the the Mojo is not injected with the value of MyProp at runtime.
> Now this could just be because there is some extra config that I need to do
> that I have missed. I am a Maven newbie.
> But I've followed all the doco for maven-release-plugin as well as anything I
> could find on building plugins.
> So if its my bad, please point me in the right direction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-513) Invalid POM: aspectwerkz/aspectwerkz-core
Invalid POM: aspectwerkz/aspectwerkz-core - Key: MEV-513 URL: http://jira.codehaus.org/browse/MEV-513 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Jing Xue http://repo1.maven.org/maven2/aspectwerkz/aspectwerkz-core/2.0/aspectwerkz-core-2.0.pom The closing tag is missing the "/". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2876) versionrange doesn't handle singluar version correctly (tests and patch already in svn)
[ http://jira.codehaus.org/browse/MNG-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2876: --- Fix Version/s: (was: 2.0.x) 2.1 Updated javadoc in 2.0.7...moving issue for better resolution in 2.1 > versionrange doesn't handle singluar version correctly (tests and patch > already in svn) > --- > > Key: MNG-2876 > URL: http://jira.codehaus.org/browse/MNG-2876 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts >Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5 >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.1 > > > I'm still having trouble with this. I wrote a sample class to show my > problem. The issue is that all the contains calls are correct except that a > singular version ie "2.0.5" always returns true. Is this an artifact bug, or > am I doing something wrong? According to the javadoc for the method (shown in > my original post below) the singular version is allowed as a version range. > The tests and fix are here: > https://svn.apache.org/repos/asf/maven/plugins/branches/maven-artifact-version-range-fix > > I just need someone to take a look and I can apply. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2926) group search order for plugins is inverted
group search order for plugins is inverted -- Key: MNG-2926 URL: http://jira.codehaus.org/browse/MNG-2926 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.6, 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Reporter: Brian Fox currently the mojo.codehaus.org is used if a plugin name conflicts with maven.apache.org. It should be the other way around. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2926) group search order for plugins is inverted
[ http://jira.codehaus.org/browse/MNG-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2926: --- Assignee: Brian Fox Fix Version/s: 2.0.7 > group search order for plugins is inverted > -- > > Key: MNG-2926 > URL: http://jira.codehaus.org/browse/MNG-2926 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.0.7 > > > currently the mojo.codehaus.org is used if a plugin name conflicts with > maven.apache.org. It should be the other way around. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
[ http://jira.codehaus.org/browse/MRELEASE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91996 ] William Ferguson commented on MRELEASE-213: --- Loks like I also need access to the SCM version that has been checked out by the maven-release-plugin for safety. > Need ability to access values gathered by maven-release-plugin in Mojos > executed as part of preparationGoals element > > > Key: MRELEASE-213 > URL: http://jira.codehaus.org/browse/MRELEASE-213 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: William Ferguson > > I have a plugin containing a Mojo that needs to be executed as part of the > maven-release-plugin's preparationGoals phase. > The Mojo needs access to some of the information gathered by the > maven-release-plugin. > Namely it needs access to the SCM release tag specified by the user. > The aim of the plugin is to update the subclipse:tags property of the project > being released in a similar manner that the Eclipse/Subversion Subclipse > plugin does. So the information that I need to gather from the > maven-release-plugin is > 1) SCM release tag specified by the user. > 2) Any other SCM details that have been modified for the release plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-79) ConcurrentModificationException : TransferEventSupport needs synchronization
[ http://jira.codehaus.org/browse/WAGON-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof updated WAGON-79: - Attachment: WAGON-79-testcase.patch This new patch includes a test-case that demonstrates the issue. This may not be fully reproductible as unit-testing thread safety is not easy. The idea of the test is : create a listener (mock1) that takes 500ms to handle the event. the listener is registered 2 times. a new thread is started, with a Runnable that will fire an event. The main test Thread waits this new thread to be started and fire secondevent. The wait-timing is expected to have : - Testcase thread running - Event fired from second thread, first listener notified (500ms wait) mock1 is registered as a 3d listener. The listener list is updated when the second thread iterates the list for next listener, the list has been updated and a ConcurrentModificationException is thrown. I don't know any thread-safety unit tool that may make such testcase esaier / cleaner. > ConcurrentModificationException : TransferEventSupport needs synchronization > > > Key: WAGON-79 > URL: http://jira.codehaus.org/browse/WAGON-79 > Project: wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 1.0 > Environment: archiva Snapshot >Reporter: nicolas de loof > Attachments: WAGON-79-testcase.patch, WAGON-79.patch > > > I get some thraead-safety issues with maven archiva : > 2007-04-02 10:11:25,392 [http--1] ERROR [RepositoryServlet]- > "Servlet.service()" pour la servlet RepositoryServlet a généré une exception > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(Unknown Source) > at java.util.AbstractList$Itr.next(Unknown Source) > at > org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress > (TransferEventSupport.java:117) > at > org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:350) > There is a thread-safety issue in Wagon TransferEventSupport > The listeners list is an ArrayList and add/remove/fireEvent methods are not > synchronized. > This requires either synchronization or use of a CopyOnWriteArrayList (java5 > or backport). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
