[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_94058 ] Julien Vermillard commented on MAVENUPLOAD-1488: oups, re-uploaded > 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] Created: (SCM-302) NPE in clearcase checkout command if version is null
NPE in clearcase checkout command if version is null Key: SCM-302 URL: http://jira.codehaus.org/browse/SCM-302 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-clearcase Affects Versions: 1.0-rc1 Reporter: Emmanuel Venisse Fix For: 1.0 -- 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-302) NPE in clearcase checkout command if version is null
[ http://jira.codehaus.org/browse/SCM-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed SCM-302. Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.0 > NPE in clearcase checkout command if version is null > > > Key: SCM-302 > URL: http://jira.codehaus.org/browse/SCM-302 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0-rc1 >Reporter: Emmanuel Venisse >Assignee: Emmanuel Venisse > Fix For: 1.0 > > -- 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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
(False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6. - Key: MNG-2962 URL: http://jira.codehaus.org/browse/MNG-2962 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: windows Reporter: Geoffrey De Smet Since m2.0.6 builds that work perfectly on linux machine A and sometimes even on a windows machine B, breaks on another windows machine C. We have some "false transitive dependencies": transitive dependencies that should be direct dependencies. (We currently do this to avoid having to duplicate the version number as the different projects don't have a common superpom.) Making those dependencies direct dependencies fixes the problem with windows machine C, but the real problem is that the guy on linux machine A should get the problems too, before committing. The compiler plugin version is locked down to 2.0.2, but are using maven 2.0.6. This did not occur in maven 2.0.5. Attached you'll find the "mvn -X install" logs of the 2 windows machines. The log of machine C is specifically interesting, as it shows "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the classpath in the compiler plugin: [DEBUG] Adding managed depedendencies for unknown:atlas-spring ... [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile ... [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes .. (no org.springframework:spring-beans:jar:2.0.2) Machine B instead has instead this at the classpath log part: [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes ... C:\Documents and Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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] Updated: (MNG-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated MNG-2962: -- Attachment: m2.0.6-failing-compile-machineC.log > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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] Updated: (MNG-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated MNG-2962: -- Attachment: m2.0.6-working-compile-machineB.log > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94063 ] Geoffrey De Smet commented on MNG-2962: --- There is thread @user called "m2.0.6 with false transitive dependencies fails on windows, works on linux": http://www.nabble.com/m2.0.6-with-false-transitive-dependencies-fails-on-windows%2C-works-on-linux-tf3643824.html#a10176290 > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94066 ] Jerome Lacoste commented on MNG-2962: - in your fail build log: be.schaubroeck.atlas:atlas-spring:test-jar:tests:0.4.0-SNAPSHOT:test (selected for test) commons-logging:commons-logging:jar:1.1:test (applying scope: compile) be.schaubroeck.atlas:atlas-core:jar:0.4.0-SNAPSHOT:test (applying scope: compile) commons-lang:commons-lang:jar:2.2:test (applying scope: compile) org.springframework:spring-beans:jar:2.0.2:test (applying scope: compile) org.springframework:spring-beans:jar:2.0.2:compile (selected for compile) org.springframework:spring-context:jar:2.0.2:test (applying scope: compile) notice how spring-beans jar is both as test and compile scope. This doesn't happen in the working one. Are you 100% sure that your poms are completely identical on both machines, including local caches ? Why is working machine has this in the logs: +[DEBUG] Skipping disabled repository schaubroeck-dev +[DEBUG] maven-compiler-plugin: resolved to version 2.0.2 from repository central ? > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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] Updated: (MNG-612) implement conflict resolution techniques
[ http://jira.codehaus.org/browse/MNG-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MNG-612: Attachment: MNG-612-2.patch Attaching slightly improved version of the patch: - better ConflictResolver API - made ArtifactCollector API change backwards-compatible > implement conflict resolution techniques > > > Key: MNG-612 > URL: http://jira.codehaus.org/browse/MNG-612 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories, Design, Patterns & Best > Practices >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Critical > Fix For: 2.1.x > > Attachments: MNG-612-2.patch, MNG-612.patch > > Original Estimate: 8 hours > Remaining Estimate: 8 hours > > currently, the collector only: > - selects nearest "suggested" version in a valid range > - latest version from the valid ranges if none suggested > - fails if ranges are over-constrained > This needs to be configurable: > - select newest, even if there is a nearer suggestion > - select oldest, even if there is a nearer suggestion > - fail if all suggestions don't equate or a range results instead of a single > version > - ignore over constrained ranges and fallback to some other algorithm > - select snapshots even if they weren't explicitly specified -- 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-190) Problem with dependency conflict resolution on multi-module project
[
http://jira.codehaus.org/browse/MASSEMBLY-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94069
]
Geoffrey De Smet commented on MASSEMBLY-190:
I also have this issue.
I include 2 modules, both have a conflict resolution that ends up on
xstream-1.2.1; nevertheless xstream-1.1.3 stil appears in my lib dir.
(I make the jar plugin generate of both modules the classpath in the
manifest.MF, both times it's 1.2.1.)
ggg:ggg-distro
ggg:ggg-uploader
/lib
false
660
${artifactId}-${baseVersion}.${extension}
runtime
> Problem with dependency conflict resolution on multi-module project
> ---
>
> Key: MASSEMBLY-190
> URL: http://jira.codehaus.org/browse/MASSEMBLY-190
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Using maven 2.0.5 and assembly 2.2-SNAPSHOT
>Reporter: Frédéric ESNAULT
>
> Hi,
> I'm trying to use the assembly plugin to gather all the jars of my project,
> including all dependencies.
> As the project is composed of several modules, I use a descriptor which looks
> like this :
>
> bin
>
> zip
>
> false
>
>
>
> /
> false
> true
>
>
>
>
> It seems to work fine at first sight - it creates a zip containing all the
> jar files. However, I find in the archive several instances of the same
> dependency with differents versions, for instance asm-1.5.3 and asm-2.2.3.
> This is a surprise as maven is supposed to take care of conflict resolution.
> When I look at a detailed trace, it appears that conflict resolution is done
> but on each module independently. But my modules are intended to work
> together and I expect to get an assembly with only one version of each
> dependency found on the whole set of mudules. It seems to me that conflict
> resolution is not managed properly in this use case.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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_94071
]
Elid OR commented on MANTRUN-51:
There are multiple poms, one per module. And in each pom there is a antrun
section. In each antrun section there could be multiple execution section, for
me there is only one exection section in each antrun declaration. And I have
set a unique Id for each execution but it doesn't now work. Only plugin
classpath of the first antrun section of the first pom is used in all module of
a multi project.
> 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}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> package
>
>
>classname="com.izforge.izpack.ant.IzPackTask"/>
>input="${project.build.directory}/classes/izPack.xml"
> output="${project.build.directory}/CorasTool-${coras.version}-installer.jar"
> basedir="${project.build.directory}"/>
>
>
>
> run
>
>
>
>
>
> izpack
> standalone-compiler
> 3.8.0
>
>
>
> [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.izfo
[jira] Commented: (MPTEST-66) 1.8 version introduces bug in other plugins
[
http://jira.codehaus.org/browse/MPTEST-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94079
]
Lukas Theussl commented on MPTEST-66:
-
We need to decide what to do about this issue for m11. Personally, I don't want
to revert MPTEST-46 as the current way is the way it *should* be. Also, we have
already adapted our other plugins to it (MPEJB-23, MPWAR-62, jar), so
internally, we are clean. The only problem is with backward compatibility when
using third-party plugins that rely on java:compile being called with
test:test. For this case, there is a simple workaround, eg for the javaapp
plugin, add the following in your maven.xml:
{code:xml}
{code}
Sources being compiled twice is not a real problem (and btw it was that way
before already), as the second time only the goal will be called but the
sources not actually compiled.
So my suggestion is to leave it as is and write a paragraph on the main plugin
page to document the problem. Unless someone comes up with a new solution, as
none of the alternatives above seem acceptable to me.
> 1.8 version introduces bug in other plugins
> ---
>
> Key: MPTEST-66
> URL: http://jira.codehaus.org/browse/MPTEST-66
> Project: maven-test-plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: nicolas de loof
>Assignee: Lukas Theussl
> Fix For: 1.8.1
>
> Attachments: MPTEST-66.patch
>
>
> When maven-war-plugin is run with maven.test.skip=true, the sources are not
> compiled.
> Latest version of test-plugin has removed prereqs on java:compile &
> java:jar-resources.
> Assuming other plugins themself run the java:compile goal may have impact on
> lots of plugin and can break many application builds. I think the "test:test"
> goal may have a prereqs="java:compile,java:jar-resources", and the
> "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources"
--
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-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 closed MRELEASE-220. - Resolution: Fixed > 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] Closed: (MRELEASE-160) The next snapshot version is not used un submodules
[ http://jira.codehaus.org/browse/MRELEASE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-160. - Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 2.0-beta-5 Already fixed. > The next snapshot version is not used un submodules > --- > > Key: MRELEASE-160 > URL: http://jira.codehaus.org/browse/MRELEASE-160 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-5 > > Attachments: 2.0-beta-4.patch, dryRun.patch, PomRewriteVersions.patch > > > In multi-module mode the release plugin replaces the version of snapshot > dependencies in the submodules automatically for dependencies that are also > part of the release. But this versions are not set to the next version after > the release process. E.g. in a module with two submodules (one EJB and an EAR > depedning on this EJB) the EJB depednency is added with a SNAPSHOT > depednecny. At release time the plugin replaces this version with the version > used for the release. After the release the version tag in the parent section > of both POMs are set to the next version, but the verison in the EARs > depednency stays at the release. This is higly error-prone, since with the > next release the EAR still references the old version of the EJB. -- 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-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-145. - Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 2.0-beta-5 > release:prepare requires all modules to be SNAPSHOTS > > > Key: MRELEASE-145 > URL: http://jira.codehaus.org/browse/MRELEASE-145 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Jörg Hohwiller >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-5 > > > The biggest need for the maven-release-plugin is in complex projects with a > lot of modules (that may again have modules). If I do not get it wrong, the > current released version forces all modules to be snapshots and releases them > individually. This is completely useless in my situation because in the end > this forces me to release alle modules together for every change that is to > be released and more or less causes that all modules have the same version > number. When I call mvn replease:prepare on my toplevel project this is no > snapshot, it fails with this error: > The project : isn't a snapshot (). > I would expect release:prepare to leave non SNAPSHOT modules untouched (and > only verify that they do not have SNAPSHOT dependencies, what should never be > the case if the version is no snapshot). > All reactor projects that have a "-SNAPHSOT" version should be released and > theier project-internal dependencies should also be set to the acording > released version (and later be set to the new SNAPSHOT). > Additionally I want to have the complete project to be tagged as a whole > instead of each module. This could potentially be configureable (especially > which directory is actually tagged, e.g. if the toplevel project is not in > trunk/ but somewhere deeper say trunk/develop because other directories in > trunk are huge but do not need to be checked out by every developer but need > to be tagged). > I personally think that the best flexibility and final freedom would be to > split off the release:prepare goal into 3 goals: > -create release version(s) > -create tag(s) > -update to snapshot version(s) > These goals could be used individually and one could add some custom steps or > replace one with something else. > For creating the snapshot versions there is also the problem, that you do not > know right away which project will be modified when in the future. The > coolest thing would be if this would happen automatically when the first > change is commited to the module. But this is of cause not praticable in > reality (maybe if all commits would be done with maven). -- 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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[ http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94100 ] Geoffrey De Smet commented on MNG-2962: --- At one point, machine A and machine C removed their local repo's and made sure they had the same poms (with "svn update"), nevertheless machine A would build and machine C would not. Between machine B and machine C we used the same poms and our settings.xml differ little or not, there are no claims of a repository. I have no explenation why machine B would skip our dev repo (and not our deploy repo) and machine C didn't. Our dev repo does not contain org.springframework:spring-beans whatever (no meta data about it either). > (False) transitive dependencies don't appear on the compiler classpath in > some windows environments since m2.0.6. > - > > Key: MNG-2962 > URL: http://jira.codehaus.org/browse/MNG-2962 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: windows >Reporter: Geoffrey De Smet > Attachments: m2.0.6-failing-compile-machineC.log, > m2.0.6-working-compile-machineB.log > > > Since m2.0.6 builds that work perfectly on linux machine A and sometimes even > on a windows machine B, breaks on another windows machine C. > We have some "false transitive dependencies": transitive dependencies that > should be direct dependencies. > (We currently do this to avoid having to duplicate the version number as the > different projects don't have a common superpom.) > Making those dependencies direct dependencies fixes the problem with windows > machine C, but the real problem is that the guy on linux machine A should get > the problems too, before committing. > The compiler plugin version is locked down to 2.0.2, but are using maven > 2.0.6. This did not occur in maven 2.0.5. > Attached you'll find the "mvn -X install" logs of the 2 windows machines. > The log of machine C is specifically interesting, as it shows > "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the > classpath in the compiler plugin: > [DEBUG] Adding managed depedendencies for unknown:atlas-spring > ... > [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile > ... > [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes > .. (no org.springframework:spring-beans:jar:2.0.2) > Machine B instead has instead this at the classpath log part: > [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes > ... > C:\Documents and > Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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-2962) (False) transitive dependencies don't appear on the compiler classpath in some windows environments since m2.0.6.
[
http://jira.codehaus.org/browse/MNG-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94101
]
Geoffrey De Smet commented on MNG-2962:
---
However, if we - instead of adding the false transitive dependences - removed
the test-jar dependency it would also build on machine C (if test-compiling was
disabled at least):
${project.groupId}
atlas-spring
test-jar
If m2.0.6 fixed the unrandomizing handling of "the dependency path resolution",
how can the path differ between machines?
It looks like a randomizing factor has crept into transitive dependencies
combined with compile en test scope?
> (False) transitive dependencies don't appear on the compiler classpath in
> some windows environments since m2.0.6.
> -
>
> Key: MNG-2962
> URL: http://jira.codehaus.org/browse/MNG-2962
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.6
> Environment: windows
>Reporter: Geoffrey De Smet
> Attachments: m2.0.6-failing-compile-machineC.log,
> m2.0.6-working-compile-machineB.log
>
>
> Since m2.0.6 builds that work perfectly on linux machine A and sometimes even
> on a windows machine B, breaks on another windows machine C.
> We have some "false transitive dependencies": transitive dependencies that
> should be direct dependencies.
> (We currently do this to avoid having to duplicate the version number as the
> different projects don't have a common superpom.)
> Making those dependencies direct dependencies fixes the problem with windows
> machine C, but the real problem is that the guy on linux machine A should get
> the problems too, before committing.
> The compiler plugin version is locked down to 2.0.2, but are using maven
> 2.0.6. This did not occur in maven 2.0.5.
> Attached you'll find the "mvn -X install" logs of the 2 windows machines.
> The log of machine C is specifically interesting, as it shows
> "spring-beans:2.0.2" as a transitive dependency, yet it forgets it on the
> classpath in the compiler plugin:
> [DEBUG] Adding managed depedendencies for unknown:atlas-spring
> ...
> [DEBUG] org.springframework:spring-beans:jar:2.0.2:compile
> ...
> [DEBUG] Classpath: [d:\sources\atlas-all\atlas-checkpoint\target\classes
> .. (no org.springframework:spring-beans:jar:2.0.2)
> Machine B instead has instead this at the classpath log part:
> [DEBUG] Classpath: [d:\projects\sb\atlas_all\atlas-checkpoint\target\classes
> ...
> C:\Documents and
> Settings\gds\.m2\repository\org\springframework\spring-beans\2.0.2\spring-beans-2.0.2.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: (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_94107 ] Ian Springer commented on MENFORCER-3: -- Ah, I didn't realize that was a Maven limitation. Thanks, Ian > 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] Closed: (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:all-tabpanel ] Ian Springer closed MENFORCER-3. Resolution: Won't Fix Maven does no allow plugins to bind to more than one phase, even if the phases are in different lifecycles. > 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] 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_94112 ] zhoushuqun commented on MAVENUPLOAD-1496: - OK, I've updated file http://redv.com/blogger-api-client/downloads/blogger-api-client-1.1-bundle.jar. Please check again, thanks. > 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] Created: (MRRESOURCES-22) Provide "excludes" for artifacts that are passed into velocity
Provide "excludes" for artifacts that are passed into velocity -- Key: MRRESOURCES-22 URL: http://jira.codehaus.org/browse/MRRESOURCES-22 Project: Maven 2.x Remote Resources Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-5 Reporter: Daniel Kulp It would be nice to configure an excludes for the list of projects heading into Velocity (and can do wildcards like the latest assembly). For example, the CXF distribution ends up with a lot of "Uses Apache CXF Common", "Uses Apache CXF HTTP", etc... It would be nice to be able to do org.apache.cxf:* to exclude those since they are built as part of the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-221) XML header missing in modified POM after release:prepare
XML header missing in modified POM after release:prepare Key: MRELEASE-221 URL: http://jira.codehaus.org/browse/MRELEASE-221 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Windows XP, CVSNT, Eclipse Reporter: Alain Coetmeur When release plugin modifies the POM to prepare a new release, the new file does not containt the XML header it cause problems with XML editors who ignore the encoding and breaks all unusual characters. some XML tools also don't accept XML files without headers... -- 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-2963) Do not update metadata unless the artifact actually made it down
Do not update metadata unless the artifact actually made it down Key: MNG-2963 URL: http://jira.codehaus.org/browse/MNG-2963 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.x Reporter: Jason van Zyl We can also have a secondard check to see that if a metadata file contains no valid versions to nuke it and try to download a valid one. This will correct anything left over from previous versions of Maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (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 ] Vlad Skarzhevskyy reopened MAVENUPLOAD-1493: Next time: I will create repository. No problem. I'm going to make release microemulator soon. The problem I have now: How do I update maven-metadata.xml. Is it loaded from repository for sync? Now tag is missing in plugins e.g.: com/pyx4me/proguard-maven-plugin/maven-metadata.xml This does not allow me to use plugin withour refferencing its version in other projects. > 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: (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:comment-tabpanel#action_94129 ] Carlos Sanchez commented on MAVENUPLOAD-1493: - these manual uploads don't add the metadata, I could fix it by hand provided I have the time or you can set up an automated sync and then you would manage your section of the repository yourself > 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] Created: (CONTINUUM-1254) Clarification of Configuring Continuum as a Service in "Getting Started" Guide
Clarification of Configuring Continuum as a Service in "Getting Started" Guide -- Key: CONTINUUM-1254 URL: http://jira.codehaus.org/browse/CONTINUUM-1254 Project: Continuum Issue Type: Improvement Components: Documentation Reporter: James Williamson Priority: Minor I was running the service using the Local System account Log On credentials. I changed the Log On credentials to specify my NT Login and password and now it works fine. Looking back at the Continuum "Getting Started" Guide, it explicitly states: "By default, the service logs on as the Local System account. Be sure to change this to an account where you want the service to start upon login." However, I had supposed this meant change it if you want the service to run in some location other than your local machine. In fact, I discovered that you will need to change it if you want your service to work correctly. This document could be improved by stating: "Be sure to change this to an account where you want the service to start upon login. If you are hosting the service on your local machine you still need to specify your login credentials in order for your service to function properly." -- 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-1493) Uploading pyx4me 2.0.1 to The Central Repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94134 ] Vlad Skarzhevskyy commented on MAVENUPLOAD-1493: I will create repository and let you know. Don't spend time on this for now. > 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] Created: (MECLIPSE-261) IdeUtils.toRelativeAndFixSeparator returns incomplete path
IdeUtils.toRelativeAndFixSeparator returns incomplete path -- Key: MECLIPSE-261 URL: http://jira.codehaus.org/browse/MECLIPSE-261 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Windows XP, jdk 1.5.0_11-b03, maven 2.0.5 Reporter: Marcio Paulo Guedes Attachments: .classpath, patch.txt, pom.xml .classpath file is generated with incomplete path for classpathentry when kind is "var". Example: when is expected. It's caused by IdeUtils.toRelativeAndFixSeparator when basepath is not equal absolutepath. Code on line 99 shifts the string 1 character to the right, corrupting the result path. -- 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-157) Share version for multi-module releases
[ http://jira.codehaus.org/browse/MRELEASE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schneider updated MRELEASE-157: --- Attachment: release-plugin-autoVersionSubmodules.patch I'm attaching a patch for a autoVersionSubmodules for the release plugin. With this option enabled, the submodules will automatically get the version of the parent without prompting for each submodule. We have a maven project with 52+ submodules and typing in the version for each one is too tedious. This is the first stab at this functionality. I'll probably we making some tweaks to this code to remove the duplicated code and clean it up a bit, but I wanted to get this out there just in case anyone was interested. > Share version for multi-module releases > --- > > Key: MRELEASE-157 > URL: http://jira.codehaus.org/browse/MRELEASE-157 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-4 >Reporter: Joerg Schaible > Attachments: release-plugin-autoVersionSubmodules.patch > > > In our setup all artifacts of a multi-module setup share the same release. > Therefore it would be really good, if we could configure the plugin (e.g. > shareVersion=true) to ask once for the version to release and once for the > version to set after the release for all 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] Commented: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94149 ] Piotr Tabor commented on MWAR-97: - So I think there are need for such tasks (assigned to "goals"): Goals: *war:exploded* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTaks - RealizeOverlaysTask *war:inplace* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTask - RealizeOverlaysTask *war:war* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTaks - RealizeOverlaysTask - ArchiveWarTask *war:manifest* - GenerateManifestTask I think that every task should have constructor with one parameter that will AbstractWarMojo provide from do Mojo all important informations and some "busines" methods. > War plugin and Overlays handling > > > Key: MWAR-97 > URL: http://jira.codehaus.org/browse/MWAR-97 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Piotr Tabor >Assignee: Stephane Nicoll > Attachments: MWAR-97.diff > > > Piotr and I are currently working on the war plugin and especially > this overlay mechanism that needs to be upgraded. Currently a couple > of issues [1] in the war plugin are linked to this functionality and > we should really address them. > The idea here is to provide a better way to handle overlays through an > explicit configuration. An overlay has the following parameters: > * groupId > * artifactId > * classifier (optionnal) > * includes (default includes everything) > * excludes (default META-INF) > The order in which overlays are specified defined the order in which > they are applied. An overlay without a groupId/artifactId is > considered as the current build. If no such overlay is defined, it is > applied *last*. > The behavior should be deterministic so the copy will happen not > matter how if a file is newer than the one being applied. Overlays > order always wins. > If no overlays section is defined, the wars are processed as before; > dependentWarIncludes and dependentWarExcludes are honored. If an > overlays section is defined and those configuration items are defined, > they are ignored and a warning is logged. > If a dependent war is missing in the overlays section, it's applied > after custom overlays *and* before the current build (if the current > build is not specified of course) with the default includes/excludes. > Does that sounds ok to you? If so I'll add the proposition to the war > site and start the implementation with Piotr. We're also thinking > about integrating the merge functionality of the cargo plugin but we > still need to discuss with the cargo guys if it will be feasible. > Please comment. > Stéphane -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] 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_94138 ] Tim Ducheyne commented on MAVENUPLOAD-1497: --- I removed the optional qualifier for the provided dependencies. Uploaded it in a new bundle jar, the url remains the same. Thanks for installing the new bundle, Tim > 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] Created: (CONTINUUM-1255) FATAL EnvironmentCheck Failure on Continuum Startup
FATAL EnvironmentCheck Failure on Continuum Startup --- Key: CONTINUUM-1255 URL: http://jira.codehaus.org/browse/CONTINUUM-1255 Project: Continuum Issue Type: Sub-task Affects Versions: 1.1-alpha-1 Environment: JBoss 4.0.5.GA, JDK 1.4.2_12 Reporter: Gabriel Misura 42734 [http-0.0.0.0-8080-1] INFO org.codehaus.plexus.security.system.check.EnvironmentCheck:required-roles - Checking the existance of required roles. 43501 [http-0.0.0.0-8080-1] FATAL com.opensymphony.xwork.interceptor.Interceptor:pssEnvironmentCheckInterceptor - EnvironmentCheck Failure. == ENVIRONMENT FAILURE !! Missing "/security" package namespace in xwork.xml Missing [1] xwork.xml configuration elements. == 43651 [http-0.0.0.0-8080-1] INFO com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor initialized! 43876 [http-0.0.0.0-8080-1] INFO com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor initialized! 43886 [http-0.0.0.0-8080-1] INFO com.opensymphony.xwork.interceptor.Interceptor:pssSecureActionInterceptor - org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor initialized! 45228 [http-0.0.0.0-8080-1] INFO com.opensymphony.xwork.interceptor.Interceptor:pssForceAdminUserInterceptor - Admin user found. No need to configure admin user. 49640 [http-0.0.0.0-8080-2] INFO com.opensymphony.webwork.views.freemarker.FreemarkerManager - Instantiating Freemarker ConfigManager!, com.opensymphony.webwork.views.freemarker.FreemarkerManager -- 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-253) eclipse:eclipse should use classpath variable JAVA_HOME or JDK_HOME when writing .classpath for tools.jar
[ http://jira.codehaus.org/browse/MECLIPSE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94150 ] Jasper Rosenberg commented on MECLIPSE-253: --- We are seeing the same issue, and it is a hassle as some developers are on XP and some are on OS X. > eclipse:eclipse should use classpath variable JAVA_HOME or JDK_HOME when > writing .classpath for tools.jar > - > > Key: MECLIPSE-253 > URL: http://jira.codehaus.org/browse/MECLIPSE-253 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: All. >Reporter: Parag Mehta > > Classpath generated by eclipse:eclipse contains absolute reference to the jdk > being used > > This creates a classpath that is not portable amongst multiple > machines/developers (who may have the jdk installed elsewhere). Using > variables like JAVA_HOME or JDK_HOME would yield a more portable result (like > users are expected to define M2_REPO or the plugin can do so). > > 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] Commented: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94153 ] Stephane Nicoll commented on MWAR-97: - Sounds good except the overlay thingy. Instead of a method that will realize the whole overlay I would have one task per overlay. Once we have this, we put all tasks in a ordered list according to, namely, the configuration tag. And the only thing is to have a manager that will execute the tasks. We also need some sort of context object to pass information from one task to the other. A base AbstractTask could have common methods (copyFile, unpack, filtering, etc) > War plugin and Overlays handling > > > Key: MWAR-97 > URL: http://jira.codehaus.org/browse/MWAR-97 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 >Reporter: Piotr Tabor >Assignee: Stephane Nicoll > Attachments: MWAR-97.diff > > > Piotr and I are currently working on the war plugin and especially > this overlay mechanism that needs to be upgraded. Currently a couple > of issues [1] in the war plugin are linked to this functionality and > we should really address them. > The idea here is to provide a better way to handle overlays through an > explicit configuration. An overlay has the following parameters: > * groupId > * artifactId > * classifier (optionnal) > * includes (default includes everything) > * excludes (default META-INF) > The order in which overlays are specified defined the order in which > they are applied. An overlay without a groupId/artifactId is > considered as the current build. If no such overlay is defined, it is > applied *last*. > The behavior should be deterministic so the copy will happen not > matter how if a file is newer than the one being applied. Overlays > order always wins. > If no overlays section is defined, the wars are processed as before; > dependentWarIncludes and dependentWarExcludes are honored. If an > overlays section is defined and those configuration items are defined, > they are ignored and a warning is logged. > If a dependent war is missing in the overlays section, it's applied > after custom overlays *and* before the current build (if the current > build is not specified of course) with the default includes/excludes. > Does that sounds ok to you? If so I'll add the proposition to the war > site and start the implementation with Piotr. We're also thinking > about integrating the merge functionality of the cargo plugin but we > still need to discuss with the cargo guys if it will be feasible. > Please comment. > Stéphane -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt reopened CONTINUUM-358: -- > User Authentication via LDAP > > > Key: CONTINUUM-358 > URL: http://jira.codehaus.org/browse/CONTINUUM-358 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Frank Zhao > Fix For: 1.1-alpha-1 > > > Please add LDAP support for the user authentication in Continuum user > management function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse McConnell updated CONTINUUM-358: -- reopening this one since its not supported anymore until we get that acegi provider integrated again in redback > User Authentication via LDAP > > > Key: CONTINUUM-358 > URL: http://jira.codehaus.org/browse/CONTINUUM-358 > Project: Continuum > Issue Type: New Feature > Components: Web interface >Reporter: Frank Zhao > Fix For: 1.1-alpha-1 > > > Please add LDAP support for the user authentication in Continuum user > management function. -- 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-1502) JPF - Java Plugin Framework
JPF - Java Plugin Framework --- Key: MAVENUPLOAD-1502 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1502 Project: maven-upload-requests Issue Type: Task Reporter: Stefan Two bundles: http://files.sradonia.net/jpf/jpf-1.5-bundle.jar http://files.sradonia.net/jpf/jpf-boot-1.5-bundle.jar Project description: JPF (Java Plugin Framework) is a general-purpose plug-in framework intended to help building scalable, extendable Java applications with low cost of maintenance. The framework is specially designed to be easily included into Java project of any kind. Please upload these two bundles to the central repository! Thank you very much! -- 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-145) release:prepare requires all modules to be SNAPSHOTS
[ http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94170 ] Emmanuel Venisse commented on MRELEASE-145: --- No the release project allow to release a set of projects even if some of them aren't SNAPSHOT. For projects that aren't SNAPSHOT, they aren't modified before to create the tag, then when the plugin ask for new versions, it's possible to set them to SNAPSHOT. The tag created contain all projects that was in the reactor. > release:prepare requires all modules to be SNAPSHOTS > > > Key: MRELEASE-145 > URL: http://jira.codehaus.org/browse/MRELEASE-145 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: Jörg Hohwiller >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-5 > > > The biggest need for the maven-release-plugin is in complex projects with a > lot of modules (that may again have modules). If I do not get it wrong, the > current released version forces all modules to be snapshots and releases them > individually. This is completely useless in my situation because in the end > this forces me to release alle modules together for every change that is to > be released and more or less causes that all modules have the same version > number. When I call mvn replease:prepare on my toplevel project this is no > snapshot, it fails with this error: > The project : isn't a snapshot (). > I would expect release:prepare to leave non SNAPSHOT modules untouched (and > only verify that they do not have SNAPSHOT dependencies, what should never be > the case if the version is no snapshot). > All reactor projects that have a "-SNAPHSOT" version should be released and > theier project-internal dependencies should also be set to the acording > released version (and later be set to the new SNAPSHOT). > Additionally I want to have the complete project to be tagged as a whole > instead of each module. This could potentially be configureable (especially > which directory is actually tagged, e.g. if the toplevel project is not in > trunk/ but somewhere deeper say trunk/develop because other directories in > trunk are huge but do not need to be checked out by every developer but need > to be tagged). > I personally think that the best flexibility and final freedom would be to > split off the release:prepare goal into 3 goals: > -create release version(s) > -create tag(s) > -update to snapshot version(s) > These goals could be used individually and one could add some custom steps or > replace one with something else. > For creating the snapshot versions there is also the problem, that you do not > know right away which project will be modified when in the future. The > coolest thing would be if this would happen automatically when the first > change is commited to the module. But this is of cause not praticable in > reality (maybe if all commits would be done with maven). -- 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
