[jira] Updated: (MGROOVY-26) Add an archetype for groovy-mojo projects
[ http://jira.codehaus.org/browse/MGROOVY-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated MGROOVY-26: Fix Version/s: 1.0-alpha-3 Component/s: mojo support > Add an archetype for groovy-mojo projects > - > > Key: MGROOVY-26 > URL: http://jira.codehaus.org/browse/MGROOVY-26 > Project: Maven 2.x Groovy Plugin > Issue Type: New Feature > Components: mojo support >Reporter: Jason Dillon > Assigned To: Jason Dillon > Fix For: 1.0-alpha-3 > > > Add an archetype for groovy-mojo projects to quick start users to making > their mojo's groovy. Update the site docs to explain how to use it. -- 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: (MGROOVY-27) Split up the mojo support from the compilation/execution support
Split up the mojo support from the compilation/execution support Key: MGROOVY-27 URL: http://jira.codehaus.org/browse/MGROOVY-27 Project: Maven 2.x Groovy Plugin Issue Type: New Feature Reporter: Jason Dillon Assigned To: Jason Dillon Compilation and execution does not need all of the dependencies which are needed for the plugin extraction, so split up the modules to allow the dependency set to be tailored for each use. -- 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: (MGROOVY-26) Add an archetype for groovy-mojo projects
Add an archetype for groovy-mojo projects - Key: MGROOVY-26 URL: http://jira.codehaus.org/browse/MGROOVY-26 Project: Maven 2.x Groovy Plugin Issue Type: New Feature Reporter: Jason Dillon Assigned To: Jason Dillon Add an archetype for groovy-mojo projects to quick start users to making their mojo's groovy. Update the site docs to explain how to use it. -- 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: (MGROOVY-27) Split up the mojo support from the compilation/execution support
[ http://jira.codehaus.org/browse/MGROOVY-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed MGROOVY-27. --- Resolution: Fixed Fix Version/s: 1.0-alpha-3 > Split up the mojo support from the compilation/execution support > > > Key: MGROOVY-27 > URL: http://jira.codehaus.org/browse/MGROOVY-27 > Project: Maven 2.x Groovy Plugin > Issue Type: New Feature >Reporter: Jason Dillon > Assigned To: Jason Dillon > Fix For: 1.0-alpha-3 > > > Compilation and execution does not need all of the dependencies which are > needed for the plugin extraction, so split up the modules to allow the > dependency set to be tailored for each use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MWAR-97: Attachment: MWAR-97.diff I attached complete implementation with tests. The only problem with testExplodedWarMergeWarUpdated(org.apache.maven.plugin.war.WarExplodedMojoTest (connected with a copyFileIfModified method) needs some discuss. > War plugin and Overlays handling > > > Key: MWAR-97 > URL: http://jira.codehaus.org/browse/MWAR-97 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Piotr Tabor > Attachments: MWAR-97.diff > > > Piotr and I are currently working on the war plugin and especially > this overlay mechanism that needs to be upgraded. Currently a couple > of issues [1] in the war plugin are linked to this functionality and > we should really address them. > The idea here is to provide a better way to handle overlays through an > explicit configuration. An overlay has the following parameters: > * groupId > * artifactId > * classifier (optionnal) > * includes (default includes everything) > * excludes (default META-INF) > The order in which overlays are specified defined the order in which > they are applied. An overlay without a groupId/artifactId is > considered as the current build. If no such overlay is defined, it is > applied *last*. > The behavior should be deterministic so the copy will happen not > matter how if a file is newer than the one being applied. Overlays > order always wins. > If no overlays section is defined, the wars are processed as before; > dependentWarIncludes and dependentWarExcludes are honored. If an > overlays section is defined and those configuration items are defined, > they are ignored and a warning is logged. > If a dependent war is missing in the overlays section, it's applied > after custom overlays *and* before the current build (if the current > build is not specified of course) with the default includes/excludes. > Does that sounds ok to you? If so I'll add the proposition to the war > site and start the implementation with Piotr. We're also thinking > about integrating the merge functionality of the cargo plugin but we > still need to discuss with the cargo guys if it will be feasible. > Please comment. > Stéphane -- 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: (MAVENUPLOAD-1459) upload of svnkit 1.1.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1459. --- Assignee: Carlos Sanchez Resolution: Fixed > upload of svnkit 1.1.2 > -- > > Key: MAVENUPLOAD-1459 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1459 > Project: maven-upload-requests > Issue Type: Task >Reporter: Renaud Bruyeron > Assigned To: Carlos Sanchez > > This is release 1.1.2 for svnkit, a pure-java subversion client used by many > other projects. > Note that the svnkit developers have added the necessary hooks in their build > to easily produce the bundle with each release, which should smooth out the > publication to the repository from now on. -- 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: (MAVENUPLOAD-1460) Jython 2.2-beta-1 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1460. --- Assignee: Carlos Sanchez Resolution: Fixed > Jython 2.2-beta-1 upload request > > > Key: MAVENUPLOAD-1460 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1460 > Project: maven-upload-requests > Issue Type: Task >Reporter: Kevin Menard > Assigned To: Carlos Sanchez > > The Jython project is submitting a bundle for its latest maven bundle. This > one is a significant departure from the previous bundles in that it now uses > the new style groupId. Rather than "jython" it now uses "org.python", making > it more maven-friendly and reflecting the fact that Jython is a first-class > PSF project. This can be seen on: > http://www.python.org/psf/records/board/resolutions/ > "RESOLVED, that the org.python.* Java package name be reserved for use by the > Jython project. > Approved by IRC vote 7-0-0, March 12, 2007." > Please note that the jython.org domain is also under the jurisdiction of the > PSF, as evidenced by the WHOIS records. > Hopefully this is sufficient enough detail to prove that bundle is in good > standing for upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1462) Request to upload hamcrest library 1.0 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92283 ] Carlos Sanchez commented on MAVENUPLOAD-1462: - who owns org.hamcrest ? > Request to upload hamcrest library 1.0 bundle > - > > Key: MAVENUPLOAD-1462 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1462 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joe Walnes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1454) Upload of rmock 2.0.0. Group already exists.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92282 ] Carlos Sanchez commented on MAVENUPLOAD-1454: - that pom is not the parent please setup your own repo and use mvn deploy we'll sync and save everybody's time > Upload of rmock 2.0.0. Group already exists. > > > Key: MAVENUPLOAD-1454 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1454 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Brolund > > RMock 2.0.0 is a Java mock object framework to use with jUnit. RMock has > support for a setup-modify-run-verify workflow when writing jUnit tests. It > integrates better with IDE refactoring support and allows designing classes > and interfaces in a true test-first fashion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-513) Invalid POM: aspectwerkz/aspectwerkz-core
[ http://jira.codehaus.org/browse/MEV-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92281 ] Carlos Sanchez commented on MEV-513: that pom s wrong anyway, with snapshots, missing license,... any chance the get a correct one ? > Invalid POM: aspectwerkz/aspectwerkz-core > - > > Key: MEV-513 > URL: http://jira.codehaus.org/browse/MEV-513 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Jing Xue > > http://repo1.maven.org/maven2/aspectwerkz/aspectwerkz-core/2.0/aspectwerkz-core-2.0.pom > The closing tag is missing the "/". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-514) Please fix maven-metadata.xml for JMock
[ http://jira.codehaus.org/browse/MEV-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MEV-514. -- Assignee: Carlos Sanchez Resolution: Fixed > Please fix maven-metadata.xml for JMock > --- > > Key: MEV-514 > URL: http://jira.codehaus.org/browse/MEV-514 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Stefan Hübner > Assigned To: Carlos Sanchez > > It's impossible to retrieve jmock 1.1.0 from Central because of screwed > metadata. There is an 1.1.0 in the repo but it's not mentioned in > maven-metadata.xml > (http://repo1.maven.org/maven2/jmock/jmock/maven-metadata.xml): > > jmock > jmock > 1.0.0 > > > 1.0.0 > 1.0.0.RC1 > 1.0.1 > 20031129.200437 > 2004-03-19 > usedbypico > > > > Could this please be fixed? > Thanks a lot! > Stefan Hübner -- 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-22) patch to allow extra webapp and webapp/WEB-INF/classes files to be specified that override existing files
[ http://jira.codehaus.org/browse/MWAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92278 ] Piotr Tabor commented on MWAR-22: - I will have to apply an overlay with new resources when 2.1 version will be released . Look at http://jira.codehaus.org/browse/MWAR-97. > patch to allow extra webapp and webapp/WEB-INF/classes files to be specified > that override existing files > - > > Key: MWAR-22 > URL: http://jira.codehaus.org/browse/MWAR-22 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Cameron Braid > Attachments: maven-war-plugin-extraWarResources.patch > > > Currnelty, there is no way to execute a plugin inbetween the 'build exploded > webapp' part of this plugin, and the 'zip up resources' bit. > I have the need to override classpath resources, and sometimes other webapp > resources, based on a deployment target, such as test / staging or production. > With this patch, I will be able to have files layed out like this : > /profile/test/config.properties > /src/main/resources/config.properties > then configure the war plugin : > > profile/test > > thus producing a war that contains profile/test/config.properties instead of > the default /src/main/resources/config.properties > I have investigated alternative ways to achive this goal, and none of them > seemed easy. > Some ideas : > * split the package phase into 2 phases - preparePackage and package > * provide a generic technique to allow plugins to expose extension points > where other plugins can hook into > * create a plugin that runs after the war plugin, that creates a new war - > slow since the ziping will need to be done twice > i'm keen to hear anyone's thoughts on the mailing list or in irc - my nick is > Fracture -- 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-97) War plugin and Overlays handling
War plugin and Overlays handling Key: MWAR-97 URL: http://jira.codehaus.org/browse/MWAR-97 Project: Maven 2.x War Plugin Issue Type: New Feature Affects Versions: 2.0.2, 2.0.1, 2.0, 2.0.3 Reporter: Piotr Tabor Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied *last*. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays order always wins. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays *and* before the current build (if the current build is not specified of course) with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane -- 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-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92277 ] Carlos Sanchez commented on MNG-2931: - I added a workaround to the code to avoid changing the originating artifact version until a better solution. > DefaultArtifactCollector changes the version of the originatingArtifact if > it's in the dependencyManagement with another version > > > Key: MNG-2931 > URL: http://jira.codehaus.org/browse/MNG-2931 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts >Affects Versions: 2.0.5, 2.0.6 >Reporter: Carlos Sanchez > Attachments: MNG-2931.patch > > > DefaultDependencyTreeBuilder > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java > calls collect like this > collector.collect( project.getDependencyArtifacts(), > project.getArtifact(), managedVersions, repository, >project.getRemoteArtifactRepositories(), > metadataSource, null, >Collections.singletonList( listener ) ); > Problem: > This pom > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom > extends > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom > that in dependencyManagement has > org.codehaus.plexus:plexus-component-api:1.0-alpha-19 > so during collect project.getArtifact().getVersion() is changed to the > managedVersion instead of the original one > Either this is a bug or an exception should be thrown when > originatingArtifact is in managedVersions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1454) Upload of rmock 2.0.0. Group already exists.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92276 ] Daniel Brolund commented on MAVENUPLOAD-1454: - I hope it works. For some reason I couldn't bundle a pom with packaging pom, so I changed packaging to jar. This is the URL: http://rmock.sourceforge.net/parent-2.0.0-bundle.jar > Upload of rmock 2.0.0. Group already exists. > > > Key: MAVENUPLOAD-1454 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1454 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Brolund > > RMock 2.0.0 is a Java mock object framework to use with jUnit. RMock has > support for a setup-modify-run-verify workflow when writing jUnit tests. It > integrates better with IDE refactoring support and allows designing classes > and interfaces in a true test-first fashion. -- 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-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-2940: Attachment: patch.txt Changed name and encapsulate exception > Add a method to the embedder to list available versions of an artifact > -- > > Key: MNG-2940 > URL: http://jira.codehaus.org/browse/MNG-2940 > Project: Maven 2 > Issue Type: New Feature > Components: Embedding >Affects Versions: 2.1-alpha-1 >Reporter: Carlos Sanchez > Attachments: patch.txt, patch.txt > > > I've added a method following the style of the resolve method already present > public void resolve( Artifact artifact, List remoteRepositories, > ArtifactRepository localRepository ) throws ArtifactResolutionException, > ArtifactNotFoundException -- 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-2940) Add a method to the embedder to list available versions of an artifact
Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 2.1-alpha-1 Reporter: Carlos Sanchez Attachments: patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- 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: (MCLOVER-34) Generate Aggregated site reports on the first build run
[ http://jira.codehaus.org/browse/MCLOVER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92269 ] Vincent Massol commented on MCLOVER-34: --- When Maven is fixed! There's nothing wrong with the Clover plugin... > Generate Aggregated site reports on the first build run > --- > > Key: MCLOVER-34 > URL: http://jira.codehaus.org/browse/MCLOVER-34 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Vincent Massol > Assigned To: Vincent Massol > > There's currently an issue in Maven's site lifecycle that prevents > @aggregatore mojos from executing last when run from the site lifecycle (see > MNG-2184). Once this is fixed this issue will be fixed. -- 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: (MCLOVER-34) Generate Aggregated site reports on the first build run
[ http://jira.codehaus.org/browse/MCLOVER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92268 ] Jason Wu commented on MCLOVER-34: - When will this issue be fixed? Thanks! > Generate Aggregated site reports on the first build run > --- > > Key: MCLOVER-34 > URL: http://jira.codehaus.org/browse/MCLOVER-34 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Vincent Massol > Assigned To: Vincent Massol > > There's currently an issue in Maven's site lifecycle that prevents > @aggregatore mojos from executing last when run from the site lifecycle (see > MNG-2184). Once this is fixed this issue will be fixed. -- 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: (DOXIA-95) Doxia omits closing elements
[ http://jira.codehaus.org/browse/DOXIA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92266 ] Henning Schmiedehausen commented on DOXIA-95: - Probably yes. > Doxia omits closing elements > - > > Key: DOXIA-95 > URL: http://jira.codehaus.org/browse/DOXIA-95 > Project: doxia > Issue Type: Bug >Reporter: Henning Schmiedehausen > Fix For: 1.0-alpha-9 > > > Consider the following xdoc file: > > > > test1 > > > > text > > list1 > > text2 > > list1 > > > > > > This renders to the following HTML output: > section name > text > > list1 > > text2 > > list1 > > > Please note that there is no closing between and > This is obviously no valid XHTML. -- 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-2824) Value of parameter with expression=${plugin} is always null in Mojo
[
http://jira.codehaus.org/browse/MNG-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92264
]
Laurent Fontvielle commented on MNG-2824:
-
It is possible to use the following workaround:
1.declare the parameter:
/**
* @parameter expression="${plugin.mojos}"
* @required
* @readonly
*/
protected List pluginMojos;
2.In the plugin code, you can access the PluginDescriptor instance with this
code:
MojoDescriptor mojoDescriptor = (MojoDescriptor) pluginMojos.get(0);
PluginDescriptor plugin = mojoDescriptor.getPluginDescriptor();
> Value of parameter with expression=${plugin} is always null in Mojo
> ---
>
> Key: MNG-2824
> URL: http://jira.codehaus.org/browse/MNG-2824
> Project: Maven 2
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4
> Environment: I believe it happens everywhere since it's a logic
> problem in code
>Reporter: Jiaqi Guo
> Attachments: MNG-2824-maven-core.patch, MNG-2824-maven-core.patch
>
>
> Parameter with expression="${plugin}" in a Mojo is always null at runtime.
> Looking at
> http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.4/maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java,
> line 169 ~ 242, I realized that an "else if" check for "${plugin}" is
> missing. So if expression is "plugin", line 233 will be executed.
> expression.substring( 1 ) becomes "lugin" and pluginDescriptor.getLugin()
> will be called by ReflectionValueExtractor, and returns null because it's
> invalid. More detail has been discussed in mailing list:
> http://www.nabble.com/Can-anyone-explain-this-code-tf3218981s177.html
> The fix is simple. I can just add another condition check for
> "plugin".equals(expression).
> The problem has been there since 2.0 release but it doesn't exist in trunk.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-251) Allows prefixing of eclipse project name
Allows prefixing of eclipse project name
Key: MECLIPSE-251
URL: http://jira.codehaus.org/browse/MECLIPSE-251
Project: Maven 2.x Eclipse Plugin
Issue Type: New Feature
Components: multiproject
Affects Versions: 2.4
Reporter: Martin Desruisseaux
This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They were
closed as fixed by MECLIPSE-189, but the later doesn't adress fully our issue
(or works only if we are lucky).
We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
modules. Some Geoserver modules may (by accident) have the same name than
Geotools modules. For example both Geotools and Geoserver have a module named
"_main_". We need to import those two projects in Eclipse, because they are
closely related and share the same pool of developpers. Before MECLIPSE-189, it
was not possible with those names, because of module name clash like "_main_".
Since MECLIPSE-189, it is possible if we are lucky enough to have different
Geotools and Geoserver version numbers.
We would like a way to prefix every Eclipse module names. For example we would
like a way to add {{"gt-"}} in front of every Geotools modules imported in
Eclipse. I realize that the common practice in Maven projects seems to be long
module names (for example "{{maven-eclipse-plugin}}"), but such practice seems
quite redundant with group name. We would like to keep module names that match
SVN directory names or Maven report directory names (otherwise we often get
broken links in generated HTML pages), and we would like to keep the path names
simple and intelligible (long module names don't bring much compared to full
path names, which should already be unique).
The ability to add some prefix before Eclipse project names would help. If this
is not possible, something like {{addGroupNameToProjectName}} property (similar
to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a fallback.
--
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-2934) Cannot Deploy Using Webdav due to DependencyManagement
[ http://jira.codehaus.org/browse/MNG-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92263 ] Stephen Duncan Jr commented on MNG-2934: Notes: This only happens with Maven 2.0.6, not with 2.0.5. Also, is not only dependencyManagement that seems to break the extension, but also a direct dependency, or anything that causes the wrong version of commons-httpclient to be resolved. Dependency resolution within the project should no affect extension dependency resolution. > Cannot Deploy Using Webdav due to DependencyManagement > -- > > Key: MNG-2934 > URL: http://jira.codehaus.org/browse/MNG-2934 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Deployment >Affects Versions: 2.0.6 >Reporter: Stephen Duncan Jr > Attachments: pom.xml > > > The webdav wagon requires commons-httpclient-2.0.2.jar. If I have a > dependencyManagement section that specifies commons-httpclient 3.0.1, then > deployment fails. > The resulting output is: > [EMAIL PROTECTED] webdavtest]$ mvn deploy > [INFO] Scanning for projects... > [INFO] artifact org.apache.maven.wagon:wagon-webdav: checking for updates > from ce-releases > - > this realm = app0.child-container[extensions] > urls[0] = > file:/home/duncans/.m2/repository/de/zeigermann/xml/xml-im-exporter/1.1/xml-im-exporter-1.1.jar > urls[1] = file:/home/duncans/.m2/repository/jdom/jdom/1.0/jdom-1.0.jar > urls[2] = > file:/home/duncans/.m2/repository/org/apache/maven/wagon/wagon-webdav/1.0-beta-2/wagon-webdav-1.0-beta-2.jar > urls[3] = > file:/home/duncans/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar > urls[4] = > file:/home/duncans/.m2/repository/slide/slide-webdavlib/2.1/slide-webdavlib-2.1.jar > urls[5] = > file:/home/duncans/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > urls[6] = > file:/home/duncans/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[7] = > file:/home/duncans/.m2/repository/commons-httpclient/commons-httpclient/3.0.1/commons-httpclient-3.0.1.jar > urls[8] = file:/home/duncans/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > Number of imports: 0 > this realm = plexus.core > urls[0] = file:/home/duncans/apps/maven/lib/maven-core-2.0.6-uber.jar > Number of imports: 0 > - > [INFO] > > [INFO] Building Unnamed - test:webdavtest:pom:1.0-SNAPSHOT > [INFO]task-segment: [deploy] > [INFO] > > [INFO] [site:attach-descriptor] > [INFO] [install:install] > [INFO] Installing /home/duncans/tmp/webdavtest/pom.xml to > /home/duncans/.m2/repository/test/webdavtest/1.0-SNAPSHOT/webdavtest-1.0-SNAPSHOT.pom > [INFO] [deploy:deploy] > altDeploymentRepository = null > [INFO] Retrieving previous build number from snapshots > [WARNING] repository metadata for: 'snapshot test:webdavtest:1.0-SNAPSHOT' > could not be retrieved from repository: snapshots due to an error: > Unsupported Protocol: 'dav': Cannot find wagon which supports the requested > protocol: dav > [INFO] Repository 'snapshots' will be blacklisted > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot find > wagon which supports the requested protocol: dav > Component descriptor cannot be found in the component repository: > org.apache.maven.wagon.Wagondav. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Thu Apr 05 13:49:52 EDT 2007 > [INFO] Final Memory: 6M/10M > [INFO] > -- 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-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allan Shoup updated MNG-2923: - Attachment: MNG-2923-maven-artifact.patch In the scenario represented in MNG-2929, the problem appears to be a result of the VersionRange supplied to VersionRange.restrict having no restrictions and a recommended ArtifactVersion. The recommended version of the supplied VersionRange is ignored in this situation. "MNG-2923-maven-artifact.patch" will cause the specified VersionRange's recommended version to be used if the original VersionRange doesn't have a recommended version. Doing so resolves the scenario in question. I'm not quite sure why the recommended version range of the original VersionRange takes precedence, however. Can someone elaborate on this? > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann >Priority: Blocker > Attachments: MNG-2923-maven-artifact.patch, pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-78) create eclipse projects which are m2eclipse ready
[ http://jira.codehaus.org/browse/MECLIPSE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Baily updated MECLIPSE-78: -- Attachment: MECLIPSE-78-tag-2.3-rev3.patch Based on the latest m2eclipse plugin (0.0.10) I have included a new patch file. It seems to behave a bit differently in the following respects: - It no longer needs the project dependencies included in the source path. It seems to handle these much better. - The order of the nature and builds is such that Maven is now at the end. I've gone ahead and tried to incorporate this into the patch. I suppose if necessary a version could be specified for the m2eclipse plugin like is done for WTP. I chose not to do that at this point since I don't know of any reason not to upgrade that plugin. One thing I did find (unrelated to this plugin) is that if you (at least me) have a multi project setup I cannot access the source for debugging unless the projects are specified in the launch (Run) configuration to look at the projects. Its pretty easy though and it only needs to be done when you set up your webapp. Not sure if it happens in other cases. Still hoping that one day folks will find this worthy enough to include in the plugin. :) Cheers! > create eclipse projects which are m2eclipse ready > - > > Key: MECLIPSE-78 > URL: http://jira.codehaus.org/browse/MECLIPSE-78 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Environment: Fedora Core 3, Sun JDK 1.5.0.06, Eclipse 3.1.1, Maven > 2.0.2 >Reporter: Joshua Nichols > Attachments: m2eclipse-add-repo-tag-2.3.patch, > m2eclipse-add-repo.patch, m2eclipse.patch, m2eclipse.patch, m2eclipse.patch, > m2eclipse.patch, MECLIPSE-78-tag-2.3-rev2.patch, > MECLIPSE-78-tag-2.3-rev3.patch, MECLIPSE-78-tag-2.3.patch, MECLIPSE-78.patch > > > WIth the recent development of the m2eclipse plugin, I believe it is useful > to create eclipse projects via mvn eclipse:eclipse that use m2eclipse from > the start. One of the advantages of using m2eclipse is that you don't have to > rerun eclipse:eclipse when you update any dependencies. > A few things are necessary to accomplish this, in terms of changes to > .classpath and .project. > .project needs a new nature and builder added. For the builder: > > org.maven.ide.eclipse.maven2Builder > > > For the nature: > org.maven.ide.eclipse.maven2Nature > In the .classpath, we need to add: >path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > In .classpath, you also don't want entries path="M2_REPO/blah/blah/x.y.z/blah-x.y.z.jar"/>, because they would conflict > with m2eclipse setting up the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-295) NullPointerException in VSS SCM provider
[ http://jira.codehaus.org/browse/SCM-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92245 ] Laszlo Hornyak Kocka commented on SCM-295: -- oops, seems to be duplicate with SCM-278 > NullPointerException in VSS SCM provider > > > Key: SCM-295 > URL: http://jira.codehaus.org/browse/SCM-295 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-vss >Affects Versions: 1.0-beta-4 > Environment: Operating system : Windows XP(Service Pack 2) > Java version : 1.5.0_11(Sun Microsystems Inc.) > continuum 1.0.3 with the scm packages upgraded to 1.0-beta4 >Reporter: Laszlo Hornyak Kocka > > org.apache.maven.continuum.scm.ContinuumScmException: Error while update > sources. > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) > at > org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) > at > org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) > at > org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) > at > org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM > command. > at > org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:62) > at > org.apache.maven.scm.provider.vss.VssScmProvider.update(VssScmProvider.java:209) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:418) > at > org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:395) > at > org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) > ... 5 more > Caused by: java.lang.NullPointerException > at java.util.Calendar.setTime(Calendar.java:1032) > at java.text.SimpleDateFormat.format(SimpleDateFormat.java:785) > at java.text.SimpleDateFormat.format(SimpleDateFormat.java:778) > at java.text.DateFormat.format(DateFormat.java:314) > at > org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:114) > at > org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:52) > at -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-295) NullPointerException in VSS SCM provider
NullPointerException in VSS SCM provider Key: SCM-295 URL: http://jira.codehaus.org/browse/SCM-295 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-vss Affects Versions: 1.0-beta-4 Environment: Operating system : Windows XP(Service Pack 2) Java version : 1.5.0_11(Sun Microsystems Inc.) continuum 1.0.3 with the scm packages upgraded to 1.0-beta4 Reporter: Laszlo Hornyak Kocka org.apache.maven.continuum.scm.ContinuumScmException: Error while update sources. at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272) at org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command. at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:62) at org.apache.maven.scm.provider.vss.VssScmProvider.update(VssScmProvider.java:209) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:418) at org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:395) at org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242) ... 5 more Caused by: java.lang.NullPointerException at java.util.Calendar.setTime(Calendar.java:1032) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:785) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:778) at java.text.DateFormat.format(DateFormat.java:314) at org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:114) at org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:52) at -- 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-1462) Request to upload hamcrest library 1.0 bundle
Request to upload hamcrest library 1.0 bundle - Key: MAVENUPLOAD-1462 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1462 Project: maven-upload-requests Issue Type: Task Reporter: Joe Walnes -- 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-1461) Request to upload hamcrest api 1.0 bundle
Request to upload hamcrest api 1.0 bundle - Key: MAVENUPLOAD-1461 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1461 Project: maven-upload-requests Issue Type: Task Reporter: Joe Walnes -- 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-2939) ${basedir isn't well interpolated in properties files
[
http://jira.codehaus.org/browse/MNG-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated MNG-2939:
--
Fix Version/s: 2.0.7
> ${basedir isn't well interpolated in properties files
> -
>
> Key: MNG-2939
> URL: http://jira.codehaus.org/browse/MNG-2939
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4, 2.0.5, 2.0.6
>Reporter: Emmanuel Venisse
> Fix For: 2.0.7
>
>
> If you have ${basedir} in a properties file, it is interpolated to a
> directory path like C:\mypath\myproject instead of C\:\\mypath\\myproject
--
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-2939) ${basedir isn't well interpolated in properties files
${basedir isn't well interpolated in properties files
-
Key: MNG-2939
URL: http://jira.codehaus.org/browse/MNG-2939
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.6, 2.0.5, 2.0.4
Reporter: Emmanuel Venisse
Fix For: 2.0.7
If you have ${basedir} in a properties file, it is interpolated to a directory
path like C:\mypath\myproject instead of C\:\\mypath\\myproject
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1218) Automatically determine correct POM file location in Build Definition when checking out from SCMs like ClearCase
[ http://jira.codehaus.org/browse/CONTINUUM-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1218: Fix Version/s: 1.1-alpha-2 The change must be done in DefaultBuildController in continuum-core. When the scmresult is returned, need to update the builddefinition.buildFile if the buildFile is defined to a default value. > Automatically determine correct POM file location in Build Definition when > checking out from SCMs like ClearCase > > > Key: CONTINUUM-1218 > URL: http://jira.codehaus.org/browse/CONTINUUM-1218 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-1 >Reporter: Arne Degenring > Fix For: 1.1-alpha-2 > > > SCM-288 has introduced an attribute in CheckoutScmResult that contains the > relative path of the project directory, relative to the checkout directory. > This is needed for SCMs like ClearCase that do NOT perform the checkout into > the checkout directory itself, but into a subdirectory. See SCM-288 for > details. > This information should be honored by Continuum when adding a new project > after checking out the sources. The POM filename of the Build Definition > should automatically be set accordingly. In most cases the default "pom.xml" > is sufficient, but in cases like ClearCase it would be e.g. > "MY_VOB/my/project/dir/pom.xml". -- 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: (MRELEASE-208) Support for ClearCase, and other SCMs that do checkout projects to subdirectories of the checkout directory
[ http://jira.codehaus.org/browse/MRELEASE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-208. - Resolution: Fixed Applied. Thanks. > Support for ClearCase, and other SCMs that do checkout projects to > subdirectories of the checkout directory > --- > > Key: MRELEASE-208 > URL: http://jira.codehaus.org/browse/MRELEASE-208 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.0-beta-5 >Reporter: Arne Degenring > Assigned To: Emmanuel Venisse > Fix For: 2.0-beta-5 > > Attachments: patch-match-release-manager.txt > > > The attached patch makes the maven-release-manager support SCMs that do NOT > checkout projects into the checkout directory itself but into subdirectories > of the checkout directory. The SCM provider implementation must provide a > relative path to the project directory within the CheckoutScmResult. This has > been implemented for ClearCase already. See SCM-288 for further details. > The patch also contains a ScmTranslator implementation for ClearCase, and > therefore makes it possible to use the Release plugin with ClearCase (only > when using auto-generated config specs as introduced by SCM-287). > PS: The maven-release-plugin's unit tests in trunk seem to fail at the > moment, even without this patch, at least in my environment. This patch only > makes changes to maven-release-manager, not maven-release-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
