[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_72277 ] Wonne Keysers commented on MWAR-9: -- Compile time dependencies can be excluded from the WEB-INF/lib by using the optionaltrue/optional flag. However, this currently does not work recursively. For example: if the war has a dependency on A.jar, but A.jar itself s dependant from B.jar, putting the A-dependency optional excludes it from the war (yet it includes it in the manifest), but B.jar is still included in the WEB-INF/lib. If the optional flag would be working recursively, I think the solution would be complete? WAR plugin should support minimal WARs for inclusion within an EAR -- Key: MWAR-9 URL: http://jira.codehaus.org/browse/MWAR-9 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Mike Perham I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my deps. This is fine for a default but maven should also support skeleton WARs which will be packaged within an EAR. We have EARs which package 3-4 WARs each and to have the deps duplicated within each WAR means we cannot have shared data (since the classes are loaded within each WAR's classloader, rather than by the parent EAR's classloader). It also means 80MB EARs! :-) It seems like two things need to happen: 1) Add a skeleton flag which prevents copying any dependencies to WEB-INF/lib. 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which lists the relative locations of the dependencies within the parent EAR. Fabrice has basically the same idea written down here. Starting with - for a War... : http://marc.theaimsgroup.com/?l=turbine-maven-userm=112737860024530w=2 -- 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: (CONTINUUM-812) Fix resolution of ${plexus.home}
[ http://jira.codehaus.org/browse/CONTINUUM-812?page=comments#action_72278
]
Emmanuel Venisse commented on CONTINUUM-812:
this parameter must be added in plexus context in plexus-xwork-integration.
I think some other parameters should be added too.
Fix resolution of ${plexus.home}
Key: CONTINUUM-812
URL: http://jira.codehaus.org/browse/CONTINUUM-812
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1
Reporter: Carlos Sanchez
Continuum creates the DB in a folder called ${plexus.home}
--
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: (CONTINUUM-812) Fix resolution of ${plexus.home}
[ http://jira.codehaus.org/browse/CONTINUUM-812?page=comments#action_72280
]
Trygve Laugstol commented on CONTINUUM-812:
---
I'm pretty sure the code for finding out plexus.hom is in plexus-servlet
somewhere, I'm sure something can be stolen from that code.
I think some clever code for figuring out how to handle un-exploded webapps
needs to be written too.
Fix resolution of ${plexus.home}
Key: CONTINUUM-812
URL: http://jira.codehaus.org/browse/CONTINUUM-812
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1
Reporter: Carlos Sanchez
Continuum creates the DB in a folder called ${plexus.home}
--
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: (MEAR-29) EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment
[ http://jira.codehaus.org/browse/MEAR-29?page=all ] Stephane Nicoll reopened MEAR-29: - I need more detail regarding this XML compliance problem. EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment -- Key: MEAR-29 URL: http://jira.codehaus.org/browse/MEAR-29 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: OS: WIN2K (likely any platform) Application Server: JBOSS 4.0.3 (likely not relevant) Reporter: Thierry Barnier Assigned To: Stephane Nicoll Fix For: 2.3 Attachments: no-context-root for Maven-EARplugin.patch I embed a WAR portlet module inside an EAR module I configure the EAR module as follows plugin groupId org.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.1/version configuration displayNamePortlet/displayName descriptionJBOSS portlet/description modules webModule groupIdmyApp/groupId artifactIdJBPortlet1-war/artifactId !--contextRoot/portlet/contextRoot My problem goes here -- /webModule /modules /configuration /plugin The maven-EAR-module generates an application.xml of the following form: application display-nameThierry Portlet/display-name descriptionJBOSS portlet/description module web web-uri JBPortlet1-war-1.0.war/web-uri context-root/portlet/context-root I would like to remove automatically this line /web /module /application The problem is: In case of a portlet deployment, the context-root element must be omitted, or the application server reject the EAR package. There is no way today to disable context-root generation in application.xml If i comment / remove the contextroot line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the context-root line. what could be the strategy? =a noContextRoot tag added to the ear plugin config webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId noContextRoot/ /webModule =a way to specify that application-xml has to be generated regarding portlet constraints? (isPortlet property) webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId isPortlettrue/isPortlet /webModule -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-67) webResource filtering needs filter
[ http://jira.codehaus.org/browse/MWAR-67?page=all ] Franz Allan Valencia See updated MWAR-67: - Attachment: MWAR-67-maven-war-plugin-2.patch MWAR-67-maven-war-plugin-2.patch contains what MWAR-67-maven-war-plugin.patch has plus a modified testExplodedWar_WithResourceFiltering() of the WarExplodedMojoTest Class. webResource filtering needs filter -- Key: MWAR-67 URL: http://jira.codehaus.org/browse/MWAR-67 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: Tomasz Pik Priority: Minor Attachments: MWAR-67-maven-war-plugin-2.patch, MWAR-67-maven-war-plugin.patch Filtering of webResources works only, if there's at least one filterpath/to/properties/filter defined in pom. So without such a configuration there's no possiblity to build war file with filtering using values specified during build invocation, with -D options (System properties are ignored). Adding reference to (even empty) file using filter element 'solves' the problem and properties defined using -D are used. -- 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: (MPIR-54) Team list table improvement
[ http://jira.codehaus.org/browse/MPIR-54?page=comments#action_72283 ] Dmitry Kobyleha commented on MPIR-54: - I did not want to change basic logic of columns output. I only added verification of blank columns presence. For example on http://embedchat.org/team-list-old.html there are 3 empty columns: Organization, Organization URL and Properties. In a patch I just remove from output empty columns. As about union of organization and organizations url columns I initially don't think about it. Possibly it would be not bad to add some output configuration to plugin options in pom.xml. Is there some chance to plug my changes in some next version? Team list table improvement --- Key: MPIR-54 URL: http://jira.codehaus.org/browse/MPIR-54 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.0-beta-3, 2.0, 2.0.1 Reporter: Dmitry Kobyleha Attachments: TeamListReport.java When fo all developers in pom.xml we some property not defined, it is good to not include it to html output. Fow example: ... developer iddeveloper1/id nameDeveloper 1/name email[EMAIL PROTECTED]/email roles roleProject Manager/role roleArchitect/role roleJava Developer/role /roles timezone+2/timezone /developer developer iddeveloper2/id nameDeveloper 2/name email[EMAIL PROTECTED]/email roles roleJava Developer/role /roles timezone+2/timezone /developer ... For both developers properties like URL, Organization,Organization URL and Properties not specified. In result html we have cells with -. As for me it is good not not include columns where only - present at all. -- 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: (MCHANGELOG-43) Changelog not getting created properly.
[ http://jira.codehaus.org/browse/MCHANGELOG-43?page=comments#action_72284 ] Abhijit Diwan commented on MCHANGELOG-43: - It is like any other SCM where you check-out and have working copy of the project locally on your development machine. So the local copy of the repository is on your development machine. Also I am able to run the mvn scm:status command as well. Changelog not getting created properly. --- Key: MCHANGELOG-43 URL: http://jira.codehaus.org/browse/MCHANGELOG-43 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: Windows xp SP2 / maven 2.0.4 Reporter: Abhijit Diwan I am trying to generate change log for my maven project. I have following scm section under my pom.xml scm connectionscm:perforce://EJB/ejb-dev/MavenCodeline//connection /scm and following plugin decalration under reporting section plugin groupIdorg.codehaus.mojo/groupId artifactIdchangelog-maven-plugin/artifactId reportSets reportSet idPerofrce report/id configuration typerange/type range10/range repositoryConnection scm:perforce://EJB/ejb-dev/MavenCodeline//repositoryConnection properties maven.changelog.factory org.apache.maven.perforcelib.PerforceChangeLogFactory/maven.changelog.factory /properties /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin I have already defined P4PORT variable on my machine. When I ran mvn site command from module directory AeConnector I get following error. [INFO] Generating changed sets xml to: E:\views\EJB\ejb-dev\MavenCodeline\AeConn ector\target\changelog.xml [INFO] SCM Working Directory: E:\views\EJB\ejb-dev\MavenCodeline\AeConnector\src \main\java [INFO] SCM Command Line[0]: p4 [INFO] SCM Command Line[1]: filelog [INFO] SCM Command Line[2]: -tl [INFO] SCM Command Line[3]: //EJB/ejb-dev/MavenCodeline/AeConnector [ERROR] //EJB/ejb-dev/MavenCodeline/AeConnector - no such file(s). All my java code is under that directory but the plugin is not able to recurse all the subdirectories under that directory. I looked at perforce doc and ran command p4 filelog //EJB/ejb-dev/MavenCodeline/AeConnector/... and it worked so I think with plugin those last 3 dots which makes p4 recurse is not there. The documentation for p4 command you can find from following url - (http://www.perforce.com/perforce/doc.051/manuals/cmdref/filelog.html) Please please help. thanks a lot abhijit -- 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: (MEAR-29) EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment
[ http://jira.codehaus.org/browse/MEAR-29?page=all ] Stephane Nicoll closed MEAR-29. --- Resolution: Won't Fix Fix Version/s: (was: 2.3) The product is JBoss portal As discussed previously, check the JBoss portal documentation to solve this particular issue. EAR:generate-application-xml : Ability to deactivate context-root generation to be compliant with portlet deployment -- Key: MEAR-29 URL: http://jira.codehaus.org/browse/MEAR-29 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: OS: WIN2K (likely any platform) Application Server: JBOSS 4.0.3 (likely not relevant) Reporter: Thierry Barnier Assigned To: Stephane Nicoll Attachments: no-context-root for Maven-EARplugin.patch I embed a WAR portlet module inside an EAR module I configure the EAR module as follows plugin groupId org.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.1/version configuration displayNamePortlet/displayName descriptionJBOSS portlet/description modules webModule groupIdmyApp/groupId artifactIdJBPortlet1-war/artifactId !--contextRoot/portlet/contextRoot My problem goes here -- /webModule /modules /configuration /plugin The maven-EAR-module generates an application.xml of the following form: application display-nameThierry Portlet/display-name descriptionJBOSS portlet/description module web web-uri JBPortlet1-war-1.0.war/web-uri context-root/portlet/context-root I would like to remove automatically this line /web /module /application The problem is: In case of a portlet deployment, the context-root element must be omitted, or the application server reject the EAR package. There is no way today to disable context-root generation in application.xml If i comment / remove the contextroot line in the POM file , it takes the WAR filename as context-root in the application.xml I would like to remove automatically the context-root line. what could be the strategy? =a noContextRoot tag added to the ear plugin config webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId noContextRoot/ /webModule =a way to specify that application-xml has to be generated regarding portlet constraints? (isPortlet property) webModule groupIdtutorials/groupId artifactIdJBPortlet1-war/artifactId isPortlettrue/isPortlet /webModule -- 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-812) Fix resolution of ${plexus.home}
[ http://jira.codehaus.org/browse/CONTINUUM-812?page=all ]
Emmanuel Venisse closed CONTINUUM-812.
--
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 1.1
Done.
The resolution of plexus.home for unexploded webapp will be in an other issue.
Fix resolution of ${plexus.home}
Key: CONTINUUM-812
URL: http://jira.codehaus.org/browse/CONTINUUM-812
Project: Continuum
Issue Type: Bug
Components: Database
Affects Versions: 1.1
Reporter: Carlos Sanchez
Assigned To: Emmanuel Venisse
Fix For: 1.1
Continuum creates the DB in a folder called ${plexus.home}
--
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: (MEAR-33) add option to include modules in EAR in exploded (i.e. directory) form, rather than as in jar form
[ http://jira.codehaus.org/browse/MEAR-33?page=all ] Stephane Nicoll closed MEAR-33. --- Resolution: Fixed Done. Two ways to configure this * Add: unpacktrue/unpack to the module's configuration * Specify a list of types that will be unpacked, unpackTypesrar,ejb,war/unpackTypes add option to include modules in EAR in exploded (i.e. directory) form, rather than as in jar form -- Key: MEAR-33 URL: http://jira.codehaus.org/browse/MEAR-33 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ian Springer Assigned To: Stephane Nicoll Fix For: 2.3 Attachments: MEAR-33.patch In JBoss, and perhaps other app servers, modules can be packaged in an EAR as directories. For example: my.ear/ my.war/ service1.sar/ service2.sar/ Please add an option on the ear plugin that allows you to specify that modules should be packaged in exploded form. -- 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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_72300 ] Ralph Goers commented on MNG-1577: -- Brett. This can easily be done without breaking compatibility. It wasn't too hard to figure out how to add an override child element to the dependencyManagement element. By using false as the default value for this compatibility is maintained. The problem I am having is in figuring out how to pass this flag to the artifact resolver since the dependency management object is converted into a simple Map. dependencyManagement does not work for transitive dependencies -- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.1 The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-67) assembling dependent jars or snapshots uses timestamp formatted version instead of ${version}
[ http://jira.codehaus.org/browse/MASSEMBLY-67?page=comments#action_72301 ]
Richard van der Hoff commented on MASSEMBLY-67:
---
ah right, thanks. I'll look into rolling my own build of it then...
assembling dependent jars or snapshots uses timestamp formatted version
instead of ${version}
-
Key: MASSEMBLY-67
URL: http://jira.codehaus.org/browse/MASSEMBLY-67
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Reporter: Mark J. Titorenko
Assigned To: John Casey
Fix For: 2.2
Attachments: MJAR-28-Notes.txt, MJAR-28-TestCases-Patch.txt
I'm using the jar plugin to add my dependencies to the manifest. I'm also
using the assembly plugin to package all dependencies into one archive. The
problem is that the jar manifest adds my dependencies as foo-SNAPHOT and
the archiver adds them as foo-20041113.jar.
This causes my snapshot classes to not be found at runtime.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-149) Optionally lock perforce labels
Optionally lock perforce labels --- Key: MRELEASE-149 URL: http://jira.codehaus.org/browse/MRELEASE-149 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: Yuri Schimke Priority: Minor Perforce labels can be optionally locked. The maven-release-plugin creates unlocked labels, however we would like to have the option of locking them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (SCM-226) Optionally lock perforce labels
[ http://jira.codehaus.org/browse/SCM-226?page=all ] Mike Perham moved MRELEASE-149 to SCM-226: -- Affects Version/s: (was: 2.0-beta-4) 1.0-beta-3 Complexity: Intermediate Issue Type: New Feature (was: Improvement) Key: SCM-226 (was: MRELEASE-149) Project: Maven SCM (was: Maven 2.x Release Plugin) Optionally lock perforce labels --- Key: SCM-226 URL: http://jira.codehaus.org/browse/SCM-226 Project: Maven SCM Issue Type: New Feature Affects Versions: 1.0-beta-3 Reporter: Yuri Schimke Priority: Minor Perforce labels can be optionally locked. The maven-release-plugin creates unlocked labels, however we would like to have the option of locking them. -- 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-68) Adding twiki plugin as build extension makes goal site:site fail.
Adding twiki plugin as build extension makes goal site:site fail. - Key: DOXIA-68 URL: http://jira.codehaus.org/browse/DOXIA-68 Project: doxia Issue Type: Bug Components: Module - Twiki Affects Versions: 1.0-alpha-8 Environment: WinXp, Java5 Reporter: Martin Zeltner When I add the twiki module as an extension in my pom.xml the goal site:site will fail. Extension config snippet: -- build extensions !-- Site -- extension artifactIddoxia-module-twiki/artifactId groupIdorg.apache.maven.doxia/groupId version1.0-alpha-9-SNAPSHOT/version /extension /extensions /build -- Console output: -- mvn site:site -X + Error stacktraces are turned on. Maven version: 2.1-SNAPSHOT [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'site'. [INFO] [INFO] Building EL4J module core [INFO]task-segment: [site:site] [INFO] [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] ** [INFO] Starting Jakarta Velocity v1.4 [INFO] RuntimeInstance initializing. [INFO] Default Properties File: org\apache\velocity\runtime\defaults\velocity.properties [INFO] Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl) [INFO] Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader [INFO] ClasspathResourceLoader : initialization starting. [INFO] ClasspathResourceLoader : initialization complete. [INFO] ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl) [INFO] Default ResourceManager initialization complete. [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach [INFO] Created: 20 parsers. [INFO] Velocimacro : initialization starting. [INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' [INFO] Velocimacro : VM library template macro registration complete. [INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be global in scope if allowed. [INFO] Velocimacro : initialization complete. [INFO] Velocity successfully started. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error getting reports from the plugin 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find the mojo 'org.apache.maven.plugins:maven-jxr-plugin:2.1-SNAPSHOT:jxr' in the plugin 'org.apache .maven.plugins:maven-jxr-plugin' [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports from the plugin 'org.apache.maven.plugins:maven-jxr-plugin': Unable to find the mojo 'org.apache.maven.plugins:maven-jxr-p lugin:2.1-SNAPSHOT:jxr' in the plugin 'org.apache.maven.plugins:maven-jxr-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:689) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:637) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at
[jira] Created: (DOXIA-69) Uncorrect role taken for plexus component configuration
Uncorrect role taken for plexus component configuration --- Key: DOXIA-69 URL: http://jira.codehaus.org/browse/DOXIA-69 Project: doxia Issue Type: Bug Components: Module - Twiki Affects Versions: 1.0-alpha-8 Environment: WinXp, Java5 Reporter: Martin Zeltner Attachments: patch_doxia-twiki-plugin.txt In parser and site module classes the false role is configured. Problem solved in appended patch. Cheers, Martin -- 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-70) Scope test must be added in dependency doxia-core:test-jar in doxia-modules
Scope test must be added in dependency doxia-core:test-jar in doxia-modules - Key: DOXIA-70 URL: http://jira.codehaus.org/browse/DOXIA-70 Project: doxia Issue Type: Bug Components: Core Affects Versions: 1.0-alpha-8 Environment: WinXp, Java5 Reporter: Martin Zeltner Attachments: patch_doxia-modules.txt Scope test must be added in dependency doxia-core:test-jar in doxia-modules. See appended patch. Cheers, Martin -- 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: (MEAR-32) Review EAR Plugin site documentation
[ http://jira.codehaus.org/browse/MEAR-32?page=all ] Edwin Punzalan closed MEAR-32. -- Resolution: Fixed Stephane, Thanks a lot for helping ^_^ Review EAR Plugin site documentation Key: MEAR-32 URL: http://jira.codehaus.org/browse/MEAR-32 Project: Maven 2.x Ear Plugin Issue Type: Task Affects Versions: 2.2 Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Fix For: 2.3 Original Estimate: 1 day, 12 hours Time Spent: 13 hours Remaining Estimate: 23 hours Also, apply docck rules -- 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: (MPWAR-63) ClassNotFoundException when trying to war SNAPSHOT version
[ http://jira.codehaus.org/browse/MPWAR-63?page=comments#action_72304 ] Steve Molloy commented on MPWAR-63: --- Works fine with 1.6.1... ClassNotFoundException when trying to war SNAPSHOT version -- Key: MPWAR-63 URL: http://jira.codehaus.org/browse/MPWAR-63 Project: maven-war-plugin Issue Type: Bug Affects Versions: 1.6.2 Environment: Fedora Core 5 Sun JDK 1.5.0_07 Maven 1.1-beta3 Reporter: Steve Molloy When trying to build a war for a SNAPSHOT version, a ClassNotFoundException occurs when trying to perform the staticInvoke on StringUtils: ... war:war: [echo] Building WAR TawJni BUILD FAILED java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.commons.jelly.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:91) at org.apache.commons.jelly.tags.core.InvokeStaticTag.loadClass(InvokeStaticTag.java:167) at org.apache.commons.jelly.tags.core.InvokeStaticTag.doTag(InvokeStaticTag.java:124) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:237) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:234) at org.apache.commons.jelly.TagSupport.getBodyText(TagSupport.java:222) at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:160) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:82) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:115) at org.apache.maven.werkz.Goal.fire(Goal.java:647) at org.apache.maven.werkz.Goal.attain(Goal.java:582) at org.apache.maven.werkz.Goal.attainPrecursors(Goal.java:494) at org.apache.maven.werkz.Goal.attain(Goal.java:580) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:709) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:264) at org.apache.maven.cli.App.doMain(App.java:546) at org.apache.maven.cli.App.main(App.java:1390) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) File.. file:/home/smolloy/.maven/cache/maven-war-plugin-1.6.2/plugin.jelly Element... j:invokeStatic Line.. 103 Column 130 org.apache.commons.lang.StringUtils 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 com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Total time : 2 minutes 26 seconds Finished at : Monday, August 14, 2006 11:06:43 EDT AM -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-122) Apply docck rules to the assembly plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-122?page=comments#action_72305 ] Edwin Punzalan commented on MASSEMBLY-122: -- I'd like to close this issue but I'm a bit bothered by the Descriptor Format page... I think it needs to be refactored to remove unsupported SetBase elements such as fileModes and directoryModes when its a child of dependencySet. Apply docck rules to the assembly plugin Key: MASSEMBLY-122 URL: http://jira.codehaus.org/browse/MASSEMBLY-122 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Original Estimate: 1 day, 9 hours Time Spent: 1 day, 16 hours Remaining Estimate: 1 hour -- 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: (MRESOURCES-29) An escape mechanism for property interpolation is missing.
An escape mechanism for property interpolation is missing.
--
Key: MRESOURCES-29
URL: http://jira.codehaus.org/browse/MRESOURCES-29
Project: Maven 2.x Resources Plugin
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Hendrik Schreiber
It would be great, if there was a mechanism that let's you escape a property so
that it is not replaced by the filtering machism. E.g. in a log4j.xml
configuration file you might want to preserve ${user.home}, but replace some
other property like ${log.dir}. Currently there is no convenient way to achieve
that.
Alternatively to escaping, it would be helpful, if one could choose the token
format. So, if one could say, only honor @token@ and not ${token} (or the other
way around) one could easily work around the escape problem.
Workaround for the problem mentioned above:
replace the ${user.home} in log4j.xml with @[EMAIL PROTECTED]@end@ and define
start=${and end=$} in the property file
--
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: (MSITE-175) Log message shows wrong port number for site:run
[ http://jira.codehaus.org/browse/MSITE-175?page=all ]
Dennis Lundberg closed MSITE-175.
-
Resolution: Fixed
Fix Version/s: 2.0
Patch applied. Thanks!
Log message shows wrong port number for site:run
Key: MSITE-175
URL: http://jira.codehaus.org/browse/MSITE-175
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Reporter: Wendy Smoak
Assigned To: Dennis Lundberg
Priority: Trivial
Fix For: 2.0
mvn site:run -Dport=8123 works correctly, but the log message still says that
Jetty was started on 8080.
The port number is hard coded in the log message on line 86 of SiteRunMojo:
Index: src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
===
--- src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
(revision 428603)
+++ src/main/java/org/apache/maven/plugins/site/SiteRunMojo.java
(working copy)
@@ -83,7 +83,7 @@
handlers[1] = notFoundHandler;
server.setHandlers( handlers );
-getLog().info( Starting Jetty on http://localhost:8080/; );
+getLog().info( Starting Jetty on http://localhost:; + port + / );
try
{
server.start();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-150) Can't add prefix to tags without affecting version
Can't add prefix to tags without affecting version
--
Key: MRELEASE-150
URL: http://jira.codehaus.org/browse/MRELEASE-150
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Yuri Schimke
Priority: Minor
I added the following to my POM
plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagXXX-${artifactId}-${version}/tag
/configuration
/plugin
However the tag comes out incorrectly.
[INFO] Full run would be tagging C:\PerforceViews\... with label:
'XXX-myproject-0.5.4-SNAPSHOT
What is the default? tag${artifactId}-${version}/tag
Note: this seems to be missing from the plugin documentation, it only mentions
releaseLabel, which defaults to tag.
--
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-226) Optionally lock perforce labels
[ http://jira.codehaus.org/browse/SCM-226?page=comments#action_72310 ] Yuri Schimke commented on SCM-226: -- Is there an easy way to integrate this with the release plugin? A system property seems fine for using the scm plugin directly. but when using the release plugin, it should really be part of the config there. I release it will take a while to get into a release with the different components involved. But thanks for the quick feedback. Optionally lock perforce labels --- Key: SCM-226 URL: http://jira.codehaus.org/browse/SCM-226 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Reporter: Yuri Schimke Priority: Minor Fix For: 1.0 Perforce labels can be optionally locked. The maven-release-plugin creates unlocked labels, however we would like to have the option of locking them. -- 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-226) Optionally lock perforce labels
[ http://jira.codehaus.org/browse/SCM-226?page=comments#action_72311 ] Yuri Schimke commented on SCM-226: -- I realise Optionally lock perforce labels --- Key: SCM-226 URL: http://jira.codehaus.org/browse/SCM-226 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Reporter: Yuri Schimke Priority: Minor Fix For: 1.0 Perforce labels can be optionally locked. The maven-release-plugin creates unlocked labels, however we would like to have the option of locking them. -- 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: (MPIR-55) Detailed Artifact Information Repository Location for each Dependency.
[ http://jira.codehaus.org/browse/MPIR-55?page=all ] Joakim Erdfelt updated MPIR-55: --- Attachment: MPIR-55-incremental.diff Incremental patch created (using standard diff, not svn diff) Contains: * Changing repository locations report default to false. * DependenciesReport is now Contextualizable. * Jar object is instantiated via plexus lookup. * Repository Locations report does not run in offline mode. Detailed Artifact Information Repository Location for each Dependency. Key: MPIR-55 URL: http://jira.codehaus.org/browse/MPIR-55 Project: Maven 2.x Project Info Reports Plugin Issue Type: New Feature Reporter: Joakim Erdfelt Fix For: 2.1 Attachments: MPIR-55-dependencies-details-and-repo-locations.diff, MPIR-55-incremental.diff I've created a patch that uses MNG-2489 (maven-shared-jar) and WAGON-58 (wagon provider improvements) to increase the level of information about the dependencies on the dependencies report. Example Report: http://joakim.erdfelt.com/maven-project-info-reports-plugin/dependencies.html (See sections titled Dependency File Details and Dependency Repository Locations) This adds the following information about each dependency. * File size * Count of entries * Count of classes * Count of packages * JDK Revision of compiled classes * If Debug is Present in compiled classes. * If Jar is Sealed (in the manifest) * What Repository the artifact can be found in And adds a small section of all of the repositories in use by the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1048) Upload backport-util-concurrent-2.2
Upload backport-util-concurrent-2.2 --- Key: MAVENUPLOAD-1048 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1048 Project: maven-upload-requests Issue Type: Task Reporter: Taras Puchko http://fileanchor.com/53065-d http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ This package is the backport of java.util.concurrent API, introduced in Java 5.0, to Java 1.4. Needed for http://retrotranslator.sourceforge.net. -- 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-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=comments#action_72313 ] Holger Hoffstätte commented on MNG-1412: I want to add another point of view and request ordering of exported jars *by name*, at least as option. While I can understand Mark's use case for controlling export ordering (POM order is a good step forward from the current way), I like to think of the need for a properly ordered classpath as a build management bug in the first place. This should just not be an issue for IDE development; I'd venture the guess that quickly finding classes in a list of jars is the much more common case. 99% of the time I am simply not interested in detailed dependency trees, and for launching I can still rearrange in the launch config. Looking at the patches it seems to me that an optional name ordering should not be much more complicated, e.g. by throwing everything into a TreeMap before output. dependency sorting in classpath --- Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0 Reporter: Mark Hobson Assigned To: fabrizio giustina Fix For: 2.1 Attachments: artifact-order_maven-artifact-manager.txt, artifact-order_maven-artifact.txt, artifact-order_maven-project.txt The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- 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: (MNGECLIPSE-177) Compiler Plugin Fails
Compiler Plugin Fails - Key: MNGECLIPSE-177 URL: http://jira.codehaus.org/browse/MNGECLIPSE-177 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Eclipse 3.2, Windows XP, Java 1.5.0-06 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Attachments: lidalia-test-message.zip Choosing Run as on a very simple maven enabled project and specifying as goals clean install results in a compiler error as so: [INFO] compiler:compile Compiling 1 source file to C:\Documents and Settings\Rob\Eclipse Workspaces\Experimentation Workspace\lidalia-test-remoting\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : uk.org.lidalia:lidalia-test-remoting:jar:0.0.1 ( task-segment: [clean, install] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more Running mvn clean install from the command line works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-177) Compiler Plugin Fails
[ http://jira.codehaus.org/browse/MNGECLIPSE-177?page=all ] Eugene Kuleshov closed MNGECLIPSE-177. -- Resolution: Won't Fix Most likely you are running Eclipse using JRE and have JRE as default JVM in your Eclipse? Check Java - Installd JREs in Eclipse preferences and make sure you have JDK in there as default one. You can also choose specific JDK in Maven launch configuration. Feel free to reopen this issue if above evaluation is invalid. Compiler Plugin Fails - Key: MNGECLIPSE-177 URL: http://jira.codehaus.org/browse/MNGECLIPSE-177 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Eclipse 3.2, Windows XP, Java 1.5.0-06 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Attachments: lidalia-test-message.zip Choosing Run as on a very simple maven enabled project and specifying as goals clean install results in a compiler error as so: [INFO] compiler:compile Compiling 1 source file to C:\Documents and Settings\Rob\Eclipse Workspaces\Experimentation Workspace\lidalia-test-remoting\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : uk.org.lidalia:lidalia-test-remoting:jar:0.0.1 ( task-segment: [clean, install] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more Running mvn clean install from the command line works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-177) Compiler Plugin Fails
[ http://jira.codehaus.org/browse/MNGECLIPSE-177?page=comments#action_72315 ] Robert Elliot commented on MNGECLIPSE-177: -- That was it. Sorry for bothering you. Compiler Plugin Fails - Key: MNGECLIPSE-177 URL: http://jira.codehaus.org/browse/MNGECLIPSE-177 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Maven Launcher Affects Versions: 0.0.9 Environment: Eclipse 3.2, Windows XP, Java 1.5.0-06 Reporter: Robert Elliot Assigned To: Eugene Kuleshov Attachments: lidalia-test-message.zip Choosing Run as on a very simple maven enabled project and specifying as goals clean install results in a compiler error as so: [INFO] compiler:compile Compiling 1 source file to C:\Documents and Settings\Rob\Eclipse Workspaces\Experimentation Workspace\lidalia-test-remoting\target\classes [ERROR] mojo-execute : compiler:compile Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project [ERROR] project-execute : uk.org.lidalia:lidalia-test-remoting:jar:0.0.1 ( task-segment: [clean, install] ) Diagnosis: Compilation failure FATAL ERROR: Error executing Maven for a project org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:441) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:382) at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 8 more Running mvn clean install from the command line works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2497) multi module reporting - main page doesn't show links to contained modules
multi module reporting - main page doesn't show links to contained modules -- Key: MNG-2497 URL: http://jira.codehaus.org/browse/MNG-2497 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Reporter: Jan Vissers In a multi module project, the site generates a main page index.html, which has the contained modules on the upper left hand corner in bold face. These should be hyperlinks to the actual module's index.html -- 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-83) Aggregated javadoc page stays empty when site is generated with the destination option active
Aggregated javadoc page stays empty when site is generated with the destination option active - Key: MJAVADOC-83 URL: http://jira.codehaus.org/browse/MJAVADOC-83 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Reporter: Jan Vissers The rest of the site is (more-or-less) placed in the location as specified by the -D option. However the aggregated javadoc remains empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-150) Can't add prefix to tags without affecting version
[ http://jira.codehaus.org/browse/MRELEASE-150?page=comments#action_72317 ]
Mike Perham commented on MRELEASE-150:
--
I suspect the variables are getting resolved during the POM snapshot - release
transform so that the tag value is then hardcoded to that value, no longer
using variables.
Can't add prefix to tags without affecting version
--
Key: MRELEASE-150
URL: http://jira.codehaus.org/browse/MRELEASE-150
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Yuri Schimke
Priority: Minor
I added the following to my POM
plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagXXX-${artifactId}-${version}/tag
/configuration
/plugin
However the tag comes out incorrectly.
[INFO] Full run would be tagging C:\PerforceViews\... with label:
'XXX-myproject-0.5.4-SNAPSHOT
What is the default? tag${artifactId}-${version}/tag
Note: this seems to be missing from the plugin documentation, it only
mentions releaseLabel, which defaults to tag.
--
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: (MCHANGELOG-43) Changelog not getting created properly.
[ http://jira.codehaus.org/browse/MCHANGELOG-43?page=comments#action_72318 ] Dennis Lundberg commented on MCHANGELOG-43: --- Yes I know, but I was asking about the repository - not your working copy. Is your perforce repository on your machine or some other machine? Can you please run the command again with the -X flag som that you get a complete stack trace. Then either post the stack trace to this issue or attach it as a file. Changelog not getting created properly. --- Key: MCHANGELOG-43 URL: http://jira.codehaus.org/browse/MCHANGELOG-43 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: Windows xp SP2 / maven 2.0.4 Reporter: Abhijit Diwan I am trying to generate change log for my maven project. I have following scm section under my pom.xml scm connectionscm:perforce://EJB/ejb-dev/MavenCodeline//connection /scm and following plugin decalration under reporting section plugin groupIdorg.codehaus.mojo/groupId artifactIdchangelog-maven-plugin/artifactId reportSets reportSet idPerofrce report/id configuration typerange/type range10/range repositoryConnection scm:perforce://EJB/ejb-dev/MavenCodeline//repositoryConnection properties maven.changelog.factory org.apache.maven.perforcelib.PerforceChangeLogFactory/maven.changelog.factory /properties /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin I have already defined P4PORT variable on my machine. When I ran mvn site command from module directory AeConnector I get following error. [INFO] Generating changed sets xml to: E:\views\EJB\ejb-dev\MavenCodeline\AeConn ector\target\changelog.xml [INFO] SCM Working Directory: E:\views\EJB\ejb-dev\MavenCodeline\AeConnector\src \main\java [INFO] SCM Command Line[0]: p4 [INFO] SCM Command Line[1]: filelog [INFO] SCM Command Line[2]: -tl [INFO] SCM Command Line[3]: //EJB/ejb-dev/MavenCodeline/AeConnector [ERROR] //EJB/ejb-dev/MavenCodeline/AeConnector - no such file(s). All my java code is under that directory but the plugin is not able to recurse all the subdirectories under that directory. I looked at perforce doc and ran command p4 filelog //EJB/ejb-dev/MavenCodeline/AeConnector/... and it worked so I think with plugin those last 3 dots which makes p4 recurse is not there. The documentation for p4 command you can find from following url - (http://www.perforce.com/perforce/doc.051/manuals/cmdref/filelog.html) Please please help. thanks a lot abhijit -- 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: (CONTINUUM-777) Handle filesystem problems when adding a pom
[ http://jira.codehaus.org/browse/CONTINUUM-777?page=comments#action_72319 ] Carlos Sanchez commented on CONTINUUM-777: -- refactored architecture to handle this. Errors that must be presented to the user don't throw exceptions, they are added to a ContinuumProjectBuildingResult. ContinuumProjectBuildingResult has constants with the keys of the errors. We use keys so it can be i18n later on the web layer. Errors to be shown to the user are (but not limited to): - xml errors in pom - host unknown - url doesn't exist - pom has missing info (scm, groupId, artifactId...) Anything unexpected must be thrown as an exception to be catched by the upper layers http://svn.apache.org/viewvc?view=revrevision=431403 Handle filesystem problems when adding a pom Key: CONTINUUM-777 URL: http://jira.codehaus.org/browse/CONTINUUM-777 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma Attachments: CONTINUUM-777.patch, CONTINUUM-777_2.patch I see in the logs 61589439 [SocketListener0-5] INFO org.apache.maven.continuum.Continuum - Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/ svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) 6 we should check that file error and show an internal error page instead of current Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) Check the logs for more details. -- 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: (CONTINUUM-777) Handle filesystem problems when adding a pom
[ http://jira.codehaus.org/browse/CONTINUUM-777?page=comments#action_72320 ] Carlos Sanchez commented on CONTINUUM-777: -- I have added a bunch of TODOs for what still needs to be done Handle filesystem problems when adding a pom Key: CONTINUUM-777 URL: http://jira.codehaus.org/browse/CONTINUUM-777 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma Attachments: CONTINUUM-777.patch, CONTINUUM-777_2.patch I see in the logs 61589439 [SocketListener0-5] INFO org.apache.maven.continuum.Continuum - Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/ svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) 6 we should check that file error and show an internal error page instead of current Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) Check the logs for more details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-150) Can't add prefix to tags without affecting version
[ http://jira.codehaus.org/browse/MRELEASE-150?page=comments#action_72321 ]
Yuri Schimke commented on MRELEASE-150:
---
Just realised, the default is obviously null, so that it prompts you to enter
the label.
So its actually set at a point that understands the various versions. Can this
be addressed by adding extra variables that can be referenced i.e.
- version.previous
- version.release
- version.next
Can't add prefix to tags without affecting version
--
Key: MRELEASE-150
URL: http://jira.codehaus.org/browse/MRELEASE-150
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Yuri Schimke
Priority: Minor
I added the following to my POM
plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagXXX-${artifactId}-${version}/tag
/configuration
/plugin
However the tag comes out incorrectly.
[INFO] Full run would be tagging C:\PerforceViews\... with label:
'XXX-myproject-0.5.4-SNAPSHOT
What is the default? tag${artifactId}-${version}/tag
Note: this seems to be missing from the plugin documentation, it only
mentions releaseLabel, which defaults to tag.
--
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: (MPIR-55) Detailed Artifact Information Repository Location for each Dependency.
[ http://jira.codehaus.org/browse/MPIR-55?page=all ] Carlos Sanchez closed MPIR-55. -- Assignee: Carlos Sanchez Resolution: Fixed Detailed Artifact Information Repository Location for each Dependency. Key: MPIR-55 URL: http://jira.codehaus.org/browse/MPIR-55 Project: Maven 2.x Project Info Reports Plugin Issue Type: New Feature Reporter: Joakim Erdfelt Assigned To: Carlos Sanchez Fix For: 2.1 Attachments: MPIR-55-dependencies-details-and-repo-locations.diff, MPIR-55-incremental.diff I've created a patch that uses MNG-2489 (maven-shared-jar) and WAGON-58 (wagon provider improvements) to increase the level of information about the dependencies on the dependencies report. Example Report: http://joakim.erdfelt.com/maven-project-info-reports-plugin/dependencies.html (See sections titled Dependency File Details and Dependency Repository Locations) This adds the following information about each dependency. * File size * Count of entries * Count of classes * Count of packages * JDK Revision of compiled classes * If Debug is Present in compiled classes. * If Jar is Sealed (in the manifest) * What Repository the artifact can be found in And adds a small section of all of the repositories in use by the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2450) Ant Tasks do not work on the ZOS
[ http://jira.codehaus.org/browse/MNG-2450?page=comments#action_72324 ] Jeff Maxwell commented on MNG-2450: --- Remote repositories do not work. The poms are in download as UTF-8 which as stated in the description can not be parsed by the plexus MXParser. Ant Tasks do not work on the ZOS Key: MNG-2450 URL: http://jira.codehaus.org/browse/MNG-2450 Project: Maven 2 Issue Type: Bug Components: Ant tasks Affects Versions: 2.0, 2.0.1, 2.0.3, 2.0.2, 2.0.4 Environment: OS: Z/OS 1.4 JDK 1.4.2 Ant 1.6.5 Reporter: Jeff Maxwell Priority: Critical The current distribution does not work on Z/OS without modification. The issue stems from the XML parser. The plexus MXParser (org.codehaus.plexus.util.xml.pull.MXParser) does not handle xml encoding and different character sets properly. Any xml files that are sent to the MXParser MUST be in the same character set as the operating system default. Three files in the distribution META-INF/plexus/components.xml, org/apache/maven/project/pom-4.0.0.xml and org/codehaus/plexus/plexus-bootstrap.xml must be converted to EBCDIC in order for the ant tasks to function. Also any poms must be in EBCDIC regardless of the xml encoding. -- 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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_72330 ] Bernd commented on SUREFIRE-31: --- Looks like I could successfully connect maven reporting with JUnitCore, the problems mentioned above are not existing. Some basic test run now and mvn site creates to surefire html report. But now I run into MSUREFIREREP-26, I will have a look at that... support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Reporter: John Didion Attachments: SUREFIRE-31-maven-surefire-plugin.patch, surefire-junit4.zip I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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-60) wagon-webdav fails with commons-logging classloader issues
[ http://jira.codehaus.org/browse/WAGON-60?page=comments#action_72332 ] Yuri Schimke commented on WAGON-60: --- I deleted ~/.m2/repository and tried it again, its now working. I guess I had a bad jar, or possibly one of the snapshots I had built myself was getting in the way. wagon-webdav fails with commons-logging classloader issues -- Key: WAGON-60 URL: http://jira.codehaus.org/browse/WAGON-60 Project: wagon Issue Type: Bug Components: wagon-webdav Affects Versions: 1.0-beta-1 Environment: maven 2.0.4 Reporter: Yuri Schimke Priority: Critical I tried it with a build extension and also putting jars in $M2_HOME/lib, but both ways I get classloader issues with commons-logging. My project uses commons logging and I've seen at least one other report that it can be a problem. with things in lib: Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at org.apache.commons.httpclient.HttpClient.clinit(HttpClient.java:69) ... 30 more Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) ... 34 more Caused by: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385) using build extension: java.lang.ExceptionInInitializerError at org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145) at org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127) at org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320) at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408) at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:290) at org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.init(CorrectedWebdavResource.java:52) at org.apache.maven.wagon.providers.webdav.WebDavWagon.openConnection(WebDavWagon.java:139) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:132) 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.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at
[jira] Created: (MNG-2498) Thousands of [WARNING] Component returned which is not the same manager.
Thousands of [WARNING] Component returned which is not the same manager. - Key: MNG-2498 URL: http://jira.codehaus.org/browse/MNG-2498 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Reporter: Brian Fox Reported to Jason in IRC. This is starting to happen on more and more machines: [WARNING] Component returned which is not the same manager. Ignored. component=o [EMAIL PROTECTED] It happens when processing resources, mostly for war projects although I'm not 100% positive it's only wars. We see one of these warnings apparently for every file processed because sometimes there are just a few and sometimes there are 1000s correlating to the number of files in the project. So far it only happens on dual-core machines although not every time. It smells of a multithreading issue. -- 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: (MASSEMBLY-137) No support for avoiding assembly as attached artifact
No support for avoiding assembly as attached artifact - Key: MASSEMBLY-137 URL: http://jira.codehaus.org/browse/MASSEMBLY-137 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Windows XP Reporter: James Carpenter Unlike the source and javadoc plugins the current version of the assembly plugin doesn't support a mechanism to indicate whether the assembly should be included as an attached artifact. From observed behavior it appears it always treats the assembly as an attached artifact. Motivation: I am using an assembly descriptor to create an application installation. The application installation contains all my jar dependencies, start scripts, etc. It doesn't make any sense to deploy this large application installation to my internal maven repository, yet it is certainly appropriate for the release plugin to create it. Potentially the release plugin should even cause the application installation to be placed on a given ftp server dedicated to application releases. All of this is easily accomplished simply by defining the release-profile within my pom. Although I havn't done so, I could easily use a custom plugin, and/or the ant plugin to ensure the application installation (assembly) is copied to a particular location. Any of my normal artifacts will still be deployed to the maven repository as desired when the maven release plugin runs. #within my POM I have: profiles profile idrelease-profile/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin artifactIdmaven-assembly-plugin/artifactId version2.1/version executions execution idrelease/id phasepackage/phase inheritedfalse/inherited goals goalassembly/goal /goals !--Desired, but non-existent, config support configuration attachfalse/attach /configuration -- /execution /executions /plugin /plugins /build /profile /profiles -- 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: (MEAR-35) Generate id for modules in application.xml
[ http://jira.codehaus.org/browse/MEAR-35?page=comments#action_72334 ] Manikandan Balasubramanian commented on MEAR-35: The id is not mandatory, but it would enable eclipse deployment to be much more simpler. And since id is part of http://java.sun.com/xml/ns/j2ee/application_1_4.xsd it would be a good thing if you generated it. Generate id for modules in application.xml -- Key: MEAR-35 URL: http://jira.codehaus.org/browse/MEAR-35 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Manikandan Balasubramanian Priority: Minor When the ear plugin generates application.xml, it should generate an id with each module. This id is according to application.xml schema. This would help eclipse plugin to generate correct eclipse metedata. -- 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: (CONTINUUM-802) Use fine grained permissions per project
[ http://jira.codehaus.org/browse/CONTINUUM-802?page=comments#action_72335 ] Carlos Sanchez commented on CONTINUUM-802: -- Actually is per project group Use fine grained permissions per project Key: CONTINUUM-802 URL: http://jira.codehaus.org/browse/CONTINUUM-802 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Carlos Sanchez -- 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: (MAVEN-1778) change the visibility of methods MavenUtils.getNonJellyProject and MavenUtils.getJellyProject to public
change the visibility of methods MavenUtils.getNonJellyProject and MavenUtils.getJellyProject to public --- Key: MAVEN-1778 URL: http://jira.codehaus.org/browse/MAVEN-1778 Project: Maven Issue Type: Task Components: core Affects Versions: 1.1-beta-3, 1.1-beta-2, 1.1-beta-1 Environment: Maven 1.1-beta-3 os=winxp jdk=java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) Classic VM (build 1.4.1, J2RE 1.4.1 IBM Windows 32 build cn1411-20031011 (JIT enabled: jitc)) Reporter: Arnaud Heritier Fix For: 1.1-rc1 These methods are used by the artifact plugin and we can't access to them with the IBM's JDK. see MPARTIFACT-70. -- 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: (MAVEN-1778) change the visibility of methods MavenUtils.getNonJellyProject and MavenUtils.getJellyProject to public
[ http://jira.codehaus.org/browse/MAVEN-1778?page=all ] Arnaud Heritier closed MAVEN-1778. -- Resolution: Fixed Done. change the visibility of methods MavenUtils.getNonJellyProject and MavenUtils.getJellyProject to public --- Key: MAVEN-1778 URL: http://jira.codehaus.org/browse/MAVEN-1778 Project: Maven Issue Type: Task Components: core Affects Versions: 1.1-beta-2, 1.1-beta-1, 1.1-beta-3 Environment: Maven 1.1-beta-3 os=winxp jdk=java version 1.4.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1) Classic VM (build 1.4.1, J2RE 1.4.1 IBM Windows 32 build cn1411-20031011 (JIT enabled: jitc)) Reporter: Arnaud Heritier Fix For: 1.1-rc1 These methods are used by the artifact plugin and we can't access to them with the IBM's JDK. see MPARTIFACT-70. -- 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: (MPARTIFACT-70) java.lang.IllegalAccessException in artifact:artifact-install
[ http://jira.codehaus.org/browse/MPARTIFACT-70?page=all ] Arnaud Heritier closed MPARTIFACT-70. - Assignee: Arnaud Heritier Resolution: Fixed Fixed but the problem isn't in the plugin. It's solved by MAVEN-1778 which is available in maven = 1.1 RC1 java.lang.IllegalAccessException in artifact:artifact-install - Key: MPARTIFACT-70 URL: http://jira.codehaus.org/browse/MPARTIFACT-70 Project: maven-artifact-plugin Issue Type: Bug Affects Versions: 1.8 Reporter: dion gillard Assigned To: Arnaud Heritier Fix For: 1.8.1 I get the following when installing a plugin: --- Nested Exception --- java.lang.IllegalAccessException: org/apache/maven/MavenUtils at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:41) at java.lang.reflect.Method.invoke(Method.java:386) at org.apache.maven.artifact.PomRewriter.getRewrittenModel(PomRewriter.j ava:85) at org.apache.maven.artifact.PomRewriter.getRewrittenPom(PomRewriter.jav a:50) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleInst all(DefaultArtifactDeployer.java:165) From reading http://svn.apache.org/viewvc/maven/maven-1/plugins/trunk/artifact/src/main/org/apache/maven/artifact/PomRewriter.java?view=markup PomRewriter calls MavenUtils.getNonJellyProject and MavenUtils.getJellyProject, of which both are declared as private static -- 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: (MAVENUPLOAD-1046) pom~ in org/apache/maven/wagon/wagon/
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1046?page=all ] Carlos Sanchez closed MAVENUPLOAD-1046. --- Assignee: Carlos Sanchez Resolution: Fixed pom~ in org/apache/maven/wagon/wagon/ - Key: MAVENUPLOAD-1046 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1046 Project: maven-upload-requests Issue Type: Wish Reporter: Rainer Wasserfuhr Assigned To: Carlos Sanchez see http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.md5 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~.asc http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-3/wagon-1.0-alpha-3.pom~ http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.sha1 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.md5 http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~.asc http://ibiblio.org/maven2/org/apache/maven/wagon/wagon/1.0-alpha-2/wagon-1.0-alpha-2.pom~ -- 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-1029) fit-1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1029?page=comments#action_72340 ] Carlos Sanchez commented on MAVENUPLOAD-1029: - read groupId conventions in instructions fit-1.1 Key: MAVENUPLOAD-1029 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1029 Project: maven-upload-requests Issue Type: Wish Reporter: Mauro Talevi Assigned To: Carlos Sanchez Please upload fit-1.1.jar with POM project modelVersion4.0.0/modelVersion groupIdfit/groupId artifactIdfit/artifactId nameFit/name version1.1/version /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1044) Cojen 1.1.4 bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1044?page=comments#action_72341 ] Carlos Sanchez commented on MAVENUPLOAD-1044: - read groupId conventions in instructions Cojen 1.1.4 bundle upload - Key: MAVENUPLOAD-1044 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1044 Project: maven-upload-requests Issue Type: Task Reporter: Brian S O'Neill Cojen is a Java library which makes it easy to dynamically generate and inject Java bytecode. I am listed as lead developer broneill on the team-list page. http://cojen.sourceforge.net/team-list.html -- 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: (MAVENUPLOAD-1032) IRCLib from org.schwering
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1032?page=all ] Carlos Sanchez closed MAVENUPLOAD-1032. --- Assignee: Carlos Sanchez Resolution: Fixed IRCLib from org.schwering - Key: MAVENUPLOAD-1032 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1032 Project: maven-upload-requests Issue Type: Task Reporter: Andrew Williams Assigned To: Carlos Sanchez IRClib is a free Java implementation of the IRC protocol. The upload is needed to support some new Plexus IRC features :) -- 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: (MAVENUPLOAD-1031) Jackcess 1.1.6 release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1031?page=all ] Carlos Sanchez closed MAVENUPLOAD-1031. --- Assignee: Carlos Sanchez Resolution: Fixed Jackcess 1.1.6 release -- Key: MAVENUPLOAD-1031 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1031 Project: maven-upload-requests Issue Type: Task Reporter: james ahlborn Assigned To: Carlos Sanchez Latest jar of the jackcess package. Jackcess ia a pure Java library for reading from and writing to MS Access databases. -- 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: (MAVENUPLOAD-1030) Please upload json-lib-0.6
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1030?page=all ] Carlos Sanchez closed MAVENUPLOAD-1030. --- Assignee: Carlos Sanchez Resolution: Fixed Please upload json-lib-0.6 -- Key: MAVENUPLOAD-1030 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1030 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray Assigned To: Carlos Sanchez JSON-lib is a java library for transforming beans, maps and XML to JSON and back again to beans and DynaBeans. Javadocs are at http://json-lib.sourceforge.net/json-lib-0.6-javadoc.jar -- 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: (MEV-431) axis-jaxrpc and axis-saaj both version 1.4 have no POM
[ http://jira.codehaus.org/browse/MEV-431?page=all ] Carlos Sanchez closed MEV-431. -- Assignee: Carlos Sanchez Resolution: Incomplete axis-jaxrpc and axis-saaj both version 1.4 have no POM -- Key: MEV-431 URL: http://jira.codehaus.org/browse/MEV-431 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Aede Assigned To: Carlos Sanchez Both axis-saaj and axis-jaxrpc (which specified as dependencies in axis:axis:pom:1.4) do not have a pom of their own. This will cause maven to use stubs and not store de deps in its local repo. axis-saaj would need a pom (axis-saaj-1.4.pom) with the following content: project modelVersion4.0.0/modelVersion groupIdaxis/groupId artifactIdaxis-saaj/artifactId version1.4/version /project axis-saaj would need a pom (axis-jaxrpc-1.4.pom) with the following content: project modelVersion4.0.0/modelVersion groupIdaxis/groupId artifactIdaxis-jaxrpc/artifactId version1.4/version /project -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1047) Upload Retroweaver 1.2.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1047?page=comments#action_72342 ] Xavier Le Vourch commented on MAVENUPLOAD-1047: --- Sorry, this is the first time I'm creating bundles and I'm not too familiar with the process. I've created two distinct bundles now: http://retroweaver.sourceforge.net/files/bundle-retroweaver-1.2.4.jar http://retroweaver.sourceforge.net/files/bundle-retroweaver-rt-1.2.4.jar They contains: jar tf bundle-retroweaver-1.2.4.jar META-INF/ META-INF/MANIFEST.MF retroweaver-1.2.4.jar retroweaver-1.2.4-sources.jar pom.xml jar tf bundle-retroweaver-rt-1.2.4.jar META-INF/ META-INF/MANIFEST.MF retroweaver-rt-1.2.4.jar retroweaver-rt-1.2.4-sources.jar pom.xml Hopefully, it will work this time... Upload Retroweaver 1.2.4 Key: MAVENUPLOAD-1047 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1047 Project: maven-upload-requests Issue Type: Task Reporter: Xavier Le Vourch Retroweaver is a tool, which converts Java 5 (or 6) compliant class files into Java 1.x compliant class files. The jar file retroweaver.jar contains both the class processor (which may be used at compile time) and the runtime classes. Additionally there is the jar file retroweaver-rt.jar (which contains the runtime classes only). The bundle contains file for both the retroweaver and retroweaver-rt subpackages. -- 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: (MASSEMBLY-119) dir format will fail with an error because it can not install the directory into the repository
[ http://jira.codehaus.org/browse/MASSEMBLY-119?page=all ] Baerrach bonDierne updated MASSEMBLY-119: - Attachment: MASSEMBLY-119-patch.txt New patch that works with new unit test layout by John Casey. dir format will fail with an error because it can not install the directory into the repository --- Key: MASSEMBLY-119 URL: http://jira.codehaus.org/browse/MASSEMBLY-119 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Baerrach bonDierne Fix For: 2.2 Attachments: MASSEMBLY-119 Format dir fails on install.zip, MASSEMBLY-119-patch.txt, MASSEMBLY-119-patch.txt See the discussion on MASSEMBLY-39 which originally created the dir format. I believe the dir format should never be added to the repository as it's only purpose is to ease the development process by providing an un-archived version ready for testing on disk. The workaround is to manually extract the archive, or to create a second duplicate descriptor and use that to create the directory version (do not bind this second one to the package phase) Will attach example project shortly. The error received is: [INFO] [install:install] [INFO] Installing path\target\artifactId-0.0.1-SNAPSHOT.jar to repo\.m2\repository\groupId\artifactId\0.0.1-SNAPSHOT\artifactId-0.0.1-SNAPSHOT.jar [INFO] Installing path\target\artifactId-0.0.1-SNAPSHOT-bin.dir to repo\.m2\repository\groupId\artifactId\0.0.1-SNAPSHOT\artifactId-0.0.1-SNAPSHOT-bin.dir [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact: path\target\artifactId-0.0.1-SNAPSHOT-bin.dir (Acc ess is denied) When I run with -X the root cause error is: Caused by: java.io.FileNotFoundException: path\target\artifactId-0.0.1-SNAPSHOT-bin. dir (Access is denied) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820) at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:70) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1049) Upload stripes 1.4-beta2 to IBiblio
Upload stripes 1.4-beta2 to IBiblio --- Key: MAVENUPLOAD-1049 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1049 Project: maven-upload-requests Issue Type: Task Reporter: Tim Fennell I'm not sure if it's common to upload beta versions to ibiblio, but users of mine are requesting that the beta be made available there, so if you could upload it I'd be grateful. Thanks! -t -- 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-777) Handle filesystem problems when adding a pom
[ http://jira.codehaus.org/browse/CONTINUUM-777?page=all ] Joakim Erdfelt updated CONTINUUM-777: - Attachment: CONTINUUM-777_more_result_handling.patch Added patch to satisfy Carlos' request. NOTE: The Validation Errors in DefaultMavenBuilderHelper.getMavenProject(ContinuumProjectBuildingResult, File) require the need for parameters on the error messages. The stubs ContinuumProjectBuildingResult.addError(String key, Object param) and ContinuumProjectBuildingResult.addError(String key, Object params[]) have been created to facilitate this work. Another patch can be submitted (in a different jira?) to add i18n / parameter support to the ContinuumProjectBuildingResult and related JSPs. Handle filesystem problems when adding a pom Key: CONTINUUM-777 URL: http://jira.codehaus.org/browse/CONTINUUM-777 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma Attachments: CONTINUUM-777.patch, CONTINUUM-777_2.patch, CONTINUUM-777_more_result_handling.patch I see in the logs 61589439 [SocketListener0-5] INFO org.apache.maven.continuum.Continuum - Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/ svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) 6 we should check that file error and show an internal error page instead of current Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) Check the logs for more details. -- 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: (CONTINUUM-777) Handle filesystem problems when adding a pom
[ http://jira.codehaus.org/browse/CONTINUUM-777?page=comments#action_72350 ] Carlos Sanchez commented on CONTINUUM-777: -- committed patch Handle filesystem problems when adding a pom Key: CONTINUUM-777 URL: http://jira.codehaus.org/browse/CONTINUUM-777 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma Attachments: CONTINUUM-777.patch, CONTINUUM-777_2.patch, CONTINUUM-777_more_result_handling.patch I see in the logs 61589439 [SocketListener0-5] INFO org.apache.maven.continuum.Continuum - Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/ svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) 6 we should check that file error and show an internal error page instead of current Could not download https://svn.simulalabs.net/svn/repos/BEA-DotNet/trunk/pom.xml: /tmp/continuum/svn/repos/BEA-DotNet/trunk/pom.xml (No such file or directory) Check the logs for more details. -- 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: (CONTINUUM-814) change ContinuumActionSupport to ContinuumConfigurationInterceptor
[ http://jira.codehaus.org/browse/CONTINUUM-814?page=comments#action_72353 ] Carlos Sanchez commented on CONTINUUM-814: -- I don't see this approach working, configuration action must need an administrator role and it's a security hole to let it through the first time Also why move the jsps into /jsp? I understand the admin ones under admin but not the other ones. change ContinuumActionSupport to ContinuumConfigurationInterceptor -- Key: CONTINUUM-814 URL: http://jira.codehaus.org/browse/CONTINUUM-814 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Jesse McConnell Attachments: configuration-interceptor.patch a bit ago I submitted a patch in CONTINUUM-810 that added a ContinuumActionSupport class that leveraged the prepare interceptor to always call a prepare() method checking if the continuum configuration was initialized and if it wasn't to redirect to configuration. well shortly after that brett pointed me at how he had solved it in mrm so I figured I would just back out that previous patch and redo it his way.. that is what this patch does, makes the continuum configuration checking match that of mrm. as a byproduct of this the xwork.xml file now has multiple packages and namespaces in it, so I took the oppurtunity to move all of the jsps into src/main/webapp/jsp and the configuration ones into src/main/webapp/jsp/admin this is largely cosmetic but it cleans up the -webapp module in ide's and I was in the xwork.xml file anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-211) Tag should associate current user with Perforce Label owner
[ http://jira.codehaus.org/browse/SCM-211?page=all ] Mike Perham closed SCM-211. --- Resolution: Fixed Fix Version/s: 1.0 Tag should associate current user with Perforce Label owner --- Key: SCM-211 URL: http://jira.codehaus.org/browse/SCM-211 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Reporter: Mike Perham Assigned To: Mike Perham Fix For: 1.0 When creating a new label for the tag command, the Owner property should be set to the current Perforce username. -- 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: (CONTINUUM-814) change ContinuumActionSupport to ContinuumConfigurationInterceptor
[ http://jira.codehaus.org/browse/CONTINUUM-814?page=comments#action_72355 ] Jesse McConnell commented on CONTINUUM-814: --- 1) yes, that is a problem...how is mrm solving that then? looks like it does the same displaying of configuration if its not setup initially. 2) that was mostly just to get them out of the webapp directory so it displays nicer with in an ide, so you can hide all the jsp's easily...mrm's are all under src/main/webapp/WEB-INF/jsp change ContinuumActionSupport to ContinuumConfigurationInterceptor -- Key: CONTINUUM-814 URL: http://jira.codehaus.org/browse/CONTINUUM-814 Project: Continuum Issue Type: Improvement Components: Web interface Reporter: Jesse McConnell Attachments: configuration-interceptor.patch a bit ago I submitted a patch in CONTINUUM-810 that added a ContinuumActionSupport class that leveraged the prepare interceptor to always call a prepare() method checking if the continuum configuration was initialized and if it wasn't to redirect to configuration. well shortly after that brett pointed me at how he had solved it in mrm so I figured I would just back out that previous patch and redo it his way.. that is what this patch does, makes the continuum configuration checking match that of mrm. as a byproduct of this the xwork.xml file now has multiple packages and namespaces in it, so I took the oppurtunity to move all of the jsps into src/main/webapp/jsp and the configuration ones into src/main/webapp/jsp/admin this is largely cosmetic but it cleans up the -webapp module in ide's and I was in the xwork.xml file anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-221) scm:update has no effect
[ http://jira.codehaus.org/browse/SCM-221?page=all ] Mike Perham closed SCM-221. --- Resolution: Won't Fix Fix Version/s: 1.0 There's no clear issue here so I'm closing this unless you have more specific feedback. The property is maven.scm.perforce.clientspec.name. scm:update has no effect Key: SCM-221 URL: http://jira.codehaus.org/browse/SCM-221 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0 Environment: http://svn.apache.org/maven-snapshot-repository/org/apache/maven/scm/maven-scm-provider-perforce/1.0-SNAPSHOT/maven-scm-provider-perforce-1.0-20060616.160825-6.jar Reporter: Yuri Schimke Assigned To: Mike Perham Priority: Critical Fix For: 1.0 We are trying to use scm:update in a cruisecontrol build to update the project before building. However it doesn't seem to actually write any changes to disk. The command completes successfully, but the files are not synced to head. The directory for the update is a working perforce directory. i.e. after the command below fails to update the files, p4 sync works immediately. [INFO] [scm:update] [INFO] Checkout working directory: C:\PerforceViews\dms_1.2_dev\dms [INFO] Executing: p4 client -i [INFO] Executing: p4 client -d nbk7xsp-B001279A7BC2E-MavenSCM-C:\PerforceViews\dms_1.2_dev\dms Is the generated clientspec just using for determining changesets? There is a valid clientspec already associated with the current project 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] Closed: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=all ] Mike Perham closed SCM-165. --- Resolution: Fixed John, I updated the changelog command as you mentioned. There is a maven.scm.persistcheckout system property (see also ScmProviderRepository.setPersistCheckout()) which will persist the clientspec across invocations. Feel free to test this change and reopen if you find still have problems. PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Reporter: John Didion Assigned To: Mike Perham Priority: Critical Fix For: 1.0 Attachments: PerforceChangeLogCommand.diff, svn.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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: (MAVENUPLOAD-1044) Cojen 1.1.4 bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1044?page=all ] Brian S O'Neill closed MAVENUPLOAD-1044. Resolution: Won't Fix I'll get an org, repackage, and then bump the version number. Cojen 1.1.4 bundle upload - Key: MAVENUPLOAD-1044 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1044 Project: maven-upload-requests Issue Type: Task Reporter: Brian S O'Neill Cojen is a Java library which makes it easy to dynamically generate and inject Java bytecode. I am listed as lead developer broneill on the team-list page. http://cojen.sourceforge.net/team-list.html -- 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-815) directory configuration
directory configuration --- Key: CONTINUUM-815 URL: http://jira.codehaus.org/browse/CONTINUUM-815 Project: Continuum Issue Type: Improvement Components: Documentation Affects Versions: 1.0.3 Reporter: Torsten Curdt When I was installing maven it was not clear what the directories are for that I had to specify. - working directory - build output directory - local repository The installation guide should explain values like these. Especially awkward is that the builds happen in the working area - not in the build output area. Just needs some documentation. -- 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-816) runas in run script
runas in run script --- Key: CONTINUUM-816 URL: http://jira.codehaus.org/browse/CONTINUUM-816 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.0.3 Environment: linux Reporter: Torsten Curdt When I installed continuum I've changed the runas user in the run script but then started it via run.sh console. Unfortunately the console mode is ignoring the runas user setting so when I was trying to run it with run.sh start afterwards I was getting exception because the continuum user could not access the files. After fixing the ownerships everything was ok again. I suggest that run.sh console should also use the runas user. -- 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: (CONTINUUM-815) directory configuration
[ http://jira.codehaus.org/browse/CONTINUUM-815?page=comments#action_72358 ] Torsten Curdt commented on CONTINUUM-815: - ups ...I meant when installing continuum ;-) directory configuration --- Key: CONTINUUM-815 URL: http://jira.codehaus.org/browse/CONTINUUM-815 Project: Continuum Issue Type: Improvement Components: Documentation Affects Versions: 1.0.3 Reporter: Torsten Curdt When I was installing maven it was not clear what the directories are for that I had to specify. - working directory - build output directory - local repository The installation guide should explain values like these. Especially awkward is that the builds happen in the working area - not in the build output area. Just needs some documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-226) Optionally lock perforce labels
[ http://jira.codehaus.org/browse/SCM-226?page=all ] Mike Perham closed SCM-226. --- Assignee: Mike Perham Resolution: Fixed Added label locking by default. You can turn it off by passing -Dmaven.scm.locktag=false on the command line. But since the release plugin is the major tag creator, this seems like a reasonable thing to enable by default. Optionally lock perforce labels --- Key: SCM-226 URL: http://jira.codehaus.org/browse/SCM-226 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-perforce Affects Versions: 1.0-beta-3 Reporter: Yuri Schimke Assigned To: Mike Perham Priority: Minor Fix For: 1.0 Perforce labels can be optionally locked. The maven-release-plugin creates unlocked labels, however we would like to have the option of locking them. -- 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-2493) Snapshot plugin repositories should be included for reference at the Maven site
[ http://jira.codehaus.org/browse/MNG-2493?page=comments#action_72360 ] Baerrach bonDierne commented on MNG-2493: - When you patch it can you change the id's to codehaus.org I'm not sure what the id value should be, but maven-assembly-plugin defines it as codehaus.org. Snapshot plugin repositories should be included for reference at the Maven site --- Key: MNG-2493 URL: http://jira.codehaus.org/browse/MNG-2493 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Reporter: Baerrach bonDierne Assigned To: Vincent Siveton Fix For: 2.0.5 Attachments: MNG-2493-patch-2.txt, MNG-2493-patch.txt When developing a plugin (or patching an existing plugin), the plugin often depends upon snapshot versions of plugins. There is no reference material for where these snapshot plugin repositories are located. Luckily people respond on the list with this information, but it would help to include it as part of the reference material on the web site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-45) Support for mappers in assembly desriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-45?page=comments#action_72362 ] John Casey commented on MASSEMBLY-45: - I'm going to have to take a step back from this implementation. I've adapted it from the patch to work with the refactored assembly plugin, but wound up backing the change out. I need to review the approach a little more. In the meantime, the mapper functionality has been implemented in the org.apache.maven.shared:file-management snapshot I just deployed, but it still needs tests. Support for mappers in assembly desriptors -- Key: MASSEMBLY-45 URL: http://jira.codehaus.org/browse/MASSEMBLY-45 Project: Maven 2.x Assembly Plugin Issue Type: Bug Reporter: Anuerin Diaz Assigned To: John Casey Fix For: 2.2 Attachments: maven-assembly-plugin.patch I would like to forward a wish to have the assembly plugin support the notion of file mappers similar to the ones in Ant[1]. To illustrate, assuming a multi-module project with the following layout: Root |-Module1 |-Module2 |-Container | |-Module3 | |-Module4 |-Module5 |- pom.xml and an assembly desriptor entry for the contained modules like this fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes /fileSets /fileSets The assembly plugin will be able to get all jar files produced by Module3 and Module4 but the Container/ModuleName/target structure will still be included. One workaround is to enumerate each ModuleName artifact but problematic if the number of contained sub-modules is numerous. Support for filemappers which look like this: fileSets fileSets directoryContainer/directory outputDirectory/outputDirectory includes include**/target/*.jar/include /includes mapper type=flatten /fileSets /fileSets will cause all contained jar files to be copied without their original structure. This feature would be useful for globbing artifact names as well as for physically organizing project structures according to type. [1] http://ant.apache.org/manual/CoreTypes/mapper.html -- 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
