[jira] Commented: (MASSEMBLY-29) Possibility to aggrates sources from other modules
[ http://jira.codehaus.org/browse/MASSEMBLY-29?page=comments#action_61362 ] Allan Ramirez commented on MASSEMBLY-29: You mean that all the sources from the submodules would be bundled into one jar? > Possibility to aggrates sources from other modules > -- > > Key: MASSEMBLY-29 > URL: http://jira.codehaus.org/browse/MASSEMBLY-29 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Alexandre Poitras > Fix For: 2.1 > > > It would be nice if it was possible to aggregate the sources of the other > sibling modules instead of having to archive different jar files containing > the sources. I would like also to be able to do that with Javadoc but I think > it's already in the scope of the javadoc 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] Updated: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=all ] John Tolentino updated MWAR-26: --- Attachment: MWAR-26-maven-war-plugin-2.diff > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-255) Problem with junit-addons 1.4
[ http://jira.codehaus.org/browse/MEV-255?page=all ] Carlos Sanchez closed MEV-255: -- Resolution: Fixed > Problem with junit-addons 1.4 > - > > Key: MEV-255 > URL: http://jira.codehaus.org/browse/MEV-255 > Project: Maven Evangelism > Type: Task > Reporter: David Eric Pugh > Assignee: Carlos Sanchez > > > junit-addons's M2 pom: > http://www.ibiblio.org/maven2/junit-addons/junit-addons/1.4/junit-addons-1.4.pom > says taht it depends on junit-addons-runner-1.0-alpha1. However, this jar > doesn't exist on ibiblio or Maven2 repositories. Additionally, > www.ibiblio.org/maven/junit-addons/jars/ didn't have it either. -- 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: (MWAR-26) Do not overwrite target unless source is modified
[ http://jira.codehaus.org/browse/MWAR-26?page=all ] Edwin Punzalan closed MWAR-26: -- Resolution: Fixed Patch applied. Thanks. > Do not overwrite target unless source is modified > - > > Key: MWAR-26 > URL: http://jira.codehaus.org/browse/MWAR-26 > Project: Maven 2.x War Plugin > Type: Bug > Reporter: Andres March > Assignee: John Tolentino > Fix For: 2.0 > Attachments: MWAR-26-maven-war-plugin-2.diff, MWAR-26-maven-war-plugin.diff > > Time Spent: 3 hours, 40 minutes >Remaining: 0 minutes > > I thought MWAR-8 had fixed my issue but it seems to still exist. Correct me > if I'm wrong but doing incremental builds with this war plugin is not > possible. All the web app sources get overwritten regardless if they have > been modified or not. Incremental build were possible in Maven 1 because it > was ANT based. This version uses plexus FileUtils which overwrites without > regard to if the target file exists or older than the source. Besides the > time issue, overwriting the web.xml each time makes my context reload since > the context runs on tomcat from the target location. I think this is a > reasonable configuration but if there is a better way, let me know. Building > inplace wars is not an option as it dirties the source. > If we are in agreement, I may be able to provide a patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository - Key: MIDEA-39 URL: http://jira.codehaus.org/browse/MIDEA-39 Project: Maven 2.x Idea Plugin Type: Improvement Versions: 2.0 Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 Reporter: Vikash Ramanlal Priority: Minor When I generate my idea files using "mvn idea:idea", all works fine. However if I have module a and module b (both jar packaging) and b depends on a, then I expected the idea plugin to generate the project files such that for module b, a is a dependent module. However what I get is a library entry for a that points to a jar in the local repository. Maven 1.0.2 idea plugin did not work this way. I created the module dependencies in correctly in the idea project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-61) Adding custom source paths to javadoc
Adding custom source paths to javadoc
-
Key: MJAVADOC-61
URL: http://jira.codehaus.org/browse/MJAVADOC-61
Project: Maven 2.x Javadoc Plugin
Type: New Feature
Versions: 2.0-beta-3
Environment: FedoreCore 4 kernel 2.6.10-1.760_FC3smp #1
Reporter: Erik van Zijst
I have a code generator that creates sources during the compile stage. These
sources end up in a custom directory
(${project.build.directory}/generated-sources/main/java). The problem is that
javadoc skips these files when it generates the documentation. What I'm looking
for is a way to manipulate javadoc's sourcefilenames argument.
I have already tried adding
${project.build.directory}/generated-sources/main/java
to the code generation step, but it didn't affect javadoc.
--
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-634) Add notion of top level project with modules to prevent notification floods
Add notion of top level project with modules to prevent notification floods --- Key: CONTINUUM-634 URL: http://jira.codehaus.org/browse/CONTINUUM-634 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.3 Reporter: Vincent Massol Take the Maven project which has tens of modules. If a change is made in some core part, then lots of modules get rebuilt generating a flood of notification emails... If continuum knew about the list of modules making a project, then it could decide which module need rebuilding and only send a single email for all modules belonging to a project after they have been 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] Commented: (MNG-2050) Classloader.getResource() doesn't encode blanks
[ http://jira.codehaus.org/browse/MNG-2050?page=comments#action_61369 ]
Roland Kofler commented on MNG-2050:
I am not a comitter but a simple user that discovered this issue.
> Classloader.getResource() doesn't encode blanks
> ---
>
> Key: MNG-2050
> URL: http://jira.codehaus.org/browse/MNG-2050
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.0.1
> Environment: win xp
> Reporter: Roland Kofler
>
>
> When I'm executing an
> getClass().getClassLoader().getResource(s);
> it gives back an URL encoded string in eclipse while Maven2 gives me blanks
> in my URL:
> * eclipse
>
> file:/C:/Dokumente%20und%20Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> *maven2
> file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> MY PROBLEM WITH THIS:
> Because of this behaviour a
> new URI("file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg")
> throws a URISyntaxException.
--
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-2050) Classloader.getResource() doesn't encode blanks
[ http://jira.codehaus.org/browse/MNG-2050?page=comments#action_61370 ]
Carlos Sanchez commented on MNG-2050:
-
I think you are misunderstanding something.
When do you execute getClass().getClassLoader().getResource(s), in a maven
plugin , in a unit test,...???
> Classloader.getResource() doesn't encode blanks
> ---
>
> Key: MNG-2050
> URL: http://jira.codehaus.org/browse/MNG-2050
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.0.1
> Environment: win xp
> Reporter: Roland Kofler
>
>
> When I'm executing an
> getClass().getClassLoader().getResource(s);
> it gives back an URL encoded string in eclipse while Maven2 gives me blanks
> in my URL:
> * eclipse
>
> file:/C:/Dokumente%20und%20Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> *maven2
> file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> MY PROBLEM WITH THIS:
> Because of this behaviour a
> new URI("file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg")
> throws a URISyntaxException.
--
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-2050) Classloader.getResource() doesn't encode blanks
[ http://jira.codehaus.org/browse/MNG-2050?page=comments#action_61371 ]
Carlos Sanchez commented on MNG-2050:
-
and have you tried 2.0.2 ?
> Classloader.getResource() doesn't encode blanks
> ---
>
> Key: MNG-2050
> URL: http://jira.codehaus.org/browse/MNG-2050
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.0.1
> Environment: win xp
> Reporter: Roland Kofler
>
>
> When I'm executing an
> getClass().getClassLoader().getResource(s);
> it gives back an URL encoded string in eclipse while Maven2 gives me blanks
> in my URL:
> * eclipse
>
> file:/C:/Dokumente%20und%20Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> *maven2
> file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> MY PROBLEM WITH THIS:
> Because of this behaviour a
> new URI("file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg")
> throws a URISyntaxException.
--
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: (MIDEA-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=comments#action_61372 ] Geoffrey De Smet commented on MIDEA-34: --- 1)One problem with setting resources as a source filter was that IntelliJ filters it's source dirs and doesn't include png etc by default. But that was fixed in http://jira.codehaus.org/browse/MIDEA-18 2) Another problem is the order of who copies the resources, but if you set Intellij to save on windows deactivation and synch on window activition (as you should if you 're using it combined with maven), that does't matter. 3) Another problem might be filtered resources. But I strongly believe this is a maven design flaw: resources that are filtered/transformed should be in a different directly then normal resources that aren't filtered/transformed. > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Critical > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-153) Continuum fails while trying to build from clearcase
[ http://jira.codehaus.org/browse/SCM-153?page=comments#action_61374 ] Kjetil Ødegaard commented on SCM-153: - I don't know if this is related, but I also get the "A registry entry already exists" every time I try to build a ClearCase project from Continuum. "scm:update" works fine from the command line. > Continuum fails while trying to build from clearcase > > > Key: SCM-153 > URL: http://jira.codehaus.org/browse/SCM-153 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-clearcase > Versions: 1.0 > Environment: Clearcase UCM / Windows XP / Snapshot view > Reporter: David Dandeneau > > > When trying to perform a build from continuum I receive the following error: > Provider message: The cleartool command failed. > Command output: > --- > cleartool: Error: A registry entry already exists for > "dandendj-LNGDAYD-4130684-maven-7". > --- > This happens on the second time through. On the first time through I receive: > org.apache.maven.continuum.execution.ContinuumBuildExecutorException: Could > not find Maven project descriptor. > at > org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:111) > at > org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:62) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:169) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:53) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGECLIPSE-88) doesn't make use of ~/.m2/settings.xml
doesn't make use of ~/.m2/settings.xml -- Key: MNGECLIPSE-88 URL: http://jira.codehaus.org/browse/MNGECLIPSE-88 Project: Maven 2.x Extension for Eclipse Type: Improvement Versions: 0.0.5 Environment: linux Reporter: Jacek Gerbszt Assigned to: Eugene Kuleshov Priority: Minor Attachments: Maven2Executor.diff Mavenide doesn't make any use of user's settings. It can be fix by a single line of code in Maven2Executor class, because the latest maven-embedder lib, version 2.0.3-SNAPSHOT allows to align maven with a user installation. Maven-embedder lib have to be replaced, of course. -- 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-2156) maven-jar-plugin doesn't accept element in configuration
maven-jar-plugin doesn't accept element in configuration --- Key: MNG-2156 URL: http://jira.codehaus.org/browse/MNG-2156 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.2 Reporter: Sachin Patel Priority: Blocker The maven-jar-plugin does not accept the manfiestFile element in the configuration as advertised. The error reported is... [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-jar-plugin:2.1-SNAPSHOT Cause: Cannot find setter nor field in org.apache.maven.archiver.ManifestConfiguration for 'manifestFile' Need to mark this as a blocker as their is no way to merge an existing MANFIEST that is needed to build an eclipse-plugin. The MANIFEST entries cannot be respecified in the plugin configuration because this would break running the plugin in a eclipse runtime-workbench. Keeping the manifest entires in the POM and in the MANIFEST file synchronized is too much maintainance. Need to support merging an existing manifest file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2156) maven-jar-plugin doesn't accept element in configuration
[ http://jira.codehaus.org/browse/MNG-2156?page=comments#action_61375 ] Sachin Patel commented on MNG-2156: --- The element works, the plugin documentation is incorrect and should be updated. The manifestFile element needs to be specified under not under org.apache.maven.plugins maven-jar-plugin META-INF/MANIFEST.MF lowering severity > maven-jar-plugin doesn't accept element in configuration > --- > > Key: MNG-2156 > URL: http://jira.codehaus.org/browse/MNG-2156 > Project: Maven 2 > Type: Bug > Components: Plugins and Lifecycle > Versions: 2.0.2 > Reporter: Sachin Patel > Priority: Blocker > > > The maven-jar-plugin does not accept the manfiestFile element in the > configuration as advertised. The error reported is... > [INFO] Failed to configure plugin parameters for: > org.apache.maven.plugins:maven-jar-plugin:2.1-SNAPSHOT > Cause: Cannot find setter nor field in > org.apache.maven.archiver.ManifestConfiguration for 'manifestFile' > Need to mark this as a blocker as their is no way to merge an existing > MANFIEST that is needed to build an eclipse-plugin. The MANIFEST entries > cannot be respecified in the plugin configuration because this would break > running the plugin in a eclipse runtime-workbench. Keeping the manifest > entires in the POM and in the MANIFEST file synchronized is too much > maintainance. Need to support merging an existing manifest file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-88) doesn't make use of ~/.m2/settings.xml
[ http://jira.codehaus.org/browse/MNGECLIPSE-88?page=all ] Eugene Kuleshov closed MNGECLIPSE-88: - Resolution: Duplicate > doesn't make use of ~/.m2/settings.xml > -- > > Key: MNGECLIPSE-88 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-88 > Project: Maven 2.x Extension for Eclipse > Type: Improvement > Versions: 0.0.5 > Environment: linux > Reporter: Jacek Gerbszt > Assignee: Eugene Kuleshov > Priority: Minor > Attachments: Maven2Executor.diff > > > Mavenide doesn't make any use of user's settings. It can be fix by a single > line of code in Maven2Executor class, because the latest maven-embedder lib, > version 2.0.3-SNAPSHOT allows to align maven with a user installation. > Maven-embedder lib have to be replaced, of course. -- 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: (MPLUGIN-14) Document how to define new lifecycle
Document how to define new lifecycle Key: MPLUGIN-14 URL: http://jira.codehaus.org/browse/MPLUGIN-14 Project: Maven 2.x Plugin Plugin Type: Improvement Versions: 2.1 Reporter: Andreas Ebbert-Karroum Please update the documentation [1] to include how the plexus/components.xml can be included in the plugin, so that a new lifecycle or artifact handler can be defined, as described here [2]. It took me a week to find out (and also the mailing list was no big help BTW). The solution is really simple, but if you don't know how to do it, it's not obvious. I've described it in my mail [3]. [1] http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html [2] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [3] http://www.mail-archive.com/users@maven.apache.org/msg37705.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] Commented: (MNG-2050) Classloader.getResource() doesn't encode blanks
[ http://jira.codehaus.org/browse/MNG-2050?page=comments#action_61380 ]
Gili commented on MNG-2050:
---
Yes, this is being executed in a unit test and it is failing horribly :) Works
perfectly in Maven 1 though. Yes, I have tried 2.0.2 and it has the same
problem.
> Classloader.getResource() doesn't encode blanks
> ---
>
> Key: MNG-2050
> URL: http://jira.codehaus.org/browse/MNG-2050
> Project: Maven 2
> Type: Bug
> Components: General
> Versions: 2.0.1
> Environment: win xp
> Reporter: Roland Kofler
>
>
> When I'm executing an
> getClass().getClassLoader().getResource(s);
> it gives back an URL encoded string in eclipse while Maven2 gives me blanks
> in my URL:
> * eclipse
>
> file:/C:/Dokumente%20und%20Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> *maven2
> file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg
> MY PROBLEM WITH THIS:
> Because of this behaviour a
> new URI("file:/C:/Dokumente und
> Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg")
> throws a URISyntaxException.
--
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-32) Plugin test harness
[ http://jira.codehaus.org/browse/MNG-32?page=all ] Jesse McConnell updated MNG-32: --- Attachment: maven-project.patch > Plugin test harness > --- > > Key: MNG-32 > URL: http://jira.codehaus.org/browse/MNG-32 > Project: Maven 2 > Type: Task > Components: Sandbox, Plugin API, Design, Patterns & Best Practices > Reporter: Jason van Zyl > Assignee: Jesse McConnell > Priority: Blocker > Attachments: compiler-harness.patch, jar-harness.patch, > maven-compiler-plugin.jar, maven-jar-plugin.jar, maven-project.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_61392 ] Jochen Kuhnle commented on MNGECLIPSE-59: - I tried applying the attached patch (EclipseArtifactResolver.patch), but it seems garbled starting with line 862. Looks like a comparison with a unicode encoded file wend wrong... Is there a correct version available? > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Fix For: 1.0.0 > Attachments: EclipseArtifactResolver.patch, > maven-embedder-2.1-SNAPSHOT-dep.jar > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-360) nanocontainer has invalid xpp3 dependency
nanocontainer has invalid xpp3 dependency - Key: MEV-360 URL: http://jira.codehaus.org/browse/MEV-360 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Wayne Fay http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-RC-3/nanocontainer-1.0-RC-3.pom nanocontainer nanocontainer NanoContainer Core 1.0-RC-3 ... xpp3 xpp3 1.1.3.4-RC8_min This should be updated to use a classifier instead: xpp3 xpp3 1.1.3.4-RC8_min RC8_min -- 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-360) nanocontainer has invalid xpp3 dependency
[ http://jira.codehaus.org/browse/MEV-360?page=comments#action_61393 ] Wayne Fay commented on MEV-360: --- Oops... That should have been: This should be updated to use a classifier instead: xpp3 xpp3 1.1.3.4 RC8_min > nanocontainer has invalid xpp3 dependency > - > > Key: MEV-360 > URL: http://jira.codehaus.org/browse/MEV-360 > Project: Maven Evangelism > Type: Improvement > Components: Dependencies > Reporter: Wayne Fay > > > http://www.ibiblio.org/maven2/nanocontainer/nanocontainer/1.0-RC-3/nanocontainer-1.0-RC-3.pom > nanocontainer > nanocontainer > NanoContainer Core > 1.0-RC-3 > ... > > xpp3 > xpp3 > 1.1.3.4-RC8_min > > This should be updated to use a classifier instead: > > xpp3 > xpp3 > 1.1.3.4-RC8_min > RC8_min > -- 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-361) picocontainer has invalid xpp3 dependency
picocontainer has invalid xpp3 dependency - Key: MEV-361 URL: http://jira.codehaus.org/browse/MEV-361 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: Wayne Fay http://www.ibiblio.org/maven2/picocontainer/picocontainer/1.2-RC-2/picocontainer-1.2-RC-2.pom picocontainer picocontainer PicoContainer Core 1.2-RC-2 ... xpp3 xpp3 1.1.3.4-RC8_min This should be updated to use a classifier instead: xpp3 xpp3 1.1.3.4 RC8_min -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_61396 ] Mark J. Sinke commented on MNGECLIPSE-59: - Jochen, I apologize for the issue with the patch file. I'll try and fix the patch this weekend or the Monday after and upload a better version. I'm fairly new to SVN patches and I'm pretty sure the error is human (that is, on my side :-( ). > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Type: New Feature > Components: Dependency Resolver > Versions: 0.0.4 > Reporter: Leonardo Quijano Vincenzi > Assignee: Eugene Kuleshov > Fix For: 1.0.0 > Attachments: EclipseArtifactResolver.patch, > maven-embedder-2.1-SNAPSHOT-dep.jar > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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-1665) allow changing plexus components implementations dynamically through embedder
[ http://jira.codehaus.org/browse/MNG-1665?page=comments#action_61397 ] Mark J. Sinke commented on MNG-1665: Milos, That is exactly right. The Plexus Embedder that is passed to lookupComponents is preloaded with the maven-embedder plexus.xml and dependent component.xml files, but you can access and tweak the model, before any lookups happen (and hence, before any objects get created). So, yes, your object will get subsituted for all ArtifactResolvers in the entire container object graph (or any other component you wish to subsititute). I did the same thing - I started out with delegation of most of the ArtifactManager to its original version. However, I quickly found that internally, the DefaultArtifactResolver sometimes calls resolve(), which I had to get access to as well. Hence I decided to subclass the original implementation, which of course introduces tighter coupling. I assumed that was the price to pay at the moment ... > allow changing plexus components implementations dynamically through embedder > - > > Key: MNG-1665 > URL: http://jira.codehaus.org/browse/MNG-1665 > Project: Maven 2 > Type: New Feature > Components: Embedding > Reporter: Milos Kleint > Attachments: custom-config.patch > > > when running in the IDE one might have special requirements on Artifact > resolution, handling, output handling or any other aspect of the maven > environment. > it would be nice to be able to replace the default implementations with > custom ones for that matter. The most natural place seems to be the embedder > class. > example usecase. > When resolving dependencies for a project (even transitively), I would like > 1. to know what deps were not resolved correctly, 2. avoid downloading the > dependencies at certain times. -- 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: (MPCHANGELOG-85) Download of changelog plugin fails due to unresolved artifact
Download of changelog plugin fails due to unresolved artifact - Key: MPCHANGELOG-85 URL: http://jira.codehaus.org/browse/MPCHANGELOG-85 Project: maven-changelog-plugin Type: Bug Reporter: Markus Klink I have configured changelog as follows: org.codehaus.mojo changelog-maven-plugin 2.0-beta-1 range 30 -MM-dd When trying to generate the site I get an error that it failed to resolve artifact org.netbeans:lib:jar:3.6 Before I got a warning that this artifact had been relocated from netbeans:cvslib:3.6 Trying with 2.0-beta-2-SNAPSHOT did not help either. Thanks for taking care. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-78) create eclipse projects which are m2eclipse ready
create eclipse projects which are m2eclipse ready - Key: MECLIPSE-78 URL: http://jira.codehaus.org/browse/MECLIPSE-78 Project: Maven 2.x Eclipse Plugin Type: New Feature Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven 2.0.2 Reporter: Joshua Nichols WIth the recent development of the m2eclipse plugin, I believe it is useful to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from the start. One of the advantages of using m2eclipse is that you don't have to rerun eclipse:eclipse when you update any dependencies. A few things are necessary to accomplish this, in terms of changes to .classpath and .project. .project needs a new nature and builder added. For the builder: org.maven.ide.eclipse.maven2Builder For the nature: org.maven.ide.eclipse.maven2Nature In the .classpath, we need to add: In .classpath, you also don't want entries , because they would conflict with m2eclipse setting up the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-78) create eclipse projects which are m2eclipse ready
[ http://jira.codehaus.org/browse/MECLIPSE-78?page=all ] Joshua Nichols updated MECLIPSE-78: --- Attachment: m2eclipse.patch > create eclipse projects which are m2eclipse ready > - > > Key: MECLIPSE-78 > URL: http://jira.codehaus.org/browse/MECLIPSE-78 > Project: Maven 2.x Eclipse Plugin > Type: New Feature > Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven 2.0.2 > Reporter: Joshua Nichols > Attachments: m2eclipse.patch > > > WIth the recent development of the m2eclipse plugin, I believe it is useful > to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from > the start. One of the advantages of using m2eclipse is that you don't have to > rerun eclipse:eclipse when you update any dependencies. > A few things are necessary to accomplish this, in terms of changes to > .classpath and .project. > .project needs a new nature and builder added. For the builder: > > org.maven.ide.eclipse.maven2Builder > > > For the nature: > org.maven.ide.eclipse.maven2Nature > In the .classpath, we need to add: >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > In .classpath, you also don't want entries path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict > with m2eclipse setting up the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRAR-4) Rar Plugin should allow the user to set "rarName" like "jarName" in Jar Plugin
Rar Plugin should allow the user to set "rarName" like "jarName" in Jar Plugin -- Key: MRAR-4 URL: http://jira.codehaus.org/browse/MRAR-4 Project: Maven 2.x Rar Plugin Type: New Feature Versions: 2.2 Reporter: Jian Wu In RarMojo.java, rarName has been set as @readonly which prevent the user from setting the final rarName in pom.xml. I think that the "rarName' is like "jarName" in Jar Plugin which should allow the user to set the final rar name in pom.xml unless there is a specific reason not doing so. And, this can simply be done by removing the annotation in the source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-87) Enabling Maven on a project does not change the context sensitive menu
[ http://jira.codehaus.org/browse/MNGECLIPSE-87?page=comments#action_61408 ] Robert Elliot commented on MNGECLIPSE-87: - Narrowed it down - it's J2EE Standard Tools (JST) 1.0.1 that causes the problem. And it definitely does it to the Spring plugin, too - incorrect visibility context menus appearing. I'll look for/raise a bug over at Eclipse. > Enabling Maven on a project does not change the context sensitive menu > -- > > Key: MNGECLIPSE-87 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-87 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.5 > Environment: Eclipse 3.2 M5a > Reporter: Robert Elliot > Assignee: Eugene Kuleshov > > > 1) Create a new Java project in Eclipse 3.2 M5a > 2) Right click on the project, and in the resulting context sensitive menu go > to Maven2 -> Enable > 3) Complete the wizard, making this a Maven enabled project > 4) Notice that the Maven nature & builder is correctly added to the .project > file > 5) Notice that the Maven icon is not added to the Project > 6) Right click on the project, and in the resulting context sensitive menu go > to Maven2. Notice that the only available option is still "Enable" - you > cannot disable or add dependencies. > 7) Notice that you can right-click on the pom and add dependencies. > No errors in the m2 console, nor anything immediately obvious in the debug > output. Don't currently understand Eclipse plugins well enough to work it > out from the code. -- 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-1954) Need better handling of malformed poms in local cache, like check for an update every run
[ http://jira.codehaus.org/browse/MNG-1954?page=all ] ruel loehr updated MNG-1954: Attachment: MNG-1954.txt > Need better handling of malformed poms in local cache, like check for an > update every run > - > > Key: MNG-1954 > URL: http://jira.codehaus.org/browse/MNG-1954 > Project: Maven 2 > Type: Improvement > Components: Artifacts and Repositories > Versions: 2.0 > Reporter: Steve Loughran > Attachments: MNG-1954.txt > > > If a pom has a typo in it, it is downloaded and parsed with a (misspelled) > error message printed > [m2:libraries] [WARNING] POM for > 'org.hibernate:hibernate-tools:pom:3.1.0.beta2' is invalid. It will be > ignored for artifact resolution. Reason: Parse error reading POM. Reason: > expected > to finsh end tag not < from line 7 (position: TEXT seen > ...\r\n but if the pom is corrected in the source repository, the local system doesnt > check for a change, it just goes with what is there. > Invalid pom files should be remembered and replacements looked for, because > there is no value in retaining them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1954) Need better handling of malformed poms in local cache, like check for an update every run
[ http://jira.codehaus.org/browse/MNG-1954?page=comments#action_61410 ] ruel loehr commented on MNG-1954: - I made a patch which resolves the above issue. When the defaultArtifactResolver is handed an artifact to resolve, if that artifact is already located in the local cache, it evaluates the hash values of the files compared to those in the remote repo. If the values differ it will attempt to pull down the remote artifact. > Need better handling of malformed poms in local cache, like check for an > update every run > - > > Key: MNG-1954 > URL: http://jira.codehaus.org/browse/MNG-1954 > Project: Maven 2 > Type: Improvement > Components: Artifacts and Repositories > Versions: 2.0 > Reporter: Steve Loughran > Attachments: MNG-1954.txt > > > If a pom has a typo in it, it is downloaded and parsed with a (misspelled) > error message printed > [m2:libraries] [WARNING] POM for > 'org.hibernate:hibernate-tools:pom:3.1.0.beta2' is invalid. It will be > ignored for artifact resolution. Reason: Parse error reading POM. Reason: > expected > to finsh end tag not < from line 7 (position: TEXT seen > ...\r\n but if the pom is corrected in the source repository, the local system doesnt > check for a change, it just goes with what is there. > Invalid pom files should be remembered and replacements looked for, because > there is no value in retaining them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-87) Enabling Maven on a project does not change the context sensitive menu
[ http://jira.codehaus.org/browse/MNGECLIPSE-87?page=comments#action_61411 ] Robert Elliot commented on MNGECLIPSE-87: - Eclipse bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=132419 > Enabling Maven on a project does not change the context sensitive menu > -- > > Key: MNGECLIPSE-87 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-87 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.5 > Environment: Eclipse 3.2 M5a > Reporter: Robert Elliot > Assignee: Eugene Kuleshov > > > 1) Create a new Java project in Eclipse 3.2 M5a > 2) Right click on the project, and in the resulting context sensitive menu go > to Maven2 -> Enable > 3) Complete the wizard, making this a Maven enabled project > 4) Notice that the Maven nature & builder is correctly added to the .project > file > 5) Notice that the Maven icon is not added to the Project > 6) Right click on the project, and in the resulting context sensitive menu go > to Maven2. Notice that the only available option is still "Enable" - you > cannot disable or add dependencies. > 7) Notice that you can right-click on the pom and add dependencies. > No errors in the m2 console, nor anything immediately obvious in the debug > output. Don't currently understand Eclipse plugins well enough to work it > out from the code. -- 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: (MPJALOPY-10) Jalopy removes import statements
[ http://jira.codehaus.org/browse/MPJALOPY-10?page=comments#action_61413 ] Lukas Theussl commented on MPJALOPY-10: --- The jalopy plugin 1.3.1 works fine for me (m11b3, java 1.4.2, Linux FC3), but I can't get it to work with the jalopy 1.5b5 or 1.5rc3 releases for various reasons. One is apparently a known problem with the ant plugin: http://tinyurl.com/onvfr , the other probably a dependency issue (eg I had to revert jdom to 1.0b8 as there was an incompatible change between 1.0b8 and 1.0). I am wondering if we shouldn't revert the plugin to the state of the 1.3.1 release to include in m11b3. > Jalopy removes import statements > > > Key: MPJALOPY-10 > URL: http://jira.codehaus.org/browse/MPJALOPY-10 > Project: maven-jalopy-plugin > Type: Bug > Versions: 1.4.1 > Environment: WinXP, JDK 1.5 > Reporter: Wendy Smoak > Fix For: 1.4.1 > > > Upgrading to the latest 1.4.1 snapshot results in import statements being > removed from code. > Steps to reproduce: > maven plugin:download -DgroupId=maven -DartifactId=maven-jalopy-plugin > -Dversion=1.4.1-SNAPSHOT > -Dmaven.repo.remote=http://cvs.apache.org/repository/ > mkdir testapp > cd testapp > maven genapp (answer questions) > maven jar(works fine) > maven jalopy (output lists 'removing unused import...') > maven jar(tests fail-- import statements have been removed) > Advice on how to revert to Jalopy 1.0b11 would be appreciated, as the 1.3.1 > release fails with a NoClassDefFound error. > Relevant mailing list threads: > * http://www.nabble.com/Jalopy-plugin-problem-t1098724.html > * http://www.nabble.com/-m1-Jalopy-plugin-problems-t1080969.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] Commented: (MPJALOPY-9) Jalopy Classes not found
[ http://jira.codehaus.org/browse/MPJALOPY-9?page=comments#action_61414 ] Lukas Theussl commented on MPJALOPY-9: -- I am not sure this is the right fix for this problem: how can the root classloader fix a ClassCastException? I checked that going back to the configuration of the 1.3.1 release of the jalopy plugin, everything works for me without having to specify the root class loader. I have no idea though where the CCE above is coming from. I'd suspect a configuration problem, since, as Wendy points out herself, it still works for other people. On the other hand, the jalopy plugin 1.4 seems completely borked, see my comment at MPJALOPY-10. > Jalopy Classes not found > > > Key: MPJALOPY-9 > URL: http://jira.codehaus.org/browse/MPJALOPY-9 > Project: maven-jalopy-plugin > Type: Bug > Versions: 1.3.1, 1.4 > Reporter: Arnaud Heritier > Assignee: Arnaud Heritier > Priority: Blocker > Fix For: 1.4.1 > > > Mail from Wendy Smoak : > Twice now, on two different machines (same codebase, though,) the > Jalopy plugin was working fine and then suddenly stopped working with > the error below. > Full output of maven jalopy -X is here: > http://wiki.wsmoak.net/cgi-bin/wiki.pl?Maven/Jalopy > The only thing that changed was Jalopy's config file. Reverting those > changes to a known good state didn't help. Other developers on the > project aren't having any trouble. Obviously I've done *something* to > it (twice!) but I have no idea what. > Does anyone see anything that looks suspicious? > -Wendy > /svn/struts/current/action > $ maven jalopy > __ __ > | \/ |__ _Apache__ ___ > | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ > |_| |_\__,_|\_/\___|_||_| v. 1.0.2 > java.lang.ClassCastException: java.lang.String >at > de.hunsicker.jalopy.storage.Convention.synchronize(Convention.java:24 > 19) >at > de.hunsicker.jalopy.storage.Convention.synchronize(Convention.java:24 > 45) >at de.hunsicker.jalopy.storage.Convention.(Convention.java:211) >at de.hunsicker.jalopy.plugin.ant.AntPlugin.(AntPlugin.java:60) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct > orAccessorImpl.java:39) >at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC > onstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:494) >at > org.apache.tools.ant.AntClassLoader.initializeClass(AntClassLoader.ja > va:490) >at > org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:231) >at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:162) >at org.apache.tools.ant.Task.perform(Task.java:341) >at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185) > ... > build:start: > jalopy:taskdef: > java:prepare-filesystem: > java:compile: >[echo] Compiling to c:\svn\struts\current\action/target/classes > BUILD FAILED > File.. c:\java\m1-repository\cache\maven-jalopy-plugin-1.3.1\plugin.jelly > Element... ant:jalopy > Line.. 64 > Column 46 > java.lang.NoClassDefFoundError > Total time: 2 seconds > Finished at: Tue Feb 07 22:20:09 GMT-07:00 2006 > Arnaud's note : > I have a similar error with the jalopy plugin 1.4 and maven 1.1 beta 3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2157) Properties defined in top-level profiles.xml do no propagate to child modules
Properties defined in top-level profiles.xml do no propagate to child modules
-
Key: MNG-2157
URL: http://jira.codehaus.org/browse/MNG-2157
Project: Maven 2
Type: Bug
Components: POM
Versions: 2.0.2
Reporter: Jason Dillon
Priority: Blocker
I have a multi-module build, and at the top-level I have a profile called
'release-environment', which is activated by -Denv=release.
I need the local release build to use different values for JDBC configuration
to run integration tests, and defined them in a profiles.xml:
{code}
local-release-environment
env
release
mif_jason
mif_jason
MIF_JASON
{code}
My project looks like:
pom.xml
merchant/pom.xml
merchant/core/pom.xml
merchant/services/pom.xml
If i put profiles.xml as a peer to pom.xml and run {{mvn clean install
-Denv=release}} from the top-level, I get errors because the properties are not
propagated to the merchant/core/pom.xml module.
If I put profiles.xml as a peer to merchant/core/pom.xml and run {{mvn clean
install -Denv=release}}, then it works as expected... properties are set as
they are defined in profiles.xml.
But, this is not manageable, as I need to set some properties for all of the
modules in a multi-module build... But I don't want to use those properties for
all Maven2 projects, so I can not really put it into ~/.m2/settings.xml
I had expected that a top-level profiles.xml would work, but it does not. Is
this by design, is there another recommend way to provide per-top-level
multi-module project configuration on a local user basis (ie. no pom.xml
modifications)?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-64) jar-with-dependencies has a last-one-copies-wins policy which can fail signed jars
[ http://jira.codehaus.org/browse/MASSEMBLY-64?page=comments#action_61420 ]
Napoleon Esmundo C. Ramirez commented on MASSEMBLY-64:
--
The reason why you get that SecurityException when running the uberjar is
because of all the security files in META-INF/ of every dependency accumulates
in the META-INF/ of the uberjar when assembly:assembly is used with the
jar-with-dependencies descriptor. This happens because assembling using
jar-with-dependencies causes maven to unpack all the dependencies (defaults to
true as specified in the ${assembly.dependencySets.dependency.unpack} of
jar-with-dependencies.xml) at the same directory where the uberjar is assembled.
Here are some solutions without removing the security files (removing security
files might have license issues):
A simple fix would be to provide an assembly descriptor similar to the
jar-with-dependencies.xml and modify
${assembly.dependencySets.dependency.unpack} to false so that the security
files in the META-INF/ of every dependency wouldn't mix into the META-INF/ of
the uberjar.
Another fix also would be to provide an assembly descriptor similar to the
jar-with-dependencies.xml and modify
${assembly.dependencySets.dependencySet.outputDirectory} to a directory other
than / so that the security files in the META-INF/ of every dependency would
accumulate in the specified directory, and thus wouldn't mix into the META-INF/
of the uberjar. But I doubt that this would work all the time. it may have
classpath issues (for this issue, the manifest should be modified to provide
the classpath).
> jar-with-dependencies has a last-one-copies-wins policy which can fail signed
> jars
> --
>
> Key: MASSEMBLY-64
> URL: http://jira.codehaus.org/browse/MASSEMBLY-64
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Versions: 2.0.1
> Reporter: Geoffrey De Smet
> Fix For: 2.1
>
>
> I've configured the plugins like this:
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> ggg.GGGStandaloneApp
> true
>
>
>
>
>
> maven-assembly-plugin
>
> jar-with-dependencies
>
>
> ggg.GGGStandaloneApp
>
>
>
>
> BTW: Please document the archive option in the assembly plugin on the
> assembly site, it took me a while of trial and error to find it.
> However the application doesn't work yet, because:
> Exception in thread "main" java.lang.SecurityException: no manifiest section
> for signature file entry javax/activation/D
> ataContentHandlerFactory.class
> at sun.security.util.SignatureFileVerifier.verifySection(Unknown
> Source)
> at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source)
> at sun.security.util.SignatureFileVerifier.process(Unknown Source)
> at java.util.jar.JarVerifier.processEntry(Unknown Source)
> ...
> It looks like it's because the everything in the META-INF directory have a
> last-one-copied-wins policy.
> Jar-jar would also solve this of course.
> PS: I am also using acegisecurity, so I belive you can replicate this issue
> by making an assembly of a HelloWorld dependend on acegi & activation.
--
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
