[jira] Updated: (MNG-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=all ] Jason van Zyl updated MNG-1577: --- Fix Version/s: (was: 2.0.x) 2.0.6 > 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 > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, > mng1577c.patch, mng1577d.patch, mng1577e-trunk.patch, mng1577e.patch, > mng1577f.patch, mng1577trunk.patch > > > 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] Created: (MDEPLOY-47) Timeout during SCP upload
Timeout during SCP upload - Key: MDEPLOY-47 URL: http://jira.codehaus.org/browse/MDEPLOY-47 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Windows XP, Java 1.5, Maven 2.0.4 Reporter: Dennis Kieselhorst It seems that there is a timeout during the upload. Unfortunately the deploy-plugin doesn't detect it. I have to close the console and kill the java process in the task manager. Uploading: scp://mydevserver/opt/www/htdocs/maven2/de/dekies/test/test-client/2.8.27rc2/test-client-2.8.27rc2.jar 4/20K 8/20K 12/20K 16/20K 20/20K 20/20K 20K uploaded [INFO] Retrieving previous metadata from dekies [INFO] Uploading repository metadata for: 'artifact de.dekies.test:test-client' [INFO] Retrieving previous metadata from dekies [INFO] Uploading project information for test-client 2.8.27rc2 --> nothing happens after this (for hours)! -- 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: (MRM-267) Managed Repositories and Proxied Repositories buttons under Administration are not displayed when using Internet Explorer 7.
Managed Repositories and Proxied Repositories buttons under Administration are not displayed when using Internet Explorer 7. Key: MRM-267 URL: http://jira.codehaus.org/browse/MRM-267 Project: Archiva Issue Type: Bug Components: web application Reporter: Dawn Angelito When using Internet Explorer 7, the "Managed Repositories" and "Proxied Repositories" buttons under Administration are not displayed. -- 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: (MRM-267) Managed Repositories and Proxied Repositories buttons under Administration are not displayed when using Internet Explorer 7.
[ http://jira.codehaus.org/browse/MRM-267?page=all ] Dawn Angelito updated MRM-267: -- Attachment: MRM-267-archiva-webapp.patch Fixed. Patch for this attached. > Managed Repositories and Proxied Repositories buttons under Administration > are not displayed when using Internet Explorer 7. > > > Key: MRM-267 > URL: http://jira.codehaus.org/browse/MRM-267 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Dawn Angelito > Attachments: MRM-267-archiva-webapp.patch > > > When using Internet Explorer 7, the "Managed Repositories" and "Proxied > Repositories" buttons under Administration are not displayed. -- 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-581) Share continuum build number to underlying build project
[ http://jira.codehaus.org/browse/CONTINUUM-581?page=comments#action_84725
]
Lasconic commented on CONTINUUM-581:
Anything is done about this bug ?
I would like to put the build number into a properties file of my project to
display it later. If nothing is done as I see that is a novice complexity maybe
I can do that if someone gives some guide lines. I'm about writing a maven
plugin to do this because I really need it. Any other solutions ?
> Share continuum build number to underlying build project
>
>
> Key: CONTINUUM-581
> URL: http://jira.codehaus.org/browse/CONTINUUM-581
> Project: Continuum
> Issue Type: New Feature
> Components: Core system
>Reporter: Alex Boisvert
> Fix For: 1.1
>
>
> It would be nice if Continuum shared its build number with the underlying
> build projects (e.g. Ant/Maven{1,2})
> What I'm trying to do is generate artifacts with the following naming
> convention:
> myproject-1.0-123.zip
> where 1.0 is the version number defined in Maven (e.g. pom.xml), and 123
> is the Continuum build number. Artifacts could be .zip, .jar, .war, etc.
> I guess one way to do this is to pass the build number via an environment
> variable
--
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: (MEV-488) JCR 1.0 JAR has disappeared
JCR 1.0 JAR has disappeared --- Key: MEV-488 URL: http://jira.codehaus.org/browse/MEV-488 Project: Maven Evangelism Issue Type: Bug Reporter: Vincent Massol The XWiki project's build has started failing about a week ago. It seems someone removed the jcr-1.0.jar from the central repo! This doesn't look right. Thanks -Vincent -- 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: (MEV-488) JCR 1.0 JAR has disappeared
[ http://jira.codehaus.org/browse/MEV-488?page=comments#action_84727 ] Vincent Massol commented on MEV-488: unless it's been removed because the JCR JAR was there by mistake before > JCR 1.0 JAR has disappeared > --- > > Key: MEV-488 > URL: http://jira.codehaus.org/browse/MEV-488 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Vincent Massol > > The XWiki project's build has started failing about a week ago. It seems > someone removed the jcr-1.0.jar from the central repo! > This doesn't look right. > Thanks > -Vincent -- 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-488) JCR 1.0 JAR has disappeared
[ http://jira.codehaus.org/browse/MEV-488?page=all ] fabrizio giustina closed MEV-488. - Assignee: fabrizio giustina Resolution: Won't Fix see http://issues.apache.org/jira/browse/JCR-592#action_12445587 the jcr jar was once uploaded to the central repo, but after further discussions about licensing it turned out that only day (spec lead) can distribute it freely (the already have a public maven 1 repo) so it was removed. Ask day.com to provide a version with the correct groupId in their own repo. > JCR 1.0 JAR has disappeared > --- > > Key: MEV-488 > URL: http://jira.codehaus.org/browse/MEV-488 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Vincent Massol > Assigned To: fabrizio giustina > > The XWiki project's build has started failing about a week ago. It seems > someone removed the jcr-1.0.jar from the central repo! > This doesn't look right. > Thanks > -Vincent -- 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-2756) parent resolution is done first before property interpolation
parent resolution is done first before property interpolation - Key: MNG-2756 URL: http://jira.codehaus.org/browse/MNG-2756 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.1.x Reporter: Franz Allan Valencia See Attachments: parent-filtering.zip Possible problems * using properties in the parent tag * using proeprties in the repositories tag with the parent being unknown except to that repo Attach is a sample project whose child project does not get built. -- 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-2756) parent resolution is done first before property interpolation
[ http://jira.codehaus.org/browse/MNG-2756?page=all ] Emmanuel Venisse updated MNG-2756: -- Affects Version/s: 2.0.x Fix Version/s: 2.0.x > parent resolution is done first before property interpolation > - > > Key: MNG-2756 > URL: http://jira.codehaus.org/browse/MNG-2756 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.x, 2.1.x >Reporter: Franz Allan Valencia See > Fix For: 2.0.x > > Attachments: parent-filtering.zip > > > Possible problems > * using properties in the parent tag > * using proeprties in the repositories tag with the parent being unknown > except to that repo > Attach is a sample project whose child project does not get built. -- 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: (MRM-266) Changed the location of the "Run Now" link in the Configuration page.
[ http://jira.codehaus.org/browse/MRM-266?page=all ] Emmanuel Venisse closed MRM-266. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Applied. > Changed the location of the "Run Now" link in the Configuration page. > - > > Key: MRM-266 > URL: http://jira.codehaus.org/browse/MRM-266 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 >Reporter: Dawn Angelito > Assigned To: Emmanuel Venisse >Priority: Minor > Fix For: 1.0 > > Attachments: MRM-266-archiva-webapp.patch > > > If your window is not wide, you have to scroll right and may not even notice > that Run Now is there. Link is now under "Last Indexing Time". -- 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: (MRM-267) Managed Repositories and Proxied Repositories buttons under Administration are not displayed when using Internet Explorer 7.
[ http://jira.codehaus.org/browse/MRM-267?page=all ] Emmanuel Venisse closed MRM-267. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 Applied. > Managed Repositories and Proxied Repositories buttons under Administration > are not displayed when using Internet Explorer 7. > > > Key: MRM-267 > URL: http://jira.codehaus.org/browse/MRM-267 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Dawn Angelito > Assigned To: Emmanuel Venisse > Fix For: 1.0 > > Attachments: MRM-267-archiva-webapp.patch > > > When using Internet Explorer 7, the "Managed Repositories" and "Proxied > Repositories" buttons under Administration are not displayed. -- 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: (MANTRUN-64) Pass properties through
Pass properties through --- Key: MANTRUN-64 URL: http://jira.codehaus.org/browse/MANTRUN-64 Project: Maven 2.x Antrun Plugin Issue Type: Improvement Affects Versions: 1.1, 1.0 Reporter: Daniel Takai Fix For: 1.2 I'd like to automatically pass through project properties to the antrun plugin. This would really help cut down on pom size and would make configuration so much easier. Right now each property has to be passed through manually using elements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-206) Move the webapp features to a separate plugin
[ http://jira.codehaus.org/browse/MSITE-206?page=all ] Jason van Zyl updated MSITE-206: Fix Version/s: 2.0 > Move the webapp features to a separate plugin > - > > Key: MSITE-206 > URL: http://jira.codehaus.org/browse/MSITE-206 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-5 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0 > > > Prevent the complete download of Jetty for rendering the site and move to a > separate plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-206) Move the webapp features to a separate plugin
Move the webapp features to a separate plugin - Key: MSITE-206 URL: http://jira.codehaus.org/browse/MSITE-206 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Reporter: Jason van Zyl Fix For: 2.0 Prevent the complete download of Jetty for rendering the site and move to a separate 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: (MWAR-64) resource processing does not occur correct hierarchical modules.
[ http://jira.codehaus.org/browse/MWAR-64?page=comments#action_84739 ]
Aaron Digulla commented on MWAR-64:
---
The solution is to set to ${basedir}/src/main/webapp
This bug can be closed.
> resource processing does not occur correct hierarchical modules.
>
>
> Key: MWAR-64
> URL: http://jira.codehaus.org/browse/MWAR-64
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Windows XP
>Reporter: Brian Keyser
>
> I have a project that is similar to
> + - ProjectA
>|
>- pom.xml
>|
>+ ProjectB
> |
> - pom.xml
> Within the pom.xml for ProjectB there is an entry describing additional
> resources to include in the war
> ...
>
> org.apache.maven.plugins
> maven-war-plugin
>
>
>
> src/main/resources
> true
>
>
>
>
> ...
> When running 'mvn install' from the project A directory, I get the following
> error
> ...
> [INFO] Copy webapp webResources to
> C:\thinktank\thinktank-d1.1.0\server\server-webapp\target\server-webapp-1.1.0-SNAPSHOT
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] basedir src\main\resources does not exist
> [INFO]
>
> [DEBUG] Trace
> java.lang.IllegalStateException: basedir src\main\resources does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.getWarFiles(AbstractWarMojo.java:810)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:437)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:355)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:161)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:127)
> 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
> 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.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> However, if I change the to
> ...
> projectb/src/main/resources
> ...
> The install goal works fine.
> If I run 'mvn install' from projectb with the first configuration it does
> perform an install, ie, when the directory is configured as
> 'src/main/resources'. Seems like there is a problem in reading the base
> directory for hierarchical projects.
> Thanks for taking a look at this.
--
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-1134) Build number is not a link for guest user
Build number is not a link for guest user - Key: CONTINUUM-1134 URL: http://jira.codehaus.org/browse/CONTINUUM-1134 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1 Reporter: Wendy Smoak Priority: Minor The build state icon in the first column works, but the build number in the fourth column is not a link. >From IRC: http://maven.zones.apache.org/continuum/projectGroupSummary.action?projectGroupId=7 evenisse: why is the 'build state' icon clickable when the 'build number' text is not? I'd expect the guest user to either have access to build results, or not. the build state column is a link to the latest build result so we always have a link on it log out and look at the link above. As a guest, I can click on the icon, but not the build number. the build number column is a link to the latest build result in success, so when continuum build the project, we don't know if the build will be in succes or not, it's why we change the number to a building icon and remove the link I'm looking at the link above. I am not logged in. There is a 'success' icon in the first column and the plain text "1" (not a link) in the 'Build' column. I can get to the results through project -> builds tab -> results link, so it's not permissions, it's a UI issue. yes, it's a bug can you file an 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] Work started: (CONTINUUM-1121) Incorrect build number links on Project Group Summary
[ http://jira.codehaus.org/browse/CONTINUUM-1121?page=all ] Work on CONTINUUM-1121 started by Emmanuel Venisse. > Incorrect build number links on Project Group Summary > - > > Key: CONTINUUM-1121 > URL: http://jira.codehaus.org/browse/CONTINUUM-1121 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > > On the Project Group Summary, the 'build number' link is incorrect. > For example, the text '1' links to > > http://localhost:9090/continuum/buildResult.action?buildId=1&projectId=121&projectGroupId=10&projectName=Apache+Struts > This produces an error: >org.apache.maven.continuum.ContinuumException: No such object > The wrong buildId request parameter value is being used. The 1-based > sequential build number for each project is apparently not the key to the > results where they are stored. > For example, the corresponding 'build state' icon in the first column for > this project links to: >http://localhost:9090/continuum/buildResult.action?buildId=72&projectId=121 > Note: buildId=1 in the first link vs. buildId=72 in the second link. -- 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] Work started: (CONTINUUM-1134) Build number is not a link for guest user
[ http://jira.codehaus.org/browse/CONTINUUM-1134?page=all ] Work on CONTINUUM-1134 started by Emmanuel Venisse. > Build number is not a link for guest user > - > > Key: CONTINUUM-1134 > URL: http://jira.codehaus.org/browse/CONTINUUM-1134 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse >Priority: Minor > > The build state icon in the first column works, but the build number in the > fourth column is not a link. > From IRC: > > http://maven.zones.apache.org/continuum/projectGroupSummary.action?projectGroupId=7 > evenisse: why is the 'build state' icon clickable when the 'build > number' text is not? > I'd expect the guest user to either have access to build results, or > not. > the build state column is a link to the latest build result so we > always have a link on it > log out and look at the link above. As a guest, I can click on the > icon, but not the build number. > the build number column is a link to the latest build result in > success, so when continuum build the project, we don't know if the build will > be in succes or not, it's why we change the number to a building icon and > remove the link > I'm looking at the link above. I am not logged in. There is a > 'success' icon in the first column and the plain text "1" (not a link) in the > 'Build' column. > I can get to the results through project -> builds tab -> results > link, so it's not permissions, it's a UI issue. > yes, it's a bug > can you file an 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] Closed: (DOXIA-76) Doxia misses line breaks in apt when \ is not followed by \n
[ http://jira.codehaus.org/browse/DOXIA-76?page=all ] Vincent Siveton closed DOXIA-76. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.0 Applied in svn with a test case > Doxia misses line breaks in apt when \ is not followed by \n > > > Key: DOXIA-76 > URL: http://jira.codehaus.org/browse/DOXIA-76 > Project: doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-alpha-8 > Environment: Windows XP >Reporter: Mathieu Champlon > Assigned To: Vincent Siveton > Fix For: 1.0 > > Attachments: DOXIA-76.patch, DOXIA-76_testcase.zip > > > Trying to force a line break in an apt file using \ as explained in [1] does > not work on the windows platform. > A test case is provided as a very simple maven project using the minimal pom > from [2] and only an index.apt file in src/main/site/apt > Simply run 'mvn site' on a windows box to reproduce the issue. > The resulting page fom target/site/index.html displays : > Line\ break. > instead of : > Line > break. > [1] http://maven.apache.org/guides/mini/guide-apt-format.html > [2] http://maven.apache.org/guides/introduction/introduction-to-the-pom.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: (CONTINUUM-1121) Incorrect build number links on Project Group Summary
[ http://jira.codehaus.org/browse/CONTINUUM-1121?page=all ] Emmanuel Venisse closed CONTINUUM-1121. --- Resolution: Fixed Fix Version/s: 1.1 Fixed. > Incorrect build number links on Project Group Summary > - > > Key: CONTINUUM-1121 > URL: http://jira.codehaus.org/browse/CONTINUUM-1121 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > On the Project Group Summary, the 'build number' link is incorrect. > For example, the text '1' links to > > http://localhost:9090/continuum/buildResult.action?buildId=1&projectId=121&projectGroupId=10&projectName=Apache+Struts > This produces an error: >org.apache.maven.continuum.ContinuumException: No such object > The wrong buildId request parameter value is being used. The 1-based > sequential build number for each project is apparently not the key to the > results where they are stored. > For example, the corresponding 'build state' icon in the first column for > this project links to: >http://localhost:9090/continuum/buildResult.action?buildId=72&projectId=121 > Note: buildId=1 in the first link vs. buildId=72 in the second link. -- 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] Work stopped: (CONTINUUM-1121) Incorrect build number links on Project Group Summary
[ http://jira.codehaus.org/browse/CONTINUUM-1121?page=all ] Work on CONTINUUM-1121 stopped by Emmanuel Venisse. > Incorrect build number links on Project Group Summary > - > > Key: CONTINUUM-1121 > URL: http://jira.codehaus.org/browse/CONTINUUM-1121 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > On the Project Group Summary, the 'build number' link is incorrect. > For example, the text '1' links to > > http://localhost:9090/continuum/buildResult.action?buildId=1&projectId=121&projectGroupId=10&projectName=Apache+Struts > This produces an error: >org.apache.maven.continuum.ContinuumException: No such object > The wrong buildId request parameter value is being used. The 1-based > sequential build number for each project is apparently not the key to the > results where they are stored. > For example, the corresponding 'build state' icon in the first column for > this project links to: >http://localhost:9090/continuum/buildResult.action?buildId=72&projectId=121 > Note: buildId=1 in the first link vs. buildId=72 in the second link. -- 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: (SCM-270) scm:update does not set revisionKey/scm.property
scm:update does not set revisionKey/scm.property
Key: SCM-270
URL: http://jira.codehaus.org/browse/SCM-270
Project: Maven SCM
Issue Type: Bug
Affects Versions: 1.0-beta-3
Environment: Windows XP, Java(TM) 2 Runtime Environment, Standard
Edition (build 1.5.0_10-b03),
Reporter: Bernd
Using
org.apache.maven.plugins
maven-scm-plugin
validate
getting-scm.revision
update
as suggested on the user list results in
[INFO] [scm:update {execution: getting-scm.revision}]
[INFO] Executing: svn --username maven --non-interactive update
[INFO] Working directory: D:\projekte\template\templatePom-trunk
[DEBUG] Revision 375.
[INFO] Unknown file status: 'R' in line Revision 375..
[INFO] Storing revision in 'scm.revision' project property.
This does not result in rev. 375 being replaced in filtered files.
Actual result is that the content of scm.revision is "0"
The filtered file looks like
xyz=0
instead of the expteced
xyz=375
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPA-83) Process Andy Williams
[ http://jira.codehaus.org/browse/MPA-83?page=all ] Jason van Zyl closed MPA-83. Resolution: Fixed Account has been setup and he can commit. > Process Andy Williams > - > > Key: MPA-83 > URL: http://jira.codehaus.org/browse/MPA-83 > Project: Maven Project Administration > Issue Type: Task > Components: New Committers >Affects Versions: 2006-q4 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2006-q4 > > -- 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-1134) Build number is not a link for guest user
[ http://jira.codehaus.org/browse/CONTINUUM-1134?page=all ] Emmanuel Venisse closed CONTINUUM-1134. --- Resolution: Fixed Fix Version/s: 1.1 The link is fixed in r.495263 but it appaers only if guest or authenticated user have at least a 'Project User' role > Build number is not a link for guest user > - > > Key: CONTINUUM-1134 > URL: http://jira.codehaus.org/browse/CONTINUUM-1134 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse >Priority: Minor > Fix For: 1.1 > > > The build state icon in the first column works, but the build number in the > fourth column is not a link. > From IRC: > > http://maven.zones.apache.org/continuum/projectGroupSummary.action?projectGroupId=7 > evenisse: why is the 'build state' icon clickable when the 'build > number' text is not? > I'd expect the guest user to either have access to build results, or > not. > the build state column is a link to the latest build result so we > always have a link on it > log out and look at the link above. As a guest, I can click on the > icon, but not the build number. > the build number column is a link to the latest build result in > success, so when continuum build the project, we don't know if the build will > be in succes or not, it's why we change the number to a building icon and > remove the link > I'm looking at the link above. I am not logged in. There is a > 'success' icon in the first column and the plain text "1" (not a link) in the > 'Build' column. > I can get to the results through project -> builds tab -> results > link, so it's not permissions, it's a UI issue. > yes, it's a bug > can you file an 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] Commented: (MNG-1408) filesetId does not contain all dependencies when artifact was not yet locally installed
[ http://jira.codehaus.org/browse/MNG-1408?page=comments#action_84771 ] Peter Murray commented on MNG-1408: --- I have encountered this problem too, but have more to share on it. The failure to properly use the SNAPSHOT part of the path to the file seems to be related to when there is a definition of a in the ant build file. If the part was commented out (after the files were downloaded to the local repository) the paths would use SNAPSHOT as expected instead of the timestamp. > filesetId does not contain all dependencies when artifact was not yet locally > installed > --- > > Key: MNG-1408 > URL: http://jira.codehaus.org/browse/MNG-1408 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks >Affects Versions: 2.0 > Environment: java version "1.4.2_04", Linux 2.6.11.12, Apache Ant > version 1.6.5 >Reporter: Ingo Weichsel > Fix For: 2.0.x > > Attachments: patch.txt > > > In the artifact:dependencies task the filesetId is only correctly set, when > the artifact was installed locally before running ant. > After deletion of the local repository the dependant artifacts will be > downloaded to the local repository, but only one of two dependant files will > be included in the ant fileset. The classpath is set correctly. > After running "mvn install" locally for the "as-base-launcher" maven project, > ant computes the correct filesetId. > The ant-project depends on the artifact "as-base-launcher" which itselfs > depends only on classworlds. Snippets from ant buildfiles, poms and ant > output follows: > From the ant buildfile: > > > > pathId="as-launcher.classpath" verbose="true"> > > > > > > > > > > > > > > > > > The referenced POM defining the ant dependencies: > > 4.0.0 > actis > ant-as-base > 1.0-SNAPSHOT > > > actis > as-base-launcher > 1.0-SNAPSHOT > > > > > actisRepository > actisRepository > http://company.com:/repository/ > > > > Output of the ant run: > launcherJAR: > actis:ant-as-base:jar:1.0-SNAPSHOT (selected) > actis:as-base-launcher:jar:1.0-SNAPSHOT (selected) > classworlds:classworlds:jar:1.1-alpha-1 (selected) > [echo] CLASSPATH: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar:/home/iwe/.m2/repository/actis/as-base-launcher/1.0-20051103.102305-8/as-base-launcher-1.0-20051103.102305-8.jar > [echo] FILESET: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.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] Commented: (SUREFIRE-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=comments#action_84775 ] David Dunwoody commented on SUREFIRE-59: Reproduced here with TestNG 5.1+ and the 2.8-SNAPSHOT version of surefire. > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > Please, correct surefire to be compatible with new testng. -- 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-59) Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V
[ http://jira.codehaus.org/browse/SUREFIRE-59?page=comments#action_84776 ] David Dunwoody commented on SUREFIRE-59: ^^ Apologies, that should read TestNG 5.2+ > Not compatible with TestNG 5.2: java.lang.NoSuchMethodError: > org.testng.xml.XmlSuite.setParallel(Z)V > - > > Key: SUREFIRE-59 > URL: http://jira.codehaus.org/browse/SUREFIRE-59 > Project: surefire > Issue Type: Improvement > Components: TestNG support > Environment: > maven-surefire-plugin > 2.2 > > > org.testng > testng > 5.2 > jdk15 > test > >Reporter: Damian Golda > > I have project with dependency to testng and surefire plugin as in > Environment. > I run tests and get exception: > org.apache.maven.surefire.booter.SurefireExecutionException: > org.testng.xml.XmlSuite.setParallel(Z)V; nested exception i > s java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > java.lang.NoSuchMethodError: org.testng.xml.XmlSuite.setParallel(Z)V > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:135) > at org.apache.maven.surefire.Surefire.run(Surefire.java:129) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) > Please, correct surefire to be compatible with new testng. -- 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-1319) JIntellitype 1.2
JIntellitype 1.2 Key: MAVENUPLOAD-1319 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1319 Project: maven-upload-requests Issue Type: Task Reporter: Emil A. Lefkof III Please upload JIntellitype 1.2 to ibiblio. -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=all ] Carlos Sanchez reopened MCOMPILER-22: - > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84778 ] Carlos Sanchez commented on MCOMPILER-22: - To use it you just need to set the version of the plugin to 2.1-SNAPSHOT and add the apache snapshot repo > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_84779 ] Carlos Sanchez commented on MCOMPILER-22: - There's still a problem to be fixed, argument files don't accept the -J options that we are using for Xmx and Xms http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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-1135) Deleting subproject from multiproject can corrupt database
Deleting subproject from multiproject can corrupt database -- Key: CONTINUUM-1135 URL: http://jira.codehaus.org/browse/CONTINUUM-1135 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Environment: linux CentOS 4.4 Linux 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT 2005 i686 i686 i386 GNU/Linux Reporter: Chris Audley I have a few project with multiple modules. When I load one of these projects, I delete the subprojects and remove the --non-recursive flag from the parent project. Frequently (~30% of the time) deleting the subproject corrupts the continuum database. After the delete, the parent project is listed twice, any attempt to remove either of the duplicate parent project listings will fail with an exception. ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be deleted NestedThrowables: javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM BUILDDEFINITION WHERE ID = ? NestedThrowables: SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of foreign key constraint 'PROJECT_BUILP8_FK2' for key (1). The statement has been rolled back.] at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) at ognl.ASTMethod.getValueBody(ASTMethod.java:75) at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) at ognl.SimpleNode.getValue(SimpleNode.java:210) at ognl.Ognl.getValue(Ognl.java:333) at ognl.Ognl.getValue(Ognl.java:378) at ognl.Ognl.getValue(Ognl.java:357) at org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) at org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) at org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) at org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) /-- Encapsulated exception \ javax.jdo.JDOUserException: One or more instances could not be deleted at org.jpox.AbstractPersistenceManager.deletePersistentAll(AbstractPersistenceManager.java:1438) at org.jpox.store.rdbms.scostore.ElementContainerStore.clear(ElementContainerStore.java:595) at org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304) at org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332) at org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTable.java:2280) at org.jpox.store.StoreManager.deleteDependent(StoreManager.java:838) at org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4049) at org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1391) at org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1402) at org.codehaus.plexus.jdo.PlexusJdoUtils.removeObject(PlexusJdoUtils.java:53) at org.apache.maven.continuum.store.JdoContinuumStore.removeObject(JdoContinuumStore.java:969) at org.apache.maven.continuum.store.JdoContinuumStore.removeProject(JdoContinuumStore.java:901) at org.apache.maven.continuum.DefaultContinuum.removeProject(DefaultContinuum.java:328) at sun.reflect.NativeMetho
[jira] Closed: (MCOMPILER-22) Compilation fails: "The command line is too long."
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=all ] Carlos Sanchez closed MCOMPILER-22. --- Resolution: Fixed Fixed by using Xmx and Xms only when forking > Compilation fails: "The command line is too long." > -- > > Key: MCOMPILER-22 > URL: http://jira.codehaus.org/browse/MCOMPILER-22 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Matthew Beermann > Assigned To: Carlos Sanchez >Priority: Critical > Fix For: 2.1 > > Attachments: maven-compiler-plugin-space-fix.patch, > maven-compiler-plugin.patch, MCOMPILER-22.patch, > MNG-MCCOMPILER-22-maven-compiler-plugin.patch, > MNG-MCCOMPILER-22-plexus-compilers-noformatting.patch, > MNG-MCCOMPILER-22-plexus-compilers.patch, plexus-compiler-javac-1.5.2.jar, > plexus-compiler-javac.patch > > > For one of my project, compilation fails with the message "The command line > is too long". As far as I can tell, it's listing each and every source file, > one at a time, in the -sourcepath attribute. (?!?) Here's the log: > [DEBUG] Source roots: > [DEBUG] C:\continuum-1.0.2\apps\continuum\working-directory\26\src > [DEBUG] Command line options: > [DEBUG] -d > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > -classpath -sourcepath SOURCE FILES HERE> -g -nowarn -target 1.4 -source 1.4 > Compiling 167 source files to > C:\continuum-1.0.2\apps\continuum\working-directory\26\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > Failure executing javac, but could not parse the error: > The command line is too long. > [INFO] > > [DEBUG] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:429) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:110) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) > ... 16 more -- 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-1135) Deleting subproject from multiproject can corrupt database
[ http://jira.codehaus.org/browse/CONTINUUM-1135?page=comments#action_84783 ] Chris Audley commented on CONTINUUM-1135: - After trying this over and over again to try and isolate an error message or repeatable pattern, I think I've narrowed down the circumstances that trigger the bug. Basically, things only go wrong if I delete a subproject while things are still being checked out of subversion. If I patiently wait for the projects to finished checking out of subversion, I never have a problem. > Deleting subproject from multiproject can corrupt database > -- > > Key: CONTINUUM-1135 > URL: http://jira.codehaus.org/browse/CONTINUUM-1135 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 > Environment: linux CentOS 4.4 > Linux 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT 2005 i686 i686 i386 > GNU/Linux >Reporter: Chris Audley > > I have a few project with multiple modules. When I load one of these > projects, I delete the subprojects and remove the --non-recursive flag from > the parent project. Frequently (~30% of the time) deleting the subproject > corrupts the continuum database. After the delete, the parent project is > listed twice, any attempt to remove either of the duplicate parent project > listings will fail with an exception. > ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL > PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be > deleted > NestedThrowables: > javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM > BUILDDEFINITION WHERE ID = ? > NestedThrowables: > SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of > foreign key constraint 'PROJECT_BUILP8_FK2' for key (1). The statement has > been rolled back.] > at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) > at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) > at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) > at ognl.ASTMethod.getValueBody(ASTMethod.java:75) > at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) > at ognl.SimpleNode.getValue(SimpleNode.java:210) > at ognl.Ognl.getValue(Ognl.java:333) > at ognl.Ognl.getValue(Ognl.java:378) > at ognl.Ognl.getValue(Ognl.java:357) > at > org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) > at > org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) > at > org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) > /-- Encapsulated exception \ > javax.jdo.JDOUserException: One or more instances could not be deleted > at > org.jpox.AbstractPersistenceManager.deletePersistentAll(AbstractPersistenceManager.java:1438) > at > org.jpox.store.rdbms.scostore.ElementContainerStore.clear(ElementContainerStore.java:595) > at > org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304) > at > org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332) > at > org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTable.java:2280) > at org.jpox.store.StoreManager.deleteDependent(StoreManager.java:838) > at > org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4
[jira] Created: (MEV-489) JTest poms contain invalid characters
JTest poms contain invalid characters - Key: MEV-489 URL: http://jira.codehaus.org/browse/MEV-489 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Wendy Smoak The license URL in the JTest poms is causing a problem: A semi colon character was expected. Error processing resource 'http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/8.0 http://www.parasoft.com/jsp/products/editions_licenses.jsp?product=Jtest&itemId=301 --... Both of the versions are affected: http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/7.5.72/jtest-7.5.72.pom http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/8.0.122/jtest-8.0.122.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: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=comments#action_84785 ]
Christian Goetze commented on MNG-624:
--
I would like to add my support for allowing the use of ${...} in the
... sections. I just fail to see any downside to it, and it
would certainly make my life easier, as I cannot use the release plugin as it
is...
> 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
> Assigned To: Brett Porter
>Priority: Blocker
> Fix For: 2.1.x
>
> 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] Closed: (MEV-489) JTest poms contain invalid characters
[ http://jira.codehaus.org/browse/MEV-489?page=all ] Carlos Sanchez closed MEV-489. -- Assignee: Carlos Sanchez Resolution: Fixed > JTest poms contain invalid characters > - > > Key: MEV-489 > URL: http://jira.codehaus.org/browse/MEV-489 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Wendy Smoak > Assigned To: Carlos Sanchez > > The license URL in the JTest poms is causing a problem: > A semi colon character was expected. Error processing resource > 'http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/8.0 > > http://www.parasoft.com/jsp/products/editions_licenses.jsp?product=Jtest&itemId=301 > --... > Both of the versions are affected: > > http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/7.5.72/jtest-7.5.72.pom > > http://repo1.maven.org/maven2/com/parasoft/jtest/jtest/8.0.122/jtest-8.0.122.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: (MEV-487) Xalan and hsqldb versions outdated
[ http://jira.codehaus.org/browse/MEV-487?page=comments#action_84786 ] Carlos Sanchez commented on MEV-487: you need to upload hsql missing verisions http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Xalan and hsqldb versions outdated > -- > > Key: MEV-487 > URL: http://jira.codehaus.org/browse/MEV-487 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Mikko Wuokko > Attachments: xalan-hsqldb-dependency.patch > > > Xalan seems to use now x.x.x type of version so 2.4 -> 2.4.0. > I couldn find from the main Maven2 repos hsqldb of version 1.8.0, but there > are 1.8.0.1, 1.8.0.4, 1.8.0.5 and 1.8.0.1.7 versions. > Another thing I noticed is that the jar file for jdo 1.0.1 or neither the jar > or the pom files could not be found for jdori for any version. Don't know how > to handle that. -- 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-174) Regression bug with 2.2-SNPASHOT: archive configuration is not taken into account
[ http://jira.codehaus.org/browse/MASSEMBLY-174?page=all ] John Casey updated MASSEMBLY-174: - Fix Version/s: 2.2 > Regression bug with 2.2-SNPASHOT: archive configuration is not taken into > account > - > > Key: MASSEMBLY-174 > URL: http://jira.codehaus.org/browse/MASSEMBLY-174 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Maven 2.04 - 2.0.x >Reporter: Emmanuel Hugonnet >Priority: Blocker > Fix For: 2.2 > > > With the 2.2-SNAPSHOT (maven-assembly-plugin-2.2-20070105.002350-29) the > archive configuration (manifest, manifestEntries, etc.) are not used when > building a jar with the assembly plugin. If I move back to the 2.1 all 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] Updated: (MASSEMBLY-169) Document new elements in the assembly descriptor as "Since 2.2"
[ http://jira.codehaus.org/browse/MASSEMBLY-169?page=all ] John Casey updated MASSEMBLY-169: - Priority: Blocker (was: Major) Fix Version/s: 2.2 > Document new elements in the assembly descriptor as "Since 2.2" > --- > > Key: MASSEMBLY-169 > URL: http://jira.codehaus.org/browse/MASSEMBLY-169 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Wendy Smoak >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly-since-2.2.patch > > > The assembly.html page includes elements introduced after the 2.1 release. > These need to be documented as "Since 2.2" to avoid confusion. > (Another option would be for modello:xdoc to generate something based on the > in the model.) -- 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-161) Archive Configuration ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-161?page=all ]
John Casey updated MASSEMBLY-161:
-
Priority: Blocker (was: Major)
Fix Version/s: 2.2
> Archive Configuration ignored
> -
>
> Key: MASSEMBLY-161
> URL: http://jira.codehaus.org/browse/MASSEMBLY-161
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Martin Sturzenhecker
>Priority: Blocker
> Fix For: 2.2
>
>
> I'd like to create executable .jar files.
> I tried
> {code:xml}
>
>
> makeExecJar_1
> package
>
> attached
>
>
>
> assembly/my-assembly.xml
>
> ../../target/dist/final-1
>
> false
>
> my.package.MyMainClass
>
>
>
>
>
> {code}
> as well as
> {code:xml}
>
>
> makeExecJar_1
> package
>
> attached
>
>
>
> assembly/my-assembly.xml
>
> ../../target/dist/final-1
>
> false
> MY_MANIFEST.MF
>
>
>
>
> {code}
> The result is the same. In the final jar file
> * maven descriptors are added
> * standard {{MANIFEST.MF}} is 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] Updated: (MASSEMBLY-121) Custom manifest attributres are ignored.
[ http://jira.codehaus.org/browse/MASSEMBLY-121?page=all ]
John Casey updated MASSEMBLY-121:
-
Fix Version/s: 2.2
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
> Fix For: 2.2
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
>
> ${project.build.directory}
>
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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-164) "Unrecognised tag: 'unpackOptions' " error in unpackOptions tag in the dependencySet
[ http://jira.codehaus.org/browse/MASSEMBLY-164?page=all ] John Casey updated MASSEMBLY-164: - Priority: Blocker (was: Major) Fix Version/s: 2.2 need to mark this as @since 2.2 > "Unrecognised tag: 'unpackOptions' " error in unpackOptions tag in the > dependencySet > - > > Key: MASSEMBLY-164 > URL: http://jira.codehaus.org/browse/MASSEMBLY-164 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: version 2.1 of maven-assembly-plugin > maven version 2.0.4 > java version 1.5.0_07 > Windows XP version 5.1.2600 >Reporter: Tom McGee >Priority: Blocker > Fix For: 2.2 > > > I'm using version 2.1 of maven-assembly-plugin. > The documentaion on the assembly saids I can have unpackOptions tag in the > dependencySet but I get an "Unrecognised tag: 'unpackOptions' " error. > Here's the stack trace: > org.apache.maven.lifecycle.LifecycleExecutionException: Error reading > descriptor > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > 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.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading > descriptor > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:839) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:814) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.readAssemblies(AbstractAssemblyMojo.java:742) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:233) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > ... 16 more > Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: > Unrecognised tag: 'unpackOptions' (position: START_TAG seen ...\r\n > \r\n >... @11:23) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseDependencySet(AssemblyXpp3Reader.java:638) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.parseAssembly(AssemblyXpp3Reader.java:456) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:1717) > at > org.apache.maven.plugins.assembly.model.io.xpp3.AssemblyXpp3Reader.read(AssemblyXpp3Reader.java:1728) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.getAssembly(AbstractAssemblyMojo.java:829) > ... 21 more > The pom: > 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";> > 4.0.0 > play.ejb > play-ejb > jar > 1.0-SNAPSHOT > play-ejb > http://maven.apache.org > > > org.springframework > spring > 2.0 > compile > > > junit > junit > 3.8.1 > test > > > > > > > > maven-assembly-plugin > > > assembly > package > > assembly >
[jira] Updated: (MASSEMBLY-135) Clarify the addition of dependancies in assembly:assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-135?page=all ] John Casey updated MASSEMBLY-135: - Fix Version/s: 2.2 > Clarify the addition of dependancies in assembly:assembly > - > > Key: MASSEMBLY-135 > URL: http://jira.codehaus.org/browse/MASSEMBLY-135 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: n/a >Reporter: Gwyn Evans > Fix For: 2.2 > > > It was unclear to me for quite a while that the assembly plugin could pack > dependancies The documentation suggested that it should, by default, do so, > but when trying wth the built-in "bin" descriptor, nothing happened. I > worked around it for a while by having the dependancy plugin copy the jars > into my target folder, until I came back to it today. > What I found was that if I took the built-in 'bin', created my own[1] and > simply added > > > > > then I got the behaviour I wanted. > I'd suggest two changes - (1) some comment (in the descriptor format > description) about how dependancies are not included without the above and > (2) an additional pre-defined descriptior, e.g. "bin-with-dependancies", as > that seems to be a common requirement, judging from the M2 mailing list. > /Gwyn > [1] By the way, I couldn't find any documentation that explained the correct > syntax for this - > http://maven.apache.org/plugins/maven-assembly-plugin/howto.html just uses > & > http://maven.apache.org/plugins/maven-assembly-plugin/assembly-mojo.html > mentions be only by trial & error do you find what it should > contain (OK, convention suggests it would , but the description > said files, which I first read as the filepath & was marked as > depreciated. ) -- 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-142) Should be able to use artifact version as variable in
[ http://jira.codehaus.org/browse/MASSEMBLY-142?page=all ]
John Casey updated MASSEMBLY-142:
-
Fix Version/s: 2.2
> Should be able to use artifact version as variable in
>
>
> Key: MASSEMBLY-142
> URL: http://jira.codehaus.org/browse/MASSEMBLY-142
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Simon Gunzenreiner
> Fix For: 2.2
>
>
> It would be useful to be able to use the artifact version as variable in the
> element. If ${version} is use right now, the version of the
> current pom is used. It seems there is no way to use the artifact version
> though.
--
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-134) Incorrect link to issue tracker
[ http://jira.codehaus.org/browse/MASSEMBLY-134?page=all ] John Casey updated MASSEMBLY-134: - Fix Version/s: 2.2 > Incorrect link to issue tracker > --- > > Key: MASSEMBLY-134 > URL: http://jira.codehaus.org/browse/MASSEMBLY-134 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: n/a >Reporter: Gwyn Evans > Fix For: 2.2 > > > The project's "Issue Tracking" page at > http://maven.apache.org/plugins/maven-assembly-plugin/issue-tracking.html > links to http://jira.codehaus.org/browse/MPA (the Maven Project > Administration JIRA) rather than where it should, i.e. here > (http://jira.codehaus.org/browse/MASSEMBLY) > /Gwyn -- 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-150) Clarify or fix relative scoping in assembly descriptor to be module centric or location of mvn execution
[ http://jira.codehaus.org/browse/MASSEMBLY-150?page=all ] John Casey updated MASSEMBLY-150: - Fix Version/s: 2.2 > Clarify or fix relative scoping in assembly descriptor to be module > centric or location of mvn execution > --- > > Key: MASSEMBLY-150 > URL: http://jira.codehaus.org/browse/MASSEMBLY-150 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: windows xp >Reporter: Harold Shinsato > Fix For: 2.2 > > > According to > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the > assembly descriptor's source is supposed to be absolute or relative > from the module's directory. This works when I execute mvn in the module > directory. But when I run it from a top level super project, it seems to run > from that higher level project. This isn't how the works, which we > were using before, but we needed to set filtering to true, which caused this > to break. > So this is how we have to write this to make this work from the top level, > but it breaks when running the assembly from this directory. > > > fileutil/src/main/scripts/FileUploadUtility.bat > file-utility > true > > > This is how it used to be specified, where it worked both from the top level > and from the subdirectory: > > > ../fileutil > file-utility > > FileUploadUtility.bat > > > > Hopefully this won't make a difference, but we've plugged our assembly into > the execution of the package phase. This is copied from the pom.xml of the > module. > > > > maven-assembly-plugin > > > src/main/assembly/dist.xml > > > > > > attached > > package > > > > > -- 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-153) files included with the tag have fileMode 204
[ http://jira.codehaus.org/browse/MASSEMBLY-153?page=all ] John Casey updated MASSEMBLY-153: - Fix Version/s: 2.2 > files included with the tag have fileMode 204 > > > Key: MASSEMBLY-153 > URL: http://jira.codehaus.org/browse/MASSEMBLY-153 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: linux >Reporter: Paul Jungwirth >Priority: Minor > Fix For: 2.2 > > > I'm trying to include files like this: > > > README > true > > > src/blah > > > I'm packaging them as both .tar.gz and .zip. In the tarball, the files wind > up with mode 0204: > --wr-- > In the zip file, they wind up with mode 1204: > --wr-T > Using a element of 644 does not fix the problem. This only happens > for files specified in , not . It happens whether I use > filtering or not. > These are pretty weird modes. I don't think this is a duplicate of > MASSEMBLY-75. It's not just losing the mode I set; it's assigning a very > peculiar mode as if with a mind of its own. > My umask is 0002. > Paul -- 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-125) add mojo for creating a source bundle
[ http://jira.codehaus.org/browse/MASSEMBLY-125?page=all ] John Casey updated MASSEMBLY-125: - Fix Version/s: 2.2 > add mojo for creating a source bundle > - > > Key: MASSEMBLY-125 > URL: http://jira.codehaus.org/browse/MASSEMBLY-125 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Reporter: Ovidio Mallo > Fix For: 2.2 > > > I think it would be nice to have some mojo "source:jar-with-dependencies" or > something similar which not only includes the artifact's sources into the JAR > but also those of its transitive dependencies. This would e.g. allow to > create a source bundle for an assembly created with Maven. > As a concrete example, the "Maven 2.x Plugin for Eclipse" project, which is > no Maven but a simple PDE project, uses the MavenEmbedder assembly. There, it > would be very handy to also have such a source bundle to attach to the > assembly JAR file inside Eclipse for developing and especially for debugging. > Would there maybe be any interest (beside my single use case :-)) in such a > feature? If so, I would eventually give it a try myself if I find the time... -- 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-147) In multi project assembly, parent pom.xml not included in tar assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-147?page=all ]
John Casey updated MASSEMBLY-147:
-
Fix Version/s: 2.2
> In multi project assembly, parent pom.xml not included in tar assembly
> --
>
> Key: MASSEMBLY-147
> URL: http://jira.codehaus.org/browse/MASSEMBLY-147
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dominic Zaza
>Priority: Minor
> Fix For: 2.2
>
>
> I'm trying to create a source bundle for a multi module project.
> I followed steps in
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-source-inclusion-simple.html
> and was able to product a tar file.
> However, my parent pom.xml is not included in the result tar file.
> Additionally, I would like to "not" include my tests. I attempted to use the
> following
>
>
>
> ${artifactId}
>
> **/src/test/**
>
>
>
>
> However, didn't work
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-172) Extension-Name and Specification-Title added to MANIFEST.MF
[ http://jira.codehaus.org/browse/MASSEMBLY-172?page=all ] John Casey updated MASSEMBLY-172: - Fix Version/s: 2.2 > Extension-Name and Specification-Title added to MANIFEST.MF > --- > > Key: MASSEMBLY-172 > URL: http://jira.codehaus.org/browse/MASSEMBLY-172 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Heinrich Nirschl >Priority: Minor > Fix For: 2.2 > > > The assembly plugin (at least when using the predefined descriptor > jar-with-dependencies; I did not check others) adds the Extension-Name and > Specification-Title attributes to the generated jar. See also MJAR-38 which > describes the same problem for the jar plugin. > Here is the configuration I used: > ... > > maven-assembly-plugin > > > jar-with-dependencies > > > > > example.Main > > > > > > ... -- 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-175) MANIFEST entries are not preserved during assemby
[ http://jira.codehaus.org/browse/MASSEMBLY-175?page=all ] John Casey updated MASSEMBLY-175: - Fix Version/s: 2.2 > MANIFEST entries are not preserved during assemby > - > > Key: MASSEMBLY-175 > URL: http://jira.codehaus.org/browse/MASSEMBLY-175 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Tomasz Pik > Fix For: 2.2 > > > "jar-with-dependencies" assembly should preserve MANIFEST entries from > project main result (so configuration for this will be inherited from > maven-jar-plugin). > This is especially important in case for parameter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-162) In a multiproject environment, assembly takes wrong dependencies
[ http://jira.codehaus.org/browse/MASSEMBLY-162?page=all ]
John Casey updated MASSEMBLY-162:
-
Fix Version/s: 2.2
> In a multiproject environment, assembly takes wrong dependencies
>
>
> Key: MASSEMBLY-162
> URL: http://jira.codehaus.org/browse/MASSEMBLY-162
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: M. van Leeuwen
>Priority: Critical
> Fix For: 2.2
>
>
> With a projectstructure like 'Project/{ejb,war,ear,client}' packaging the
> client as a fat jar-with-dependencies, it works fine using the following
> configuration.
> === etc/fatjar.xml
> fat
> jar
> false
>
> target/classes
> /
>
>
>
> /
> true
> runtime
>
>
>
> === pom.xml ===
>
> 0.3-SNAPSHOT
> 4.0.0
> mygroup
> myapp-client
> My Application
>
>
>
>
>
>
> maven-assembly-plugin
> 2.1
>
>
> etc/fatjar.xml
>
>
> path.to.MainClass
>
>
>
> package
> assembly
>
>
>
>
>
> But when I'm on the level above (packaging all) it just assembles all
> underlying dependencies into my clientjar, and not the dependencies of the
> childproject.
--
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-168) dependencySets not allowed within binaries tag
[ http://jira.codehaus.org/browse/MASSEMBLY-168?page=all ] John Casey updated MASSEMBLY-168: - Fix Version/s: 2.2 > dependencySets not allowed within binaries tag > -- > > Key: MASSEMBLY-168 > URL: http://jira.codehaus.org/browse/MASSEMBLY-168 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maurice Montgénie > Fix For: 2.2 > > > On http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html we've > got > > ... > > > > > > > > But i've got an error if i do that : > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error reading descriptor > Embedded error: Unrecognised tag: 'dependencySets' (position: START_TAG seen > ... > \r\n... @18:33) > I've got no way to specify scope of the dependencies i want to include because > ... > false > > >system > > > ... > Does not work -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-173) inside a tag is interpreted as decimal, not octal
[ http://jira.codehaus.org/browse/MASSEMBLY-173?page=all ] John Casey updated MASSEMBLY-173: - Fix Version/s: 2.2 > inside a tag is interpreted as decimal, not octal > --- > > Key: MASSEMBLY-173 > URL: http://jira.codehaus.org/browse/MASSEMBLY-173 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Mac OS X 10.4.8 (8L2127) Intel > Maven version: 2.0.4 >Reporter: Lars Sonchocky-Helldorf > Fix For: 2.2 > > > If I want to use the tag inside a tag I have to resort to > decimal numbers. This doesn't happen inside the tags. As example > some snipped from a Assembly Descriptor I currently use: > > > target/MDEditor-fat.jar > 0493 > > > > > deploy/Euro1 > keep > / > > **/*.sh > > 0755 > > > deploy/Euro1 > keep > / > > **/*.sh > > 0644 > > -- 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-151) Documentation for the assembly plugin is utterly confusing
[ http://jira.codehaus.org/browse/MASSEMBLY-151?page=all ]
John Casey updated MASSEMBLY-151:
-
Fix Version/s: 2.2
> Documentation for the assembly plugin is utterly confusing
> --
>
> Key: MASSEMBLY-151
> URL: http://jira.codehaus.org/browse/MASSEMBLY-151
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: Nigel Magnay
> Fix For: 2.2
>
>
> This is going to come across as a whinge, I'm afraid, but the assembly plugin
> is a fairly important vital component in M2; I find it very confusing and
> I've been using it for a bit. I have observed it putting off other people
> from using m2 at all, which is I think a shame.
> I'd document it myself, but I don't understand the differences between some
> of the goals (and I don't understand why the fix in MASSEMBLY-97 is
> neccessary).
> In the goals page,there's lots of options that seem to overlap or do the same
> thing. There's no clue (other than trial and error) as to why some of them
> will work some times, and some will not (e.g. in multiproject builds). What's
> worse is some of the problems only appear in specific circumstances (E.g.
> doing multiprojects in a 'clean' build').
> This either needs documenting, or (better), fixing in the code. We have (from
> the site):
> assembly:assemblyAssemble an application bundle or distribution
> from an assembly descriptor.
> Good, seems logical to me
> assembly:unpack Unpack project dependencies. Currently supports
> dependencies of type jar and zip.
> The reverse. Yep.
> assembly:attached Assemble an application bundle or distribution from an
> assembly descriptor. Do not specify a phase, so make it usable in a reactor
> environment where forking would create issues.
> Erk? How should a user read this? To me "usable in a reactor environment
> where forking would create issues" reads to me as "there's a bug in
> assembly:assembly if used in a multiproject build".
> - it assumes that the user knows a multi project build is a 'reactor' build
> - why can't assembly:assembly be fixed so it does work in multiproject
> builds? Why can't it detect the environment, and do the 'right thing' (or at
> the very least spit out a warning) ?
> This is just inviting the user to pick the wrong goal.
> assembly:directoryAssemble an application bundle or distribution.
> Without a descriptor? If I click the link to the goal parameters for this or
> for assembly:assembly, I get identical pages of parameters. How is this
> different?
> assembly:directory-inline Assemble an application bundle or distribution
> from an assembly descriptor without launching a parallel lifecycle build.
> In what scenarios would I as a user need this? Is it for a bug workaround?
> Would it not be better as a parameter to turn off/on "parallel lifecycle
> build" ?
> assembly:single Assemble an application bundle or distribution from an
> assembly descriptor. Do not specify a phase, so make it usable in a reactor
> environment where forking would create issues. Do not specify it as an
> aggregator, so it is only for a single project. Both cases aid it in working
> around issues with the Maven lifecycle that should be addressed in Maven 2.1.
> A whole heap of information that seems to boil down to "there is a bug", and
> a heap of confusing terminology ("do not specify it as an aggregator").
> When should this be used ? Every time you actually want assembly:assembly in
> a multiproject build? How is it different to assembly:attached?
> It seems to me that the plugin does 2 things. (pack things, unpack things).
> All these additional goals seem to be (I can't tell this) workarounds for
> bugs.
> Why can't we just have
> assembly:assembly
> and
> assembly:unpack
> and make the plugin work properly? If multiproject builds fail on fork, then
> stop the plugin from forking until it can be fixed (or keep it as a cryptic
> option for people that really want to optimise their builds rather than
> confusing new customers).
--
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-101) META-INF/plexus/components.xml are being processed even if it is excluded or not included
[ http://jira.codehaus.org/browse/MASSEMBLY-101?page=all ] John Casey updated MASSEMBLY-101: - Fix Version/s: (was: 2.2) > META-INF/plexus/components.xml are being processed even if it is excluded or > not included > - > > Key: MASSEMBLY-101 > URL: http://jira.codehaus.org/browse/MASSEMBLY-101 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Edwin Punzalan >Priority: Minor > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-155) Ability to filter unpacked content in the assembly
[ http://jira.codehaus.org/browse/MASSEMBLY-155?page=all ] John Casey updated MASSEMBLY-155: - Fix Version/s: (was: 2.2) > Ability to filter unpacked content in the assembly > -- > > Key: MASSEMBLY-155 > URL: http://jira.codehaus.org/browse/MASSEMBLY-155 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Stephane Nicoll > Attachments: assembly.unpack_options.patch > > > It would be handy to be able to provide includes/excludes filter when > unpacking dependencies. > see [this > thread|http://www.nabble.com/assembly-extraction-of-dependency-without-META-INF-directory-tf2519607.html] > for a concrete use case. -- 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-45) Support for mappers in assembly desriptors
[ http://jira.codehaus.org/browse/MASSEMBLY-45?page=all ] John Casey updated MASSEMBLY-45: Fix Version/s: (was: 2.2) > 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 > 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 > > > Container > > > **/target/*.jar > > > > The assembly plugin will be able to get all jar files produced by Module3 and > Module4 but the "Container//target" structure will still be > included. One workaround is to enumerate each artifact but > problematic if the number of contained sub-modules is numerous. Support for > filemappers which look like this: > > > Container > > > **/target/*.jar > > > > > 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
[jira] Closed: (CONTINUUM-1082) Projects are visible to users with no roles
[ http://jira.codehaus.org/browse/CONTINUUM-1082?page=all ] Emmanuel Venisse closed CONTINUUM-1082. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Already fixed. > Projects are visible to users with no roles > --- > > Key: CONTINUUM-1082 > URL: http://jira.codehaus.org/browse/CONTINUUM-1082 > Project: Continuum > Issue Type: Bug > Components: Web - Security >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > I first noticed this with the guest/unauthenticated user, because you can see > everything from project groups down to build results without logging in. > http://www.nabble.com/Projects-are-visible-to-a-guest-user-with-no-roles-t2873616.html > It's the same with any other user. > Project Groups (and the projects within them) should not be visible at all > unless the user has the "Project User" role for that group. > (If the user has no roles, it would be nice to display a helpful message > rather than an empty list of Project Groups.) -- 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-1135) Deleting subproject from multiproject can corrupt database
[ http://jira.codehaus.org/browse/CONTINUUM-1135?page=all ] Emmanuel Venisse closed CONTINUUM-1135. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1 Already fixed. > Deleting subproject from multiproject can corrupt database > -- > > Key: CONTINUUM-1135 > URL: http://jira.codehaus.org/browse/CONTINUUM-1135 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 > Environment: linux CentOS 4.4 > Linux 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT 2005 i686 i686 i386 > GNU/Linux >Reporter: Chris Audley > Assigned To: Emmanuel Venisse > Fix For: 1.1 > > > I have a few project with multiple modules. When I load one of these > projects, I delete the subprojects and remove the --non-recursive flag from > the parent project. Frequently (~30% of the time) deleting the subproject > corrupts the continuum database. After the delete, the parent project is > listed twice, any attempt to remove either of the duplicate parent project > listings will fail with an exception. > ognl.MethodFailedException: Method "removeProject" failed for object [EMAIL > PROTECTED] [javax.jdo.JDOUserException: One or more instances could not be > deleted > NestedThrowables: > javax.jdo.JDODataStoreException: Delete request failed: DELETE FROM > BUILDDEFINITION WHERE ID = ? > NestedThrowables: > SQL Exception: DELETE on table 'BUILDDEFINITION' caused a violation of > foreign key constraint 'PROJECT_BUILP8_FK2' for key (1). The statement has > been rolled back.] > at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) > at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) > at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) > at ognl.ASTMethod.getValueBody(ASTMethod.java:75) > at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) > at ognl.SimpleNode.getValue(SimpleNode.java:210) > at ognl.Ognl.getValue(Ognl.java:333) > at ognl.Ognl.getValue(Ognl.java:378) > at ognl.Ognl.getValue(Ognl.java:357) > at > org.codehaus.plexus.formica.action.DeleteEntity.uponSuccessfulValidation(DeleteEntity.java:57) > at > org.codehaus.plexus.formica.action.DeleteEntity.execute(DeleteEntity.java:47) > at > org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) > /-- Encapsulated exception \ > javax.jdo.JDOUserException: One or more instances could not be deleted > at > org.jpox.AbstractPersistenceManager.deletePersistentAll(AbstractPersistenceManager.java:1438) > at > org.jpox.store.rdbms.scostore.ElementContainerStore.clear(ElementContainerStore.java:595) > at > org.jpox.store.mapping.CollectionMapping.preDelete(CollectionMapping.java:304) > at > org.jpox.store.mapping.CollectionMapping.deleteDependent(CollectionMapping.java:332) > at > org.jpox.store.rdbms.table.ClassTable.deleteDependent(ClassTable.java:2280) > at org.jpox.store.StoreManager.deleteDependent(StoreManager.java:838) > at > org.jpox.state.StateManagerImpl.deletePersistent(StateManagerImpl.java:4049) > at > org.jpox.AbstractPersistenceManager.internalDeletePersistent(AbstractPersistenceManager.java:1391) > at > org.jpox.AbstractPersistenceManager.deletePersistent(AbstractPersistenceManager.java:1402) > at > org.codehaus.
[jira] Commented: (MNG-2709) Maven 2 doesn't resolve parent test dependencies when using JDK 6
[ http://jira.codehaus.org/browse/MNG-2709?page=comments#action_84791 ] Matt Raible commented on MNG-2709: -- Any chance of getting this fixed in 2.0.5? > Maven 2 doesn't resolve parent test dependencies when using JDK 6 > - > > Key: MNG-2709 > URL: http://jira.codehaus.org/browse/MNG-2709 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 >Reporter: Matt Raible > > http://www.nabble.com/Maven-2-and-JDK-6-tf2841587s177.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: (MNG-2757) Allow dependency properties to be overriden by projects that use them
Allow dependency properties to be overriden by projects that use them - Key: MNG-2757 URL: http://jira.codehaus.org/browse/MNG-2757 Project: Maven 2 Issue Type: Wish Components: Dependencies Affects Versions: 2.0.4 Reporter: Matt Raible http://www.nabble.com/Overriding-properties-in-a-dependency%27s-pom.xml-tf2921218s177.html http://issues.appfuse.org/browse/APF-565 Thanks! -- 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-1136) relying on default charset while backing up continuum store
relying on default charset while backing up continuum store --- Key: CONTINUUM-1136 URL: http://jira.codehaus.org/browse/CONTINUUM-1136 Project: Continuum Issue Type: Bug Components: Database Affects Versions: 1.1 Environment: Windows XP Professional SP2 JDK6 Reporter: Marcelo Takeshi Fukushima While backing up the store, jdo continuum store uses a FileWriter wich relies on the system's default charset encoding, but the continuum database tries to store using utf-8. Should use a FileOutputStream and OutputStreamWriter ( OutputStream, Charset ) instead -- 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-1136) relying on default charset while backing up continuum store
[ http://jira.codehaus.org/browse/CONTINUUM-1136?page=all ] Marcelo Takeshi Fukushima updated CONTINUUM-1136: - Attachment: data-management.patch this is the fix: its pretty straight forward as you can use the same charset encoding used later > relying on default charset while backing up continuum store > --- > > Key: CONTINUUM-1136 > URL: http://jira.codehaus.org/browse/CONTINUUM-1136 > Project: Continuum > Issue Type: Bug > Components: Database >Affects Versions: 1.1 > Environment: Windows XP Professional SP2 > JDK6 >Reporter: Marcelo Takeshi Fukushima > Attachments: data-management.patch > > > While backing up the store, jdo continuum store uses a FileWriter wich relies > on the system's default charset encoding, but the continuum database tries to > store using utf-8. > Should use a FileOutputStream and OutputStreamWriter ( OutputStream, Charset > ) instead -- 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-1103) Build Fresh checkbox doesn't stay checked
[ http://jira.codehaus.org/browse/CONTINUUM-1103?page=all ] Teodoro Cue Jr. updated CONTINUUM-1103: --- Attachment: CONTINUUM-1103-continuum-core.patch Seems that buildFresh was not copied to the object being stored. > Build Fresh checkbox doesn't stay checked > - > > Key: CONTINUUM-1103 > URL: http://jira.codehaus.org/browse/CONTINUUM-1103 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Wendy Smoak > Assigned To: Teodoro Cue Jr. > Attachments: buildFresh.patch, CONTINUUM-1103-continuum-core.patch, > jpox1.1.3.patch > > > To reproduce: > Project Groups -> [any group] -> Build Definitions tab > 1. Edit a build definition > 2. check the 'Build Fresh' checkbox > 3. Save > 4. Edit the same build definition > The checkbox should remain checked, but it does not. -- 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: (MASSEMBLY-158) tempRoot directory not created, exceptions thrown when filtering files
[ http://jira.codehaus.org/browse/MASSEMBLY-158?page=all ] John Casey closed MASSEMBLY-158. Resolution: Fixed I removed the shutdown hook. > tempRoot directory not created, exceptions thrown when filtering files > -- > > Key: MASSEMBLY-158 > URL: http://jira.codehaus.org/browse/MASSEMBLY-158 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Linux/maven 2.0.4 >Reporter: Daniel Kulp > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > Attachments: assembly_temproot.patch > > > The tempRoot directory isn't actually created before it attempts to write > files into it. Thus, creation of the files fails with FileNotFound > exceptions. > The patch forces the directory to be created at the start of execute() and > clears it up at the end.It also updates the > org/apache/maven/plugin/assembly/format/FileFormatter.java to make sure the > directory is created first. -- 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-1133) Project Site URL in wagon notifier edit pages is required but doesn't have validation
[ http://jira.codehaus.org/browse/CONTINUUM-1133?page=all ] Henry S. Isidro updated CONTINUUM-1133: --- Attachment: [CONTINUUM-1133]-continuum-webapp.patch-2 File Attached: [CONTINUUM-1133]-continuum-webapp.patch-2 The first patch is incorrect, it only validates an ordinary URL, whereas wagon uses URLs like dav:http:// The second patch has a custom validator for this. > Project Site URL in wagon notifier edit pages is required but doesn't have > validation > - > > Key: CONTINUUM-1133 > URL: http://jira.codehaus.org/browse/CONTINUUM-1133 > Project: Continuum > Issue Type: Bug > Components: Notification Subsystem >Reporter: Henry S. Isidro >Priority: Minor > Attachments: [CONTINUUM-1133]-continuum-webapp.patch, > [CONTINUUM-1133]-continuum-webapp.patch-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] Created: (MNG-2758) Circular Dependency which shouldn't be
Circular Dependency which shouldn't be -- Key: MNG-2758 URL: http://jira.codehaus.org/browse/MNG-2758 Project: Maven 2 Issue Type: Bug Components: Dependencies Reporter: Andrew Franklin Attachments: circular-test-case.tar.gz I've got a situation where Maven is telling me I have a circular dependency that should be resolved. Let's say I've got applicationArtifact which provides an interface which I want to consume at compile time in an artifact called pluginArtifact. When applicationArtifact is ready to be packaged, I want to include pluginArtifact in the libs as a runtime dependency. ie. applicationArtifact pluginArtifact runtime pluginArtifact applicationArtifact compile Maven won't compile the above as it cites a circular dependency. This should work because of the following valid order: 1) compile applicationArtifact (ignore pluginArtifact because it's scoped at Runtime) 2) compile pluginArtifact (include a compile time reference to applicationArtifact) 3) package applicationArtifact (which drags in pluginArtifact) I should also mention the circular dependency comes about because I have a parent pom to these 2 projects which defines them each as modules... ie. parentProject applicationArtifact pluginArtifact -- 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: (MASSEMBLY-161) Archive Configuration ignored
[ http://jira.codehaus.org/browse/MASSEMBLY-161?page=all ]
John Casey closed MASSEMBLY-161.
Assignee: John Casey
Resolution: Fixed
fixed, deployed snapshot should be hitting the repository in a minute.
> Archive Configuration ignored
> -
>
> Key: MASSEMBLY-161
> URL: http://jira.codehaus.org/browse/MASSEMBLY-161
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Martin Sturzenhecker
> Assigned To: John Casey
>Priority: Blocker
> Fix For: 2.2
>
>
> I'd like to create executable .jar files.
> I tried
> {code:xml}
>
>
> makeExecJar_1
> package
>
> attached
>
>
>
> assembly/my-assembly.xml
>
> ../../target/dist/final-1
>
> false
>
> my.package.MyMainClass
>
>
>
>
>
> {code}
> as well as
> {code:xml}
>
>
> makeExecJar_1
> package
>
> attached
>
>
>
> assembly/my-assembly.xml
>
> ../../target/dist/final-1
>
> false
> MY_MANIFEST.MF
>
>
>
>
> {code}
> The result is the same. In the final jar file
> * maven descriptors are added
> * standard {{MANIFEST.MF}} is 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] Closed: (MASSEMBLY-174) Regression bug with 2.2-SNPASHOT: archive configuration is not taken into account
[ http://jira.codehaus.org/browse/MASSEMBLY-174?page=all ] John Casey closed MASSEMBLY-174. Assignee: John Casey Resolution: Fixed Fixed snapshot should be hitting the repository in a minute. > Regression bug with 2.2-SNPASHOT: archive configuration is not taken into > account > - > > Key: MASSEMBLY-174 > URL: http://jira.codehaus.org/browse/MASSEMBLY-174 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Maven 2.04 - 2.0.x >Reporter: Emmanuel Hugonnet > Assigned To: John Casey >Priority: Blocker > Fix For: 2.2 > > > With the 2.2-SNAPSHOT (maven-assembly-plugin-2.2-20070105.002350-29) the > archive configuration (manifest, manifestEntries, etc.) are not used when > building a jar with the assembly plugin. If I move back to the 2.1 all 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: (MASSEMBLY-121) Custom manifest attributres are ignored.
[ http://jira.codehaus.org/browse/MASSEMBLY-121?page=all ]
John Casey closed MASSEMBLY-121.
Assignee: John Casey
Resolution: Fixed
Fixed version should be hitting snapshot repository in a minute.
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
> Assigned To: John Casey
> Fix For: 2.2
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
>
> ${project.build.directory}
>
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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: (MASSEMBLY-172) Extension-Name and Specification-Title added to MANIFEST.MF
[ http://jira.codehaus.org/browse/MASSEMBLY-172?page=all ] John Casey closed MASSEMBLY-172. Assignee: John Casey Resolution: Fixed should be working now. try using the same override that the jar plugin uses. > Extension-Name and Specification-Title added to MANIFEST.MF > --- > > Key: MASSEMBLY-172 > URL: http://jira.codehaus.org/browse/MASSEMBLY-172 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Heinrich Nirschl > Assigned To: John Casey >Priority: Minor > Fix For: 2.2 > > > The assembly plugin (at least when using the predefined descriptor > jar-with-dependencies; I did not check others) adds the Extension-Name and > Specification-Title attributes to the generated jar. See also MJAR-38 which > describes the same problem for the jar plugin. > Here is the configuration I used: > ... > > maven-assembly-plugin > > > jar-with-dependencies > > > > > example.Main > > > > > > ... -- 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
