[jira] Created: (MEJB-55) on dependency snapshot archive , the MANIFEST.MF different maven-ear-plugin's created MANIFEST.MF
on dependency snapshot archive , the MANIFEST.MF different maven-ear-plugin's created MANIFEST.MF - Key: MEJB-55 URL: https://jira.codehaus.org/browse/MEJB-55 Project: Maven 2.x EJB Plugin Issue Type: Bug Affects Versions: 2.3 Environment: win7 x64 maven3.0.2 sun-jdk 1.6_26b maven-ejb-plugin-2.3 maven-ear-plugin-2.6 Reporter: siyuan zen ear's MANIFEST.MF --- Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: Asus Build-Jdk: 1.6.0_26 Class-Path: edspEJB.jar nbsmEJB.jar edsp.war nbsm.war nbsmEJBClient-1. 0.0.jar edspEJBClient-1.0.0.jar edsp-core-3.0.0-SNAPSHOT.jar ejb's MANIFEST.MF --- Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: Asus Build-Jdk: 1.6.0_26 Class-Path: edspEJBClient-1.0.0.jar edspEJB-1.0.0.jar nbsmEJBClient-1. 0.0.jar edsp-core-3.0.0-2030.095532-29.jar -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-705) Use Aether (or the shared exposed interface) to ensure correct .classpath ordering of dependencies.
[ https://jira.codehaus.org/browse/MECLIPSE-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrie Treloar updated MECLIPSE-705: Fix Version/s: 2.10 > Use Aether (or the shared exposed interface) to ensure correct .classpath > ordering of dependencies. > --- > > Key: MECLIPSE-705 > URL: https://jira.codehaus.org/browse/MECLIPSE-705 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.9 >Reporter: Barrie Treloar >Priority: Critical > Fix For: 2.10 > > > The eclipse plugin works out the classpath ordering itself. > It should be re-using whatever is done internally by Maven. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-642) "String index out of range" during eclipse:eclipse for a project that works with 2.7
[
https://jira.codehaus.org/browse/MECLIPSE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar closed MECLIPSE-642.
---
Resolution: Fixed
> "String index out of range" during eclipse:eclipse for a project that works
> with 2.7
>
>
> Key: MECLIPSE-642
> URL: https://jira.codehaus.org/browse/MECLIPSE-642
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.8
> Environment: Windows XP, Maven 2.2.1, Maven 2.x Eclipse Plugin v2.8
>Reporter: Matthew McCullough
>Assignee: Barrie Treloar
> Attachments: Eclipse Plugin 2.8 Out Of Bounds Error.txt
>
>
> We tried to upgrade to using v2.8 of the plugin, but a regression stops us
> dead in our tracks. Reverting to 2.7 allows us to continue for now.
> When running eclipse:eclipse on our projects, we get an occasional
> "String index out of range: -6"
> The stack trace indicates this is on line 111 of:
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.8/src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseSettingsWriter.java?view=markup
> I see that those lines are:
> 109{
> 110 Resource resource = (Resource) it.next();
> 111 String relativePath = resource.getDirectory().substring(
> basedir.length() ).replace( '\\', '/' );
> 112 coreSettings.put( PROP_JDT_CORE_COMPILER_ENCODING +
> relativePath, encoding );
> 113}
> I've attached a snippet of the -X output (about the last 50 lines)...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-642) "String index out of range" during eclipse:eclipse for a project that works with 2.7
[
https://jira.codehaus.org/browse/MECLIPSE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar updated MECLIPSE-642:
Fix Version/s: 2.9
> "String index out of range" during eclipse:eclipse for a project that works
> with 2.7
>
>
> Key: MECLIPSE-642
> URL: https://jira.codehaus.org/browse/MECLIPSE-642
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Workspace settings
>Affects Versions: 2.8
> Environment: Windows XP, Maven 2.2.1, Maven 2.x Eclipse Plugin v2.8
>Reporter: Matthew McCullough
>Assignee: Barrie Treloar
> Fix For: 2.9
>
> Attachments: Eclipse Plugin 2.8 Out Of Bounds Error.txt
>
>
> We tried to upgrade to using v2.8 of the plugin, but a regression stops us
> dead in our tracks. Reverting to 2.7 allows us to continue for now.
> When running eclipse:eclipse on our projects, we get an occasional
> "String index out of range: -6"
> The stack trace indicates this is on line 111 of:
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-eclipse-plugin-2.8/src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseSettingsWriter.java?view=markup
> I see that those lines are:
> 109{
> 110 Resource resource = (Resource) it.next();
> 111 String relativePath = resource.getDirectory().substring(
> basedir.length() ).replace( '\\', '/' );
> 112 coreSettings.put( PROP_JDT_CORE_COMPILER_ENCODING +
> relativePath, encoding );
> 113}
> I've attached a snippet of the -X output (about the last 50 lines)...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-167) Unconfigured checkstyle plugin duplicates entries in aggregated report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCHECKSTYLE-167.
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Olivier Lamy
fixed with MCHECKSTYLE-168
> Unconfigured checkstyle plugin duplicates entries in aggregated report
> --
>
> Key: MCHECKSTYLE-167
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-167
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: {{{
> mvn --version
> Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home:
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
> }}}
>Reporter: Mirko Friedenhagen
>Assignee: Olivier Lamy
> Fix For: 2.9
>
> Attachments: checkstyle-report-duplicates-errors-in-aggregate.zip
>
>
> Using a very simple single module project, the aggregated report is created
> by default and reports an incorrect number of violations, it just doubles the
> numbers. I checked out
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-checkstyle-plugin-2.8
> and modified the integration test project {{checkstyle-report}} a little bit:
> * I deleted the {{reportSets}} configuration from the {{pom.xml}}.
> * I modified {{src/main/java/org/MyClass.java}} to actually have errors.
> The build log looks like this:
> {code}
> [mirko@borg checkstyle-report]$ mvn clean site
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building check-pass 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ check-pass ---
> [INFO] Deleting
> /Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/target
> [INFO]
> [INFO] --- maven-site-plugin:3.0:site (default-site) @ check-pass ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.8
> [INFO] Relativizing decoration links with respect to project URL:
> http://maven.apache.org/
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
> [INFO]
> [INFO] There are 2 checkstyle errors.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
> [INFO]
> [INFO] There are 4 checkstyle errors.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 4.847s
> [INFO] Finished at: Tue Nov 29 21:13:40 CET 2011
> [INFO] Final Memory: 12M/81M
> [INFO]
>
> {code}
> {{target/checkstyle-result.xml}} looks like this and reports the same errors
> twice:
> {code}
>
>
> name="/Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/src/main/java/org/MyClass.java">
> source="com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck"/>
> source="com.puppycrawl.tools.checkstyle.checks.FinalParametersCheck"/>
>
> name="/Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/src/main/java/org/MyClass.java">
> source="com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck"/>
> source="com.puppycrawl.tools.checkstyle.checks.FinalParametersCheck"/>
>
>
> {code}
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated and
> {{checkstyle-aggregate}} reports the same errors twice. I attach the patched
> project which includes a check in {{verify.groovy}} to assert that only one
> {{file}} entry is present in the created {{target/checkstyle-result.xml}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-649) Enhance SCM changelog model to hold more data about changes
[ https://jira.codehaus.org/browse/SCM-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-649: - Fix Version/s: 1.7 Assignee: Olivier Lamy > Enhance SCM changelog model to hold more data about changes > --- > > Key: SCM-649 > URL: https://jira.codehaus.org/browse/SCM-649 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-git, > maven-scm-provider-svn >Affects Versions: 1.6 >Reporter: Petr Kozelka >Assignee: Olivier Lamy > Fix For: 1.7 > > Attachments: scm-richmodel-git.patch, scm-richmodel-model.patch, > scm-richmodel-svn.patch > > > Hello, > I would like to get more information from SCM changelog command, and attached > patches contain my proposal doing some part of this. > There are separate patches for model and for GIT and SVN implementations, I > hope it makes them easier to review. > New functionality is mostly covered with tests. > +Summary of proposed enhancements:+ > ChangeFile.java: > - added: ScmFileStatus *action* > - added: String *originalName* > - added: String *originalRevision* > - they all included in toString() > ScmFileStatus.java: > - added: *RENAMED* = new ScmFileStatus( "renamed" ); > - added: *COPIED* = new ScmFileStatus( "copied" ); > ChangeSet.java: > - added: String *parentRevision* > - added: Set *mergedRevisions* > - both added to toString() > - both added to toXML() + those from ChangeFile - all values stored in > elements not attributes just like the others > GIT implementation notes (GitChangeLogConsumer): > - besides parsing the "whatchanged" command, now the consumer can handle also > many options of the "log" command and harvest most of its provided info. > In particular, the output of "git log --format=raw -C --raw --no-abbrev" > can be parsed. > - there is a potential to simply enable parsing for some more information > like committer, committerDate and treeHash, which I didn't yet (as GIT-only > stuff it may require separate discussion) > SVN implementation notes (SvnChangeLogConsumer): > - svn action "A" (Add) translates to "added" or "copied" depending of > presence of originalFile > - svn action "M" (Modified) always translates to "modified" no matter if > there is an originalFile; _any opinions about this ?_ > - svn action "R" (Replace) translates to "updated" which IMHO has > sufficiently close semantic -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINDEXER-46) bad url in jira description
[ https://jira.codehaus.org/browse/MINDEXER-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINDEXER-46. Resolution: Fixed Assignee: Olivier Lamy thanks for report. > bad url in jira description > --- > > Key: MINDEXER-46 > URL: https://jira.codehaus.org/browse/MINDEXER-46 > Project: Maven Indexer > Issue Type: Bug >Reporter: Petr Kozelka >Assignee: Olivier Lamy >Priority: Trivial > > current url shown at http://jira.codehaus.org/browse/MINDEXER is: > http://maven.apache.org/indexer/ (results in Page Not Found) > It should be http://maven.apache.org/maven-indexer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-168) checkstyle-aggregate give a wrong file count
[ https://jira.codehaus.org/browse/MCHECKSTYLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCHECKSTYLE-168. Resolution: Fixed Fix Version/s: 2.9 Assignee: Olivier Lamy fixed r1209263 Thanks! > checkstyle-aggregate give a wrong file count > > > Key: MCHECKSTYLE-168 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-168 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Antonio Petrelli >Assignee: Olivier Lamy > Fix For: 2.9 > > Attachments: checkstyle-multisource-patch.diff > > > In a multi-source-directory environment, currently verifiable only with > multi-module projects, the total file count is wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-361) avoid writing temporary file in putFromStream from wagon-http
[ https://jira.codehaus.org/browse/WAGON-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-361. -- Resolution: Fixed fixed r1209251 > avoid writing temporary file in putFromStream from wagon-http > - > > Key: WAGON-361 > URL: https://jira.codehaus.org/browse/WAGON-361 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http >Affects Versions: 2.0, 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-361) avoid writing temporary file in putFromStream from wagon-http
[ https://jira.codehaus.org/browse/WAGON-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-361: --- Fix Version/s: 2.2 > avoid writing temporary file in putFromStream from wagon-http > - > > Key: WAGON-361 > URL: https://jira.codehaus.org/browse/WAGON-361 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http >Affects Versions: 2.0, 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-361) avoid writing temporary file in putFromStream from wagon-http
avoid writing temporary file in putFromStream from wagon-http - Key: WAGON-361 URL: https://jira.codehaus.org/browse/WAGON-361 Project: Maven Wagon Issue Type: Improvement Components: wagon-http Affects Versions: 2.1, 2.0 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSKINS-15) With sidebar and no topbar external links should be rendered as menu
With sidebar and no topbar external links should be rendered as menu
Key: MSKINS-15
URL: https://jira.codehaus.org/browse/MSKINS-15
Project: Maven Skins
Issue Type: Improvement
Components: Fluido Skin
Affects Versions: fluido-1.0, fluido-1.1
Environment: {code}
mvn --version
Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
{code}
Reporter: Mirko Friedenhagen
Attachments: enable-external-links-for-sidebar-when-no-topbar.patch
External links specified in {{//project/body/links}} of the {{site.xml}} are
only rendered as dropdown menu when the topbar is enabled.
When only the sidebar is enabled these links are missing completely. I have
attached a patch against revision 1206640 of
http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin, which will
render these links as additional menu in the sidebar when
{{topbarEnabled==false}} and {{sidebarEnabled==true}}.
Example output might be found at http://mojo.codehaus.org/fluido-preview/ for
the ckjm-maven-plugin.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-395) Module dependencies not included
[ https://jira.codehaus.org/browse/MASSEMBLY-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284693#comment-284693 ] Jaan Vajakas commented on MASSEMBLY-395: The problem is still there in assembly plugin 2.2.1 with Maven version 3.0.3. > Module dependencies not included > - > > Key: MASSEMBLY-395 > URL: https://jira.codehaus.org/browse/MASSEMBLY-395 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-3 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_09 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Jaan Vajakas > Attachments: my-app.assembly-plugin-2.2.zip, my-app.zip > > > Maven assebly plugin 2.2-beta-3 does not include module dependencies, even > when the explicit true is used in > assembly descriptor. Maven assebly plugin 2.2-beta-2 did not have this issue. > See the attached project: running mvn package for the parent project my-app > creates a ZIP that contains only my-app-module1-1.0-SNAPSHOT.jar. If assembly > plugin 2.2-beta-2 is used (i.e. if one replaces 2.2-beta-3 with 2.2-beta-2 in > pom.xml of my-app) then the ZIP also contains my-app-module2-1.0-SNAPSHOT.jar > and junit-3.8.1.jar. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-269) war fails to build while using m2e in workspace resolution mode
war fails to build while using m2e in workspace resolution mode --- Key: MWAR-269 URL: https://jira.codehaus.org/browse/MWAR-269 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Chris Gamache Attachments: maven-war-plugin.patch This is my first time for an issue/patch submission. Apologies if I'm doing it wrong When building in Eclipse using m2e in workspace resolution mode, the maven-war-plugin is not prepared for a "dependency" which isn't an assembly but is instead a folder containing the compiled classes from within the local workspace. I propose that if the incoming dependency happens to be a directory that it get packaged up and copied to the destination instead of blowing up with an exception. See attached patch for your review... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-146) Installation Instructions don't work for Windows
[ https://jira.codehaus.org/browse/MNGSITE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MNGSITE-146. --- Resolution: Not A Bug You seem to have downloaded the source distribution. Try with the binary distribution instead. > Installation Instructions don't work for Windows > > > Key: MNGSITE-146 > URL: https://jira.codehaus.org/browse/MNGSITE-146 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows 7 >Reporter: Jim Goodwin >Priority: Minor > > Step 3 of the Installation Instructions on this page > http://maven.apache.org/download.html say to add %M2_HOME%\bin directory to > the PATH environment variable. There is no %M2_HOME%\bin directory. For > example, when I extracted the downloaded archive, I extracted it to > c:\apache-maven-3.0.3. That is supposed to be path for M2_HOME, however there > is no \bin directory under that path. There is a \bin directory under > c:\apache-maven-3.0.3\apache-maven. > The end result is that running the mvn command results in "'mvn' is not > recognized as an internal or external command, operable program or batch > file." > Here is the content of my M2_HOME environment variable: > C:\apache-maven-3.0.3>echo %M2_HOME% > C:\apache-maven-3.0.3 > Here is the content of my PATH environment variable: > C:\apache-maven-3.0.3>echo %PATH% > C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files\IntelWiFi\bin\;C:\Program Files\Common > Files\Intel\WirelessCommon\;C:\Program > Files\TortoiseSVN\bin;C:\apache-ant-1.8.2\bin;C:\IBM\SDP\runtimes\base_v7\java\bin;C:\apache-maven-3.0.3\bin > Following step 7 of the instructions results in: > C:\apache-maven-3.0.3>mvn --version > 'mvn' is not recognized as an internal or external command, operable program > or batch file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-586) Add global/ubiquitous excludes to assembly and component descriptors
Add global/ubiquitous excludes to assembly and component descriptors Key: MASSEMBLY-586 URL: https://jira.codehaus.org/browse/MASSEMBLY-586 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Reporter: Lars Corneliussen Especially when composing assembly descriptors from multiple components, it would be good to be able to define excludes, that have global effect on all descriptors. The files and folders excluded globally "do just no exist". For example, if I want to be sure, "**/target/**" is ignored, I want to make sure that this is valid for ALL defined files and filesets. The easiest way would be to to inject those into all fileSets after (while respecting basedirs). If you like the idea, I'm happy to provide a patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-585) Add support for componentDescriptorRefs in Assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284676#comment-284676
]
Lars Corneliussen commented on MASSEMBLY-585:
-
Looking at {{DefaultAssemblyReader.java}} it seems to make more sense, just to
add {{locator.addStrategy( new PrefixedClasspathLocatorStrategy(
"/assemblies/components/" ) ); }} in {{mergeComponentsWithMainAssembly}}
*Please change the title accordingly*
> Add support for componentDescriptorRefs in Assemblies
> -
>
> Key: MASSEMBLY-585
> URL: https://jira.codehaus.org/browse/MASSEMBLY-585
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Reporter: Lars Corneliussen
>
> It would be great, if we could compose assembly descriptors from components
> provided by dependencies.
> This would help to apply favor composition over inheritance.
> {code:title=Assembly Descriptor}
> ..
>
>
> bin
>
> ..
> {code}
> ComponentDescriptors should override componentDescriptorRefs; hence be
> applied later.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-585) Add support for componentDescriptorRefs in Assemblies
Add support for componentDescriptorRefs in Assemblies
-
Key: MASSEMBLY-585
URL: https://jira.codehaus.org/browse/MASSEMBLY-585
Project: Maven 2.x Assembly Plugin
Issue Type: New Feature
Reporter: Lars Corneliussen
It would be great, if we could compose assembly descriptors from components
provided by dependencies.
This would help to apply favor composition over inheritance.
{code:title=Assembly Descriptor}
..
bin
..
{code}
ComponentDescriptors should override componentDescriptorRefs; hence be applied
later.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
[ https://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284667#comment-284667 ] Donatas Ciuksys commented on MASSEMBLY-211: --- Hellmut, please comment and vote for MASSEMBLY-584, since it seems to be exactly the same case you have described (or very similar). Cheers, Donatas > assembly plugin and jar plugin disagree about whether to use uniqueVersion > snapshot names > - > > Key: MASSEMBLY-211 > URL: https://jira.codehaus.org/browse/MASSEMBLY-211 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Max Bowsher >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-3 > > Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt > > > Background: Consider the following setup: > jar-plugin configured with addClasspath=true, writing list of dependency jar > file names into manifest of project jar. > assembly-plugin configured with a dependencySet pulling all dependencies into > a single directory. > Result: application is runnable with with "java -jar mainartifact.jar" > There has long been a problem (i.e. with assembly-plugin 2.1) that when > deployed snapshot jars were in use, the jar and assembly plugins would > disagree in whether the uniqueVersion name was used, and this is MNG-2456. > However, assembly-plugin 2.2-beta-1 has introduced further complications to > the situation by not using the lifecycle's default set of resolved artifacts, > but by running a manual resolution of its own. This has made the two plugins > disagree in more scenarios than before, and broke the workaround patch that I > posted in MNG-2456. > At the root of these problems is some very peculiar handling of the 'file', > 'baseVersion' and 'version' fields of Artifact objects, two notable instances > of which are the DefaultArtifact.isSnapshot method, which despite being an > accessor, actually changes the state of the object, and the > DefaultArtifactResolver.resolve method, which contains some rather bizarre > manipulation of the 'file' field (more detail may comments in MNG-2456). > An interim fix to this issue might involve workarounds in both the jar and > assembly plugins to get them to agree. A true fix probably also involves > fixing Maven core classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-211) assembly plugin and jar plugin disagree about whether to use uniqueVersion snapshot names
[ https://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284666#comment-284666 ] Donatas Ciuksys commented on MASSEMBLY-211: --- Related bug report: MASSEMBLY-584 > assembly plugin and jar plugin disagree about whether to use uniqueVersion > snapshot names > - > > Key: MASSEMBLY-211 > URL: https://jira.codehaus.org/browse/MASSEMBLY-211 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Max Bowsher >Assignee: John Casey >Priority: Blocker > Fix For: 2.2-beta-3 > > Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt > > > Background: Consider the following setup: > jar-plugin configured with addClasspath=true, writing list of dependency jar > file names into manifest of project jar. > assembly-plugin configured with a dependencySet pulling all dependencies into > a single directory. > Result: application is runnable with with "java -jar mainartifact.jar" > There has long been a problem (i.e. with assembly-plugin 2.1) that when > deployed snapshot jars were in use, the jar and assembly plugins would > disagree in whether the uniqueVersion name was used, and this is MNG-2456. > However, assembly-plugin 2.2-beta-1 has introduced further complications to > the situation by not using the lifecycle's default set of resolved artifacts, > but by running a manual resolution of its own. This has made the two plugins > disagree in more scenarios than before, and broke the workaround patch that I > posted in MNG-2456. > At the root of these problems is some very peculiar handling of the 'file', > 'baseVersion' and 'version' fields of Artifact objects, two notable instances > of which are the DefaultArtifact.isSnapshot method, which despite being an > accessor, actually changes the state of the object, and the > DefaultArtifactResolver.resolve method, which contains some rather bizarre > manipulation of the 'file' field (more detail may comments in MNG-2456). > An interim fix to this issue might involve workarounds in both the jar and > assembly plugins to get them to agree. A true fix probably also involves > fixing Maven core classes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGSITE-146) Installation Instructions don't work for Windows
[ https://jira.codehaus.org/browse/MNGSITE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284665#comment-284665 ] Jim Goodwin commented on MNGSITE-146: - Also, notice that there is no \bin directory under apache-maven-3.0.3, so setting %M2_HOME%\bin per the instructions won't work. > Installation Instructions don't work for Windows > > > Key: MNGSITE-146 > URL: https://jira.codehaus.org/browse/MNGSITE-146 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows 7 >Reporter: Jim Goodwin >Priority: Minor > > Step 3 of the Installation Instructions on this page > http://maven.apache.org/download.html say to add %M2_HOME%\bin directory to > the PATH environment variable. There is no %M2_HOME%\bin directory. For > example, when I extracted the downloaded archive, I extracted it to > c:\apache-maven-3.0.3. That is supposed to be path for M2_HOME, however there > is no \bin directory under that path. There is a \bin directory under > c:\apache-maven-3.0.3\apache-maven. > The end result is that running the mvn command results in "'mvn' is not > recognized as an internal or external command, operable program or batch > file." > Here is the content of my M2_HOME environment variable: > C:\apache-maven-3.0.3>echo %M2_HOME% > C:\apache-maven-3.0.3 > Here is the content of my PATH environment variable: > C:\apache-maven-3.0.3>echo %PATH% > C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files\IntelWiFi\bin\;C:\Program Files\Common > Files\Intel\WirelessCommon\;C:\Program > Files\TortoiseSVN\bin;C:\apache-ant-1.8.2\bin;C:\IBM\SDP\runtimes\base_v7\java\bin;C:\apache-maven-3.0.3\bin > Following step 7 of the instructions results in: > C:\apache-maven-3.0.3>mvn --version > 'mvn' is not recognized as an internal or external command, operable program > or batch file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-584) Assembly Plugin is looking for SNAPSHOT artifacts in release repositories
Assembly Plugin is looking for SNAPSHOT artifacts in release repositories
-
Key: MASSEMBLY-584
URL: https://jira.codehaus.org/browse/MASSEMBLY-584
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2.1
Environment: Windows 7, java 1.6.0_29, Maven 3.0.3
Reporter: Donatas Ciuksys
Priority: Blocker
Assembly plugin fails to retrieve snapshot with unique version from repository,
and as a result the generated zip file contains
signatures-xades-1.2-SNAPSHOT.jar instead of
signatures-xades-1.2-2021.181823-3.jar.
Descriptor:
{code}
bin
zip
false
lib/
false
/
true
${project.groupId}:${project.artifactId}
{code}
Maven debug output (-X) contains:
{quote}
[DEBUG] Resolving project dependencies transitively.
[DEBUG] lt.mitsoft.vmi:eds3-batch:war:1.0-SNAPSHOT (selected for null)
[DEBUG] lt.mitsoft.vmi:eds3-mdoc:jar:1.0-SNAPSHOT:compile (selected for
compile)
[DEBUG] lt.mitsoft.adoc:adoc-core:jar:1.1:compile (selected for compile)
...
[DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile
(selected for compile)
...
[DEBUG] Verifying availability of
C:\Users\Donatas\.m2\repository\lt\mitsoft\pki\signatures\signatures-xades\1.2-SNAPSHOT\signatures-xades-1.2-2021.181823-3.pom
from [central (https://int.mitsoft.lt:3681/artifactory/repo, releases), google
(http://mbari-maven-repository.googlecode.com/svn/repository/, releases),
org.tmatesoft.svnkit-releases
(http://maven.tmatesoft.com/content/repositories/releases/, releases)]
[WARNING] Missing POM for
lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT: Error resolving
project artifact: Could not find artifact
lt.mitsoft.pki.signatures:signatures-xades:pom:1.2-2021.181823-3 for
project lt.mitsoft.pki.signatures:signatures-xades:pom:1.2-SNAPSHOT
[DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile (removed -
nearer found: 1.2-SNAPSHOT)
[DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT:compile
(selected for compile)
...
{quote}
The problem is that artifact signatures-xades-1.2-2021.181823-3.pom (that
is, signatures-xades-1.2-SNAPSHOT) is being looked-up in *release* repositories
(as shown above):
{code}
[central (https://int.mitsoft.lt:3681/artifactory/repo, releases),
google (http://mbari-maven-repository.googlecode.com/svn/repository/,
releases),
org.tmatesoft.svnkit-releases
(http://maven.tmatesoft.com/content/repositories/releases/, releases)]
{code}
The culprit might be the dependency override:
{code}
[DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile (removed -
nearer found: 1.2-SNAPSHOT)
[DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT:compile
(selected for compile)
{code}
The first candidate was signatures-xades:jar:1.1 (release), but the chosen
artifact is signatures-xades:jar:1.2-SNAPSHOT. I guess the repository type was
chosen based on the first candidate, and this is wrong.
*Even bigger problem is that since POM retrieval failed, all dependencies
specified in signatures-xades-1.2-2021.181823-3.pom were not being taken
into account (and are absent in generated zip file).*
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNGSITE-146) Installation Instructions don't work for Windows
[ https://jira.codehaus.org/browse/MNGSITE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Goodwin reopened MNGSITE-146: - I read the instructions closely and saw that text. What I DIDN'T do was write my problem description in Jira carefully. I mistakenly said I extracted the archive to c:\apache-maven-3.0.3. I didn't see a way to go back and edit the original description. I actually extracted it to c:\ whereupon it created c:\apache-maven-3.0.3. The resulting directory structure is below. If I'm reading the instructions correctly, in my case, the M2_HOME environment variable should be set to c:\apache-maven-3.0.3 and the PATH environment variable should contain %M2_HOME%\bin. Is that not correct? C:\apache-maven-3.0.3>dir Volume in drive C is TI105955W0C Volume Serial Number is 3403-3BA7 Directory of C:\apache-maven-3.0.3 11/30/2011 07:52 PM . 11/30/2011 07:52 PM .. 11/30/2011 07:50 PM apache-maven 02/28/2011 06:28 PM12,875 build.xml 02/28/2011 06:33 PM 8,198 DEPENDENCIES 02/28/2011 06:28 PM11,838 doap_Maven.rdf 02/28/2011 06:27 PM11,560 LICENSE.txt 11/30/2011 07:50 PM maven-aether-provider 02/28/2011 06:28 PM 1,314,262 maven-ant-tasks-2.1.1.jar 11/30/2011 07:50 PM maven-artifact 11/30/2011 07:50 PM maven-compat 11/30/2011 07:51 PM maven-core 11/30/2011 07:52 PM maven-embedder 11/30/2011 07:52 PM maven-model 11/30/2011 07:52 PM maven-model-builder 11/30/2011 07:52 PM maven-plugin-api 11/30/2011 07:52 PM maven-repository-metadata 11/30/2011 07:52 PM maven-settings 11/30/2011 07:52 PM maven-settings-builder 02/28/2011 06:27 PM 1,030 NOTICE.txt 02/28/2011 06:28 PM22,607 pom.xml 02/28/2011 06:28 PM 396 README.bootstrap.txt 02/28/2011 06:28 PM 304 README.md 02/28/2011 06:28 PM78 README.txt 11/30/2011 07:50 PM src 10 File(s) 1,383,148 bytes 15 Dir(s) 423,846,154,240 bytes free C:\apache-maven-3.0.3> > Installation Instructions don't work for Windows > > > Key: MNGSITE-146 > URL: https://jira.codehaus.org/browse/MNGSITE-146 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Windows 7 >Reporter: Jim Goodwin >Priority: Minor > > Step 3 of the Installation Instructions on this page > http://maven.apache.org/download.html say to add %M2_HOME%\bin directory to > the PATH environment variable. There is no %M2_HOME%\bin directory. For > example, when I extracted the downloaded archive, I extracted it to > c:\apache-maven-3.0.3. That is supposed to be path for M2_HOME, however there > is no \bin directory under that path. There is a \bin directory under > c:\apache-maven-3.0.3\apache-maven. > The end result is that running the mvn command results in "'mvn' is not > recognized as an internal or external command, operable program or batch > file." > Here is the content of my M2_HOME environment variable: > C:\apache-maven-3.0.3>echo %M2_HOME% > C:\apache-maven-3.0.3 > Here is the content of my PATH environment variable: > C:\apache-maven-3.0.3>echo %PATH% > C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files\IntelWiFi\bin\;C:\Program Files\Common > Files\Intel\WirelessCommon\;C:\Program > Files\TortoiseSVN\bin;C:\apache-ant-1.8.2\bin;C:\IBM\SDP\runtimes\base_v7\java\bin;C:\apache-maven-3.0.3\bin > Following step 7 of the instructions results in: > C:\apache-maven-3.0.3>mvn --version > 'mvn' is not recognized as an internal or external command, operable program > or batch file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-168) checkstyle-aggregate give a wrong file count
[ https://jira.codehaus.org/browse/MCHECKSTYLE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284663#comment-284663 ] Antonio Petrelli commented on MCHECKSTYLE-168: -- The patch fixes the problem in CheckstyleReportListener, where the same file is counted multiple times, in the worst case, for each directory. Anyway it can be random, depending on the length of absolute names of the source directories. > checkstyle-aggregate give a wrong file count > > > Key: MCHECKSTYLE-168 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-168 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Antonio Petrelli > Attachments: checkstyle-multisource-patch.diff > > > In a multi-source-directory environment, currently verifiable only with > multi-module projects, the total file count is wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHECKSTYLE-168) checkstyle-aggregate give a wrong file count
checkstyle-aggregate give a wrong file count Key: MCHECKSTYLE-168 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-168 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Antonio Petrelli Attachments: checkstyle-multisource-patch.diff In a multi-source-directory environment, currently verifiable only with multi-module projects, the total file count is wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-46) bad url in jira description
bad url in jira description --- Key: MINDEXER-46 URL: https://jira.codehaus.org/browse/MINDEXER-46 Project: Maven Indexer Issue Type: Bug Reporter: Petr Kozelka Priority: Trivial current url shown at http://jira.codehaus.org/browse/MINDEXER is: http://maven.apache.org/indexer/ (results in Page Not Found) It should be http://maven.apache.org/maven-indexer -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
