[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: org.apache.maven.plugins maven-surefire-report-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: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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 don"t work to generate javaodc of test classes
sourcepath and aggregate don"t 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.
org.apache.maven.plugins
maven-javadoc-plugin
2.1
${project.reporting.outputDirectory}/test-apidocs
${basedir}/src/test
true
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: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-317) Properties in surefire reports are no longer escaped
[ http://jira.codehaus.org/browse/SUREFIRE-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_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: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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.{{Quick Overview}}
> but the corresponding anchor is
> bq.{{Quick Overview}}
> Manual conversion of letters to lowercase and replacing spaces with
> underscores is too annoying to be considered workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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: > > in version 2.0.6 it look like this: > > So later reporters report XML parse errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-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: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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
[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 |
[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 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: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.ja
[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 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
> ...
>
>
> svn-repository
> scm:svn:https://[EMAIL
> PROTECTED]/svn/maven2-repository/trunk/repository
>
>
>
>
> org.apache.maven.wagon
> wagon-scm
> 1.0-alpha-5
>
>
> 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=438341&view=markup&pathrev=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\MavenParent>mvn 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.mainWithExit
[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
[jira] Updated: (MCLOVER-21) License discovery is broken
[ http://jira.codehaus.org/browse/MCLOVER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-21: -- Fix Version/s: (was: 2.1) > License discovery is broken > --- > > Key: MCLOVER-21 > URL: http://jira.codehaus.org/browse/MCLOVER-21 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Matthew Beermann > Assigned To: Vincent Massol >Priority: Critical > > Even when a valid, unexpired "clover.license" is located alongside the clover > jar, it does not appear to be located and used as Cenqua's documentation says > it should. In the example below, the directory contains a "clover.license" > that is known to work properly with the Clover plugin in Maven 1. > Yes, there is a configuration parameter that can work around > this, but that doesn't address the underlying problem (and furthermore the > fix isn't particularly portable). > [INFO] [clover:instrument] > Clover Version 1.3.11, built on November 02 2005 > loaded from: C:\maven\local_repository\clover\clover\1.3.11\clover-1.3.11.jar > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] This license has now expired. > [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: (MCLOVER-7) "mvn clover:report" generates errors in tests that execute properly in "mvn test"
[
http://jira.codehaus.org/browse/MCLOVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol updated MCLOVER-7:
-
Fix Version/s: (was: 2.1)
> "mvn clover:report" generates errors in tests that execute properly in "mvn
> test"
> -
>
> Key: MCLOVER-7
> URL: http://jira.codehaus.org/browse/MCLOVER-7
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.0-alpha-1
>Reporter: Chris Gray
> Assigned To: Vincent Massol
>
> Some of our java code opens data files, which have been stored in the
> ${PROJECT_ROOT} directory. When we execute "mvn test", the code compiles
> fine, and all unit tests pass. However, when we add the clover plugin to the
> pom.xml file, all tests fail during the clover run. As far as I can tell, it
> looks like clover when executes the tests, they look for the data files in
> the ${PROJECT_ROOT}/target/clover directory instead of the ${PROJECT_ROOT}
> directory.
--
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: (MCLOVER-8) Clover default target percentage too high - should be 0%
[ http://jira.codehaus.org/browse/MCLOVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-8: - Fix Version/s: (was: 2.0) > Clover default target percentage too high - should be 0% > > > Key: MCLOVER-8 > URL: http://jira.codehaus.org/browse/MCLOVER-8 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.0-alpha-1 >Reporter: Mark Kuzmycz > Assigned To: Vincent Massol >Priority: Trivial > > The target percentage attribute is a good idea. However, it should be treated > as optional as most projects will want to build irrespective of the target. > This is especially true when you run the site goal. In which case you want > the execution to complete (irrespective of clover restrictions) so that you > can communicate the results to the developers. > Can we please have the default value set to 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] Updated: (MCLOVER-16) Using Clover with projects that require class post-processing
[
http://jira.codehaus.org/browse/MCLOVER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol updated MCLOVER-16:
--
Fix Version/s: (was: 2.1)
> Using Clover with projects that require class post-processing
> -
>
> Key: MCLOVER-16
> URL: http://jira.codehaus.org/browse/MCLOVER-16
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Mike Perham
> Assigned To: Vincent Massol
>
> I don't know if this is a bug in the clover plugin but I have a project which
> compiles some classes and then uses backport175 to process annotations on
> those source files and add them to the generated classes since we are still
> using JDK 1.4. I'm finding that my tests run fine by themselves but fail
> when I run Clover, exactly as if the annotations were not in the classes.
> I think what is happening is that maven is running code in this order:
> compile source -> target/clover/classes
> instrument classes -> target/clover/classes
> process classes for annotations -> target/classes
> My backport configuration looks like this:
>
>
> maven-antrun-plugin
>
>
> normal
> process-classes
>
>
>
> classname="org.codehaus.backport175.compiler.task.AnnotationCTask"
>
> classpathref="maven.compile.classpath"/>
> destdir="${project.build.outputDirectory}"
>
> properties="${project.build.sourceDirectory}/annotations.properties"
> verbose="false">
>path="${project.build.sourceDirectory}" />
>path="${project.build.outputDirectory}"/>
>refid="maven.compile.classpath" />
>
>
>
>
>
> run
>
>
>
> test
> test-compile
>
>
>
> classname="org.codehaus.backport175.compiler.task.AnnotationCTask"
>classpathref="maven.test.classpath"/>
> destdir="${project.build.testOutputDirectory}"
>
> properties="${project.build.sourceDirectory}/annotations.properties"
> verbose="false">
>path="${project.build.testSourceDirectory}" />
>path="${project.build.testOutputDirectory}"/>
>/>
>
>
>
>
>
> run
>
>
>
>
> As you can see, I'm using all the standard Maven variables for directory
> names. Is there some way to get the Clover plugin working in this scenario?
> Should the project.build.outputDirectory variable be modified to point to
> target/clover/classes? Perhaps a bit of documentation on how to use the
> Clover plugin with projects that require class processing would be called for
> here.
--
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: (MCLOVER-69) Add support for excluding files when generating a report
[ http://jira.codehaus.org/browse/MCLOVER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-69: -- Summary: Add support for excluding files when generating a report (was: shoulbe be able to use excludes when generating a report) > Add support for excluding files 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 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] Closed: (MCLOVER-62) Compile errors when files are 'ed from intrumentation.
[ http://jira.codehaus.org/browse/MCLOVER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed MCLOVER-62. - Assignee: Vincent Massol Resolution: Duplicate > Compile errors when files are 'ed from intrumentation. > --- > > Key: MCLOVER-62 > URL: http://jira.codehaus.org/browse/MCLOVER-62 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Nick Pellow > Assigned To: Vincent Massol > Attachments: beanutils-clover-out.txt > > > As far as I can tell, by looking at the source code, files that are excluded > from > instrumentation, are also excluded from being compiled. > This means, that if I exclude source code that is referenced by the unit > tests, or indeed > other sources that aren't excluded, the compile will fail. > To observe this behaviour: > 1) Checkout the commons beanutils project from: > http://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk > 2) Add these lines to plugins element in the pom.xml > > org.apache.maven.plugins > maven-clover-plugin > > > **/locale/** > > > > 3) Run: mvn clean clover:instrument clover:clover > > Attached is the output from maven when running the above recipe with the -X > option. -- 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: (MCLOVER-3) classpath error
[ http://jira.codehaus.org/browse/MCLOVER-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-3: - Fix Version/s: (was: 2.0) > classpath error > --- > > Key: MCLOVER-3 > URL: http://jira.codehaus.org/browse/MCLOVER-3 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.0-alpha-1 > Environment: Windows XP, JDK 5.0 update 6, Maven 2.0, > maven-clover-plugin-2.0-alpha-1 >Reporter: Yue Ni > Assigned To: Vincent Massol > Attachments: cloverplugin-test.zip > > > I used maven clover plugin to generate test report but got > FileNotFoundException. I employ spring in my project, so I use > ClassPathXmlApplicationContext in my JUnit test case to get the application > context. When the "clover:report" goal is executed, I got the error message > "Caused by: java.io.FileNotFoundException: class path resource > [net/sf/psm4j/applicationContext.xml] cannot be opened because it does not > exist"(Actually, the file exists in the right path) . When I executed the > "mvn test" goal, the unit test can be run without exception. In the same > time, I can also run the test case in Eclipse without exception(The Eclipse > ".classpath" file is generated by maven "eclipse:eclipse" goal). Therefore, I > think there's something wrong in the maven clover plugin dealing with the > classpath. -- 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: (MCLOVER-22) The licenseFile element is not taken into account
[ http://jira.codehaus.org/browse/MCLOVER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-22: -- Fix Version/s: (was: 2.1) > The licenseFile element is not taken into account > - > > Key: MCLOVER-22 > URL: http://jira.codehaus.org/browse/MCLOVER-22 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Vincent Massol > Assigned To: Vincent Massol > > The licenseFile appears not to be used by the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINSTALL-38) Install plugin behaves incorrectly in grandchildren projects that has packaging != jar
Install plugin behaves incorrectly in grandchildren projects that has packaging != jar -- Key: MINSTALL-38 URL: http://jira.codehaus.org/browse/MINSTALL-38 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Niclas Hedhman Priority: Critical Case in hand; https://scm.ops4j.org/repos/ops4j/projects/pax/ Pax contains a handful of subprojects, which in turn contains subprojects and they are often of a custom packaging "bundle" or "osgi-bundle". When building for instance from pax/logging as the root, things work as expected and we get the following info; [INFO] [install:install] [INFO] Installing /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar to /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.jar But when building one level higher up, we get the following message; [INFO] [install:install] [INFO] Installing /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar to /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.bundle Note that when building the grandchild project, the file extension is equal to the argument, but if building a child project, it is the jar file we construct. This problem appeared not too long ago, and may not be the problem of the Install Plugin after all, and instead is somewhere in the inheritence mechanism that got screwed up. Whatever, the problem is huge as we have this in much larger commercial projects, where it is not feasible to build project by project, and the Continuous Integration setup must be populated with hundreds of projects instead of 3. -- 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: (MCLOVER-9) Locale problem in Clover plugin
[ http://jira.codehaus.org/browse/MCLOVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol updated MCLOVER-9: - Fix Version/s: (was: 2.0) > Locale problem in Clover plugin > --- > > Key: MCLOVER-9 > URL: http://jira.codehaus.org/browse/MCLOVER-9 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.0-alpha-1 >Reporter: Wim Deblauwe > Assigned To: Vincent Massol > > I get the following error with the clover plugin > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Can't find bundle for base name clover-report, locale nl_NL > [INFO] > > [INFO] Trace > java.util.MissingResourceException: Can't find bundle for base name > clover-report, locale nl_NL > at > java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:806) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:700) > at > org.apache.maven.plugin.clover.CloverReportMojo.getBundle(CloverReportMojo.java:104) > at > org.apache.maven.plugin.clover.CloverReportMojo.getName(CloverReportMojo.java:136) > at > org.apache.maven.plugins.site.ReportComparator.compare(ReportComparator.java:40) > at java.util.Arrays.mergeSort(Arrays.java:1284) > at java.util.Arrays.sort(Arrays.java:1223) > at java.util.Collections.sort(Collections.java:159) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:240) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > 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) > regards, > Wim -- 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
