[jira] Closed: (MECLIPSE-524) Cannot use "Run As Java Application/JUnit Test" (classpath problem) with ejb-client dependecy and "Resolve dependencies from Workspace projects"
[ http://jira.codehaus.org/browse/MECLIPSE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Causse closed MECLIPSE-524. - Resolution: Won't Fix Sorry... wrong project. > Cannot use "Run As Java Application/JUnit Test" (classpath problem) with > ejb-client dependecy and "Resolve dependencies from Workspace projects" > > > Key: MECLIPSE-524 > URL: http://jira.codehaus.org/browse/MECLIPSE-524 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support > Environment: M2Eclipse with WTP Support 0.9.7.200811301806 >Reporter: David Causse > Attachments: m2bug.tgz > > > With 2 module mod1 mod2 and mod2 refering mod1 ejb-client, classpath is wrong > when running unit test or Java Application : ClassNotFoundException for mod1 > classes. > This does not happen with ejb dependecy and does not happen with no workspace > project dependencies. > Test case attached. > Import attached "m2bug" and try to run unit test in > module2/src/test/java/m2bug/M1Test > You'll get ClassNotFoundException if "Resolve dependencies from Workspace > projects" is checked on module2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3989) Simple handling of external jars
[ http://jira.codehaus.org/browse/MNG-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Wilkins closed MNG-3989. - Resolution: Won't Fix Brett that's BRILLIANT! It works exactly how I wanted without any changes to maven! Thanks! I think this should be written up as THE pattern of how to include extra jars! > Simple handling of external jars > > > Key: MNG-3989 > URL: http://jira.codehaus.org/browse/MNG-3989 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.9 >Reporter: Greg Wilkins > Attachments: MNG-3989.zip > > > For whatever reason, there will always be jars that don't exist in a maven > repository. > There are numerous techniques for these - installing them in your local repo > (either manually or with > some bootstrap.sh script or special profile activation). Checking in the > jars into a local maven repository that is checked into svn > and then point to it from your settings.xml and/or top level pom (with aid of > an env variable). > But all these methods lack a very important features. You can just do: "svn > co http:/myproj.com/foo; cd foo; mvn" > If the jars change, you can't just do "svn up; mvn", you have to re-run > whatever script/profile installed the repo. > It's all rather a PITA. > What I want, is some way to have a module of a project that contains some > non-maven jars that when I > do a "mvn install" in that project, install those jars in my local repository > for use by my other modules. If the > jars are not updated, then nothing is done. > With something like this, projects that have external dependencies could > describe them to maven and > make them available for use, without manual steps and special scripts. -- 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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163696#action_163696 ] Benjamin Bentmann commented on MNG-4019: Bob, could you also attach the parent POM of the one you already provided, i.e. andromda-uml-metafacades:3.4.1-SNAPSHOT. In CVS, I only found [3.4-SNAPSHOT|http://andromda.cvs.sourceforge.net/viewvc/andromda/metafacades/uml/pom.xml?revision=1.7.2.10&view=markup&pathrev=V3_x_HEAD] which apparently isn't the same. > Unrecognised association "exclude" in pom parsing > in 2.0.10-RC10 > > > Key: MNG-4019 > URL: http://jira.codehaus.org/browse/MNG-4019 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 > Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. >Reporter: Bob Fields >Priority: Critical > Attachments: 209Debug.log, 210Debug.log, pom.xml > > > Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the > following: > > > src/java > > **/*.java > > > Fails with: > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised association: 'excludes' (position: START_TAG seen > ...\ > ... @138:31) for project > unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error > reading POM. Reason: Unrecognised association: 'excludes' (position: > START_TAG seen ...\r\n... @138:31) > for project unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) > Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 > pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from > AndroMDA: http://team.andromda.org/docs/source-repository.html under > directory metafacades\uml. -- 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: (MJAR-114) For a pom packaging project, the jar created is empty (even using ).
[
http://jira.codehaus.org/browse/MJAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163699#action_163699
]
Costin Caraivan commented on MJAR-114:
--
Thank you for the kind comment. This should be written in the documentation
though.
Your explanation is crystal clear unlike the documentation you linked to. It
could be even copy/pasted in the documentation :)
> For a pom packaging project, the jar created is empty (even using ).
> --
>
> Key: MJAR-114
> URL: http://jira.codehaus.org/browse/MJAR-114
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP SP3, Java 1.5.0.11, x86-64.
>Reporter: Costin Caraivan
>Priority: Minor
>
> Hello.
> For a pom packaging project, running a profile with this jar configuration
> results in a jar containing only the META-INF folder =>
> [INFO] [jar:jar {execution: jar-feature}]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> This is the plugin configuration:
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> jar-feature
> process-resources
>
>
> ${basedir}/**
>
> me
> true
>
>
> jar
>
>
>
> false
>
> I tried all sorts of configurations, all sorts of paths, but it does not
> work, the jar is still empty (and I'm sure that the path is valid, or so I
> hope :) ).
> PS:
> Don't ask why I'm making a jar in a pom packaging project, it has to do with
> Maven limitations (it is a wonderful tools, but it's not perfect, and real
> life > any tool :) ). There are ways around this, but this is the most
> elegant solution (or I'd have to make a 2 step build which is cumbersome for
> the users of this build, so not an option).
> Thank you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-388) Invalid lifecycle definitions
Invalid lifecycle definitions
-
Key: MASSEMBLY-388
URL: http://jira.codehaus.org/browse/MASSEMBLY-388
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-3
Reporter: Joerg Knobloch
Attachments: pom.xml
When trying to set up a small maven project, I found the lifecycle definitions
in components.xml. After modifying pom.xml (see attachment) and running {{mvn
package}}, the following error occurred:
{noformat}
[INFO] Required goal not found:
org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor in
org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-3
{noformat}
Looks like the package lifecycle phase definition in components.xml points to a
non-existent goal:
{noformat}
org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor
{noformat}
Same issue for assembly-descriptor lifecycle:
{noformat}
org.apache.maven.plugins:maven-assembly-plugin:attach-assembly-descriptor
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAR-114) For a pom packaging project, the jar created is empty (even using ).
[
http://jira.codehaus.org/browse/MJAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MJAR-114.
--
Assignee: Benjamin Bentmann
Resolution: Not A Bug
> For a pom packaging project, the jar created is empty (even using ).
> --
>
> Key: MJAR-114
> URL: http://jira.codehaus.org/browse/MJAR-114
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP SP3, Java 1.5.0.11, x86-64.
>Reporter: Costin Caraivan
>Assignee: Benjamin Bentmann
>Priority: Minor
>
> Hello.
> For a pom packaging project, running a profile with this jar configuration
> results in a jar containing only the META-INF folder =>
> [INFO] [jar:jar {execution: jar-feature}]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> This is the plugin configuration:
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> jar-feature
> process-resources
>
>
> ${basedir}/**
>
> me
> true
>
>
> jar
>
>
>
> false
>
> I tried all sorts of configurations, all sorts of paths, but it does not
> work, the jar is still empty (and I'm sure that the path is valid, or so I
> hope :) ).
> PS:
> Don't ask why I'm making a jar in a pom packaging project, it has to do with
> Maven limitations (it is a wonderful tools, but it's not perfect, and real
> life > any tool :) ). There are ways around this, but this is the most
> elegant solution (or I'd have to make a 2 step build which is cumbersome for
> the users of this build, so not an option).
> Thank you.
--
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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163714#action_163714 ] Bob Fields commented on MNG-4019: - All I did was change 3.4-SNAPSHOT to 3.4.1-SNAPSHOT locally, in order to prevent my custom local extensions from being overwritten automatically by the AndroMDA 3.4-SNAPSHOT downloaded version. I would think you would see the same problem from the pom.xml downloaded from the web site, but I haven't tried yet, I can try it today. Attached top level parent pom.xml. > Unrecognised association "exclude" in pom parsing > in 2.0.10-RC10 > > > Key: MNG-4019 > URL: http://jira.codehaus.org/browse/MNG-4019 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 > Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. >Reporter: Bob Fields >Priority: Critical > Attachments: 209Debug.log, 210Debug.log, pom.xml, pom.xml > > > Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the > following: > > > src/java > > **/*.java > > > Fails with: > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised association: 'excludes' (position: START_TAG seen > ...\ > ... @138:31) for project > unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error > reading POM. Reason: Unrecognised association: 'excludes' (position: > START_TAG seen ...\r\n... @138:31) > for project unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) > Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 > pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from > AndroMDA: http://team.andromda.org/docs/source-repository.html under > directory metafacades\uml. -- 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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Fields updated MNG-4019: Attachment: pom.xml > Unrecognised association "exclude" in pom parsing > in 2.0.10-RC10 > > > Key: MNG-4019 > URL: http://jira.codehaus.org/browse/MNG-4019 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 > Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. >Reporter: Bob Fields >Priority: Critical > Attachments: 209Debug.log, 210Debug.log, pom.xml, pom.xml > > > Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the > following: > > > src/java > > **/*.java > > > Fails with: > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised association: 'excludes' (position: START_TAG seen > ...\ > ... @138:31) for project > unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error > reading POM. Reason: Unrecognised association: 'excludes' (position: > START_TAG seen ...\r\n... @138:31) > for project unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) > Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 > pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from > AndroMDA: http://team.andromda.org/docs/source-repository.html under > directory metafacades\uml. -- 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-3999) validation of Id's too restrictive
[ http://jira.codehaus.org/browse/MNG-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163715#action_163715 ] Sven Pressler commented on MNG-3999: ok, I see the problem now, thanks. > validation of Id's too restrictive > -- > > Key: MNG-3999 > URL: http://jira.codehaus.org/browse/MNG-3999 > Project: Maven 2 > Issue Type: Improvement > Components: POM > Environment: xp, SAP NetWeaver, maven 2.x >Reporter: Sven Pressler > Attachments: pom.xml > > > I guess the validation of the Id's were introduced after issue MNG-801. > I think the validation is too strong. > The problem is that a lot of valid filenames are not validated as true. > The problem is caused by the DefaultModelValidator: private static final > String ID_REGEX = "[A-Za-z0-9_\\-.]+"; > This regular expression is far too restrictive since something like > "x=+%$§~!#^.jar" would be a valid filename on a windows operating system > I stumbled upon this because I'm developing tools for SAP NetWeaver, > currently we still use maven 1 to build our projects but we're in the process > of upgrading to maven 2. > maven 1 doesn't have this problem, since Id's didn't get validated like that. > Problem is SAP have a lot of libraries that have '~' in their names, like > 'tc~epbc~pcm~adminapi~java-5.x.y.jar'. Doesn't look any good, I don't like > it, I didn't make it like that but I have to work with it. > Maybe someone can explain why it's a good idea to be that restrictive about > the Ids, but as far as I see it, it's more like: before MNG-801 there was no > validation, and after MNG-801 there was some validation, and until now, there > was not too much complaining about it. > Attached is a pom which produces the following when trying to run mvn install: > Project ID: group:com~company~my~project > Validation Messages: > [0] 'artifactId' with value 'com~company~my~project' does not match a > valid id pattern. > Reason: Failed to validate POM for project group:com~company~my~project at > C:\test\validate\pom.xml > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for > project group:com~company~my~project at C:\test\validate\pom.xml > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > 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:324) > 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.project.InvalidProjectModelException: Failed to > validate POM for project group:com~company~my~project at > C:\test\validate\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) > ... 11 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: (MASSEMBLY-388) Invalid lifecycle definitions
[
http://jira.codehaus.org/browse/MASSEMBLY-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163712#action_163712
]
Joerg Knobloch commented on MASSEMBLY-388:
--
Sorry. Been hitting submit too fast. This bug definitely has no major priority.
> Invalid lifecycle definitions
> -
>
> Key: MASSEMBLY-388
> URL: http://jira.codehaus.org/browse/MASSEMBLY-388
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
>Reporter: Joerg Knobloch
> Attachments: pom.xml
>
>
> When trying to set up a small maven project, I found the lifecycle
> definitions in components.xml. After modifying pom.xml (see attachment) and
> running {{mvn package}}, the following error occurred:
> {noformat}
> [INFO] Required goal not found:
> org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor in
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-3
> {noformat}
> Looks like the package lifecycle phase definition in components.xml points to
> a non-existent goal:
> {noformat}
> org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor
> {noformat}
> Same issue for assembly-descriptor lifecycle:
> {noformat}
> org.apache.maven.plugins:maven-assembly-plugin:attach-assembly-descriptor
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-388) Invalid lifecycle definitions
[
http://jira.codehaus.org/browse/MASSEMBLY-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev updated MASSEMBLY-388:
-
Priority: Minor (was: Major)
> Invalid lifecycle definitions
> -
>
> Key: MASSEMBLY-388
> URL: http://jira.codehaus.org/browse/MASSEMBLY-388
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
>Reporter: Joerg Knobloch
>Priority: Minor
> Attachments: pom.xml
>
>
> When trying to set up a small maven project, I found the lifecycle
> definitions in components.xml. After modifying pom.xml (see attachment) and
> running {{mvn package}}, the following error occurred:
> {noformat}
> [INFO] Required goal not found:
> org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor in
> org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-3
> {noformat}
> Looks like the package lifecycle phase definition in components.xml points to
> a non-existent goal:
> {noformat}
> org.apache.maven.plugins:maven-assembly-plugin:attach-component-descriptor
> {noformat}
> Same issue for assembly-descriptor lifecycle:
> {noformat}
> org.apache.maven.plugins:maven-assembly-plugin:attach-assembly-descriptor
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-3862) Remove all plugin configuration manipulation from the plugin manager
[ http://jira.codehaus.org/browse/MNG-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3862 started by Shane Isbell. > Remove all plugin configuration manipulation from the plugin manager > - > > Key: MNG-3862 > URL: http://jira.codehaus.org/browse/MNG-3862 > Project: Maven 2 > Issue Type: Sub-task >Reporter: Jason van Zyl >Assignee: Shane Isbell > Fix For: 3.0-alpha-3 > > > All of this work is being done by the new model framework and the rules for > manipulating the model properties. All of the requirements for plugin > configuration inheriting and merging are taken care of. We need to detangle > the plugin configuration from execution. This will pave the way to use the > new plexus plugin manager to load and execute plugins. -- 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-3631) Introduce new MavenEmbedder.getPluginConfiguration method
[ http://jira.codehaus.org/browse/MNG-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3631: -- Fix Version/s: (was: 3.x) 3.0-alpha-3 > Introduce new MavenEmbedder.getPluginConfiguration method > - > > Key: MNG-3631 > URL: http://jira.codehaus.org/browse/MNG-3631 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Igor Fedorenko >Assignee: Shane Isbell > Fix For: 3.0-alpha-3 > > > There are five sources for maven plugin configuration -- build/plugins, > parent build/plugins, build/pluginManagement, parent build/pluginManagement > and plugin default configuration. Currently, > MavenEmbedder.readProjectWithDependencies never considers default plugin > configuration. Also, lifecycle-included plugins and configuration are not > considered during readProjectWithDependencies (see MNGECLIPSE-627). > It would be nice to have new method MavenEmbedder.getPluginConfiguration( > MavenProject project, String pluginKey ): PlexusConfiguration (or similar) > which would calculate and return fully inherited/interpolated plugin > configuration. -- 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-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated
[
http://jira.codehaus.org/browse/MNG-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-1943:
--
Fix Version/s: (was: 3.x)
3.0-alpha-3
> MavenProject::getParent() returns a MavenProject that is NOT interpolated
> -
>
> Key: MNG-1943
> URL: http://jira.codehaus.org/browse/MNG-1943
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: John Allen
>Assignee: Shane Isbell
>Priority: Blocker
> Fix For: 3.0-alpha-3
>
> Attachments: mng-1943-test.zip
>
>
> Plugin developers repeatedly use ${project}.getParent().someMethod() yet
> getParent() returns a project that has not been interpolated. This obviously
> needs to be fixed but may I also suggest that all plugin acceptance testing
> is revisted to ensure that the tests use POMs that are littered with property
> expressions and not literals.
--
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-3567) pluginManagement from parent POM not used in child
[ http://jira.codehaus.org/browse/MNG-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-3567: -- Fix Version/s: (was: 3.x) 3.0-alpha-3 > pluginManagement from parent POM not used in child > -- > > Key: MNG-3567 > URL: http://jira.codehaus.org/browse/MNG-3567 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0-alpha-1 >Reporter: John Casey >Assignee: Shane Isbell > Fix For: 3.0-alpha-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] Updated: (MNG-2174) do not propogate to child POM plugins (potentially scoped to only affecting child POM plugins that live within a )
[ http://jira.codehaus.org/browse/MNG-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell updated MNG-2174: -- Fix Version/s: (was: 3.x) 3.0-alpha-3 > do not propogate to child > POM plugins (potentially scoped to only affecting child POM plugins that live > within a ) > - > > Key: MNG-2174 > URL: http://jira.codehaus.org/browse/MNG-2174 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle >Reporter: John Allen >Assignee: Shane Isbell > Fix For: 3.0-alpha-3 > > > do not propogate to child > POM plugins. > Kenny believe this works OKAY if the childs are using the parent > preconfigured plugins in their main section > however it does NOT work if the childs are trying to use those preconfigured > plugins via their own . Configuration propogates through okay but > dependencies are missing and have to be respecified in the child POMs. -- 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-3877) Reporting output directory not basedir aligned when queried from MavenProject
[
http://jira.codehaus.org/browse/MNG-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3877:
--
Fix Version/s: (was: 3.x)
3.0-alpha-3
> Reporting output directory not basedir aligned when queried from MavenProject
> -
>
> Key: MNG-3877
> URL: http://jira.codehaus.org/browse/MNG-3877
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, POM
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-3
>
>
> Calliing {{MavenProject.getReporting().getOutputDirectory()}} inside a plugin
> delivers a relative path in case the corresponding POM element was specified
> using a relative path.
> This is a very close relative of MNG-3475 (basedir-aligned plugin parameter
> expressions) and MNG-3822 (basedir-aligned interpolation) but occurs in a
> different context.
--
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: (MJAR-114) For a pom packaging project, the jar created is empty (even using ).
[
http://jira.codehaus.org/browse/MJAR-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163698#action_163698
]
Benjamin Bentmann commented on MJAR-114:
The includes/excludes are meant to give *relative* paths, so something
including the basedir will likely not match anything. The plugin is zipping up
the contents specified by the
[classesDirectory|http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classesDirectory],
so you might want to try configuring this.
> For a pom packaging project, the jar created is empty (even using ).
> --
>
> Key: MJAR-114
> URL: http://jira.codehaus.org/browse/MJAR-114
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP SP3, Java 1.5.0.11, x86-64.
>Reporter: Costin Caraivan
>Priority: Minor
>
> Hello.
> For a pom packaging project, running a profile with this jar configuration
> results in a jar containing only the META-INF folder =>
> [INFO] [jar:jar {execution: jar-feature}]
> [WARNING] JAR will be empty - no content was marked for inclusion!
> This is the plugin configuration:
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> jar-feature
> process-resources
>
>
> ${basedir}/**
>
> me
> true
>
>
> jar
>
>
>
> false
>
> I tried all sorts of configurations, all sorts of paths, but it does not
> work, the jar is still empty (and I'm sure that the path is valid, or so I
> hope :) ).
> PS:
> Don't ask why I'm making a jar in a pom packaging project, it has to do with
> Maven limitations (it is a wonderful tools, but it's not perfect, and real
> life > any tool :) ). There are ways around this, but this is the most
> elegant solution (or I'd have to make a 2 step build which is cumbersome for
> the users of this build, so not an option).
> Thank you.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3567) pluginManagement from parent POM not used in child
[ http://jira.codehaus.org/browse/MNG-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed MNG-3567. - Resolution: Fixed > pluginManagement from parent POM not used in child > -- > > Key: MNG-3567 > URL: http://jira.codehaus.org/browse/MNG-3567 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 3.0-alpha-1 >Reporter: John Casey >Assignee: Shane Isbell > Fix For: 3.0-alpha-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] Commented: (MNG-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[
http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163718#action_163718
]
Benjamin Bentmann commented on MNG-4019:
>From the [immediate parent
>POM|http://andromda.cvs.sourceforge.net/viewvc/*checkout*/andromda/metafacades/uml/pom.xml?revision=1.7.2.10&content-type=text%2Fplain&pathrev=V3_x_HEAD]
> of the POM you provided first:
{code:xml}
src/test/java
**/*.java
{code}
i.e. the POM is indeed invalid, cf. the
[XSD|http://maven.apache.org/xsd/maven-4.0.0.xsd].
> Unrecognised association "exclude" in pom parsing
> in 2.0.10-RC10
>
>
> Key: MNG-4019
> URL: http://jira.codehaus.org/browse/MNG-4019
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.10
> Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09.
>Reporter: Bob Fields
>Priority: Critical
> Attachments: 209Debug.log, 210Debug.log, pom.xml, pom.xml
>
>
> Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the
> following:
>
>
> src/java
>
> **/*.java
>
>
> Fails with:
> org.apache.maven.reactor.MavenExecutionException: Parse error reading POM.
> Reason: Unrecognised association: 'excludes' (position: START_TAG seen
> ...\
> ... @138:31) for project
> unknown:andromda-metafacades-uml at
> C:\workspaces\A34\andromda34\metafacades\uml\pom.xml
> Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error
> reading POM. Reason: Unrecognised association: 'excludes' (position:
> START_TAG seen ...\r\n... @138:31)
> for project unknown:andromda-metafacades-uml at
> C:\workspaces\A34\andromda34\metafacades\uml\pom.xml
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591)
> Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680
> pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from
> AndroMDA: http://team.andromda.org/docs/source-repository.html under
> directory metafacades\uml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-96) earSourceExcludes does not work for jar dependency filtering like warSourceExcludes / packagingExcludes for the maven-war-plugin
[ http://jira.codehaus.org/browse/MEAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163742#action_163742 ] Bryan Loofbourrow commented on MEAR-96: --- Yep, same issue here, in version 2.3.1. Note that the earSourceExcludes value pasted above wouldn't exclude commons-logging, but the one in the attached pom.xml would. I figure that's part of what ScottH means by "munged." I worked around the problem by specifying a bundleDir for the jar in some location other than the one that the container will add to its classpath. Ugly and wasteful, but effective. > earSourceExcludes does not work for jar dependency filtering like > warSourceExcludes / packagingExcludes for the maven-war-plugin > > > Key: MEAR-96 > URL: http://jira.codehaus.org/browse/MEAR-96 > Project: Maven 2.x Ear Plugin > Issue Type: Bug > Environment: Windows XP SP3 >Reporter: Scott Heaberlin > Attachments: pom.xml > > > The earSourceExcludes parameter of the EarMojo does not appear to have any > effect on jar dependencies. Given the pom below, commons-logging.jar should > be excluded from the resultant .ear archive but is not. > The junit test for the ear mojo (test-project-014) uses earSourceExcludes but > only with files that are in the earSourceDirectory. > Similar functionality works for the maven-war-plugin (warSourceExcludes, > which was renamed to packagingExcludes) so it was a little confusing to find > that earSourceIncludes does not allow filtering in the same fashion. > -- example pom.xml > 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 > example > example-ear > ear > example-ear > 0.1-SNAPSHOT > > sample ear project demonstrating effectiveness of > earSourceExcludes parameter of the maven-ear-plugin > > > > > maven-ear-plugin > 2.3.1 > > > src/main/application > **/commons* > > > > > > > org.springframework > spring-core > 1.2.7 > > > -- 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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163748#action_163748 ] Bob Fields commented on MNG-4019: - Thank you for pointing that out, I'll fix the file on AndroMDA. I guess it was just a simple mistake from the previous developers that I didn't notice. A warning in the previous maven version would have been nice, I guess it just ignored the configuration information it didn't understand. This issue can be closed. > Unrecognised association "exclude" in pom parsing > in 2.0.10-RC10 > > > Key: MNG-4019 > URL: http://jira.codehaus.org/browse/MNG-4019 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 > Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. >Reporter: Bob Fields >Priority: Critical > Attachments: 209Debug.log, 210Debug.log, pom.xml, pom.xml > > > Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the > following: > > > src/java > > **/*.java > > > Fails with: > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised association: 'excludes' (position: START_TAG seen > ...\ > ... @138:31) for project > unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error > reading POM. Reason: Unrecognised association: 'excludes' (position: > START_TAG seen ...\r\n... @138:31) > for project unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) > Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 > pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from > AndroMDA: http://team.andromda.org/docs/source-repository.html under > directory metafacades\uml. -- 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-3969) replace maven-ant with mercury-ant in the bootstrap
[ http://jira.codehaus.org/browse/MNG-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3969: --- Fix Version/s: (was: 3.0-alpha-2) 3.0-alpha-3 > replace maven-ant with mercury-ant in the bootstrap > --- > > Key: MNG-3969 > URL: http://jira.codehaus.org/browse/MNG-3969 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build >Affects Versions: 3.0-alpha-1 >Reporter: Oleg Gusakov >Assignee: Jason van Zyl > Fix For: 3.0-alpha-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: (MJAR-114) For a pom packaging project, the jar created is empty (even using ).
For a pom packaging project, the jar created is empty (even using ).
--
Key: MJAR-114
URL: http://jira.codehaus.org/browse/MJAR-114
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Windows XP SP3, Java 1.5.0.11, x86-64.
Reporter: Costin Caraivan
Priority: Minor
Hello.
For a pom packaging project, running a profile with this jar configuration
results in a jar containing only the META-INF folder =>
[INFO] [jar:jar {execution: jar-feature}]
[WARNING] JAR will be empty - no content was marked for inclusion!
This is the plugin configuration:
org.apache.maven.plugins
maven-jar-plugin
jar-feature
process-resources
${basedir}/**
me
true
jar
false
I tried all sorts of configurations, all sorts of paths, but it does not work,
the jar is still empty (and I'm sure that the path is valid, or so I hope :) ).
PS:
Don't ask why I'm making a jar in a pom packaging project, it has to do with
Maven limitations (it is a wonderful tools, but it's not perfect, and real life
> any tool :) ). There are ways around this, but this is the most elegant
solution (or I'd have to make a 2 step build which is cumbersome for the users
of this build, so not an option).
Thank you.
--
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: (MWAR-182) warSourceIncludes no longer works
warSourceIncludes no longer works - Key: MWAR-182 URL: http://jira.codehaus.org/browse/MWAR-182 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.1-alpha-2 Environment: RHEL 3 Reporter: Bryan Loofbourrow Attachments: pom.xml The element no longer seems to work, as of 2.1-alpha-2. It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will demonstrate the problem when used as follows: 1) From the directory containing the pom.xml, create a web.xml, because otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick): mkdir -p src/main/webapp/WEB-INF touch src/main/webapp/WEB-INF/web.xml 2) Build with the 2.1-alpha-1 plugin mvn clean install -Dwar.plugin.version=2.1-alpha-1 3) Dump out the jar contents to verify that only commons-logging and the web.xml were packaged, as requested [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/web.xml WEB-INF/lib/ WEB-INF/lib/commons-logging-1.1.jar META-INF/maven/ META-INF/maven/example/ META-INF/maven/example/example-war/ META-INF/maven/example/example-war/pom.xml META-INF/maven/example/example-war/pom.properties 4) Now build using the 2.1-alpha-2 plugin version: mvn clean install -Dwar.plugin.version=2.1-alpha-1 5) Dump out the jar contents and notice that warSourceIncludes was ignored this time: [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/lib/ WEB-INF/web.xml WEB-INF/lib/commons-logging-1.1.jar WEB-INF/lib/log4j-1.2.12.jar WEB-INF/lib/logkit-1.0.1.jar WEB-INF/lib/avalon-framework-4.1.3.jar WEB-INF/lib/servlet-api-2.3.jar META-INF/maven/ META-INF/maven/example/ META-INF/maven/example/example-war/ META-INF/maven/example/example-war/pom.xml META-INF/maven/example/example-war/pom.properties -- 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-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163759#action_163759 ] Bryan Loofbourrow commented on MWAR-182: Sorry, the line in step 4 should read: mvn clean install -Dwar.plugin.version=2.1-alpha-2 Cut/paste error on my part. > warSourceIncludes no longer works > - > > Key: MWAR-182 > URL: http://jira.codehaus.org/browse/MWAR-182 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: RHEL 3 >Reporter: Bryan Loofbourrow > Attachments: pom.xml > > > The element no longer seems to work, as of 2.1-alpha-2. > It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will > demonstrate the problem when used as follows: > 1) From the directory containing the pom.xml, create a web.xml, because > otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick): > mkdir -p src/main/webapp/WEB-INF > touch src/main/webapp/WEB-INF/web.xml > 2) Build with the 2.1-alpha-1 plugin > mvn clean install -Dwar.plugin.version=2.1-alpha-1 > 3) Dump out the jar contents to verify that only commons-logging and the > web.xml were packaged, as requested > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/web.xml > WEB-INF/lib/ > WEB-INF/lib/commons-logging-1.1.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties > 4) Now build using the 2.1-alpha-2 plugin version: > mvn clean install -Dwar.plugin.version=2.1-alpha-1 > 5) Dump out the jar contents and notice that warSourceIncludes was ignored > this time: > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/classes/ > WEB-INF/lib/ > WEB-INF/web.xml > WEB-INF/lib/commons-logging-1.1.jar > WEB-INF/lib/log4j-1.2.12.jar > WEB-INF/lib/logkit-1.0.1.jar > WEB-INF/lib/avalon-framework-4.1.3.jar > WEB-INF/lib/servlet-api-2.3.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties -- 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-3989) Simple handling of external jars
[ http://jira.codehaus.org/browse/MNG-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3989: -- Attachment: MNG-3989.zip cleaned up version > Simple handling of external jars > > > Key: MNG-3989 > URL: http://jira.codehaus.org/browse/MNG-3989 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.9 >Reporter: Greg Wilkins > Attachments: MNG-3989.zip, MNG-3989.zip > > > For whatever reason, there will always be jars that don't exist in a maven > repository. > There are numerous techniques for these - installing them in your local repo > (either manually or with > some bootstrap.sh script or special profile activation). Checking in the > jars into a local maven repository that is checked into svn > and then point to it from your settings.xml and/or top level pom (with aid of > an env variable). > But all these methods lack a very important features. You can just do: "svn > co http:/myproj.com/foo; cd foo; mvn" > If the jars change, you can't just do "svn up; mvn", you have to re-run > whatever script/profile installed the repo. > It's all rather a PITA. > What I want, is some way to have a module of a project that contains some > non-maven jars that when I > do a "mvn install" in that project, install those jars in my local repository > for use by my other modules. If the > jars are not updated, then nothing is done. > With something like this, projects that have external dependencies could > describe them to maven and > make them available for use, without manual steps and special scripts. -- 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-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163766#action_163766 ] Oleg Gusakov commented on MNG-553: -- *settings-security.xml* - root tag renamed to *settingsSecurity* > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Oleg Gusakov >Priority: Critical > Fix For: 2.1.0-M2 > > Attachments: MNG-553.patch > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- 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] Issue Comment Edited: (MNG-553) Secure Storage of Server Passwords
[
http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162620#action_162620
]
Oleg Gusakov edited comment on MNG-553 at 2/3/09 1:24 PM:
--
Implemented solution is manual for now, I will add automation plugin later on.
I already have the plugin but need to modify it a little.
*Manual process*
To encrypt a password, run the following cli:
java -cp maven-2.1.0-M2-SNAPSHOT-uber.jar
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher [ -m | -p ]
where:
* *-m* means encrypt master password
* *-p* means encrypt a password
To setup encryption for server *my.server*
* encrypt master password - get the output and save in *~/.m2/sec.xml*
{code}
{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}
{code}
* encrypt the password with cli
* save the password into settings.xml
{code}
my.server
foo
{COQLCE6DU6GtcS5P=}
{code}
* that is all. Maven will intercept the password and decrypt it on the fly.
Because password is decrypted and send like that on the wire, you don't get
much security from this approach, unless the connection itself is encrypted.
The best layout is like the following:
* have all global settings in in the global settings.xml file -
*$M2_HOME/conf/settings.xml*, keep all profiles here
* move *servers* secrion to *~/.m2/settings.xml* - keep all you private
passwords encrypted in this file
* keep encrypted master password in *~/.m2/sec.xml*
** if you want to enhance this - move this file to a removable disk and put a
reference to that file into *~/.m2/sec.xml*
{code}
/Volumes/mySecureUsb/secret/sec.xml
{code}
then password will be read from */Volumes/mySecureUsb/secret/sec.xml*
was (Author: olle):
Implemented solution is manual for now, I will add automation plugin later
on. I already have the plugin but need to modify it a little.
*Manual process*
To encrypt a password, run the following cli:
java -cp maven-2.1.0-M2-SNAPSHOT-uber.jar
org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher [ -m | -p ]
where:
* *-m* means encrypt master password
* *-p* means encrypt a password
To setup encryption for server *my.server*
* encrypt master password - get the output and save in *~/.m2/sec.xml*
{code}
{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}
{code}
* encrypt the password with cli
* save the password into settings.xml
{code}
my.server
foo
{COQLCE6DU6GtcS5P=}
{code}
* that is all. Maven will intercept the password and decrypt it on the fly.
Because password is decrypted and send like that on the wire, you don't get
much security from this approach, unless the connection itself is encrypted.
The best layout is like the following:
* have all global settings in in the global settings.xml file -
*$M2_HOME/conf/settings.xml*, keep all profiles here
* move *servers* secrion to *~/.m2/settings.xml* - keep all you private
passwords encrypted in this file
* keep encrypted master password in *~/.m2/sec.xml*
** if you want to enhance this - move this file to a removable disk and put a
reference to that file into *~/.m2/sec.xml*
{code}
/Volumes/mySecureUsb/secret/sec.xml
{code}
then password will be read from */Volumes/mySecureUsb/secret/sec.xml*
> Secure Storage of Server Passwords
> --
>
> Key: MNG-553
> URL: http://jira.codehaus.org/browse/MNG-553
> Project: Maven 2
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 2.0-alpha-3
> Environment: Although it may not be relevant since this is a general
> improvement issue, Windows XP, JDK 1.4.1.
>Reporter: J. Michael McGarr
>Assignee: Oleg Gusakov
>Priority: Critical
> Fix For: 2.1.0-M2
>
> Attachments: MNG-553.patch
>
>
> This was a question pose to the Maven User's Group and it was suggested I add
> it here.
> It would be benefitial to provide a more secure means of storing password's
> to the servers listed in the .m2/settings.xml. They are currently being
> stored as plain text and could definately be considered a security breach.
> Numerous organizations would undoubtedly considered this an unacceptable
> security risk, and this could prevent widespread adoption of Maven2.
> I would suggest leaving an option to encrypt the password into the settings
> file (more secure, but not foolproof) or even requiring the password to be
> manually provided per build (would prevent automation of builds). I am sure
> that there is a secure solution to this problem and it should be part of the
> 2.0 release.
--
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 JIR
[jira] Closed: (MRELEASE-408) Release:prepare inherits profiles and isn't overriden by specifying specific profiles using -Darguments as it used to be
[
http://jira.codehaus.org/browse/MRELEASE-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol closed MRELEASE-408.
---
Assignee: Vincent Massol
Resolution: Won't Fix
I've looked at the code and it isn't quite valid so closing as won't fix and
opening some new issues
> Release:prepare inherits profiles and isn't overriden by specifying specific
> profiles using -Darguments as it used to be
>
>
> Key: MRELEASE-408
> URL: http://jira.codehaus.org/browse/MRELEASE-408
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-8
>Reporter: Vincent Massol
>Assignee: Vincent Massol
>
> In 2.0 beta 7 the following was working:
> {noformat}
> mvn release:prepare -Pci,hsqldb,mysql,pgsql,derby,jetty
> -Darguments="-Pjetty,hsqldb"
> [... SNIP ...]
> [INFO] [release:prepare]
> [INFO] Resuming release from phase 'run-preparation-goals'
> [INFO] Executing goals 'clean install'...
> [INFO] Executing: mvn clean install --no-plugin-updates -Pjetty,hsqldb -P
> ci,jetty
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] XWiki Products - Enterprise - Parent POM
> [INFO] XWiki Products - Enterprise - Wiki
> [INFO] XWiki Products - Enterprise - Database - Parent POM
> [INFO] XWiki Products - Enterprise - Database - HSQLDB
> [INFO] XWiki Products - Enterprise - Web
> [INFO] XWiki Products - Enterprise - Distribution - Parent POM
> [INFO] XWiki Products - Enterprise - Distribution - Jetty
> [INFO] XWiki Products - Enterprise - Distribution - HSQLDB
> [INFO]
>
> {noformat}
> As you can see only the specified profiles were passed to the internal build.
> With 2.0 beta 8 this is no longer working and all profiles are passed to the
> internal build.
> We need to specify more profiles in the outside build since we want to run
> the following command so that all pom.xml files are updated for the release
> but we only want to release some modules:
> {noformat}
> mvn release:prepare -Pci,hsqldb,mysql,pgsql,derby,jetty
> -Darguments="-Pjetty,hsqldb" -DautoVersionSubmodules=true
> -DreleaseVersion=1.7-milestone-2 -DdevelopmentVersion=1.7-SNAPSHOT
> {noformat}
> Reference: http://jira.xwiki.org/jira/browse/XE-331
--
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-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163763#action_163763 ] Chris Rudd commented on SCM-262: The svn command that fails is : svn copy --file /tmp/maven-scm-297444897.commit . http://XXX/svn/project/tags/foo-1.0.0 Simply adding the explicit revision to copy from solves the problem svn copy --file /tmp/maven-scm-297444897.commit -r 599 . http://XXX/svn/project/tags/foo-1.0.0 So is there an easy way for the SvnTagCommand to get the revision of the local copy? > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner > Fix For: future > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- 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: (MINSTALL-58) Build failure
[ http://jira.codehaus.org/browse/MINSTALL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MINSTALL-58. - Assignee: Benjamin Bentmann Resolution: Not A Bug bq. Is their anyone can help me for this? Please understand that the issue tracker is not the right place for basic usage questions. Have a look at [Getting Help|http://maven.apache.org/users/getting-help.html]. Also, reading [Maven in 5 Minutes|http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html] or other introdutions to Maven can help. > Build failure > - > > Key: MINSTALL-58 > URL: http://jira.codehaus.org/browse/MINSTALL-58 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows xp >Reporter: Poonam Gyanchandani >Assignee: Benjamin Bentmann > Attachments: New Text Document.txt > > > Hi, > I have installed the Maven . When I am trying to run mvn package/ mvn > install/mvn clean it is giving me "build failure". > D:\Program Files\Apache Software Foundation\apache-maven-2.0.9>mvn package > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [package] > [INFO] > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Cannot execute mojo: resources. It requires a project with an existing > po > m.xml, but the build is not using one. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Tue Feb 03 15:24:56 EST 2009 > [INFO] Final Memory: 3M/6M > [INFO] > > and when I run mvn -e > D:\Program Files\Apache Software Foundation\apache-maven-2.0.9>mvn -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] > You must specify at least one goal. Try 'mvn install' to build or 'mvn -?' for > ptions > See http://maven.apache.org for more information. > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: > You must specify at least one goal. Try 'mvn install' to build or 'mvn -?' for > ptions > See http://maven.apache.org for more information. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultL > fecycleExecutor.java:134) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > 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) > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Tue Feb 03 15:26:24 EST 2009 > [INFO] Final Memory: 1M/4M > [INFO] > > Is their anyone can help me for 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: (MNG-4020) Release plugin disregards SCM configured element within the pom
Release plugin disregards SCM configured element within the pom --- Key: MNG-4020 URL: http://jira.codehaus.org/browse/MNG-4020 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle, POM Environment: Maven 2.0.9 using maven-release-plugin version 2.0-beta-7 Reporter: Robert Bracewell I have a scenario where the SCM tag is configured with the following: scm:perforce:p4server:1666://components/projectA/pom.xml scm:perforce:p4server:1666://components/projectA/pom.xml The location in Perforce //components/projectA contains the pom.xml in question and then a bunch of sub-directories located at the same level as the pom. When the release plugin runs a perform it churns out the following: [INFO] [release:perform] [INFO] Checking out the project to perform the release ... [INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is not equal to the depot location (//components/projectA). This happens frequently with branches. Ignoring the SCM location. For my situation the above is incorrect as I am only releasing a pom not several modules. The release:perform then continues to sync every file located under //components/projectA which in my case is several thousand and as such takes several minutes to complete. The release plugin should be able to handle such SCM elements and understand that only a single file is being released when such is explicitly defined -- 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-4020) Release plugin disregards SCM configured element within the pom
[
http://jira.codehaus.org/browse/MNG-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4020:
---
Description:
I have a scenario where the SCM tag is configured with the following:
{code:xml}
scm:perforce:p4server:1666://components/projectA/pom.xml
scm:perforce:p4server:1666://components/projectA/pom.xml
{code}
The location in Perforce //components/projectA contains the pom.xml in question
and then a bunch of sub-directories located at the same level as the pom.
When the release plugin runs a perform it churns out the following:
[INFO] [release:perform]
[INFO] Checking out the project to perform the release ...
[INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is not
equal to the depot location (//components/projectA). This happens frequently
with branches. Ignoring the SCM location.
For my situation the above is incorrect as I am only releasing a pom not
several modules. The release:perform then continues to sync every file located
under //components/projectA which in my case is several thousand and as such
takes several minutes to complete.
The release plugin should be able to handle such SCM elements and understand
that only a single file is being released when such is explicitly defined
was:
I have a scenario where the SCM tag is configured with the following:
scm:perforce:p4server:1666://components/projectA/pom.xml
scm:perforce:p4server:1666://components/projectA/pom.xml
The location in Perforce //components/projectA contains the pom.xml in question
and then a bunch of sub-directories located at the same level as the pom.
When the release plugin runs a perform it churns out the following:
[INFO] [release:perform]
[INFO] Checking out the project to perform the release ...
[INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is not
equal to the depot location (//components/projectA). This happens frequently
with branches. Ignoring the SCM location.
For my situation the above is incorrect as I am only releasing a pom not
several modules. The release:perform then continues to sync every file located
under //components/projectA which in my case is several thousand and as such
takes several minutes to complete.
The release plugin should be able to handle such SCM elements and understand
that only a single file is being released when such is explicitly defined
> Release plugin disregards SCM configured element within the pom
> ---
>
> Key: MNG-4020
> URL: http://jira.codehaus.org/browse/MNG-4020
> Project: Maven 2
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-7
> Environment: Maven 2.0.9 using maven-release-plugin version 2.0-beta-7
>Reporter: Robert Bracewell
>
> I have a scenario where the SCM tag is configured with the following:
> {code:xml}
>
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> {code}
> The location in Perforce //components/projectA contains the pom.xml in
> question and then a bunch of sub-directories located at the same level as the
> pom.
> When the release plugin runs a perform it churns out the following:
> [INFO] [release:perform]
> [INFO] Checking out the project to perform the release ...
> [INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is
> not equal to the depot location (//components/projectA). This happens
> frequently with branches. Ignoring the SCM location.
> For my situation the above is incorrect as I am only releasing a pom not
> several modules. The release:perform then continues to sync every file
> located under //components/projectA which in my case is several thousand and
> as such takes several minutes to complete.
> The release plugin should be able to handle such SCM elements and understand
> that only a single file is being released when such is explicitly defined
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MRELEASE-411) Release plugin disregards SCM configured element within the pom
[
http://jira.codehaus.org/browse/MRELEASE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4020 to MRELEASE-411:
-
Component/s: (was: Plugins and Lifecycle)
(was: POM)
perform
Key: MRELEASE-411 (was: MNG-4020)
Project: Maven 2.x Release Plugin (was: Maven 2)
> Release plugin disregards SCM configured element within the pom
> ---
>
> Key: MRELEASE-411
> URL: http://jira.codehaus.org/browse/MRELEASE-411
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-7
> Environment: Maven 2.0.9 using maven-release-plugin version 2.0-beta-7
>Reporter: Robert Bracewell
>
> I have a scenario where the SCM tag is configured with the following:
> {code:xml}
>
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> {code}
> The location in Perforce //components/projectA contains the pom.xml in
> question and then a bunch of sub-directories located at the same level as the
> pom.
> When the release plugin runs a perform it churns out the following:
> [INFO] [release:perform]
> [INFO] Checking out the project to perform the release ...
> [INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is
> not equal to the depot location (//components/projectA). This happens
> frequently with branches. Ignoring the SCM location.
> For my situation the above is incorrect as I am only releasing a pom not
> several modules. The release:perform then continues to sync every file
> located under //components/projectA which in my case is several thousand and
> as such takes several minutes to complete.
> The release plugin should be able to handle such SCM elements and understand
> that only a single file is being released when such is explicitly defined
--
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: (MRELEASE-411) Release plugin disregards SCM configured element within the pom
[
http://jira.codehaus.org/browse/MRELEASE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MRELEASE-411:
---
Affects Version/s: 2.0-beta-7
> Release plugin disregards SCM configured element within the pom
> ---
>
> Key: MRELEASE-411
> URL: http://jira.codehaus.org/browse/MRELEASE-411
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0-beta-7
> Environment: Maven 2.0.9 using maven-release-plugin version 2.0-beta-7
>Reporter: Robert Bracewell
>
> I have a scenario where the SCM tag is configured with the following:
> {code:xml}
>
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> scm:perforce:p4server:1666://components/projectA/pom.xml
>
> {code}
> The location in Perforce //components/projectA contains the pom.xml in
> question and then a bunch of sub-directories located at the same level as the
> pom.
> When the release plugin runs a perform it churns out the following:
> [INFO] [release:perform]
> [INFO] Checking out the project to perform the release ...
> [INFO] The SCM location in your pom.xml (//components/projectA/pom.xml) is
> not equal to the depot location (//components/projectA). This happens
> frequently with branches. Ignoring the SCM location.
> For my situation the above is incorrect as I am only releasing a pom not
> several modules. The release:perform then continues to sync every file
> located under //components/projectA which in my case is several thousand and
> as such takes several minutes to complete.
> The release plugin should be able to handle such SCM elements and understand
> that only a single file is being released when such is explicitly defined
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3919) NPE in DefaultLifecycleBindingManager
[
http://jira.codehaus.org/browse/MNG-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-3919.
-
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
> NPE in DefaultLifecycleBindingManager
> -
>
> Key: MNG-3919
> URL: http://jira.codehaus.org/browse/MNG-3919
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-3
>
> Attachments: pom.xml
>
>
> Running "mvn validate" on the attached POM delivers:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.binding.DefaultLifecycleBindingManager.getProjectCustomBindings(DefaultLifecycleBindingManager.java:251)
> at
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:104)
> at
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructInitialProjectBuildPlan(DefaultBuildPlanner.java:72)
> at
> org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructInitialProjectBuildPlans(DefaultBuildPlanner.java:61)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:157)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:207)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:851)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:169)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> 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:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4008) [regression] Build filters are collapsed
[
http://jira.codehaus.org/browse/MNG-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163790#action_163790
]
Shane Isbell commented on MNG-4008:
---
I'm not able to reproduce this.
> [regression] Build filters are collapsed
>
>
> Key: MNG-4008
> URL: http://jira.codehaus.org/browse/MNG-4008
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-4
>
>
> Input POM snippet:
> {code:xml}
>
>
> src/main/filters/a.properties
> src/main/filters/c.properties
> src/main/filters/b.properties
> src/main/filters/d.properties
>
>
> {code}
> Effective POM:
> {code:xml}
>
>
> src/main/filters/a.properties
>
>
> {code}
> i.e. only one filter definition survives.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4008) [regression] Build filters are collapsed
[
http://jira.codehaus.org/browse/MNG-4008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-4008.
-
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
I was able to reproduce problem in joined filters of parent-child poms. Added
rule in PomTransformer.
> [regression] Build filters are collapsed
>
>
> Key: MNG-4008
> URL: http://jira.codehaus.org/browse/MNG-4008
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-3
>
>
> Input POM snippet:
> {code:xml}
>
>
> src/main/filters/a.properties
> src/main/filters/c.properties
> src/main/filters/b.properties
> src/main/filters/d.properties
>
>
> {code}
> Effective POM:
> {code:xml}
>
>
> src/main/filters/a.properties
>
>
> {code}
> i.e. only one filter definition survives.
--
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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Rudd updated SCM-262: --- Attachment: SvnTagCommand.patch Here is a patch that I made against version 1.0. It uses the svn info command on the working directory to get the current revision (presumably the revision that was built) and passes the revision to the svn cp command. This works with svn 1.5.4 (have not tested other versions, but dont see any reason it wouldnt). > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner > Fix For: future > > Attachments: SvnTagCommand.patch > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3918) NPE in CLIReportingUtils
[
http://jira.codehaus.org/browse/MNG-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-3918.
-
Resolution: Fixed
Fixed this problem with the commit for MNG-3919
> NPE in CLIReportingUtils
>
>
> Key: MNG-3918
> URL: http://jira.codehaus.org/browse/MNG-3918
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-3
>
> Attachments: pom.xml
>
>
> Running "mvn validate" on the attached POM delivers:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.maven.cli.CLIReportingUtils.handleLifecycleExecutionException(CLIReportingUtils.java:270)
> at
> org.apache.maven.cli.CLIReportingUtils.buildErrorMessage(CLIReportingUtils.java:217)
> at
> org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:162)
> at
> org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
> at
> org.apache.maven.cli.CLIReportingUtils.logResult(CLIReportingUtils.java:80)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:171)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> 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:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> {noformat}
> While the POM is indeed invalid, the original error message doesn't make it
> to the user.
> The {{LifecycleExecutionException}} to report has no project instance. In
> this particular case, the exception is created in
> {{DefaultLifecycleExecutor}} by wrapping a
> {{LifecycleSpecificationException}}. This raises the question whether the
> class {{LifecycleException}} should provide a field to carry a
> {{MavenProject}} instance, which could then be propagated to the wrapping
> exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-1943) MavenProject::getParent() returns a MavenProject that is NOT interpolated
[
http://jira.codehaus.org/browse/MNG-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-1943.
-
Resolution: Fixed
> MavenProject::getParent() returns a MavenProject that is NOT interpolated
> -
>
> Key: MNG-1943
> URL: http://jira.codehaus.org/browse/MNG-1943
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: John Allen
>Assignee: Shane Isbell
>Priority: Blocker
> Fix For: 3.0-alpha-3
>
> Attachments: mng-1943-test.zip
>
>
> Plugin developers repeatedly use ${project}.getParent().someMethod() yet
> getParent() returns a project that has not been interpolated. This obviously
> needs to be fixed but may I also suggest that all plugin acceptance testing
> is revisted to ensure that the tests use POMs that are littered with property
> expressions and not literals.
--
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-2349) pldoc repository automatic sync setup
pldoc repository automatic sync setup - Key: MAVENUPLOAD-2349 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2349 Project: Maven Upload Requests Issue Type: Wish Reporter: Zoltan Farkas Documentation Generator for PLSQL code, similar to javadoc. contains 2 artifacts: pldoc - the actual generator maven-pldoc-plugin - report plugin to generate the doc -- 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-3918) NPE in CLIReportingUtils
[
http://jira.codehaus.org/browse/MNG-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell updated MNG-3918:
--
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
> NPE in CLIReportingUtils
>
>
> Key: MNG-3918
> URL: http://jira.codehaus.org/browse/MNG-3918
> Project: Maven 2
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
>Priority: Minor
> Fix For: 3.0-alpha-3
>
> Attachments: pom.xml
>
>
> Running "mvn validate" on the attached POM delivers:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.maven.cli.CLIReportingUtils.handleLifecycleExecutionException(CLIReportingUtils.java:270)
> at
> org.apache.maven.cli.CLIReportingUtils.buildErrorMessage(CLIReportingUtils.java:217)
> at
> org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:162)
> at
> org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
> at
> org.apache.maven.cli.CLIReportingUtils.logResult(CLIReportingUtils.java:80)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:171)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> 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:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> {noformat}
> While the POM is indeed invalid, the original error message doesn't make it
> to the user.
> The {{LifecycleExecutionException}} to report has no project instance. In
> this particular case, the exception is created in
> {{DefaultLifecycleExecutor}} by wrapping a
> {{LifecycleSpecificationException}}. This raises the question whether the
> class {{LifecycleException}} should provide a field to carry a
> {{MavenProject}} instance, which could then be propagated to the wrapping
> exception.
--
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-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163800#action_163800 ] Bryan Loofbourrow commented on MWAR-182: Second correction: the text refers to "" in the first line. That should be "" > warSourceIncludes no longer works > - > > Key: MWAR-182 > URL: http://jira.codehaus.org/browse/MWAR-182 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: RHEL 3 >Reporter: Bryan Loofbourrow > Attachments: pom.xml > > > The element no longer seems to work, as of 2.1-alpha-2. > It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will > demonstrate the problem when used as follows: > 1) From the directory containing the pom.xml, create a web.xml, because > otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick): > mkdir -p src/main/webapp/WEB-INF > touch src/main/webapp/WEB-INF/web.xml > 2) Build with the 2.1-alpha-1 plugin > mvn clean install -Dwar.plugin.version=2.1-alpha-1 > 3) Dump out the jar contents to verify that only commons-logging and the > web.xml were packaged, as requested > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/web.xml > WEB-INF/lib/ > WEB-INF/lib/commons-logging-1.1.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties > 4) Now build using the 2.1-alpha-2 plugin version: > mvn clean install -Dwar.plugin.version=2.1-alpha-1 > 5) Dump out the jar contents and notice that warSourceIncludes was ignored > this time: > [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war > META-INF/ > META-INF/MANIFEST.MF > WEB-INF/ > WEB-INF/classes/ > WEB-INF/lib/ > WEB-INF/web.xml > WEB-INF/lib/commons-logging-1.1.jar > WEB-INF/lib/log4j-1.2.12.jar > WEB-INF/lib/logkit-1.0.1.jar > WEB-INF/lib/avalon-framework-4.1.3.jar > WEB-INF/lib/servlet-api-2.3.jar > META-INF/maven/ > META-INF/maven/example/ > META-INF/maven/example/example-war/ > META-INF/maven/example/example-war/pom.xml > META-INF/maven/example/example-war/pom.properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-410) Allow specifying specific profiles to execute in the prepare mojo
Allow specifying specific profiles to execute in the prepare mojo - Key: MRELEASE-410 URL: http://jira.codehaus.org/browse/MRELEASE-410 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-8 Reporter: Vincent Massol Right now the mojo calls project.getActiveProfiles() and adds them automatically to the "arguments". So they come in addition to profiles passed with "-Darguments=-Pprofile1,profile2,etc". We would like to only execute the passed profiles. I propose to add a "releaseProfiles" configuration element (as for release:perform, except that releaseProfiles values don't seem to be taken into account for perform for some reason but that's another problem). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2350) JCaptcha 1.0
JCaptcha 1.0 Key: MAVENUPLOAD-2350 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2350 Project: Maven Upload Requests Issue Type: Wish Reporter: Antoine Véret "com.octo.captcha","mavens...@web.sourceforge.net:/home/groups/j/jc/jcaptcha/maven-repo","rsync_ssh","Antoine Veret","ave...@octo.com",, -- 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: (MINSTALL-58) Build failure
Build failure - Key: MINSTALL-58 URL: http://jira.codehaus.org/browse/MINSTALL-58 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Windows xp Reporter: Poonam Gyanchandani Attachments: New Text Document.txt Hi, I have installed the Maven . When I am trying to run mvn package/ mvn install/mvn clean it is giving me "build failure". D:\Program Files\Apache Software Foundation\apache-maven-2.0.9>mvn package [INFO] Scanning for projects... [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [package] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: resources. It requires a project with an existing po m.xml, but the build is not using one. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Tue Feb 03 15:24:56 EST 2009 [INFO] Final Memory: 3M/6M [INFO] and when I run mvn -e D:\Program Files\Apache Software Foundation\apache-maven-2.0.9>mvn -e + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'mvn install' to build or 'mvn -?' for ptions See http://maven.apache.org for more information. [INFO] [INFO] Trace org.apache.maven.BuildFailureException: You must specify at least one goal. Try 'mvn install' to build or 'mvn -?' for ptions See http://maven.apache.org for more information. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultL fecycleExecutor.java:134) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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) [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Tue Feb 03 15:26:24 EST 2009 [INFO] Final Memory: 1M/4M [INFO] Is their anyone can help me for 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: (MAVENUPLOAD-2348) missing metadata
missing metadata Key: MAVENUPLOAD-2348 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2348 Project: Maven Upload Requests Issue Type: Bug Reporter: Tim Andersen Attachments: Index of _maven2_org_tmatesoft_svn_1.1.0_.htm cannot download artifacts because of missing files maven-metadata.xml sha1 and md5 files are missing also -- 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: (MERCURY-41) OpenPGP file seem to be OS-specific, add separate file for each OS in ITs
[ http://jira.codehaus.org/browse/MERCURY-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-41. --- Resolution: Not A Bug Turned out that windows cannot save signature files quick enough. Had to introduce delay after signing the artifact, tests work fine > OpenPGP file seem to be OS-specific, add separate file for each OS in ITs > - > > Key: MERCURY-41 > URL: http://jira.codehaus.org/browse/MERCURY-41 > Project: Mercury > Issue Type: Improvement >Affects Versions: 1.0.0-alpha-2 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-5 > > > ITs run on OS X, but fail on others. Traced one of the bugs to key storage > file being OS-specific. > For now - don't use PGP in ITs except for OS X -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MERCURY-61) ant tests fail on all grid nodes except for osx
[ http://jira.codehaus.org/browse/MERCURY-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-61. --- Resolution: Fixed Fix Version/s: 1.0-alpha-5 works now > ant tests fail on all grid nodes except for osx > --- > > Key: MERCURY-61 > URL: http://jira.codehaus.org/browse/MERCURY-61 > Project: Mercury > Issue Type: Bug >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov >Priority: Blocker > Fix For: 1.0-alpha-5 > > Attachments: ext-javac.patch, tools-jar.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > find out why ant test harness picks JRE instead of JDK and thus looses the > compiler -- 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: (MERCURY-41) OpenPGP file seem to be OS-specific, add separate file for each OS in ITs
[ http://jira.codehaus.org/browse/MERCURY-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163804#action_163804 ] Oleg Gusakov commented on MERCURY-41: - was able to find a test signature file, that verifies ok under OSX and Linux, but fails as BAD signature under Windows. Most probably - EOL conversion. > OpenPGP file seem to be OS-specific, add separate file for each OS in ITs > - > > Key: MERCURY-41 > URL: http://jira.codehaus.org/browse/MERCURY-41 > Project: Mercury > Issue Type: Improvement >Affects Versions: 1.0.0-alpha-2 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-5 > > > ITs run on OS X, but fail on others. Traced one of the bugs to key storage > file being OS-specific. > For now - don't use PGP in ITs except for OS X -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-41) OpenPGP file seem to be OS-specific, add separate file for each OS in ITs
[ http://jira.codehaus.org/browse/MERCURY-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163804#action_163804 ] Oleg Gusakov edited comment on MERCURY-41 at 2/3/09 8:09 PM: - was able to find a test signature file, that verifies ok under OSX and Linux, but fails as BAD signature under Windows. Most probably - EOL conversion, i.e. SVN related issue was (Author: olle): was able to find a test signature file, that verifies ok under OSX and Linux, but fails as BAD signature under Windows. Most probably - EOL conversion. > OpenPGP file seem to be OS-specific, add separate file for each OS in ITs > - > > Key: MERCURY-41 > URL: http://jira.codehaus.org/browse/MERCURY-41 > Project: Mercury > Issue Type: Improvement >Affects Versions: 1.0.0-alpha-2 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-5 > > > ITs run on OS X, but fail on others. Traced one of the bugs to key storage > file being OS-specific. > For now - don't use PGP in ITs except for OS X -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
