[jira] Issue Comment Edited: (MAVENUPLOAD-2582) JasperReports 3.6.0 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=197681#action_197681 ] Marco Noto edited comment on MAVENUPLOAD-2582 at 11/12/09 3:21 AM: --- Hi Teodor. Thank you. But what is the dependency that causes the problem? jfreechart 1.0.12? JasperReports is a great tool, it is impossible not to be used with Maven. have ypu contacted the authors of JFreeChart? anyway I install all the dependencies on my company repository, at this time seems the only solution. was (Author: cn73): Hi Teodor. Thank you. I will check every day the maven2 repository. JasperReports 3.6.0 upload -- Key: MAVENUPLOAD-2582 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2582 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu Assignee: Carlos Sanchez http://jasperreports.sf.net/maven/jasperreports-3.6.0-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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-2582) JasperReports 3.6.0 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198068#action_198068 ] Teodor Danciu commented on MAVENUPLOAD-2582: Hi, Marco Let's continue this discussion on our forums. We do have a public Maven2 repository here: http://jasperreports.sourceforge.net/maven2/ Thanks, Teodor JasperReports 3.6.0 upload -- Key: MAVENUPLOAD-2582 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2582 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu Assignee: Carlos Sanchez http://jasperreports.sf.net/maven/jasperreports-3.6.0-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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-3401) Plugin parameters must be specified outside an execution block when they are invoked from the command line
[
http://jira.codehaus.org/browse/MNG-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198075#action_198075
]
Mark Howard commented on MNG-3401:
--
The change does help in some situations, but not all. I would much prefer to be
able to specify the execution id on the command line.
For example, I have the surefire plugin setup with 2 executions - 1 bound the
the test phase and another bound to the integration test phase.
I would often want to run mvn surefire:test for the integration test as a
standalone command, for example if I've modified some configuration, but don't
want to run the full lifecycle. In my case, the pre-integration-test phase
takes several seconds, so I don't want to repeat this just to re-run the tests.
Can't we just have a new syntax along the lines of mvn
plugin:goal:execution-id, or mvn plugin:goal -execution=execution-id
Plugin parameters must be specified outside an execution block when they are
invoked from the command line
--
Key: MNG-3401
URL: http://jira.codehaus.org/browse/MNG-3401
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.8
Reporter: Michael Heß
Assignee: John Casey
Fix For: 2.2.0, 3.0-alpha-3
Attachments: maven-core-MojoExectution-r712253.patch
According to Brian E. Fox there is something wrong with the Maven Core which
causes the maven-dependency-plugin to fail if it is called by the
mvn-eclipse-plugin. I can't tell any specifics since Brian looked into it,
and only provided me a workaround. I'm pasting our dialog from the mailing
list in here. Any further questions regarding this should be directed to
Brian, since I am just a user and do not have the necessary insight.
- snip mailinglist transscript starts here
No, this is a maven core bug and will probably have to be fixed in 2.1, but
file an issue anyway.
-Original Message-
From: Michael Heß [mailto:m...@ordix.de]
Sent: Thursday, February 14, 2008 12:57 AM
To: Maven Users List
Subject: RE: dependency:unpack vs. eclipse:eclipse
Thanks Brian, for finding this out.
I have created a workaround as suggested. Only additional thing I had to
do, was to also bind the resources:resources to process-resources phase,
because otherwise the filtering occured before the dependency:unpack. It's
dirty, but at least it works now.
Have you already taken care of filing a bug? If not, I would take care of
this. The bug is in the dependency-plugin, right?
bye, Michael
Brian E. Fox schrieb:
I am able to reproduce this and it's an unfortunate bug in 2.0.x. The only
workaround I can suggest is to change the dependency plugin binding to a
later phase than is invoked by the eclipse plugin. According to [1] the
phase is generate-resources so you can bump it to process-resources.
[1]:
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
-Original Message-
From: Michael Heß [mailto:m...@ordix.de]
Sent: Wednesday, February 13, 2008 1:07 AM
To: Maven Users List
Subject: RE: dependency:unpack vs. eclipse:eclipse
Sure,
here you go, I hope it somehow survives the transfer to the list. If it's
completely garbled I can also send you the file directly as an attachment.
Furthermore I'd like to add the error I'm getting when binding the
dependendy-plugin unpack goal to a specific phase:
ERROR -
[INFO] One or more required plugin parameters are invalid/missing for
'dependency:unpack'
[0] Inside the definition for plugin 'maven-dependency-plugin' specify the
following:
configuration
...
artifactItemsVALUE/artifactItems
/configuration.
ERROR -
But as you can see in the pom below, I do have the wanted configuration
settings. Thanks for looking into this.
bye, Michael
---pom starts here---
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
parent
artifactIdabc/artifactId
groupIdde.customer/groupId
version1.0.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdde.customer.abc/groupId
artifactIdproduct-config/artifactId
packagingjar/packaging
version${parent.version}/version
nameproduct-config/name
dependencies
dependency
groupIdde.customer.abc.common/groupId
artifactIdabc-basis-config/artifactId
[jira] Updated: (ARCHETYPE-220) Unable to access remote catalogs on HTTPS protocol, even with redirection
[ http://jira.codehaus.org/browse/ARCHETYPE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic updated ARCHETYPE-220: --- Attachment: org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch One can already with 2.0-alpha-4 use archetypes from secured (https) repositories, not by specifying archetypeCatalog URL parameter, but by specifying archetypeRepository URL parameter. It is undocumented at the moment, but after 2.0-alpha-4 code analysis, I found that archetype plugin, if archetypeRepository parameter is provided, internally creates ArchetypeRepository instance with URL equal to archetypeRepository parameter value, and with id equal to %artifactId%-repo where %artifactId% is the value of archetypeArtifactId parameter. To provide credentials one has to adjust either global or user settings.xml file, by adding server definition with id equal to this calculated artifact repository id, and with appropriate credentials. Problem is that if one was to use N different artifacts (with different artifactId) from same repository, one would have to define N server definitions in settings.xml which is not nice at all. To fix this problem, I've extended archetype plugin with additional archetypeRepositoryId parameter which can be passed together with archetypeRepository (URL) parameter. If archetypeRepositoryId is configured together with archetypeRepository then plugin will construct and use ArchetypeRepository with id equal to archetypeRepositoryId parameter value. If only archetypeRepository is configured, plugin will work as before (so change is backwards compatible), setting ArchetypeRepository id to %artifactId%-repo. Attached is proposed patch with fix described above. No new unit nor integration tests are included - existing ones all pass. Documentation should be updated too with appropriate example. Unable to access remote catalogs on HTTPS protocol, even with redirection - Key: ARCHETYPE-220 URL: http://jira.codehaus.org/browse/ARCHETYPE-220 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-4 Environment: Any (Windows, Linux) Reporter: Josep F. Barranco Priority: Minor Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-220.patch I use that test: 1 - Create an archetype-catalog.xml and set it on your apache htdocs directory Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; works fine. 2 - Configure your apache to use certificates and allow SSL (port 443) to access to same archetype catalog file Executing mvn archetype:generate -DarchetypeCatalog=https://localhost; does not work. (it shows default catalog) It seems that stating with https://; does not match with allowed parameter values (local, internal, file:, http:) 3 - Anyway, try to redirect your working HTTP access to HTTPS (configure rewrite engine on Apache) as workaround to access you SSL catalog. Executing mvn archetype:generate -DarchetypeCatalog=http://localhost; (same as step 1) IS NOT WORKING!!! (it shows empty catalog) There's no way to access an archetype-catalog.xml located on a SSL url ? -- 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-4438) [regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+
[regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+ - Key: MNG-4438 URL: http://jira.codehaus.org/browse/MNG-4438 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 3.0-alpha-3 Reporter: Brett Porter I found the output quite useful in determining the source of a binary being used, particularly for snapshots but also when building releases from source: Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000) However, 3.0-alpha-3 does not report the part after the version -- 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-4438) [regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+
[ http://jira.codehaus.org/browse/MNG-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198088#action_198088 ] Olivier Lamy commented on MNG-4438: --- Difficult to have this when building from sources tarball. Because it's based on the svn metadata and sources tarball doesn't contains svn metadata. Have a look at the profile svn-buildnumber in maven-core module. [regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+ - Key: MNG-4438 URL: http://jira.codehaus.org/browse/MNG-4438 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 3.0-alpha-3 Reporter: Brett Porter I found the output quite useful in determining the source of a binary being used, particularly for snapshots but also when building releases from source: Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000) However, 3.0-alpha-3 does not report the part after the version -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4438) [regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+
[ http://jira.codehaus.org/browse/MNG-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4438. - Resolution: Cannot Reproduce Assignee: Brett Porter ah, sorry for the noise. I looked in the wrong pom. 2.1.0 added the timestamp and not the revision when building outside SVN - but I only cared about the one built from SVN which I can see is still there. [regression] CLI no longer reports the build revision and timestamp shown in Maven 2.1.0+ - Key: MNG-4438 URL: http://jira.codehaus.org/browse/MNG-4438 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 3.0-alpha-3 Reporter: Brett Porter Assignee: Brett Porter I found the output quite useful in determining the source of a binary being used, particularly for snapshots but also when building releases from source: Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000) However, 3.0-alpha-3 does not report the part after the version -- 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-4439) apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module
apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module --- Key: MNG-4439 URL: http://jira.codehaus.org/browse/MNG-4439 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.0-alpha-3 Reporter: Brett Porter I noticed these in the 3.0-alpha-3 repository. As the module contains no source and no longer shades, there is no reason to produce these JARs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4439) apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module
[ http://jira.codehaus.org/browse/MNG-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4439: -- Attachment: MNG-4439.diff here is the change I would commit at present. However, I would say that it is better to move GlobalSettingsTest to be an integration test instead (actually testing the Maven installation, and skipping when in the embedder). This would reduce the change to just being packagingpom/packaging. Any objections to such a change? apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module --- Key: MNG-4439 URL: http://jira.codehaus.org/browse/MNG-4439 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.0-alpha-3 Reporter: Brett Porter Attachments: MNG-4439.diff I noticed these in the 3.0-alpha-3 repository. As the module contains no source and no longer shades, there is no reason to produce these JARs. -- 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: (MCOMPILER-110) Out of Memory Error during Maven Compilation
Out of Memory Error during Maven Compilation Key: MCOMPILER-110 URL: http://jira.codehaus.org/browse/MCOMPILER-110 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: AIX 5.3 ,JDK 1.4 , Maven 2.0.4 Reporter: NITIN Priority: Critical In our project we use Maven to do build We use command mvn -Dmaven.test.skip=false -Dqm.skip=false clean install We have set the max MAVEN_OPTS=-Xmx2000M in Maven_Home/maven/maven-2.0.4/bin/mvn file Still we get This error Date: Thu Nov 12 16:38:38 IST 2009 VBuild Started.. Thu Nov 12 16:38:38 IST 2009 Pom Updation . Dope Upload Compilation starts Compilation outputs will be redirected to Log12112009.out file JVMDBG004: calloc failed to allocate an array of 1 elements at 32768 bytes each, time: Thu Nov 12 16:54:55 2009 JVMDBG001: malloc failed to allocate 100016 bytes, time: Thu Nov 12 16:54:55 2009 **Out of memory, aborting** *** panic: JVMCL052: Cannot allocate memory in initializeHeap for heap segment JVMDG217: Dump Handler is Processing Signal 6 - Please Wait. JVMDBG001: malloc failed to allocate 2621440 bytes, time: Thu Nov 12 16:54:55 2009 JVMDBG001: malloc failed to allocate 2097152 bytes, time: Thu Nov 12 16:54:55 2009 JVMDBG001: malloc failed to allocate 1572864 bytes, time: Thu Nov 12 16:54:55 2009 JVMDBG001: malloc failed to allocate 1048576 bytes, time: Thu Nov 12 16:54:55 2009 JVMDBG001: malloc failed to allocate 524288 bytes, time: Thu Nov 12 16:54:55 2009 JVMDG305: Java core not written, unable to allocate memory for print buffer. JVMDG215: Dump Handler has Processed Error Signal 6. runVBuild.sh[37]: 2715768 IOT/Abort trap(coredump) Thu Nov 12 16:55:43 IST 2009 Compilation Done: false Ear Creation Task FAILED Bcz of Compilation Error Script Execution Done -- 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-4440) error message should clearly indicate the module that failed, and how to continue
error message should clearly indicate the module that failed, and how to continue - Key: MNG-4440 URL: http://jira.codehaus.org/browse/MNG-4440 Project: Maven 2 Issue Type: Improvement Components: Errors Affects Versions: 3.0-alpha-3 Reporter: Brett Porter though the error reporting pushes most of the error information to a single location at the end, you need to scroll back and check which module was building at the time (or which is marked FAILED in the long list of modules) to determine where you were up to. It would be helpful to list the module name (and perhaps goal) in the error contextually. It might also be worth adding the comment: After correcting this problem, you can resume the build with the command 'mvn /goals used/ -rf /module name/' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3401) Plugin parameters must be specified outside an execution block when they are invoked from the command line
[
http://jira.codehaus.org/browse/MNG-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198106#action_198106
]
Brian Fox commented on MNG-3401:
Your best bet is to open a new issue with your improvement idea. The problem as
written should be fixed now, but your idea is logical.
Plugin parameters must be specified outside an execution block when they are
invoked from the command line
--
Key: MNG-3401
URL: http://jira.codehaus.org/browse/MNG-3401
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.8
Reporter: Michael Heß
Assignee: John Casey
Fix For: 2.2.0, 3.0-alpha-3
Attachments: maven-core-MojoExectution-r712253.patch
According to Brian E. Fox there is something wrong with the Maven Core which
causes the maven-dependency-plugin to fail if it is called by the
mvn-eclipse-plugin. I can't tell any specifics since Brian looked into it,
and only provided me a workaround. I'm pasting our dialog from the mailing
list in here. Any further questions regarding this should be directed to
Brian, since I am just a user and do not have the necessary insight.
- snip mailinglist transscript starts here
No, this is a maven core bug and will probably have to be fixed in 2.1, but
file an issue anyway.
-Original Message-
From: Michael Heß [mailto:m...@ordix.de]
Sent: Thursday, February 14, 2008 12:57 AM
To: Maven Users List
Subject: RE: dependency:unpack vs. eclipse:eclipse
Thanks Brian, for finding this out.
I have created a workaround as suggested. Only additional thing I had to
do, was to also bind the resources:resources to process-resources phase,
because otherwise the filtering occured before the dependency:unpack. It's
dirty, but at least it works now.
Have you already taken care of filing a bug? If not, I would take care of
this. The bug is in the dependency-plugin, right?
bye, Michael
Brian E. Fox schrieb:
I am able to reproduce this and it's an unfortunate bug in 2.0.x. The only
workaround I can suggest is to change the dependency plugin binding to a
later phase than is invoked by the eclipse plugin. According to [1] the
phase is generate-resources so you can bump it to process-resources.
[1]:
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
-Original Message-
From: Michael Heß [mailto:m...@ordix.de]
Sent: Wednesday, February 13, 2008 1:07 AM
To: Maven Users List
Subject: RE: dependency:unpack vs. eclipse:eclipse
Sure,
here you go, I hope it somehow survives the transfer to the list. If it's
completely garbled I can also send you the file directly as an attachment.
Furthermore I'd like to add the error I'm getting when binding the
dependendy-plugin unpack goal to a specific phase:
ERROR -
[INFO] One or more required plugin parameters are invalid/missing for
'dependency:unpack'
[0] Inside the definition for plugin 'maven-dependency-plugin' specify the
following:
configuration
...
artifactItemsVALUE/artifactItems
/configuration.
ERROR -
But as you can see in the pom below, I do have the wanted configuration
settings. Thanks for looking into this.
bye, Michael
---pom starts here---
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
parent
artifactIdabc/artifactId
groupIdde.customer/groupId
version1.0.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdde.customer.abc/groupId
artifactIdproduct-config/artifactId
packagingjar/packaging
version${parent.version}/version
nameproduct-config/name
dependencies
dependency
groupIdde.customer.abc.common/groupId
artifactIdabc-basis-config/artifactId
version${abc.common.version}/version
scopecompile/scope
/dependency
/dependencies
profiles
profile
idlocal/id
activation
property
namelocal/name
/property
/activation
build /
properties
maven.test.skiptrue/maven.test.skip
mvn.filter.file
[jira] Commented: (MRELEASE-442) scm tag phase ignores custom message (need to use scm 1.3)
[ http://jira.codehaus.org/browse/MRELEASE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198117#action_198117 ] Julien HENRY commented on MRELEASE-442: --- Is it possible to release a new version of release plugin? Maven 3 seems to use 2.0-beta-9 as a default and this bug block the release process (I have to force version of release plugin to 2.0-beta-8) Thanks scm tag phase ignores custom message (need to use scm 1.3) -- Key: MRELEASE-442 URL: http://jira.codehaus.org/browse/MRELEASE-442 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.0-beta-9 Reporter: Stas Garifulin Assignee: Olivier Lamy Fix For: 2.0-beta-10 [http://jira.codehaus.org/browse/SCM-460] -- 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: (MCHECKSTYLE-125) Update to maven-reporting-impl-2.0.4.3
[ http://jira.codehaus.org/browse/MCHECKSTYLE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson closed MCHECKSTYLE-125. --- Resolution: Fixed Fixed in r835415. Update to maven-reporting-impl-2.0.4.3 -- Key: MCHECKSTYLE-125 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-125 Project: Maven 2.x Checkstyle Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Dennis Lundberg Assignee: Mark Hobson Fix For: 2.4 -- 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: (MCHECKSTYLE-105) Update to Checkstyle 5.0
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson closed MCHECKSTYLE-105. --- Resolution: Fixed Assignee: Mark Hobson Patch has been committed a while back and no problems reported since, so closing this issue. Update to Checkstyle 5.0 Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Felix Röthenbacher Assignee: Mark Hobson Fix For: 2.4 Attachments: patch.diff, update-to-5.0-812221.patch, update-to-5.0.patch, update-to-5.0beta2.patch Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- 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-449) Permissions on directories in a zipped archive incorrect
Permissions on directories in a zipped archive incorrect
Key: MASSEMBLY-449
URL: http://jira.codehaus.org/browse/MASSEMBLY-449
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-4
Reporter: James Kavanagh
Using the following assembly plugin:
{code:xml}
assembly
idtarget-packaged/id
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
moduleSets
moduleSet
includes
include*:core-env/include
/includes
binaries
attachmentClassifierenv/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:data-bridge/include
/includes
binaries
attachmentClassifiertarget/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:web/include
/includes
binaries
attachmentClassifierweb/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
/moduleSets
/assembly
{code}
When unzipping the result on a Linux host all the directory permissions have
been set to 777.
If I revert the plugin version to 2.2-beta-3 the issue goes away.
--
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: (MCHECKSTYLE-123) remove use of Serviceable (to be compatible wih maven 3.x)
[ http://jira.codehaus.org/browse/MCHECKSTYLE-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCHECKSTYLE-123: - Fix Version/s: (was: 2.4) 2.5 remove use of Serviceable (to be compatible wih maven 3.x) -- Key: MCHECKSTYLE-123 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-123 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Olivier Lamy Assignee: Olivier Lamy Priority: Critical Fix For: 2.5 the current version use interface Serviceable which won't work with maven 3.x. -- 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: (MECLIPSE-618) MANIFEST files generated by plugin are empty when they shouldnt
MANIFEST files generated by plugin are empty when they shouldnt --- Key: MECLIPSE-618 URL: http://jira.codehaus.org/browse/MECLIPSE-618 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.7 Environment: Any Reporter: Andre Doherty MANIFEST.MF files generated by the plugin are empty, therefore a correct deployment of an EAR project on an application server such as JBoss will fail with classloading issues. After a close look at the source code the problem comes from the fact that the dependencies resolving is disabled in the mojo, in order to not feed the .classpath, but having this side-effect. I suggest resolving dependencies in any case, and adding a property instead to filter dependencies in the .classpath generation. therefore : 1: add boolean property to EclipsePlugin : ignoreDeps 2: add boolean property to EclipseWriterConfig : ignoreDeps 3: in M2EclipseMojosetupExtra() : - //setResolveDependencies( false ); - setIgnoreDeps(true); 4: in EclipsePlugincreateEclipseWriterConfig(IdeDependency[]) : - call config.setIgnoreDeps(isIgnoreDeps()); 5: in EclipseClasspathWriterwrite() : - test against if (!config.isIgnoreDeps()) around lines 348 to 387 in order to skip writing of M2_REPO... dependencies Tested here, works like a charm -- 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: (ARCHETYPE-249) Add Apache Camel WAR archetype to internal catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198149#action_198149 ] Jonathan Anstey commented on ARCHETYPE-249: --- Any chance someone could apply this for me? Add Apache Camel WAR archetype to internal catalog -- Key: ARCHETYPE-249 URL: http://jira.codehaus.org/browse/ARCHETYPE-249 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: Jonathan Anstey Attachments: camel-archetype-war.patch Could someone apply this patch to add camel-archetype-war to the internal catalog? I'd like to get it in before the next release of the archetype plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198158#action_198158 ] Robert Simmons Jr. commented on MNG-624: I would like to reiterate others points on this issue. Personally I think relativePath should be enough to specify a parent POM. I see many maven developers proselytizing about how projects should be created and how POMs should be maintained but the fact is that in an organization changing the entire process to suit Maven is not possible. The second fact is that one size or process doesnt fit all with projects. I can think of a dozen examples where projects must stay in locked version with their parent. For example, a project consisting of a data layer, web layer, web service interface and EJBs will all form one cohesive release as a war. They must stay together in versions but they shouldn't have to be updating all 6 files (projects and parent pom) each time there is a version change. They should be able to state a single version number in a parent and use that. The thinking behind different versions for each project and super pom being separate is only one use case. That use case assumes all projects are more or less independent builds. This isnt the case with other projects. Using relativePath to specify take version from the parent pom is the best of both worlds as it allows both models and takes nothing away from anyone. That seems to be a much more practical way to go then shouting from the rooftops NO YOU ARE DOING IT ALL WRONG, THROW OUT YOUR MILLIONS IN INVESTMENT AND REARCHITECT YOUR PROJECT OUR WAY. By shouting that, you are simply telling my boss nah we will stick with ant and that is counterproductive. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 2.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198163#action_198163 ] Brian Fox commented on MNG-624: --- No one is disagreeing that this wouldn't be useful. The fact is we have Maven 2 right now and in my experience, it turns out not to be a huge problem in a maven normalized project. Therefore, some guidance can be given how to minimize the impact. If that's proselytizing, so be it. Anyway, we ARE working on this, but it's not as simple as it appears at first glance. The poms must be interpolated before they are deployed to a repository. This is contingent upon knowing exactly where on disk to find the parent pom. The relativePath currently only points to the root of the parent project. Since that parent project also needed to be interpolated, we need to discover the interpolated version of it in that folder. Most of the time this would be /target but not if someone used the build.outputDirectory to change to something else. Finding this location in a manner that respects people's ability to customize their layout from maven normal and at the same time being FAST is not easy to do in M2. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 2.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198170#action_198170 ] Paul Benedict commented on MNG-624: --- I've seen POMs deployed with relativePath in usage. Is it a good idea to continue supporting that since it's no longer on disk? automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 2.x Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4361) [regression] command line option -update-snapshots does not work
[
http://jira.codehaus.org/browse/MNG-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4361:
---
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-4
Clarification: While the above commit is present in alpha-3, it only fixes half
of the problem, namely the updates of JARs. The complete fix is only available
in alpha-4.
[regression] command line option -update-snapshots does not work
--
Key: MNG-4361
URL: http://jira.codehaus.org/browse/MNG-4361
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0-alpha-3
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0-alpha-4
mvn package -U is not checking for updated snapshots on trunk and the debug
log reveals
{noformat]
[DEBUG] Skipping metadata update of snapshot ...
{noformat]
--
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: (MRESOURCES-104) while filtering resources the token replacement stops at the character @
[
http://jira.codehaus.org/browse/MRESOURCES-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198175#action_198175
]
ian pojman commented on MRESOURCES-104:
---
this isn't minor.. i just wasted 2 hours because of this
while filtering resources the token replacement stops at the character @
-
Key: MRESOURCES-104
URL: http://jira.codehaus.org/browse/MRESOURCES-104
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.4
Environment: Windows XP, Java 1.6.0_16
Reporter: Thomas Fahrmeyer
Priority: Minor
Fix For: 2.5
Create a simple file hello.txt under src/main/resources with following
content:
This property ${testProperty} was replaced
but the one behind a @ will not be processed, as you
see: ${testProperty}. You shouldn't see a property reference.
define a build section in your pom.xml like this
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
includes
include**/*.txt/include
/includes
/resource
resource
directorysrc/main/resources/directory
filteringfalse/filtering
excludes
exclude**/*.txt/exclude
/excludes
/resource
/resources
Run the command:
mvn process-resources -DtestProperty=IwasReplaced
this produces the output
This property IwasReplaced was replaced
but the one behind a @ will not be processed, as you
see: ${testProperty}. You shouldn't see a property reference.
As you see, the second property reference was not resolved. The replacement
just stops after the @ character.
--
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-4439) apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module
[ http://jira.codehaus.org/browse/MNG-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198182#action_198182 ] Benjamin Bentmann commented on MNG-4439: Well, it doesn't take a dedicated IT: If the global settings are broken, Maven won't start so quite the entire suite will tell. I specially created this UT to not require an IT to find validation errors. So unless there are other technical concerns, I would like to keep this UT around. apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module --- Key: MNG-4439 URL: http://jira.codehaus.org/browse/MNG-4439 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.0-alpha-3 Reporter: Brett Porter Attachments: MNG-4439.diff I noticed these in the 3.0-alpha-3 repository. As the module contains no source and no longer shades, there is no reason to produce these JARs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4439) apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module
[ http://jira.codehaus.org/browse/MNG-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4439. - Resolution: Fixed Fix Version/s: 3.0-alpha-4 Assignee: Brett Porter apache-maven project should not deploy a source JAR or JAR, as it is only a distribution module --- Key: MNG-4439 URL: http://jira.codehaus.org/browse/MNG-4439 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.0-alpha-3 Reporter: Brett Porter Assignee: Brett Porter Fix For: 3.0-alpha-4 Attachments: MNG-4439.diff I noticed these in the 3.0-alpha-3 repository. As the module contains no source and no longer shades, there is no reason to produce these JARs. -- 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-2660) Upload of project j-oto from code.google.com
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=198193#action_198193 ] Eduardo Pereda commented on MAVENUPLOAD-2660: - Hi, any news about this? Please, let me know if there is anything else I should do from my side. Edu Upload of project j-oto from code.google.com Key: MAVENUPLOAD-2660 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2660 Project: Maven Upload Requests Issue Type: Wish Reporter: Eduardo Pereda Attachments: uploadToMavenRepo.csv Hi, This is the first time I am doing an upload to maven central repo. I followed the guide here (http://maven.apache.org/guides/mini/guide-central-repository-upload.html) I saw on a link (https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv) that several projects in code.google.com deploy their artifacts directly from the subversion repository. I am imitating them (or at least trying) since I don't have any rsync nor rsync_ssh server for me. The attached csv file has these two lines: com.google.code.joto,http://j-oto.googlecode.com/svn/repos/release-repository/,svn,Eduardo Pereda,epe...@gmail.com,, com.google.code.joto,/home/maven/repository-staging/to-ibiblio/maven-svn,svn,Eduardo Pereda,epe...@gmail.com,,http://j-oto.googlecode.com/svn/repos/release-repository/; I guess only one of them is valid, but I am not sure. I apologize for the inconvenient. Regards, Edu PS: I am one of the owners of j-oto project (http://code.google.com/p/j-oto/people/list). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
