[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
[jira] Commented: (MGROOVY-1) Support mojo plugin.xml generation for Groovy mojos
[
http://jira.codehaus.org/browse/MGROOVY-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92044
]
Jason Dillon commented on MGROOVY-1:
Latest trunk supports (mostly untested) plugin.xml generation. More tests and
updates coming soon... after I get some sleep :-)
Support mojo plugin.xml generation for Groovy mojos
---
Key: MGROOVY-1
URL: http://jira.codehaus.org/browse/MGROOVY-1
Project: Maven 2.x Groovy Plugin
Issue Type: New Feature
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.0-alpha-3
Right now there isn't really a good way to generate a plugin.xml for a Mojo
implemented in Groovy.
There is the {{javalike-maven-plugin-tools}} module which kinda works, though
requires some icky ; tokens to get qDox to properly parse out javadocs for
parameters. I'm not sure that this module handles annotations on
super-classes either.
I've hacked up an extractor.groovy a while ago (MNG-1664) which uses regex,
but that doesn't handle super-classes either.
Really need a nice way to parse regular groovy (w/o needing ;') to generate
a plugin.xml.
--
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: (MRM-236) Unable to 'proxy through' more than one managed repo
[ http://jira.codehaus.org/browse/MRM-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92047 ] Maria Odea Ching commented on MRM-236: -- I tried this with -r525451.. I had two existing managed repo (releases and snapshots) and a proxy repo, then I added another managed repo and edited the existing proxy repo that I had. In the 'Proxied through' list, only the releases and snapshots were listed. The managed repo I've just added wasn't in the list. But when I restarted archiva and edited the proxy repo again, the last managed repo I added was already in the list. Unable to 'proxy through' more than one managed repo Key: MRM-236 URL: http://jira.codehaus.org/browse/MRM-236 Project: Archiva Issue Type: Bug Components: web application Affects Versions: 1.0 Environment: Affects r478814 1.0-SNAPSHOT Reporter: Wendy Smoak Fix For: 1.0 On Proxied Repositories - Add or Edit, only the 'first' managed repository added to the system is listed in the 'Proxied through' select list. It should allow you to choose any of the managed repositories. -- 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: (MPNATIVE-21) JDK version mismatch
JDK version mismatch Key: MPNATIVE-21 URL: http://jira.codehaus.org/browse/MPNATIVE-21 Project: maven-native-plugin Issue Type: Bug Affects Versions: 1.2.1 Environment: Windows XP JDK 1.4 Reporter: Julien HENRY Hi, I'm trying to use latest SNAPSHOT of native-maven-plugin (1.0-alpha-3-SNAPSHOT), and I get the following error : [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.codehaus.mojo:native-maven-plugin:1.0-alpha-3-SNAPSHOT:initialize': Unable to find the mojo 'org.codehaus.mojo:native-maven-plugin:1.0-alpha-3-SNAPSHOT:initialize' in the plugin 'org.codehaus.mojo:native-maven-plugin' org/codehaus/mojo/natives/plugin/NativeInitializeMojo (Unsupported major.minor version 49.0) -- 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_92049 ] Jacob Bay Hansen commented on SUREFIRE-317: --- The current one; my plugin declare looks like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId /plugin 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: property value=quot;Apple Computer, Inc.quot; name=java.vm.vendor/ in version 2.0.6 it look like this: property value=Apple Computer, Inc name=java.vm.vendor/ 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] Closed: (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 ] Maria Odea Ching closed MSOURCES-14. Resolution: Fixed 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: (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_92054 ] Roland Asmann commented on SCM-294: --- If my boss gives me time to do the changes again in trunk, I will, but atm you can take it or leave it... Sorry, but we're kind of busy here and the above changes had to happen and had to happen fast! I can live with my version of SCM for now, but like I said: when I get time (or find some time for it privately), I'll try to patch them into trunk. 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: (MJAVADOC-117) sourcepath and aggregate dont work to generate javaodc of test classes
sourcepath and aggregate dont work to generate javaodc of test classes
---
Key: MJAVADOC-117
URL: http://jira.codehaus.org/browse/MJAVADOC-117
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: maven 2.0.4
Reporter: David Vicente
HI,
i try to customize javadoc plugin configuration to generate javadoc fo test
classes as done below.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.1/version
configuration
reportOutputDirectory${project.reporting.outputDirectory}/test-apidocs/reportOutputDirectory
sourcepath${basedir}/src/test/sourcepath
aggregatetrue/aggregate
/configuration
/plugin
and nothing as result.
related with these issues :
http://jira.codehaus.org/browse/MJAVADOC-110
http://jira.codehaus.org/browse/MJAVADOC-95
i can't generate the javadoc for all test classes of my multi-modules project.
I put this issue as bug but it could be an improvement.
could we hope a simple mechanism to generate test classes javadoc with
aggregate parameter ?
--
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_92057 ] Carlos Sanchez commented on SUREFIRE-317: - that can be any version, set version to 2.3 and try 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: property value=quot;Apple Computer, Inc.quot; name=java.vm.vendor/ in version 2.0.6 it look like this: property value=Apple Computer, Inc name=java.vm.vendor/ 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_92058 ] Jacob Bay Hansen commented on SUREFIRE-317: --- When set to version 2.3, it works in Maven 2.0.4 and fails in Maven 2.0.6 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: property value=quot;Apple Computer, Inc.quot; name=java.vm.vendor/ in version 2.0.6 it look like this: property value=Apple Computer, Inc name=java.vm.vendor/ 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: (MCLOVER-45) Excluded files should be added to compiled sources
[ http://jira.codehaus.org/browse/MCLOVER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92061 ] Brendan Humphreys commented on MCLOVER-45: -- I can reproduce this problem. It occurs because when you exclude files from instrumentation, they are excluded from instrumentation *and* compilation. this means if there are any dependencies on excluded files, that dependency won't be satisfied and a compilation error will occur. The fix would involve copying (rather than instrumenting) excluded source files so they are available at compile time. Cheers, -Brendan Excluded files should be added to compiled sources --- Key: MCLOVER-45 URL: http://jira.codehaus.org/browse/MCLOVER-45 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Henrik Mejlgaard Assigned To: Vincent Massol Fix For: 2.4 When excluding files, these are not included in the compiled sources and therefor gives an compile error as the excluded files cannot be found. My proposed fix would be to collect and copy the excluded source files to an excluded_src folder in the target/clover directory, which then could be added to the compiled sources list. -- 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] Reopened: (MCLOVER-45) Excluded files should be added to compiled sources
[ http://jira.codehaus.org/browse/MCLOVER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol reopened MCLOVER-45: --- Reopening. I understand the problem now... Excluded files should be added to compiled sources --- Key: MCLOVER-45 URL: http://jira.codehaus.org/browse/MCLOVER-45 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Henrik Mejlgaard Assigned To: Vincent Massol Fix For: 2.4 When excluding files, these are not included in the compiled sources and therefor gives an compile error as the excluded files cannot be found. My proposed fix would be to collect and copy the excluded source files to an excluded_src folder in the target/clover directory, which then could be added to the compiled sources list. -- 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: (MCLOVER-45) Excluded files should be added to compiled sources
[ http://jira.codehaus.org/browse/MCLOVER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92065 ] Vincent Massol commented on MCLOVER-45: --- The issue is that when the instrument mojo executes in the forked lifecycle the source dir is now set to target/clover/src and only the instrumented files are put there. Brendan is right, we need to copy excluded files there too. Excluded files should be added to compiled sources --- Key: MCLOVER-45 URL: http://jira.codehaus.org/browse/MCLOVER-45 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Henrik Mejlgaard Assigned To: Vincent Massol Fix For: 2.4 When excluding files, these are not included in the compiled sources and therefor gives an compile error as the excluded files cannot be found. My proposed fix would be to collect and copy the excluded source files to an excluded_src folder in the target/clover directory, which then could be added to the compiled sources list. -- 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-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:all-tabpanel
]
Petr Kozelka closed MNG-2922.
-
Resolution: Duplicate
found similar report in MNG-2808 , closing
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.{{a href=*#Quick Overview*Quick Overview/a}}
but the corresponding anchor is
bq.{{a name=*quick_overview*Quick Overview/a}}
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] Closed: (MCLOVER-45) Excluded files should be added to compiled sources
[ http://jira.codehaus.org/browse/MCLOVER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed MCLOVER-45. - Resolution: Fixed Fixed Excluded files should be added to compiled sources --- Key: MCLOVER-45 URL: http://jira.codehaus.org/browse/MCLOVER-45 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Henrik Mejlgaard Assigned To: Vincent Massol Fix For: 2.4 When excluding files, these are not included in the compiled sources and therefor gives an compile error as the excluded files cannot be found. My proposed fix would be to collect and copy the excluded source files to an excluded_src folder in the target/clover directory, which then could be added to the compiled sources list. -- 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-2927) [PATCH] please make UTF-8 the default encoding
[PATCH] please make UTF-8 the default encoding -- Key: MNG-2927 URL: http://jira.codehaus.org/browse/MNG-2927 Project: Maven 2 Issue Type: Improvement Components: Sites Reporting Affects Versions: 2.0.6 Environment: Gentoo Linux, UTF-8 encoded pom files Reporter: Petr Kozelka Priority: Minor Attachments: site-plugin-UTF8-encoding.patch UTF-8 is already widely supported and used by tools, there is hardly a reason to keep with ISO-8859-1 found through the code. In my usecases, it typically makes troubles with developer names containing accented letters. Attached patch changes the default input and output encoding in maven-site-plugin which is the most important piece. -- 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: (CONTINUUM-1235) Continuum 1.1-SNAPSHOT fails to check out projects from CVS when kicking off the build
[ http://jira.codehaus.org/browse/CONTINUUM-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] apache maillist closed CONTINUUM-1235. -- Resolution: Fixed Fix Version/s: 1.1-alpha-2 looks like it is fixed. Continuum 1.1-SNAPSHOT fails to check out projects from CVS when kicking off the build -- Key: CONTINUUM-1235 URL: http://jira.codehaus.org/browse/CONTINUUM-1235 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-alpha-2 Environment: AIX Reporter: apache maillist Priority: Critical Fix For: 1.1-alpha-2 message from the GUI Exception: org/apache/maven/scm/provider/cvslib/command/checkout/CvsCheckOutConsumer message from the log 2007-03-29 11:07:32,767 [SocketListener0-0] INFO Continuum:default - Enqueuing 'securityParentPOM' (Build definition id=3). 2007-03-29 11:07:32,794 [pool-1-thread-1] INFO BuildController:default - Initializing build 2007-03-29 11:07:33,138 [pool-1-thread-1] INFO BuildController:default - Starting build of securityParentPOM 2007-03-29 11:07:33,294 [pool-1-thread-1] INFO BuildController:default - Updating working dir 2007-03-29 11:07:33,296 [pool-1-thread-1] INFO BuildController:default - Performing action check-working-directory 2007-03-29 11:07:33,308 [pool-1-thread-1] INFO BuildController:default - Performing action checkout-project 2007-03-29 11:07:33,378 [pool-1-thread-1] INFO ContinuumScm:default - Checking out project: 'securityParentPOM', id: '2' to '/apps/build/artifact-continuum/apps/continuum/working-directory/2'. 2007-03-29 11:07:34,253 [pool-1-thread-1] INFO ScmManager:default - Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/home/services/cvs/np -q checkout -d 2 securityparentpom 2007-03-29 11:07:34,255 [pool-1-thread-1] INFO ScmManager:default - Working directory: /apps/build/artifact-continuum/apps/continuum/working-directory 2007-03-29 11:07:34,277 [pool-1-thread-1] INFO BuildController:default - Merging SCM results 2007-03-29 11:07:34,974 [pool-1-thread-1] INFO BuildController:default - Error updating from SCM, not building -- 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-2928) Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,)
Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,) Key: MNG-2928 URL: http://jira.codehaus.org/browse/MNG-2928 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: MAC OS X Reporter: Dennis Schafroth Attachments: build.txt, pom.xml, pom.xml Due to selection of wrong version of a library (SystemResultDomain 1.0.2), an hard-limit was introduced on one project forcing the build to use at least 1.0.4-SNAPSHOT). All others are soft versions, so I dont see an inconsistency. The dependency check fails with: [DEBUG] com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.2:compile (selected for compile) ... [DEBUG] SystemResultDomain: resolved to version 1.0.4-20070402.154234-1 from repository mobilepeople [DEBUG] com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile (setting version to: 1.0.4-SNAPSHOT from range: [1.0.4-SNAPSHOT,) ) [DEBUG] com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile (removed - nearer found: null) ... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] version was null for com.mobilepeople.resultdomain:SystemResultDomain [INFO] [DEBUG] Trace java.lang.NullPointerException: version was null for com.mobilepeople.resultdomain:SystemResultDomain at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) at org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:118) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:96) 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) [INFO] -- 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-2929) NPE in DefaultArtifactCollector.recurse
NPE in DefaultArtifactCollector.recurse --- Key: MNG-2929 URL: http://jira.codehaus.org/browse/MNG-2929 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.6 Environment: Windows XP, maven 2.0.6 Reporter: Allan Shoup Priority: Critical Attachments: com.mycompany.test.zip Running mvn eclipse:clean eclipse:eclipse on the attached project results in the following output: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [INFO] Building Unnamed - com.mycompany.test:com.mycompany.test:jar:1.0.0-SNAPSHOT [INFO]task-segment: [eclipse:clean, eclipse:eclipse] [INFO] [INFO] [eclipse:clean] [INFO] Deleting file: .project [INFO] Deleting file: .classpath [INFO] Deleting file: .wtpmodules [INFO] Deleting file: .component [INFO] Deleting file: org.eclipse.wst.common.component [INFO] Deleting file: org.eclipse.wst.common.project.facet.core.xml [INFO] Deleting file: org.eclipse.jdt.core.prefs [INFO] Preparing eclipse:eclipse [INFO] No goals needed for project - skipping [INFO] [eclipse:eclipse] [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.collect(DefaultArtifactCollector.java:75) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:447) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) 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) [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Apr 04 12:49:21 CDT 2007 [INFO] Final Memory: 3M/7M [INFO] -- 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: (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 updated SUREFIRE-317: Affects Version/s: 2.3 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 Affects Versions: 2.3 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: property value=quot;Apple Computer, Inc.quot; name=java.vm.vendor/ in version 2.0.6 it look like this: property value=Apple Computer, Inc name=java.vm.vendor/ 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-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92085 ] Carlos Sanchez commented on MNG-2923: - There's a test case in MNG-2923 that causes the same NPE 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: profiles profile idfoo/id activation activeByDefaulttrue/activeByDefault /activation /profile /profiles ...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] Closed: (MNG-2929) NPE in DefaultArtifactCollector.recurse
[ http://jira.codehaus.org/browse/MNG-2929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MNG-2929. --- Assignee: Carlos Sanchez Resolution: Duplicate NPE in DefaultArtifactCollector.recurse --- Key: MNG-2929 URL: http://jira.codehaus.org/browse/MNG-2929 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.6 Environment: Windows XP, maven 2.0.6 Reporter: Allan Shoup Assigned To: Carlos Sanchez Priority: Critical Attachments: com.mycompany.test.zip Running mvn eclipse:clean eclipse:eclipse on the attached project results in the following output: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [INFO] Building Unnamed - com.mycompany.test:com.mycompany.test:jar:1.0.0-SNAPSHOT [INFO]task-segment: [eclipse:clean, eclipse:eclipse] [INFO] [INFO] [eclipse:clean] [INFO] Deleting file: .project [INFO] Deleting file: .classpath [INFO] Deleting file: .wtpmodules [INFO] Deleting file: .component [INFO] Deleting file: org.eclipse.wst.common.component [INFO] Deleting file: org.eclipse.wst.common.project.facet.core.xml [INFO] Deleting file: org.eclipse.jdt.core.prefs [INFO] Preparing eclipse:eclipse [INFO] No goals needed for project - skipping [INFO] [eclipse:eclipse] [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.collect(DefaultArtifactCollector.java:75) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:447) at org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:398) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) 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) [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Apr 04 12:49:21 CDT 2007 [INFO] Final Memory: 3M/7M [INFO] -- 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-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92092 ] Allan Shoup commented on MNG-2923: -- Carlos, I assume you meant MNG-2929. 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: profiles profile idfoo/id activation activeByDefaulttrue/activeByDefault /activation /profile /profiles ...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] Commented: (DOXIA-106) When using a template from a custom skin, default images and css from doxia-site-renderer are not copied to rendered site
[ http://jira.codehaus.org/browse/DOXIA-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92094 ] Dennis Lundberg commented on DOXIA-106: --- This is the behavior that I would expect. Anyone who creates a skin should supply the needed images and style sheets for it. Were you expecting the images and style sheets to be inherited from a parent skin, or site renderer itself? When using a template from a custom skin, default images and css from doxia-site-renderer are not copied to rendered site - Key: DOXIA-106 URL: http://jira.codehaus.org/browse/DOXIA-106 Project: doxia Issue Type: Bug Components: Site Renderer Affects Versions: 1.0-alpha-8 Environment: maven-site-plugin 2.0-beta-5; maven 2.0.5 Reporter: John Casey I've created my own Velocity template for rendering site pages, and included it in my own site skin. The skin makes no changes to the built-by image, or the maven-base or print CSS files. However, when I use the new skin, none of these files are found in the site. This leads to massive formatting problems and missing icons/images all over the place. When I copy the images/ and css/ directories out of the doxia-site-renderer/src/main/resources/... directory structure into my skin, all is 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] Created: (DOXIA-106) When using a template from a custom skin, default images and css from doxia-site-renderer are not copied to rendered site
When using a template from a custom skin, default images and css from doxia-site-renderer are not copied to rendered site - Key: DOXIA-106 URL: http://jira.codehaus.org/browse/DOXIA-106 Project: doxia Issue Type: Bug Components: Site Renderer Affects Versions: 1.0-alpha-8 Environment: maven-site-plugin 2.0-beta-5; maven 2.0.5 Reporter: John Casey I've created my own Velocity template for rendering site pages, and included it in my own site skin. The skin makes no changes to the built-by image, or the maven-base or print CSS files. However, when I use the new skin, none of these files are found in the site. This leads to massive formatting problems and missing icons/images all over the place. When I copy the images/ and css/ directories out of the doxia-site-renderer/src/main/resources/... directory structure into my skin, all is 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] Created: (MDEP-80) Usage page of the docs use an overWrite property, but none exists in the (auto-generated) goal reference docs
Usage page of the docs use an overWrite property, but none exists in the (auto-generated) goal reference docs - Key: MDEP-80 URL: http://jira.codehaus.org/browse/MDEP-80 Project: Maven 2.x Dependency Plugin Issue Type: Bug Affects Versions: 2.0-alpha-4 Reporter: David Jackman Assigned To: Brian Fox Priority: Minor -- 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: (CONTINUUM-1239) After loss of network connectivity, build status set to ERROR (because svn cannot checkout). When connectivity returns, build is not rerun, and status left at ERROR.
After loss of network connectivity, build status set to ERROR (because svn cannot checkout). When connectivity returns, build is not rerun, and status left at ERROR. -- Key: CONTINUUM-1239 URL: http://jira.codehaus.org/browse/CONTINUUM-1239 Project: Continuum Issue Type: Bug Components: Database Affects Versions: 1.0.3 Environment: Windows XP Reporter: D Walker Here is an example log file: You can see that the build is proceeding fine every 30 minutes, then it fails because I lose internet connectivity. When the connection recovers and jmux.svn.sourceforge.net is able to be resolved, the build is not rerun. This is fine, in theory, because there were no changes, however, the status should be set to 'SUCCESS' again. INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,384 [Thread-2] INFO ContinuumScm - Updating project: id: '1', name 'jmux - Java Modules Using XML'. INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] INFO ScmManager - Working directory: D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,109 [Thread-35] DEBUG ScmManager - At revision 20. INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,230 [Thread-2] INFO BuildController- The project was not built because there are no changes. INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,012 [defaultScheduler_Worker-7] INFO SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,082 [defaultScheduler_Worker-7] INFO Continuum - Enqueuing 'jmux - Java Modules Using XML' (Build definition id=1). INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,362 [Thread-2] INFO ContinuumScm - Updating project: id: '1', name 'jmux - Java Modules Using XML'. INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] INFO ScmManager - Working directory: D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] WARN ContinuumScm - Error while updating the code for project: 'jmux - Java Modules Using XML', id: '1' to 'D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1'. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] WARN ContinuumScm - Command output: svn: PROPFIND request failed on '/svnroot/jmux/trunk' INFO | jvm 1| 2007/04/04 15:30:16 | svn: PROPFIND of '/svnroot/jmux/trunk': Could not resolve hostname `jmux.svn.sourceforge.net': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. (http://jmux.svn.sourceforge.net) INFO | jvm 1| 2007/04/04 15:30:16 | INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,145 [Thread-2] WARN ContinuumScm - Provider message: The svn command failed. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] INFO Notifier:mail - Sending message: From '[EMAIL PROTECTED] [EMAIL PROTECTED]'. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] INFO Notifier:mail - Recipient: To '[EMAIL PROTECTED]'. INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: setDebug: JavaMail version 1.3.2 INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc] INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG SMTP: useEhlo true, useAuth false INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG SMTP: trying to connect to host smtp1.bethere.co.uk, port 25, isSSL false INFO | jvm 1| 2007/04/04 15:30:37 | 220 * INFO | jvm 1| 2007/04/04 15:30:37 | DEBUG SMTP: connected to host smtp1.bethere.co.uk, port: 25 INFO | jvm 1| 2007/04/04 15:30:37 | INFO | jvm 1| 2007/04/04 15:30:37 | EHLO plutonium INFO | jvm 1| 2007/04/04 15:30:37 | 502 Error: command not implemented INFO | jvm 1| 2007/04/04 15:30:37 | HELO plutonium INFO | jvm 1| 2007/04/04 15:30:37 | 250
[jira] Moved: (MSITE-224) [PATCH] please make UTF-8 the default encoding
[ http://jira.codehaus.org/browse/MSITE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved MNG-2927 to MSITE-224: Affects Version/s: (was: 2.0.6) Component/s: (was: Sites Reporting) Complexity: (was: Intermediate) Key: MSITE-224 (was: MNG-2927) Project: Maven 2.x Site Plugin (was: Maven 2) [PATCH] please make UTF-8 the default encoding -- Key: MSITE-224 URL: http://jira.codehaus.org/browse/MSITE-224 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Gentoo Linux, UTF-8 encoded pom files Reporter: Petr Kozelka Priority: Minor Attachments: site-plugin-UTF8-encoding.patch UTF-8 is already widely supported and used by tools, there is hardly a reason to keep with ISO-8859-1 found through the code. In my usecases, it typically makes troubles with developer names containing accented letters. Attached patch changes the default input and output encoding in maven-site-plugin which is the most important piece. -- 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: (MSITE-224) [PATCH] please make UTF-8 the default encoding
[ http://jira.codehaus.org/browse/MSITE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MSITE-224: -- Patch attached: Yes [PATCH] please make UTF-8 the default encoding -- Key: MSITE-224 URL: http://jira.codehaus.org/browse/MSITE-224 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Gentoo Linux, UTF-8 encoded pom files Reporter: Petr Kozelka Priority: Minor Attachments: site-plugin-UTF8-encoding.patch UTF-8 is already widely supported and used by tools, there is hardly a reason to keep with ISO-8859-1 found through the code. In my usecases, it typically makes troubles with developer names containing accented letters. Attached patch changes the default input and output encoding in maven-site-plugin which is the most important piece. -- 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: (CONTINUUM-1239) After loss of network connectivity, build status remains in ERROR
[ http://jira.codehaus.org/browse/CONTINUUM-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated CONTINUUM-1239: --- Description: After loss of network connectivity, build status set to ERROR (because svn cannot checkout). When connectivity returns, build is not rerun, and status left at ERROR. Here is an example log file: You can see that the build is proceeding fine every 30 minutes, then it fails because I lose internet connectivity. When the connection recovers and jmux.svn.sourceforge.net is able to be resolved, the build is not rerun. This is fine, in theory, because there were no changes, however, the status should be set to 'SUCCESS' again. INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,384 [Thread-2] INFO ContinuumScm - Updating project: id: '1', name 'jmux - Java Modules Using XML'. INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2007/04/04 15:00:00 | 2007-04-04 15:00:00,414 [Thread-2] INFO ScmManager - Working directory: D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,109 [Thread-35] DEBUG ScmManager - At revision 20. INFO | jvm 1| 2007/04/04 15:00:04 | 2007-04-04 15:00:04,230 [Thread-2] INFO BuildController- The project was not built because there are no changes. INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,012 [defaultScheduler_Worker-7] INFO SchedulesActivator - Executing build job (DEFAULT_SCHEDULE)... INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,082 [defaultScheduler_Worker-7] INFO Continuum - Enqueuing 'jmux - Java Modules Using XML' (Build definition id=1). INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,362 [Thread-2] INFO ContinuumScm - Updating project: id: '1', name 'jmux - Java Modules Using XML'. INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] INFO ScmManager - Executing: svn --non-interactive update INFO | jvm 1| 2007/04/04 15:30:00 | 2007-04-04 15:30:00,382 [Thread-2] INFO ScmManager - Working directory: D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1 INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] WARN ContinuumScm - Error while updating the code for project: 'jmux - Java Modules Using XML', id: '1' to 'D:\continuum-1.0.3\bin\win32\..\..\apps\continuum\working-directory\1'. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,135 [Thread-2] WARN ContinuumScm - Command output: svn: PROPFIND request failed on '/svnroot/jmux/trunk' INFO | jvm 1| 2007/04/04 15:30:16 | svn: PROPFIND of '/svnroot/jmux/trunk': Could not resolve hostname `jmux.svn.sourceforge.net': The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. (http://jmux.svn.sourceforge.net) INFO | jvm 1| 2007/04/04 15:30:16 | INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,145 [Thread-2] WARN ContinuumScm - Provider message: The svn command failed. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] INFO Notifier:mail - Sending message: From '[EMAIL PROTECTED] [EMAIL PROTECTED]'. INFO | jvm 1| 2007/04/04 15:30:16 | 2007-04-04 15:30:16,525 [Thread-2] INFO Notifier:mail - Recipient: To '[EMAIL PROTECTED]'. INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: setDebug: JavaMail version 1.3.2 INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc] INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG SMTP: useEhlo true, useAuth false INFO | jvm 1| 2007/04/04 15:30:16 | DEBUG SMTP: trying to connect to host smtp1.bethere.co.uk, port 25, isSSL false INFO | jvm 1| 2007/04/04 15:30:37 | 220 * INFO | jvm 1| 2007/04/04 15:30:37 | DEBUG SMTP: connected to host smtp1.bethere.co.uk, port: 25 INFO | jvm 1| 2007/04/04 15:30:37 | INFO | jvm 1| 2007/04/04 15:30:37 | EHLO plutonium INFO | jvm 1| 2007/04/04 15:30:37 | 502 Error: command not implemented INFO | jvm 1| 2007/04/04 15:30:37 | HELO plutonium INFO | jvm 1| 2007/04/04 15:30:37 | 250 smtp1.bethere.co.uk INFO | jvm 1| 2007/04/04 15:30:37 | DEBUG SMTP: use8bit false INFO | jvm 1| 2007/04/04 15:30:37 | MAIL FROM:[EMAIL PROTECTED] INFO | jvm 1| 2007/04/04 15:30:37 | 250 Ok INFO | jvm 1|
[jira] Closed: (MAVENUPLOAD-1458) new version of XINS for Maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1458. --- Assignee: Carlos Sanchez Resolution: Fixed 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 Assigned To: Carlos Sanchez 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] Commented: (MAVENUPLOAD-1455) java exchange connector
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92104 ] Carlos Sanchez commented on MAVENUPLOAD-1455: - missing license and scm sections in pom java exchange connector --- Key: MAVENUPLOAD-1455 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1455 Project: maven-upload-requests Issue Type: Wish Reporter: eli hasson java exchange connector is a pure java api for Microsoft exchange server. for more information: [EMAIL PROTECTED] -- 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: (MAVENUPLOAD-1454) Upload of rmock 2.0.0. Group already exists.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92105 ] Carlos Sanchez commented on MAVENUPLOAD-1454: - where is the parent pom? make bundle with it or even better set your own repo to sync automatically from see end of http://maven.apache.org/guides/mini/guide-central-repository-upload.html Upload of rmock 2.0.0. Group already exists. Key: MAVENUPLOAD-1454 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1454 Project: maven-upload-requests Issue Type: Task Reporter: Daniel Brolund RMock 2.0.0 is a Java mock object framework to use with jUnit. RMock has support for a setup-modify-run-verify workflow when writing jUnit tests. It integrates better with IDE refactoring support and allows designing classes and interfaces in a true test-first fashion. -- 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-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92107 ] Micah Whitacre commented on MNG-2923: - I am encountering this issue both when I have an active profile set and when I do not. I haven't debugged fully to see how active profiles play into some of my projects passing but I have debugged through a few times for projects that always throw NPE. It seems what is happening is that when building the project it is resolving all of the dependencies. A dependency is resolved multiple times because it is transitively resolved from different projects. As it is resolving the dependencies it is encountering different version ranges [1,2) and [1,3). As it determines the version it wants, enables and disables artifacts, it then restricts the version of the artifact it wants so that the version is set to 1.2 (the one available) but it restricts the versionRange of the artifact to be []. So the next time transitively finds the dependency on line 164 (the NPE) line it tries to find a version that matches the version range of []. It therefore can't find a match and then dies on the toString() call. I haven't broken this down to a simple reproduceable workflow but that is the flow that is causing it to die even without the activeProfiles/ in the settings.xml file. 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: profiles profile idfoo/id activation activeByDefaulttrue/activeByDefault /activation /profile /profiles ...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
[jira] Created: (MNG-2930) Update JavaMojoDescriptorExtractor to make it more re-use friendly
Update JavaMojoDescriptorExtractor to make it more re-use friendly
--
Key: MNG-2930
URL: http://jira.codehaus.org/browse/MNG-2930
Project: Maven 2
Issue Type: Improvement
Components: Plugin Creation Tools
Reporter: Jason Dillon
Priority: Minor
Update the {{JavaMojoDescriptorExtractor}} in the {{maven-plugin-tools-java}}
module to make it more friendly for reusability.
--
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: (MCLOVER-69) shoulbe be able to use excludes when generating a report
shoulbe be able to use excludes when generating a report Key: MCLOVER-69 URL: http://jira.codehaus.org/browse/MCLOVER-69 Project: Maven 2.x Clover Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Brendan Humphreys Hi, So that I can generate a report of a subset of the instrumented classes. This is different to using exclude at instrumentation time. Cheers, -Brendan -- 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-54) Scm Wagon not expanding ${user.home}
[
http://jira.codehaus.org/browse/WAGON-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92108
]
Gabriele Columbro commented on WAGON-54:
I'm experiencing the same issue under a Macbook Pro OSX 10.4 environment, so
it's probably not due to space in filename, but of the plugin itself.
I'm not exactly a mvn internals expert, but I'm going to work on this issue for
a project I'm working on, hoping to file a patch soon.
For the moment, any hint would be lovely appreciated ;-)
Scm Wagon not expanding ${user.home}
Key: WAGON-54
URL: http://jira.codehaus.org/browse/WAGON-54
Project: wagon
Issue Type: Bug
Components: wagon-scm
Affects Versions: 1.0-alpha-5
Environment: windows xp, maven 2.0.4
Reporter: Jean Deruelle
when trying to deploy a jar to a svn repository , wagon-scm doesn't translate
${user.home} (because of space in the user home's windows path?) and create
this directory in the current directory
...
distributionManagement
repository
idsvn-repository/id
urlscm:svn:https://[EMAIL
PROTECTED]/svn/maven2-repository/trunk/repository/url
/repository
/distributionManagement
extensions
extension
groupIdorg.apache.maven.wagon/groupId
artifactIdwagon-scm/artifactId
version1.0-alpha-5/version
/extension
/extensions
Here is the log :
[INFO] [deploy:deploy]
Uploading:
scm:svn:https://maven2-repository.dev.java.net/svn/maven2-repository/trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0/maven-slee-du-plugin-1.0.jar
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository
[INFO] Command line: svn add --non-recursive ${user.home}/.m2/repository/org
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org
[INFO] Command line: svn add --non-recursive
${user.home}/.m2/repository/org/apache
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache
[INFO] Command line: svn add --non-recursive
${user.home}/.m2/repository/org/apache/maven
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven
[INFO] Command line: svn add --non-recursive
${user.home}/.m2/repository/org/apache/maven/plugins
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins
[INFO] Command line: svn add --non-recursive
${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
[INFO] Command line: svn add --non-recursive
${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\1.0
[INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
--non-interactive checkout
https://maven2-repository.dev.java.net/svn/maven2-repository/
trunk/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0 1.0
[INFO] Working directory:
C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin
[INFO] Command line: svn --username deruelle_jean --password L0veSt1nks
--non-interactive commit --file
C:\DOCUME~1\T405732\LOCALS~1\Temp\maven-scm-465347372.commit
${user.home}/.m2/repository/org/apache/maven/plugins/maven-slee-du-plugin/1.0
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error deploying artifact: Unable to commit file svn:
'C:\java\java.net\slee-sip-ra\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\maven-slee-du-plugin\${user.home}\.m2\repository\org\apache\maven\plugins\ma
ven-slee-du-plugin' is not a working copy
--
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-2930) Update JavaMojoDescriptorExtractor to make it more re-use friendly
[
http://jira.codehaus.org/browse/MNG-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated MNG-2930:
--
Attachment: MNG-2930.diff
Attached patch:
* Removes usage of JavaSource, prefer JavaClass, drops getJavaClass()
* Promotes a few constants related to @component handling to public
* Promotes a few methods from private to protected to allow sub-class access
* Drops PluginDescriptor from createMojoDescriptor(), attaching to return
value instead
* Adds validate(MojoDescriptor) with param validation logic
* Adds discoverClasses() to find all of the JavaClass objects to process
With these changes, extractors which can generate QDox JavaClass instances for
their sources can use JavaMojoDescriptorExctractor as a super-class and
override discoverClasses() and/or invoke createMojoDescriptor() if some
additional handling needs to be done.
This works very well for my GroovyMojoDescriptorExtractor, which translates
\*.groovy into slim Java bits to allow QDox to parse out the class, field and
javadoc tags... and then processing of the tags is always in sync with the Java
impl.
Update JavaMojoDescriptorExtractor to make it more re-use friendly
--
Key: MNG-2930
URL: http://jira.codehaus.org/browse/MNG-2930
Project: Maven 2
Issue Type: Improvement
Components: Plugin Creation Tools
Reporter: Jason Dillon
Priority: Minor
Attachments: MNG-2930.diff
Update the {{JavaMojoDescriptorExtractor}} in the {{maven-plugin-tools-java}}
module to make it more friendly for reusability.
--
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: (MSITE-225) Internationalization does not seem to work with site:run
Internationalization does not seem to work with site:run Key: MSITE-225 URL: http://jira.codehaus.org/browse/MSITE-225 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: maven 2.0.5, maven-archetype-site, firefox 2.0.0.3 with Quick Locale Switcher add-on Reporter: John Casey I've tried performing site:run with the internationalized site created by the site archetype (not the simple one), and I cannot get it to render the french pages, no matter what I do. The /fr/* URLs are missing, and when I switch my local in FF to fr-FR, still no change; it's still in English. I suspect that site:run isn't looking at the src/site/fr/** directory, and/or it's not detecting the locale of the browser. -- 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: (SCM-292) Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names
[ http://jira.codehaus.org/browse/SCM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92112 ] Mike Perham commented on SCM-292: - I don't see any way to support multiple clientspecs without explicit support in Continuum and SCM. We need support for ad hoc variables associated with a build which can be passed to the provider. The system property is a hack which obviously doesn't scale. Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names Key: SCM-292 URL: http://jira.codehaus.org/browse/SCM-292 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-4 Reporter: Emmanuel Venisse Assigned To: Patrick Schneider Priority: Critical Fix For: 1.0 With a Map instead of a system property, we'll can support more that one clientspec in the jvm. It's necessary for Continuum because it access to more than one project in Perforce. -- 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-2930) Update JavaMojoDescriptorExtractor to make it more re-use friendly
[
http://jira.codehaus.org/browse/MNG-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92113
]
Brian Fox commented on MNG-2930:
Patch applied to
https://svn.apache.org/repos/asf/maven/shared/branches/maven-plugin-tools-java-MNG-2930.
The unit tests seem to cover this and everything builds and passes.
Update JavaMojoDescriptorExtractor to make it more re-use friendly
--
Key: MNG-2930
URL: http://jira.codehaus.org/browse/MNG-2930
Project: Maven 2
Issue Type: Improvement
Components: Plugin Creation Tools
Reporter: Jason Dillon
Priority: Minor
Attachments: MNG-2930.diff
Update the {{JavaMojoDescriptorExtractor}} in the {{maven-plugin-tools-java}}
module to make it more friendly for reusability.
--
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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2931: Attachment: MNG-2931.patch unit test DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Key: MNG-2931 URL: http://jira.codehaus.org/browse/MNG-2931 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.5, 2.0.6 Reporter: Carlos Sanchez Attachments: MNG-2931.patch DefaultDependencyTreeBuilder https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java calls collect like this collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository, project.getRemoteArtifactRepositories(), metadataSource, null, Collections.singletonList( listener ) ); Problem: This pom http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom extends http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19 so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions -- 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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Key: MNG-2931 URL: http://jira.codehaus.org/browse/MNG-2931 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.6, 2.0.5 Reporter: Carlos Sanchez Attachments: MNG-2931.patch DefaultDependencyTreeBuilder https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java calls collect like this collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository, project.getRemoteArtifactRepositories(), metadataSource, null, Collections.singletonList( listener ) ); Problem: This pom http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom extends http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19 so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions -- 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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92116 ] Carlos Sanchez commented on MNG-2931: - The question is do we allow a project to extend another one that has a different version of it in dependencyManagement ? if we do, then the current project version has to win over the managed one DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Key: MNG-2931 URL: http://jira.codehaus.org/browse/MNG-2931 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.5, 2.0.6 Reporter: Carlos Sanchez Attachments: MNG-2931.patch DefaultDependencyTreeBuilder https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java calls collect like this collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository, project.getRemoteArtifactRepositories(), metadataSource, null, Collections.singletonList( listener ) ); Problem: This pom http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom extends http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19 so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions -- 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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92117 ] Carlos Sanchez commented on MNG-2931: - Seems logical to fail the build if dependencyManagement and the project version don't match DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Key: MNG-2931 URL: http://jira.codehaus.org/browse/MNG-2931 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.5, 2.0.6 Reporter: Carlos Sanchez Attachments: MNG-2931.patch DefaultDependencyTreeBuilder https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java calls collect like this collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository, project.getRemoteArtifactRepositories(), metadataSource, null, Collections.singletonList( listener ) ); Problem: This pom http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom extends http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19 so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions -- 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: (MRELEASE-108) NullPointerException when POM has no SCM connection url
[ http://jira.codehaus.org/browse/MRELEASE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MRELEASE-108. --- Assignee: Carlos Sanchez Resolution: Cannot Reproduce Seems already fixed long time ago http://svn.apache.org/viewvc/maven/plugins/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/config/PropertiesReleaseDescriptorStore.java?revision=438341view=markuppathrev=466407 NullPointerException when POM has no SCM connection url --- Key: MRELEASE-108 URL: http://jira.codehaus.org/browse/MRELEASE-108 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Environment: mvn 2.0.4 WinXP Reporter: Marcel Schutte Assigned To: Carlos Sanchez Attachments: preparereleasemojo.patch When a POM has no SCM connection url, but only developerConnection, release:prepare fails with a NullPointerException. We don't have separate read-only access to our cvs repository, which is why there is only a developerconnection. C:\Data\WSAD\MijnOhra\MavenParentmvn release:prepare [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'release'. [INFO] [INFO] Building Super POM voor alle OHRA maven2 projecten [INFO]task-segment: [release:prepare] (aggregator-style) [INFO] [INFO] [release:prepare] [INFO] Verifying that there are no local modifications... [INFO] Executing: cvs -z3 -f -d :pserver:[EMAIL PROTECTED]:/framework -n -q update -d [INFO] Working directory: C:\Data\WSAD\MijnOhra\MavenParent [INFO] Checking dependencies and plugins for snapshots ... What is the release version for Super POM voor alle OHRA maven2 projecten? (nl.ohra:MavenParent) 01.08: : What is SCM release tag or label for Super POM voor alle OHRA maven2 projecten? (nl.ohra:MavenParent) MavenParent-01.08: : What is the new development version for Super POM voor alle OHRA maven2 projecten? (nl.ohra:MavenParent) 01.09-SNAPSHOT: : [INFO] Transforming 'Super POM voor alle OHRA maven2 projecten'... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:393) at java.util.Properties.setProperty(Properties.java:102) at org.apache.maven.plugins.release.config.PropertiesReleaseConfigurationStore.write(PropertiesReleaseConfigurationStore.java:225) at org.apache.maven.plugins.release.config.PropertiesReleaseConfigurationStore.write(PropertiesReleaseConfigurationStore.java:149) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:145) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:108) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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)
[jira] Created: (MGPG-7) Ability to sign jars when using deploy:deploy-file
Ability to sign jars when using deploy:deploy-file -- Key: MGPG-7 URL: http://jira.codehaus.org/browse/MGPG-7 Project: Maven 2.x GPG Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-3 Reporter: Wendy Smoak We need to be able to deploy signatures alongside jars that were not built with Maven. For example, Apache Tomcat is built with Ant, but they would like to deploy signed jars to the ASF repo to be synced to central. Because of the signature requirement, they are currently hosting a separate repository under their website. Something like mvn deploy:deploy-file gpg:sign -D... should work. -- 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: (MJAR-70) Ability to skip jar recreation if any of resources are older than existing jar
Ability to skip jar recreation if any of resources are older than existing jar -- Key: MJAR-70 URL: http://jira.codehaus.org/browse/MJAR-70 Project: Maven 2.x Jar Plugin Issue Type: Improvement Reporter: Olexandr Zakordonskyy Would be great to have boolean attribute that will help to skip jar packaging if one exists and no resources were modified(including pom and parent pom's). It will help to improve performance. -- 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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92126 ] Joerg Schaible commented on MNG-2931: - The version of the current artifact has to win! See, we manage all our versions in a global POM and that includes also our *released* artifacts. However, they are depending on each other. So it is quite normal that an artifact inherits a version from the global POM, but will declare a SNAPSHOT on its own. DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version Key: MNG-2931 URL: http://jira.codehaus.org/browse/MNG-2931 Project: Maven 2 Issue Type: Bug Components: Artifacts Affects Versions: 2.0.5, 2.0.6 Reporter: Carlos Sanchez Attachments: MNG-2931.patch DefaultDependencyTreeBuilder https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java calls collect like this collector.collect( project.getDependencyArtifacts(), project.getArtifact(), managedVersions, repository, project.getRemoteArtifactRepositories(), metadataSource, null, Collections.singletonList( listener ) ); Problem: This pom http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom extends http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom that in dependencyManagement has org.codehaus.plexus:plexus-component-api:1.0-alpha-19 so during collect project.getArtifact().getVersion() is changed to the managedVersion instead of the original one Either this is a bug or an exception should be thrown when originatingArtifact is in managedVersions -- 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
