[jira] Created: (SCM-301) perforce cannot be used with continuum
perforce cannot be used with continuum -- Key: SCM-301 URL: http://jira.codehaus.org/browse/SCM-301 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0-rc1 Environment: summary 1- fix nullpointer in changelog command 2- add logger 3- client is no more a mandatory field in accept in the perforceInfoCommand (constraint not usefull because scm create new ones) 4- add workaround (due to continuum) to accept the default choice instead of null or empty string 5- ignore pom.xml contains if the the location is not in client spec (link to 3) Reporter: Raphael PETIT Attachments: perforce.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MRELEASE-209) Snapshot versions are not restored correctly on next development version
[ http://jira.codehaus.org/browse/MRELEASE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-209. - Resolution: Fixed Done. Snapshot versions are not restored correctly on next development version Key: MRELEASE-209 URL: http://jira.codehaus.org/browse/MRELEASE-209 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4, 2.0-beta-5 Reporter: fabrizio giustina Assignee: Emmanuel Venisse Priority: Blocker Fix For: 2.0-beta-5 On a multiproject build, snapshot version are not restored correctly in a multiproject build. for example if module1 depends on module2-1.0-SNAPSHOT (both modules are part of the same reactor build) this is the initial dependency: dependency groupIdtest/groupId artifactIdmodule2/artifactId version1.0-SNAPSHOT/version /dependency during the rewrite pom for release phase the dependency will be correctly updated to module2-2.0 dependency groupIdtest/groupId artifactIdmodule2/artifactId version2.0/version /dependency but after updating poms for the next development version the version stay as is. dependency groupIdtest/groupId artifactIdmodule2/artifactId version2.0/version /dependency while it should be upgraded to 2.0-SNAPSHOT The problem is still in the current svn version, although all the tests for RewritePomsForDevelopmentPhase work correctly: the problem is that RewritePomsForDevelopmentPhase expects to update version from release version to snapshot, but the RewritePomsForReleasePhase DON'T change the versions in the loaded projects. Poms are updated as described, but at the end of the rewrite for release phase the version seen by the plugin is still the original one (1.0-SNAPSHOT for the example above). This means that rewrite works correctly if phases are tested alone (and, in a real scenario, if you kill maven in between of the release steps and restart it, so that it can re-read poms), but it don't work correctly when poms are rewritten more than once in the same run. The problem can be verified by looking at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase:updateDomVersion() where the check if ( version.equals( originalVersion ) ) fails on a full run of the 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
[jira] Closed: (MRELEASE-137) proposed SCM release tag or label in multiproject
[
http://jira.codehaus.org/browse/MRELEASE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed MRELEASE-137.
-
Assignee: Emmanuel Venisse (was: Stephane Nicoll)
Resolution: Fixed
Fixed.
I created ReleaseUtil.getRootProject that use project.isExecutionRoot()
proposed SCM release tag or label in multiproject
-
Key: MRELEASE-137
URL: http://jira.codehaus.org/browse/MRELEASE-137
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Gilles Scokart
Assignee: Emmanuel Venisse
Priority: Minor
Fix For: 2.0-beta-5
Attachments: patch.txt
If we have
- pom.xml (name : root)
--- module1
pom.xml (name : module1)
--- module2
pom.xml (name : module1)
and we prepare a release at the root level, the name proposed for the tag is
module1-${version} instead root-${version}.
Note that except the name, everything is stored as expected with SVN.
NB: I don't know if it has an impact, but the pom in module1 and module
doesn't inherit from the root (no parent tags).
--
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-301) perforce cannot be used with continuum
[ http://jira.codehaus.org/browse/SCM-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-301: - Assignee: Mike Perham Fix Version/s: 1.0 Mike, can you review the patch? It seems to be good. perforce cannot be used with continuum -- Key: SCM-301 URL: http://jira.codehaus.org/browse/SCM-301 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0-rc1 Environment: summary 1- fix nullpointer in changelog command 2- add logger 3- client is no more a mandatory field in accept in the perforceInfoCommand (constraint not usefull because scm create new ones) 4- add workaround (due to continuum) to accept the default choice instead of null or empty string 5- ignore pom.xml contains if the the location is not in client spec (link to 3) Reporter: Raphael PETIT Assignee: Mike Perham Fix For: 1.0 Attachments: perforce.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1253) Allow to deploy artifact without timestamps
Allow to deploy artifact without timestamps
---
Key: CONTINUUM-1253
URL: http://jira.codehaus.org/browse/CONTINUUM-1253
Project: Continuum
Issue Type: New Feature
Components: Core system, Integration - Maven 2, Web - UI
Affects Versions: 1.0.3
Reporter: Damian Golda
In our organisation we don't use unique names of jars in repository. So we have
set uniqueVersion to false in pom.xml:
distributionManagement
repository
idmaven2-repo/id
nameMaven2 Repository/name
urlfile://${repoPath}/url
uniqueVersionfalse/uniqueVersion
/repository
/distributionManagement
And it works while running mvn from command line.
But when we build project from continuum, it deploys built jar into Deployment
Repository Directory and unfortunately always adds timestamps to filename.
The reason is that in
org.apache.maven.continuum.core.action.DeployArtifactContinuumAction is
specified true as uniqueVersion parameter of
ArtifactRepositoryFactory.createDeploymentArtifactRepository method:
ArtifactRepository deploymentRepository =
artifactRepositoryFactory.createDeploymentArtifactRepository(
deployment-repository, location,
repositoryLayout, true );
PLEASE, change it, and allow to set required behavior by admin in Edit
Configuration page.
We have strange problems with hundreds of fat jars in repository, caused by
unique names of them.
I think it's needed to:
-add to Configuration new field, for example DeployWithUniqueVersion
-change DeployArtifactContinuumAction, to uset that field instead of hard-coded
true
-add new field to EditContinuumConfiguration.vm
-add some code to ConfigurationAction and InitializationChecker
--
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: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93980
]
Elid OR commented on MANTRUN-51:
Near one year later this bug isn't not fixed yet ...
A solution (not elegant) is to add your dependencies (in the dependencies of
the antrun plugin section) in the pom.xml of the first module launched in the
build order.
This allow all other projects to benefit of these dependencies.
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing
ant tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
[jira] Commented: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93981
]
Filippos Slavik commented on MANTRUN-51:
Give an unique id for each execution section of the antrun plugin in your
pom's and let us know if this fixes the issue.
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error executing
ant tasks
at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:77)
at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:72)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: taskdef class com.izforge.izpack.ant.IzPackTask cannot be found
at
[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_93982 ] Chris Wewerka commented on MNG-2931: Very, very ugly effect of this bug is that already deployed versions are overwritten by newer versions without notice. Maven changes the artifact version to the managed version and deploys it to the repository 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] Closed: (MRELEASE-147) Version number for a dependency with ${pom.groupId} not updated in multi-module.
[
http://jira.codehaus.org/browse/MRELEASE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed MRELEASE-147.
-
Assignee: Emmanuel Venisse
Resolution: Fixed
Fixed.
Version number for a dependency with ${pom.groupId} not updated in
multi-module.
Key: MRELEASE-147
URL: http://jira.codehaus.org/browse/MRELEASE-147
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: Sylvain Deschênes
Assignee: Emmanuel Venisse
Priority: Minor
Fix For: 2.0-beta-5
I have a multi-module project, project-A depends on project-B.
If I use in project-A :
dependency
groupId${pom.groupId}/groupId
artifactIdproject-B/artifactId
version1.0-SNAPSHOT/version
/dependency
The version number is not updated when I do a release.
But with:
dependency
groupIdcom.real.group.id/groupId
artifactIdproject-B/artifactId
version1.0-SNAPSHOT/version
/dependency
The release plugin updates it perfectly.
--
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-159) Add FAQ about building multi-module assemblies from the top using Maven 2.0
[ http://jira.codehaus.org/browse/MASSEMBLY-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93988 ] Geoffrey De Smet commented on MASSEMBLY-159: Why can mvn package assembly:directory be run, but it cannot be added like this? plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-1/version executions execution idmake-assembly/id phaseinstall/phase goals goaldirectory/goal /goals /execution /executions Add FAQ about building multi-module assemblies from the top using Maven 2.0 --- Key: MASSEMBLY-159 URL: http://jira.codehaus.org/browse/MASSEMBLY-159 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Maven 2.0 Reporter: Wendy Smoak John's post about why 'assembly:assembly' needs to be run separately with Maven 2.0 should be adapted for the FAQ. http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html Related Threads: http://www.nabble.com/Attaching-an-assembly-to-a-multi-module-project-t2608001s177.html http://www.nabble.com/HOWTO%3A-Have-assembly-plugin-call-package-automatically-before-doing-assembly--t2542444s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPPLUGIN-30) Plugins on a per-user basis
[
http://jira.codehaus.org/browse/MPPLUGIN-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MPPLUGIN-30:
Fix Version/s: (was: 1.7.1)
Plugins on a per-user basis
---
Key: MPPLUGIN-30
URL: http://jira.codehaus.org/browse/MPPLUGIN-30
Project: maven-plugin-plugin
Issue Type: Bug
Affects Versions: 1.5
Environment: Linux (Debian), Maven 1.1
Reporter: Rodrigo S. de Castro
Attachments: maven-plugin-plugin-installation.patch
Problem:
When I try to compile Geronimo, it fails when trying to install its plugin
into the $MAVEN_HOME directory, since it is a shared installation in
/usr/local/maven-1.1. It does not install the plugins on a per-user basis to
my maven local directory (~/.maven). Is this the intended behaviour?
Analysis:
In the org.apache.maven.plugin.PluginManager class, which is called for
plugin:install-now, the plugin is installed in the user plugins dir, as we
may check through the following code:
if ( cache )
{
FileUtils.copyFileToDirectory( file, userPluginsDir );
cacheManager.registerPlugin( pluginName, housing );
housing.parse( cacheManager );
cacheManager.saveCache( unpackedPluginsDir );
}
Since I am not sure if the behaviour was intentional, I would like to know
your opinion about that.
From the point of view that there is an inconsistent behaviour, I will attach
a patch that changes plugin:install to do the same as plugin:install-now:
install in the user directory. With this patch, current repository version of
Apache Geronimo works properly.
Concerning plugin removal, the code already check both directories (global
and user), as you may check here (plugin/plugin.jelly):
define:tag name=uninstall
ant:delete verbose=false failonerror=false
ant:fileset dir=${maven.plugin.dir}
ant:include name=${name}-*.jar /
/ant:fileset
ant:fileset dir=${maven.plugin.user.dir}
ant:include name=${name}-*.jar /
/ant:fileset
/ant:delete
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] Updated: (MPIDEA-41) A new property where I can set a comma separated list of excluded directories
[ http://jira.codehaus.org/browse/MPIDEA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MPIDEA-41: -- Fix Version/s: (was: 1.7) A new property where I can set a comma separated list of excluded directories - Key: MPIDEA-41 URL: http://jira.codehaus.org/browse/MPIDEA-41 Project: maven-idea-plugin Issue Type: New Feature Affects Versions: 1.6 Reporter: Ross Mason This is usful for for exculding things like xdoc and lib dirs -- 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-6) Multiproject Release: No check in
[ http://jira.codehaus.org/browse/MRELEASE-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-6. --- Assignee: Emmanuel Venisse (was: Jason van Zyl) Resolution: Fixed Done. Need to use the 'commitByProject' parameter of prepare mojo Multiproject Release: No check in - Key: MRELEASE-6 URL: http://jira.codehaus.org/browse/MRELEASE-6 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Windows XP, Eclipse Workspace Reporter: Bernd Mau Assignee: Emmanuel Venisse Priority: Critical Fix For: 2.0-beta-5 I tried to release a multiproject with 5 modules (on a Branch). Well, the POMs of all modules are changed and there are some dependencies which have been updated correctly. But only the master has been checked in correctly. I'm changed the recommended layout, to fit in an eclipse workspace. I have one master at the same level as the other modules. The module section of the master pom.xml: modules module../hhla.library.pom/module module../hhla.library.site/module module../hhla.lang/module module../hhla.common.log4jx/module /modules -- 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-204) Make a single goal (assembly:assembly) that covers all cases of assembly:attached, directory, ...
Make a single goal (assembly:assembly) that covers all cases of assembly:attached, directory, ... - Key: MASSEMBLY-204 URL: http://jira.codehaus.org/browse/MASSEMBLY-204 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Geoffrey De Smet It shouldn't be that hard to check wheter it's a multiproject or not. From a users perspective, when I bind the assembly plugin like this: plugin artifactIdmaven-assembly-plugin/artifactId executions execution goals goalassembly/goal /goals /execution it should just work, without having to figure out if it's a multiproject, etc. Ps: I 've read the 7 different assembly goals 5 times, and I only understand the difference between unpack, attached and assembly... Great improvements in 2.2's descriptor though :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-68) artifact:depencies doesnt work with Snapshot
artifact:depencies doesnt work with Snapshot
Key: MANTTASKS-68
URL: http://jira.codehaus.org/browse/MANTTASKS-68
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.0.6
Reporter: David N'DIAYE
Attachments: testDependencySnapshots.zip
-- I have a repository with snapshot
-- I create a pom with a dependency to snapshot artifact
{code:xml}
dependencies
dependency
groupIdcommons-io/groupId
artifactIdcommons-io/artifactId
version1.3-SNAPSHOT/version
/dependency
/dependencies
{code}
-- In ant, I obtain dependencies on my application
{code:xml}
artifact:dependencies filesetId=compile.dependency.fileset
useScope=compile verbose=true
pom refid=pom /
remoteRepository refid=repository /
localRepository location=./cache /
/artifact:dependencies
{code}
The {{compile.dependency.fileset}} *doesn't contains the snapshot artifact*
To test this bug, you can launch my ant test by : {color:red} *{{ant
test}}*{color}
--
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-301) perforce cannot be used with continuum
[ http://jira.codehaus.org/browse/SCM-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93992 ] Mike Perham commented on SCM-301: - I'll apply it later today. perforce cannot be used with continuum -- Key: SCM-301 URL: http://jira.codehaus.org/browse/SCM-301 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0-rc1 Environment: summary 1- fix nullpointer in changelog command 2- add logger 3- client is no more a mandatory field in accept in the perforceInfoCommand (constraint not usefull because scm create new ones) 4- add workaround (due to continuum) to accept the default choice instead of null or empty string 5- ignore pom.xml contains if the the location is not in client spec (link to 3) Reporter: Raphael PETIT Assignee: Mike Perham Fix For: 1.0 Attachments: perforce.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-301) perforce cannot be used with continuum
[ http://jira.codehaus.org/browse/SCM-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93991 ] Mike Perham commented on SCM-301: - Looks good to me. There's some minor style issues with 2-3 code blocks that don't meet the Maven code style but the functionality is improved. perforce cannot be used with continuum -- Key: SCM-301 URL: http://jira.codehaus.org/browse/SCM-301 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0-rc1 Environment: summary 1- fix nullpointer in changelog command 2- add logger 3- client is no more a mandatory field in accept in the perforceInfoCommand (constraint not usefull because scm create new ones) 4- add workaround (due to continuum) to accept the default choice instead of null or empty string 5- ignore pom.xml contains if the the location is not in client spec (link to 3) Reporter: Raphael PETIT Assignee: Mike Perham Fix For: 1.0 Attachments: perforce.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2959) Version defined in dependencyManagement section of parent pom overwrites version of current artifact
Version defined in dependencyManagement section of parent pom overwrites version of current artifact Key: MNG-2959 URL: http://jira.codehaus.org/browse/MNG-2959 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: linux, java 1.5 Reporter: Felix Knecht Priority: Critical If the parent pom dependencyManagement contains also the current artifact with a version, this version will overwrite the version of the current project. Problem: If that artifact is build with M206, the current project (artifact) will be deployed with the version coming from the parents pom dependencyManagement insted of the current projects version. -- 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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[
http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93993
]
David N'DIAYE commented on MANTTASKS-67:
I'm sorry, it is my first jira, and i'm newby with your formatting notation.
I can't modify my description, so i copy it in this comment with a good format :
-
-- The zip file contains test with Ant. To launch it : {color:red}*{{ant
test.}}*{color}
I try to deploy a snapshot artifact in repository
-- my pom.xml contains a version with the extension '-SNAPSHOT'
-- in my build file Ant i do this :
{code:xml}
artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
/artifact:deploy
{code}
In the repository the name of the artifact is
{code:xml}artifactId-version-SNAPSHOT.packaging !-- Wrong Format --
{code} instead of
{code:xml}artifactId-version-date.time-buildNumber-packaging{code}
Another problem, i try to upload *2 attachments* with my artifact ({{javadoc}}
and {{java-source}}), and the *buildNumber* in the {{maven-metadata.xml}}
increment by {color:red}*3*{color} instead of *1*
{code:xml}artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
attach file=./lib/${pom.artifactId}-src.jar type=java-source/
attach file=./lib/${pom.artifactId}-api.zip type=javadoc/
/artifact:deploy{code}
You can test it with : {color:red}*{{ant testWithAttach.}}*{color}
artifact:deploy - The name of deploying element in snapshot repository is
wrong
---
Key: MANTTASKS-67
URL: http://jira.codehaus.org/browse/MANTTASKS-67
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.0.6
Reporter: David N'DIAYE
Attachments: testSnapshots.zip
The zip file contains test with Ant.
To launch it : ant test.
I try to deploy a snapshot artifact in repository
So, my pom.xml contains a version with the extension '-SNAPSHOT'
And in my build file Ant i do this :
artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
/artifact:deploy
In the repository the name of the artifact is
artifactId-version-SNAPSHOT.packaging instead of
artifactId-version-date.time-buildNumber-packaging
Another problem, i try to upload 2 attachments with my artifact (javadoc and
java-source), and the buildNumber in the meta-data.xml increment by 3 instead
of 1
artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
attach file=./lib/${pom.artifactId}-src.jar type=java-source/
attach file=./lib/${pom.artifactId}-api.zip type=javadoc/
/artifact:deploy
You can test it with : ant testWithAttach
--
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[
http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93994
]
David N'DIAYE commented on MANTTASKS-67:
I haven't see the MANTTASKS-23, and i create a copy of it.
But my case contains an Ant testCase, and i find another problem with
attachment.
artifact:deploy - The name of deploying element in snapshot repository is
wrong
---
Key: MANTTASKS-67
URL: http://jira.codehaus.org/browse/MANTTASKS-67
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.0.6
Reporter: David N'DIAYE
Attachments: testSnapshots.zip
The zip file contains test with Ant.
To launch it : ant test.
I try to deploy a snapshot artifact in repository
So, my pom.xml contains a version with the extension '-SNAPSHOT'
And in my build file Ant i do this :
artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
/artifact:deploy
In the repository the name of the artifact is
artifactId-version-SNAPSHOT.packaging instead of
artifactId-version-date.time-buildNumber-packaging
Another problem, i try to upload 2 attachments with my artifact (javadoc and
java-source), and the buildNumber in the meta-data.xml increment by 3 instead
of 1
artifact:deploy file=lib/${pom.artifactId}.jar
remoteRepository url=file:./repository /
pom refid=pom /
attach file=./lib/${pom.artifactId}-src.jar type=java-source/
attach file=./lib/${pom.artifactId}-api.zip type=javadoc/
/artifact:deploy
You can test it with : ant testWithAttach
--
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-203) assembly:attached creates empty assemblies in reactor builds, but works fine in normal builds
[
http://jira.codehaus.org/browse/MASSEMBLY-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93997
]
Graham Leggett commented on MASSEMBLY-203:
--
Further details:
Turns out the assembly has as dependencies some packages that include
classifiers:
dependency
groupIdalchemy/groupId
artifactIdalchemy-quant/artifactId
version${alchemy-native-version}/version
classifier${os-platform}/classifier
/dependency
When the assembly is built from the assembly artifact, the assembly is built
correctly.
When the assembly is built as part of the reactor build, the assembly packaging
process breaks at the point where the dependency with the classifier is
unpacked.
The key breakage is found by the presence of a directory called -linux in the
jar (the classifier resolves to linux):
Archive:
/udd001/app/alchemy/development/mx/trunk/alchemy-measure-assembly/target/alchemy-measure-assembly-4.0.4-SNAPSHOT-jar-with-dependencies.jar
Length Date TimeName
0 04-24-07 16:15 META-INF/
3006 04-24-07 16:15 META-INF/MANIFEST.MF
0 12-12-06 13:04 org/
0 12-12-06 13:03 org/jboss/
0 04-24-07 16:15 org/jboss/annotation/
0 04-24-07 16:15 org/jboss/annotation/security/
0 04-24-07 16:15 org/jboss/annotation/ejb/
0 04-24-07 16:15 org/jboss/annotation/ejb/cache/
0 04-24-07 16:15 org/jboss/annotation/ejb/cache/simple/
0 04-24-07 16:15 org/jboss/annotation/ejb/cache/tree/
0 04-24-07 16:15 org/jboss/annotation/internal/
0 04-03-07 16:18 quant/
0 04-24-07 16:15 -linux/
0 04-03-07 16:18 -linux/quant/
0 04-03-07 16:18 -linux/META-INF/
1273 12-12-06 13:03
org/jboss/annotation/security/SecurityDomainImpl.class
440 12-12-06 13:03 org/jboss/annotation/security/RunAsPrincipal.class
668 12-12-06 13:03
org/jboss/annotation/security/RunAsPrincipalImpl.class
507 12-12-06 13:03 org/jboss/annotation/security/SecurityDomain.class
734 12-12-06 13:03 org/jboss/annotation/ejb/LocalBindingImpl.class
445 12-12-06 13:03 org/jboss/annotation/ejb/LocalBinding.class
430 12-12-06 13:03 org/jboss/annotation/ejb/Local.class
661 12-12-06 13:03 org/jboss/annotation/ejb/IIOP.class
594 12-12-06 13:03
org/jboss/annotation/ejb/ExcludeDefaultInterceptorsImpl.class
586 12-12-06 13:03
org/jboss/annotation/ejb/ExcludeClassInterceptorsImpl.class
1038 12-12-06 13:03 org/jboss/annotation/ejb/Durability.class
1135 12-12-06 13:03 org/jboss/annotation/ejb/DependsImpl.class
449 12-12-06 13:03 org/jboss/annotation/ejb/Depends.class
1062 12-12-06 13:03 org/jboss/annotation/ejb/DeliveryMode.class
1818 12-12-06 13:03
org/jboss/annotation/ejb/DefaultActivationSpecsImpl.class
470 12-12-06 13:03
org/jboss/annotation/ejb/DefaultActivationSpecs.class
555 12-12-06 13:03 org/jboss/annotation/ejb/CurrentMessageImpl.class
419 12-12-06 13:03 org/jboss/annotation/ejb/CurrentMessage.class
2217 12-12-06 13:03 org/jboss/annotation/ejb/ConsumerImpl.class
540 12-12-06 13:03 org/jboss/annotation/ejb/Consumer.class
1464 12-12-06 13:03 org/jboss/annotation/ejb/ClusteredImpl.class
600 12-12-06 13:03 org/jboss/annotation/ejb/Clustered.class
522 12-12-06 13:03
org/jboss/annotation/ejb/cache/simple/CacheConfig.class
1031 12-12-06 13:03
org/jboss/annotation/ejb/cache/simple/CacheConfigImpl.class
455 12-12-06 13:03
org/jboss/annotation/ejb/cache/simple/PersistenceManager.class
911 12-12-06 13:03
org/jboss/annotation/ejb/cache/simple/PersistenceManagerImpl.class
612 12-12-06 13:03
org/jboss/annotation/ejb/cache/tree/CacheConfig.class
1323 12-12-06 13:03
org/jboss/annotation/ejb/cache/tree/CacheConfigImpl.class
422 12-12-06 13:03 org/jboss/annotation/ejb/cache/Cache.class
694 12-12-06 13:03 org/jboss/annotation/ejb/cache/CacheImpl.class
1239 12-12-06 13:03 org/jboss/annotation/ejb/AcknowledgementMode.class
431 12-12-06 13:03 org/jboss/annotation/ejb/AspectDomain.class
739 12-12-06 13:03 org/jboss/annotation/ejb/AspectDomainImpl.class
671 12-12-06 13:03 org/jboss/annotation/ejb/LocalHomeImpl.class
521 12-12-06 13:03 org/jboss/annotation/ejb/LocalImpl.class
476 12-12-06 13:03 org/jboss/annotation/ejb/Management.class
780 12-12-06 13:03 org/jboss/annotation/ejb/ManagementImpl.class
748 12-12-06 13:03 org/jboss/annotation/ejb/MessageProperties.class
2038 12-12-06 13:03 org/jboss/annotation/ejb/MessagePropertiesImpl.class
524 12-12-06 13:03 org/jboss/annotation/ejb/PoolClass.class
1724 12-12-06 13:03
[jira] Created: (MNG-2960) Some maven-project tests fail under maven-surefire-plugin 2.3
Some maven-project tests fail under maven-surefire-plugin 2.3 - Key: MNG-2960 URL: http://jira.codehaus.org/browse/MNG-2960 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.7 Environment: Windows XP, Cygwin, Java 1.5.0_11 Reporter: Mark Hobson Attachments: patch.txt When maven-project tests are run on Windows, within a path with spaces, using maven-surefire-plugin 2.3, some tests fail with test resource path encoding problems. This appears to be due to maven-surefire-plugin 2.3 using a different context classloader to 2.2. IIRC the system classloader has different behaviour to URLClassLoader with regard to escaping spaces, so the attached patch uses the correct URL to File conversion. -- 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-220) Add property to keep released versions for dependencies
Add property to keep released versions for dependencies --- Key: MRELEASE-220 URL: http://jira.codehaus.org/browse/MRELEASE-220 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: Daniel Beland When I release a project with many modules with internal dependencies. I would like those dependencies to keep the released version rather than the next development version. ie: I only release some modules at a time (those that were changed only since last release). So when my webapp is released, I want it to become SNAPSHOT again(as it is done already) but want the internal dependencies to keep the released version. I want to update them manually whenever I change one. -- 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: (SCM-300) CVS doesn't close it's session after checkout
[ http://jira.codehaus.org/browse/SCM-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-300. Resolution: Fixed CVS doesn't close it's session after checkout - Key: SCM-300 URL: http://jira.codehaus.org/browse/SCM-300 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.0-rc1 Environment: Linux, Sun JDK 1.4. Continuum built from trunk. Reporter: Hilco Wijbenga Assignee: Emmanuel Venisse Fix For: 1.0 We've been trying to set up Continuum and consequently we started running some builds. It all worked nicely until the CVS server ran out of inodes in its /tmp directory. It looks like it's not the normal checkouts that people do that's causing this ... it appears to be Continuum. We tried a small build with Continuum and lo and behold: /tmp had a new directory that was not deleted at the end of the checkout. So we're fairly certain it's something Continuum related. CVS creates a sort of cache directory (in /tmp) for each checkout (it stores the CVS directories, not any of the files that are being checked out) and this directory (and all of its *many* subdirectories) are not being deleted. Apparently, it doesn't notice that the checkout has finished. Something like a session not being closed. After three days of this our server runs out of inodes and nothing works anymore. We've created a cron job to remove these CVS directories from /tmp at the end of the day so we have a workaround. -- 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-220) Add property to keep released versions for dependencies
[ http://jira.codehaus.org/browse/MRELEASE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated MRELEASE-220: -- Assignee: Emmanuel Venisse Description: When I release a project with many modules with internal dependencies. I would like those dependencies to keep the released version rather than the next development version. ie: I only release some modules at a time (those that were changed only since last release). So when my webapp is released, I want it to become SNAPSHOT again(as it is done already) but want the internal dependencies to keep the released version. I want to update them manually whenever I change one. was: When I release a project with many modules with internal dependencies. I would like those dependencies to keep the released version rather than the next development version. ie: I only release some modules at a time (those that were changed only since last release). So when my webapp is released, I want it to become SNAPSHOT again(as it is done already) but want the internal dependencies to keep the released version. I want to update them manually whenever I change one. Fix Version/s: 2.0-beta-5 Add property to keep released versions for dependencies --- Key: MRELEASE-220 URL: http://jira.codehaus.org/browse/MRELEASE-220 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: Daniel Beland Assignee: Emmanuel Venisse Fix For: 2.0-beta-5 When I release a project with many modules with internal dependencies. I would like those dependencies to keep the released version rather than the next development version. ie: I only release some modules at a time (those that were changed only since last release). So when my webapp is released, I want it to become SNAPSHOT again(as it is done already) but want the internal dependencies to keep the released version. I want to update them manually whenever I change one. -- 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: (MRELEASE-177) generateReleasePoms does not work
[ http://jira.codehaus.org/browse/MRELEASE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94002 ] Mark Hobson commented on MRELEASE-177: -- Just to let people know that I started work on this a while back and hope to get a patch together in the near-future. generateReleasePoms does not work - Key: MRELEASE-177 URL: http://jira.codehaus.org/browse/MRELEASE-177 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Gabriele Contini Priority: Critical the goal release:prepare does not create the release poms. All the code is commented. This make impossible to reproduce build if you use version ranges. -- 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-1461) Request to upload hamcrest api 1.0 bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94006 ] Carlos Sanchez commented on MAVENUPLOAD-1461: - who owns hamcrest.org ? 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] Commented: (MAVENUPLOAD-1476) Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94007 ] Carlos Sanchez commented on MAVENUPLOAD-1476: - this bundle is wrong either all of them share sources and javadocs, or you need a pom for each one (and so a different bundle for each) Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio -- Key: MAVENUPLOAD-1476 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1476 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/bcprov-1.36-bundle.jar http://www.bouncycastle.org/java.html The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the newly released J2ME) with the additional infrastructure to conform the algorithms to the JCE framework. -- The JDK14 version of bcprov 1.36 is already on ibiblio at /maven2/bouncycastle/bcprov-jdk14/136, but its POM file is woefully incomplete, its groupId is not in reverse domain order, and it lacks sources and javadoc attachments. I am submitting this bundle that contains the JDK14, JDK15, and JDK16 versions of bcprov 1.36 along with sources and javadoc attachments for each. The POM file in my bundle includes name, description, URL, and license information. -- 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-1492) Please upload OpenXRI Client bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1492. --- Assignee: Carlos Sanchez Resolution: Fixed Please upload OpenXRI Client bundle --- Key: MAVENUPLOAD-1492 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1492 Project: maven-upload-requests Issue Type: Task Reporter: William Tan Assignee: Carlos Sanchez http://www.openxri.org/maven/org.openxri.client/openxri-client-1.0.1-bundle.jar http://www.openxri.org/ http://sourceforge.net/project/memberlist.php?group_id=132761 OpenXRI is an open source project reference implementation of the XRI (Extensible Resource Identifier) abstract identifier resolution protocol based on the specifications from the OASIS XRI Technical Committee. The OpenXRI Client module depends on the syntax module (openxri-syntax) and provides XRI resolution functionality to client applications. -- 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-1476) Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94009 ] Matt Whitlock commented on MAVENUPLOAD-1476: I personally feel that a separate POM for each would not be correct, as they are logically the same artifact and fulfill the same role, with only minor differences to take advantage of features in different versions of the JavaSE. What do you think should happen here? Should I re-create the bundle with only these files? bcprov-1.36-jdk14.jar bcprov-1.36-jdk15.jar bcprov-1.36-jdk16.jar bcprov-1.36-javadoc.jar bcprov-1.36-sources.jar And just use the javadoc and sources from the jdk16 variant for all of them? Upload org.bouncycastle:bcprov:jar:1.36 to ibiblio -- Key: MAVENUPLOAD-1476 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1476 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/bcprov-1.36-bundle.jar http://www.bouncycastle.org/java.html The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the newly released J2ME) with the additional infrastructure to conform the algorithms to the JCE framework. -- The JDK14 version of bcprov 1.36 is already on ibiblio at /maven2/bouncycastle/bcprov-jdk14/136, but its POM file is woefully incomplete, its groupId is not in reverse domain order, and it lacks sources and javadoc attachments. I am submitting this bundle that contains the JDK14, JDK15, and JDK16 versions of bcprov 1.36 along with sources and javadoc attachments for each. The POM file in my bundle includes name, description, URL, and license information. -- 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-1493) Uploading pyx4me 2.0.1 to The Central Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1493. --- Assignee: Carlos Sanchez Resolution: Fixed next time you'll have to setup your own repo for sync http://maven.apache.org/guides/mini/guide-central-repository-upload.html Sync'ing your own repository with ibiblio Uploading pyx4me 2.0.1 to The Central Repository Key: MAVENUPLOAD-1493 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1493 Project: maven-upload-requests Issue Type: Task Reporter: Vlad Skarzhevskyy Assignee: Carlos Sanchez The collection of maven-plugins and Archetype used develop applications for the Java Micro Edition Platform Upload has 3 parent poms to be loaded first. http://www.pyx4j.com/downloads/pyx4me-2.0.1/pyx4me-parent-2.0.1-bundle.jar http://www.pyx4j.com/downloads/pyx4me-2.0.1/pyx4me-maven-plugins-parent-2.0.1-bundle.jar http://www.pyx4j.com/downloads/pyx4me-2.0.1/j2me-maven-plugin-2.0.1-bundle.jar http://www.pyx4j.com/downloads/pyx4me-2.0.1/proguard-maven-plugin-2.0.1-bundle.jar http://www.pyx4j.com/downloads/pyx4me-2.0.1/pyx4me-archetypes-parent-2.0.1-bundle.jar http://www.pyx4j.com/downloads/pyx4me-2.0.1/j2me-simple-2.0.1-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2921) ejb-client dependency no longer working
[ http://jira.codehaus.org/browse/MNG-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94011 ] John Allen commented on MNG-2921: - agreed this is not the kind of failure you expect in a minor release however with the patch one hopes we'll might see a 2.0.7 soon ejb-client dependency no longer working --- Key: MNG-2921 URL: http://jira.codehaus.org/browse/MNG-2921 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: Fedora Core 6 Reporter: Frank Cornelis Assignee: Jason van Zyl Priority: Blocker Fix For: 2.0.7 Attachments: MNG-2921.diff, test.zip When running 'mvn clean install' on the test project (see attachment) under Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. On Maven 2.0.5 I get in the log: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) Under Maven 2.0.6 I get: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT (selected for null) and an error message saying it cannot find the required interfaces defined in Model. When I remove type:ejb-client in the Client pom.xml it compiles again. -- 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-1494) spoon-core-1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1494. --- Assignee: Carlos Sanchez Resolution: Fixed spoon-core-1.1 -- Key: MAVENUPLOAD-1494 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1494 Project: maven-upload-requests Issue Type: New Feature Reporter: David Bernard Assignee: Carlos Sanchez Spoon is a Java program processor that fully supports Java 5. It provides a complete and fine-grained Java metamodel where any program element (classes, methods, fields, statements, expressions...) can be accessed both for reading and modification. javadoc : http://spoon.gforge.inria.fr/maven2/fr/inria/gforge/spoon/spoon-core/1.1/spoon-core-1.1-javadoc.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1484) Please upload EZMorph-1.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1484. --- Assignee: Carlos Sanchez Resolution: Fixed Please upload EZMorph-1.0.2 --- Key: MAVENUPLOAD-1484 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1484 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray Assignee: Carlos Sanchez EZMorph is simple java library for transforming an Object to another Object. This release covers minor bugfixes. -- 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-1488) rxtx. upload : java serial and parallel I/O API
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94015 ] Carlos Sanchez commented on MAVENUPLOAD-1488: - no pom in bundle rxtx. upload : java serial and parallel I/O API --- Key: MAVENUPLOAD-1488 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1488 Project: maven-upload-requests Issue Type: Task Reporter: Julien Vermillard RXTX is a native lib providing serial and parallel communication for the Java Development Toolkit (JDK). All deliverables are under the gnu LGPL license. I upload it because I need it for apache MINA (for more info : [EMAIL PROTECTED]), I'm not an RXTX developer. -- 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-1495) Upload FreeMarker 2.3.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1495. --- Assignee: Carlos Sanchez Resolution: Fixed Upload FreeMarker 2.3.10 Key: MAVENUPLOAD-1495 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1495 Project: maven-upload-requests Issue Type: Task Reporter: Mirko Nasato Assignee: Carlos Sanchez Please upload a relocation POM as well http://www.artofsolving.com/files/freemarker-2.3.10.pom for people using the old groupId freemarker - the new bundle uses org.freemarker. -- 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-1496) Blogger API Client is an implementation of Blogger API for Java. Please upload!
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94016 ] Carlos Sanchez commented on MAVENUPLOAD-1496: - license is missing url Blogger API Client is an implementation of Blogger API for Java. Please upload! --- Key: MAVENUPLOAD-1496 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1496 Project: maven-upload-requests Issue Type: Task Reporter: zhoushuqun http://redv.com/blogger-api-client/downloads/blogger-api-client-1.1-bundle.jar http://code.google.com/p/blogger-api-client/ http://redv.com/blogger-api-client/team-list.html Blogger API Client is an implementation of Blogger API for Java. Please 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-1497) Upload Unitils 1.0 rc 2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94017 ] Carlos Sanchez commented on MAVENUPLOAD-1497: - the use of provided scope is wrong, optional already means that a dependency is optional. Upload Unitils 1.0 rc 2 --- Key: MAVENUPLOAD-1497 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1497 Project: maven-upload-requests Issue Type: Task Reporter: Tim Ducheyne -- 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-1498) Upload JUEL
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1498. --- Assignee: Carlos Sanchez Resolution: Fixed Upload JUEL --- Key: MAVENUPLOAD-1498 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1498 Project: maven-upload-requests Issue Type: Task Reporter: Martin Ellis Assignee: Carlos Sanchez JUEL is an implementation of the javax.el.* API - the basis of the Unified Expression Language used in JSP/JSF. It's Apache 2.0 licenced, with copy of CDDL'd javax.el API from Glassfish. The main site for the project is http://juel.sf.net/ It's written by Christoph Beck, of Odysseus Software, http://odysseus.de/ The de.odysseus.juel groupId is his choice (in preference to net.sf.juel - the packages for the implementation classes are under de.odysseus. The odysseus.de domain is registered to Christoph: http://www.who.is/whois-de/ip-address/odysseus.de/ who has uploaded the bundle to that domain: http://odysseus.de/juel/juel-2.1.0-bundle.jar The pom in the referenced bundle includes my name and his (this is the best I can do for a contributor URL). The main jar includes everything you need to embed the EL interpreter. The impl jar is similar, but lacks the javax.el.* API - hence is useful for replacing the implementation used by a container that already has a copy of those classes. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1499) JEuclid 2.9.6
JEuclid 2.9.6 - Key: MAVENUPLOAD-1499 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1499 Project: maven-upload-requests Issue Type: Task Reporter: Max Berger Juclid is a complete MathML rendering solution, consisting of: a MathViewer application, command line converters from MathML to other formats, an ant task for autmated conversion, display components for AWT and Swing and a component for Apache Cocoon. This is the newest release. Thank you (also for uploading the older releases) -- 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-1500) Upload jMock 2.0.0
Upload jMock 2.0.0 -- Key: MAVENUPLOAD-1500 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1500 Project: maven-upload-requests Issue Type: Task Reporter: analogue Assignee: Carlos Sanchez http://haroon.sis.utoronto.ca/jmock-1.2.0/jmock-1.2.0-bundle.jar http://haroon.sis.utoronto.ca/jmock-1.2.0/jmock-cglib-1.2.0-bundle.jar jMock is a library that supports test-driven development of Java code with mock objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94021 ] Dennis Lundberg commented on MIDEA-88: -- This plugin uses the scm section of your pom to configure the version control in IDEA. Do you have an scm section in your pom? version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- 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-1500) Upload jMock 2.0.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94022 ] analogue commented on MAVENUPLOAD-1500: --- I cloned the Upload jMock 1.2.0 issue to create this one but now it is now the new issue is not editable. Worklog: You don't have permission to work on this issue. Please restore to an editable state so I add/update the required information. Upload jMock 2.0.0 -- Key: MAVENUPLOAD-1500 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1500 Project: maven-upload-requests Issue Type: Task Reporter: analogue Assignee: Carlos Sanchez http://haroon.sis.utoronto.ca/jmock-1.2.0/jmock-1.2.0-bundle.jar http://haroon.sis.utoronto.ca/jmock-1.2.0/jmock-cglib-1.2.0-bundle.jar jMock is a library that supports test-driven development of Java code with mock objects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94026 ] Larry Hamel commented on MIDEA-88: -- Yes, scm section has been there all along, and that scm works for calls like mvn scm:checkout. Here it is, with some details edited out: scm !-- to use this scm declaration in continuum, must have 'ext' set up to so ssh with appropriate private key -- connectionscm:cvs:ext:[EMAIL PROTECTED]:/ssr/blahk:faqtory/connection developerConnectionscm:cvs:ext:[EMAIL PROTECTED]:/ssr/blahk:faqtory/developerConnection !--tagHEAD/tag-- urlhttps://blah.com/scgi-bin/viewcvs.cgi/url /scm The key is that is clearly has 'cvs' as provider. that is the key setting that is lost in an idea:idea update. WORKAROUND: if just updating dependencies, idea:module is sufficient and doesn't change project. version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94028 ] Dennis Lundberg commented on MIDEA-88: -- Let's see if I get this now. Is this correct: 1. Generate IDEA files using 'mvn idea:idea'. Version control is now available in the IDEA project files. 2. Add a new dependency. 3. Run 'mvn idea:idea' again to get the new dependency. The version control is gone from the IDEA project files. Is this a single or multi module Maven project? version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- 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: (MIDEA-75) mvn idea:idea fails with StringIndexOutOfBoundsException (toRelative method) when adding resource to base project
[
http://jira.codehaus.org/browse/MIDEA-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MIDEA-75.
Assignee: Dennis Lundberg
Resolution: Fixed
Fix Version/s: 2.1
Fixed in r532081.
mvn idea:idea fails with StringIndexOutOfBoundsException (toRelative method)
when adding resource to base project
-
Key: MIDEA-75
URL: http://jira.codehaus.org/browse/MIDEA-75
Project: Maven 2.x Idea Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Silvestrov Ilya
Assignee: Dennis Lundberg
Fix For: 2.1
Attachments: ideaPluginBug.zip
I want a base project to handle special resource which is located in not
default location.
Example: I want all my projects to pack file history.txt located in project
basedir into jar.
So, this resource is mentioned in parent project:
build
resources
resource
directory${basedir}/directory
includes
includehistory.txt/include
/includes
/resource
/resources
/build
When I package child project it works well. But when I try to run idea:idea
(or idea:module) it fails with following stacktrace:
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1444)
at java.lang.String.substring(String.java:1411)
at
org.apache.maven.plugin.idea.AbstractIdeaMojo.toRelative(AbstractIdeaMojo.java:217)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.getModuleFileUrl(IdeaModuleMojo.java:777)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.getModuleFileUrl(IdeaModuleMojo.java:782)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.addSourceFolder(IdeaModuleMojo.java:797)
at
org.apache.maven.plugin.idea.IdeaModuleMojo.rewriteModule(IdeaModuleMojo.java:278)
at
org.apache.maven.plugin.idea.IdeaMojo.rewriteModule(IdeaMojo.java:205)
at org.apache.maven.plugin.idea.IdeaMojo.execute(IdeaMojo.java:185)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java: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)
parent and child project examples are attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94031 ] Larry Hamel commented on MIDEA-88: -- Single-module Maven project. Re: your step 1: I don't think mvn idea:idea picks up the version control from the pom.xml. Do you get that to happen? In my case, it is more like: 1. Generate 2. Manually edit Idea project to add cvs version control 3. Add new dependency 4. mvn idea:idea 5. version control setting is overwritten to 'no version control' thanks, larry version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94032 ] Dennis Lundberg commented on MIDEA-88: -- Looks like you are running into MIDEA-66. Could you please try your project using the 2.1-SNAPSHOT version of this plugin? For instructions on how to do this, see: http://maven.apache.org/guides/development/guide-testing-development-plugins.html version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-625) Value of Group column depends on how you added the project
[ http://jira.codehaus.org/browse/CONTINUUM-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Beermann closed CONTINUUM-625. -- Resolution: Fixed Fix Version/s: (was: Future) 1.1-alpha-1 Fixed via CONTINUUM-30. Value of Group column depends on how you added the project Key: CONTINUUM-625 URL: http://jira.codehaus.org/browse/CONTINUUM-625 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.0.2 Reporter: Matthew Beermann Priority: Minor Fix For: 1.1-alpha-1 The text that appears in the Group column of the project listing seems, counterintuitively, to depend on how exactly you added the project. * If I add Maven 2 projects en masse through a master POM that has modules/, the name of that master POM is used. This may be related to an (incorrect) assumption that if A has B as a module, then B has A as a parent, which is not true for me. * If I add the projects one-by-one, the results appear to be somewhat random. Looking over the list in my Continuum instance, I see projects that have their own name as their Group, and some that are displaying the name of sibling projects. I'm not quite sure what /should/ be displayed, but whatever it is, it ought to be consistent... -- 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: (MDEPLOY-36) Custom ArtifactRepositoryLayouts confuse deploy-file
[ http://jira.codehaus.org/browse/MDEPLOY-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Beermann closed MDEPLOY-36. --- Resolution: Won't Fix Fix Version/s: (was: 2.4) Withdrawing this request, as we no longer need it. Custom ArtifactRepositoryLayouts confuse deploy-file Key: MDEPLOY-36 URL: http://jira.codehaus.org/browse/MDEPLOY-36 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Matthew Beermann We've created some custom ArtifactRepositoryLayouts. They work just fine, but they seem to confuse the deploy-file goal. In particular, if the custom layout is present in maven-2.0.4\libs, then it will cause deploy-file to _always_ use the legacy layout, regardless of the value of -DrepositoryLayout. I'm pretty sure our custom ArtifactRepositoryLayout is written correctly, but just in case, here's the contents of components.xml: component-set components component roleorg.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout/role role-hinteclipse/role-hint implementationorg.apache.maven.artifact.repository.layout.EclipseRepositoryLayout/implementation /component /components /component-set -- 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-2792) When Maven runs Java 6, maven-metadata.xml file is corrupted
[ http://jira.codehaus.org/browse/MNG-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Beermann closed MNG-2792. - Resolution: Duplicate Fix Version/s: 2.0.6 Duplicate of MNG-2793. When Maven runs Java 6, maven-metadata.xml file is corrupted -- Key: MNG-2792 URL: http://jira.codehaus.org/browse/MNG-2792 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Reporter: Matthew Beermann Priority: Critical Fix For: 2.0.6 Attachments: maven-metadata.xml When you run Maven under Java 6, the maven-metadata.xml file that gets written to the remote repository is markedly different from the one generated under Java 5 and earlier. This file is corrupted in the sense that Maven reports errors about it, and might not be able to locate snapshots as a result. See attachment for an example file; you'd expect to see build numbers or -SNAPSHOTs, but not both at once. This issue is described further at http://www.nabble.com/Maven-and-JDK-1.6-t3060866s177.html (originally message only, not the followups). This might be related to MNG-2709, but I don't think it's a duplicate, as it has nothing to do with testing or parents. -- 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: (SCM-301) perforce cannot be used with continuum
[ http://jira.codehaus.org/browse/SCM-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Perham closed SCM-301. --- Resolution: Fixed Patch applied. Thanks! perforce cannot be used with continuum -- Key: SCM-301 URL: http://jira.codehaus.org/browse/SCM-301 Project: Maven SCM Issue Type: Bug Affects Versions: 1.0-rc1 Environment: summary 1- fix nullpointer in changelog command 2- add logger 3- client is no more a mandatory field in accept in the perforceInfoCommand (constraint not usefull because scm create new ones) 4- add workaround (due to continuum) to accept the default choice instead of null or empty string 5- ignore pom.xml contains if the the location is not in client spec (link to 3) Reporter: Raphael PETIT Assignee: Mike Perham Fix For: 1.0 Attachments: perforce.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1755) Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 2
[ http://jira.codehaus.org/browse/MAVEN-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1755. -- Resolution: Fixed Fixed with maven-model 3.0.2 Backward Incompability : Usage of xml entities in the POM doesn't work in maven 1.1 beta 1 2 -- Key: MAVEN-1755 URL: http://jira.codehaus.org/browse/MAVEN-1755 Project: Maven 1 Issue Type: Bug Components: core Affects Versions: 1.1-beta-1, 1.1-beta-2, 1.1-beta-3 Reporter: Arnaud Heritier Assignee: Arnaud Heritier Priority: Critical Fix For: 1.1-rc1 Attachments: project-entities.zip In maven 1.0.X it was possible to use entities in the POM. It was used for example to share some elements like the organization, ... -- 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: (MENFORCER-2) enforcer plugin is bound to 'default
enforcer plugin is bound to 'default Key: MENFORCER-2 URL: http://jira.codehaus.org/browse/MENFORCER-2 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: Ian Springer Assignee: Brian Fox -- 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: (MENFORCER-2) enforcer plugin is bound to 'default
[ http://jira.codehaus.org/browse/MENFORCER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Springer closed MENFORCER-2. Resolution: Incomplete enforcer plugin is bound to 'default Key: MENFORCER-2 URL: http://jira.codehaus.org/browse/MENFORCER-2 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Reporter: Ian Springer Assignee: Brian Fox -- 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: (MENFORCER-3) enforcer plugin should be bound to the 'clean' lifecycle in addition to the 'default' lifecycle
enforcer plugin should be bound to the 'clean' lifecycle in addition to the 'default' lifecycle --- Key: MENFORCER-3 URL: http://jira.codehaus.org/browse/MENFORCER-3 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Plugin Affects Versions: 1.0-alpha-1 Reporter: Ian Springer Assignee: Brian Fox I think it makes sense for the enforcer plugin to also be bound to the 'pre-clean' phase of the 'clean' lifecycle, so that when I just run 'mvn clean', the enforcer plugin will still check the Maven, JDK, etc. versions. -- 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 ] Brett Porter updated MNG-2923: -- Fix Version/s: 2.0.7 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 Fix For: 2.0.7 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: profiles profile idfoo/id activation activeByDefaulttrue/activeByDefault /activation /profile /profiles ...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] Commented: (MIDEA-88) version control setting lost on update
[ http://jira.codehaus.org/browse/MIDEA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94043 ] Larry Hamel commented on MIDEA-88: -- Yes, fixed there, thank you. larry version control setting lost on update -- Key: MIDEA-88 URL: http://jira.codehaus.org/browse/MIDEA-88 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Environment: idea 6.0.5 windows xp Reporter: Larry Hamel have project with version control set to cvs. change pom for a new dependency. close project. in idea mvn idea:idea open project in idea see that version control setting is lost -- 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-2961) DefaultArtifact getBaseVersion is changed to xxxx-SNAPSHOT only if you first call isSnapshot()
DefaultArtifact getBaseVersion is changed to -SNAPSHOT only if you first
call isSnapshot()
Key: MNG-2961
URL: http://jira.codehaus.org/browse/MNG-2961
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.6, 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0
Reporter: Brian Fox
Priority: Minor
calling isSnapshot() actually modifies the baseVersion:
public boolean isSnapshot()
{
if ( version != null || baseVersion != null )
{
Matcher m = VERSION_FILE_PATTERN.matcher( getBaseVersion() );
if ( m.matches() )
{
setBaseVersion( m.group( 1 ) + - + SNAPSHOT_VERSION );
return true;
}
else
{
return getBaseVersion().endsWith( SNAPSHOT_VERSION ) ||
getBaseVersion().equals( LATEST_VERSION );
}
}
else
{
return false;
}
}
--
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: (MENFORCER-3) enforcer plugin should be bound to the 'clean' lifecycle in addition to the 'default' lifecycle
[ http://jira.codehaus.org/browse/MENFORCER-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94049 ] Brian Fox commented on MENFORCER-3: --- You should be able to bind this in your pom by specifying the phase. Unfortunately, maven only allows a plugin to declare a single phase by default...that doesn't mean you can't add an execution for it though. enforcer plugin should be bound to the 'clean' lifecycle in addition to the 'default' lifecycle --- Key: MENFORCER-3 URL: http://jira.codehaus.org/browse/MENFORCER-3 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Plugin Affects Versions: 1.0-alpha-1 Reporter: Ian Springer Assignee: Brian Fox I think it makes sense for the enforcer plugin to also be bound to the 'pre-clean' phase of the 'clean' lifecycle, so that when I just run 'mvn clean', the enforcer plugin will still check the Maven, JDK, etc. versions. -- 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-1501) Upload UrlRewriteFilter 3.0.4
Upload UrlRewriteFilter 3.0.4 - Key: MAVENUPLOAD-1501 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1501 Project: maven-upload-requests Issue Type: Task Reporter: Paul Tuckey UrlRewriteFilter Based on the popular and very useful mod_rewrite for apache, UrlRewriteFilter is a Java Web Filter for any J2EE compliant web application server (such as Resin, Orion or Tomcat), which allows you to rewrite URLs before they get to your code. It is a very powerful tool just like Apache's mod_rewrite. -- 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: (MECLIPSE-128) Eclipse goal breaks manually-configured external builder
[
http://jira.codehaus.org/browse/MECLIPSE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94051
]
Sumeet Saxena commented on MECLIPSE-128:
I am blocked due to the same issue.
- Can anyone tell me when this is expected to get fixed?
- Can someone tell me of an alternate way to get the same thing done?
Eclipse goal breaks manually-configured external builder
Key: MECLIPSE-128
URL: http://jira.codehaus.org/browse/MECLIPSE-128
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows, Eclipse 3.1.2
Reporter: Matt Tucker
I'm attempting to specify an external build tool for a project in Eclipse
that does Maven dependency resolution. I do this by:
1. in Eclipse going to Project-Properties-Builders
2. click New
3. select Program, click Ok
4. Specify
Location: ${env_var:MAVEN_HOME}/bin/mvn.bat
Working directory: ${project_loc}
Arguments: eclipse:eclipse
5. Switch to Refresh tab, specify:
[x] Refresh resources upon completion
[*] The project containing ...
6. Click Ok
Specifying this build does two things within Eclipse. It alters the .project
file and adds:
projectDescription
...
buildSpec
buildCommand
nameorg.eclipse.ui.externaltools.ExternalToolBuilder/name
triggersauto,clean,incremental,/triggers
arguments
dictionary
keyLaunchConfigHandle/key
valuelt;projectgt;/.externalToolBuilders/Maven Builder.launch/value
/dictionary
/arguments
/buildCommand
...
/buildSpec
...
/projectDescription
And it creates a file .externalToolBuilders/builder name.launch, which
creates the bulk of the settings for the custom build task.
However, when the eclipse goal is run, the Maven Eclipse plugin alters the
build command specification in .project to be:
buildCommand
nameorg.eclipse.ui.externaltools.ExternalToolBuilder/name
arguments/
/buildCommand
It's completely throwing away the specified arguments to the buildCommand,
which causes Eclipse to not be able to find the custom build task details,
which causes any subsequent builds to fail. The Maven Eclipse plugin needs
to preserve this information when it writes the .project file for, as far as
I can tell, any auto-building to be useful or even possible.
--
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
