[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126007
]
Damien Lecan commented on MJAVADOC-116:
---
Still doesn't work with classifiers
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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: (MRM-688) Replace plexus-runtime with standalone jetty bundle
[ http://jira.codehaus.org/browse/MRM-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126008 ] Maria Odea Ching commented on MRM-688: -- Changes made in -r633408: - set appserver.base as additional java parameter - also added config property below to strip the quotes of the value of appserver.base (as i don't think this is currently supported by the appassembler-maven-plugin) wrapper.java.additional.1.stripquotes TRUE Btw, should we retain the PLEXUS_BASE for backwards compatibility as Brett also suggested above? > Replace plexus-runtime with standalone jetty bundle > --- > > Key: MRM-688 > URL: http://jira.codehaus.org/browse/MRM-688 > Project: Archiva > Issue Type: Task > Components: build >Affects Versions: 1.0, 1.0.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.1 > > > http://www.nabble.com/Re%3A-Archiva-1.1-Roadmap-p15331690.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-688) Replace plexus-runtime with standalone jetty bundle
[ http://jira.codehaus.org/browse/MRM-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126009 ] Maria Odea Ching commented on MRM-688: -- Would this be necessary (retain PLEXUS_BASE) if we'll be migrating to spring in the future? :-) > Replace plexus-runtime with standalone jetty bundle > --- > > Key: MRM-688 > URL: http://jira.codehaus.org/browse/MRM-688 > Project: Archiva > Issue Type: Task > Components: build >Affects Versions: 1.0, 1.0.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.1 > > > http://www.nabble.com/Re%3A-Archiva-1.1-Roadmap-p15331690.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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Lorenzini updated MINSTALL-40: -- Attachment: clean-install-with-war-2.0.2.log I've tried forcing use of 2.0.2 war plugin (adding 2.0.2 in the build section of the pom), but still I have the error as in clean-install-with-war-2.0.2.log. Will see in next comment that the same applies with a jar project. > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Lorenzini updated MINSTALL-40: -- Attachment: MINSTALL40-sample2.zip This is another example: a jar project (with no src content), packaged as a secondary artifact (with classifier). It has no sense in the real life, but it shows the same error if trying to install (see log included): File C:\Temp\MINSTALL-40-2\target\classes does not exist As I mentioned before, having a jar project with no output in target/classes has probably no sense, but maybe it can help to understand if the problem is in INSTALL plugin and not in the WAR plugin (where the empty target/classes can have sense in some environment). Hope it helps > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > MINSTALL40-sample2.zip, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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: (SUREFIRE-466) IsolatedClassLoader should also delegate resource loading
IsolatedClassLoader should also delegate resource loading - Key: SUREFIRE-466 URL: http://jira.codehaus.org/browse/SUREFIRE-466 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.4.2 Reporter: Mark Hobson IsolatedClassLoader currently delegates class loading according to whether it is configured to use parent- or child-delegation, but resource loading does not follow the same rules. Need to override getResource and getResources accordingly. -- 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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126016 ] Michele Lorenzini commented on MINSTALL-40: --- I've tried to comment the classifier in the second (jar) sample, and it installs with no problem (also without a target/classes directory). And it says: [INFO] Installing C:\Temp\MINSTALL-40-2\target\foo-jar-1.0.jar to C:\Documents and Settings\xxx\.m2\repository\foo\bar\foo-jar\1.0\foo-jar-1.0.jar If I restore the classifier, the install goal fails with this: [INFO] Installing C:\Temp\MINSTALL-40-2\target\classes to C:\Documents and Settings\xxx\.m2\repository\foo\bar\foo-jar\1.0\foo-jar-1.0.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact: File C:\Temp\MINSTALL-40-2\target\classes does not exist This trace is done in the DefaultArtifactInstaller, when the InstallMojo calls: installer.install( file, artifact, localRepository ); The DefaultArtifactInstaller tries here to copy "file" on the destination (repository) with: FileUtils.copyFile( source, destination ); thats the line that raises the Exception, if I'm right, because there is no C:\Temp\MINSTALL-40-2\target\classes directory. So the question is: why the artifact metadata, in the case of a "classified" artifact, gives "C:\Temp\MINSTALL-40-2\target\classes" as the file path, and not "C:\Temp\MINSTALL-40-2\target\foo-jar-1.0-xxx.jar" as it should be? Hope it helps > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Priority: Minor > Attachments: clean-install-with-war-2.0.2.log, clean-install.log, > MINSTALL40-sample2.zip, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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-288) Support in component descriptors
Support in component descriptors
-
Key: MASSEMBLY-288
URL: http://jira.codehaus.org/browse/MASSEMBLY-288
Project: Maven 2.x Assembly Plugin
Issue Type: Wish
Affects Versions: 2.2-beta-2
Reporter: Benjamin Bentmann
Priority: Minor
Would be nice if reusability at the component descriptor level would not stop
at {{}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-75) plugin uses artifactId in multi module builds, regardeless of the module name
[
http://jira.codehaus.org/browse/MCHANGELOG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126019
]
Felix Knecht commented on MCHANGELOG-75:
I think the problem is in
https://svn.apache.org/repos/asf/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
It uses artifactId to generate the repository path instead of the module name.
private void assembleScmInheritance( Model child, Model parent, String
childPathAdjustment, boolean appendPaths )
{
if ( parent.getScm() != null )
{
Scm parentScm = parent.getScm();
Scm childScm = child.getScm();
if ( childScm == null )
{
childScm = new Scm();
child.setScm( childScm );
}
if ( StringUtils.isEmpty( childScm.getConnection() ) &&
!StringUtils.isEmpty( parentScm.getConnection() ) )
{
childScm.setConnection(
appendPath( parentScm.getConnection(),
child.getArtifactId(), childPathAdjustment, appendPaths ) );
}
if ( StringUtils.isEmpty( childScm.getDeveloperConnection() ) &&
!StringUtils.isEmpty( parentScm.getDeveloperConnection() ) )
{
childScm
.setDeveloperConnection( appendPath(
parentScm.getDeveloperConnection(), child.getArtifactId(),
childPathAdjustment,
appendPaths ) );
}
if ( StringUtils.isEmpty( childScm.getUrl() ) &&
!StringUtils.isEmpty( parentScm.getUrl() ) )
{
childScm.setUrl(
appendPath( parentScm.getUrl(), child.getArtifactId(),
childPathAdjustment, appendPaths ) );
}
}
}
> plugin uses artifactId in multi module builds, regardeless of the module name
> -
>
> Key: MCHANGELOG-75
> URL: http://jira.codehaus.org/browse/MCHANGELOG-75
> Project: Maven 2.x Changelog Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
> Environment: linux, java 1.4, maven 2.0.7
>Reporter: werner mueller
>
> hallo
> in a multi-module build, when the changelog plugin is configured within the
> parent pom the location in scm is created using the artifactId. In our
> projects the actual modules are not named like this.
> we have:
> parentpom.xml
> - module.a.core.stuff (artifactId module-a-core-stuff)
> - module.b.core.things (artifactId module-b-core-stuff)
> - ...
> the parent pom contains the modules section referring to the modules with
> module.a.core.stuff (the actual folder name)
> the changelog plugin will use the artifactId to look up changes in scm, which
> will create a wrong path (http://localhost/trunk/module-a-core-stuff instead
> of http://localhost/trunk/module.a.core.stuff)
> i would like some configuration option in the parent pom to define what name
> shall be used (${project.artifactId} or ${project.name} for example). so the
> module name can be matched if it is not the same as the artifactId.
> 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: (MASSEMBLY-289) Fix bogus warning about attaching non-regular file
Fix bogus warning about attaching non-regular file
--
Key: MASSEMBLY-289
URL: http://jira.codehaus.org/browse/MASSEMBLY-289
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: bogus-attach-warning.patch
If an archive file is configured with attach=false, the plugin will output the
following warning because the underlying if-else is wrong:
{noformat}
[WARNING] Assembly file: .zip is not a regular file (it may be a
directory).
It cannot be attached to the project build for installation or deployment.
{noformat}
The warning must be guarded with attach=true.
--
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-290) Improve error reporting in case of unlocatable component descriptor
Improve error reporting in case of unlocatable component descriptor
---
Key: MASSEMBLY-290
URL: http://jira.codehaus.org/browse/MASSEMBLY-290
Project: Maven 2.x Assembly Plugin
Issue Type: Improvement
Affects Versions: 2.2-beta-2
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: missing-component-descriptor.patch
That's not really user-friendly:
{noformat}
[INFO] [assembly:attached {execution: make-assemblies}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:454)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:332)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:193)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:296)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
http://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126027
]
Viktor Nordling commented on MASSEMBLY-256:
---
Thanks for fixing this.
I just want to point out that this caused an issue for us and it took a few
hours off of my working day to figure out that it was not my fault, but that I
suddenly got a new version of the assembly plugin that was broken.
It's a bit scary when this happens, from now on we will be setting the plugin
version explicitly in our pom. This should probably be a "recommended practice"
from the Maven team, or is it already?
No need to dwell on it, my point is just that there are people out there who
will get some nasty surprises.
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: http://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1, 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-3
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
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-3419) Build continues despite OutOfMemoryError
[ http://jira.codehaus.org/browse/MNG-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3419. -- Assignee: Brian Fox Resolution: Cannot Reproduce Fix Version/s: (was: 2.0.9) Based on Kohsuke's comments, this is an issue in javac/apt. If there is an IT that can reproduce this to be in the core / or the compiler plugin then reopen and we'll re-evaluate. There isn't much to do without a way to reproduce. > Build continues despite OutOfMemoryError > > > Key: MNG-3419 > URL: http://jira.codehaus.org/browse/MNG-3419 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Sanjeeb Sahoo >Assignee: Brian Fox > > [I have already sent this question to users forum twice, but no response, so > I am filing this issue] > I am seeing something very strange. We have our own plugin(it's basically an > annotation processor) that gets invoked as part of compile phase. It appears > that the JVM gets OutOfMemoryError when this plugin is executed, yet the > build continues to the next phase instead of aborting. I ran with -X option > and it shows that the plugin is invoked in process. I have looked at our > plugin code and we do not catch Throwable or Error in our code. So, it > appears to be a bug in Maven. Given below is some selected output that I > think should give an idea of what's going on... > [INFO] > > [INFO] Building Web Container for GlassFish > [INFO]task-segment: [install] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > ... > [DEBUG] Configuring mojo > 'com.sun.enterprise:hk2-maven-plugin:0.2-SNAPSHOT:hk2-compile' --> > ... > [DEBUG] (f) fork = false > ... > [INFO] [hk2:hk2-compile] > [DEBUG] Using compiler 'hk2-apt'. > [DEBUG] Source directories: > [/space/ss141213/WS/gf/v3/web/webtier/src/main/java] > [DEBUG] Classpath: [/space/ss141213/WS/gf/v3/web/webtier/target/classes... > [INFO] Compiling 660 source files to > /space/ss141213/WS/gf/v3/web/webtier/target/classes > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: Java heap space >at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99) >at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393) >at java.lang.StringBuilder.append(StringBuilder.java:120) >at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1756) >at com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882) >at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1901) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.jvm.ClassReader.completeOwners(ClassReader.java:1547) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1534) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) >at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1440) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1434) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at com.sun.tools.javac.code.Types.asSuper(Types.java:1407) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.visitClassType(Types.java:429) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.isSubType(Types.java:353) >at com.sun.tools.javac.code.Types.isSubType(Types.java:331) >at com.sun.tools.javac.code.Types.isSubTypeUnchecked(Types.java:311) >at com.sun.tools.javac.code.Types.isConvertible(Types.java:278) >at com.sun.tools.javac.code.Types.isAssignable(Types.java:1630) >at com.sun.tools.javac.comp.Check.checkType(Check.java:325) >at com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:122) >at > com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:705) > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:dep
[jira] Commented: (CONTINUUM-1680) Add functionality to remove/recreate a working copy
[ http://jira.codehaus.org/browse/CONTINUUM-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126029 ] Wendy Smoak commented on CONTINUUM-1680: What version of Continuum are you using? One thing that comes to mind is the "Build Fresh" option, which will make Continuum delete and re-check out the project. If you enable that and force a build, does it help? > Add functionality to remove/recreate a working copy > --- > > Key: CONTINUUM-1680 > URL: http://jira.codehaus.org/browse/CONTINUUM-1680 > Project: Continuum > Issue Type: New Feature > Components: SCM, Web - UI >Reporter: Nick Stolwijk >Priority: Minor > > Sometimes a subversion working copy gets corrupted and can not be repaired > through the user interface. This is possible when you have a strange build > which overwrites directories or conflicting commits/build(*). It would be > nice if the User interface offered a possibility to recreate the working copy > (remove and new checkout for example). > (*) We had a directory called etc. In a few commits someone removed that > directory, another one added build code to create a file in that directory > and another person added this folder again in SVN. Continuum (or rather the > SVN under it) was a little confused and could not update. -- 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: (MPMD-75) PMD plugin unable to exclude groovy-stub files.
[ http://jira.codehaus.org/browse/MPMD-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126035 ] guillaume carre commented on MPMD-75: - I have the problem using Apache CXF. By default CXF generates java sources in target\generated\src\main\java I can't exclude this directory, it seems one can't exclude anything that is located in the target directory. > PMD plugin unable to exclude groovy-stub files. > --- > > Key: MPMD-75 > URL: http://jira.codehaus.org/browse/MPMD-75 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.3 > Environment: windows xp, java 1.6.0_04, maven 2.0.8, groovy 1.5.1, > groovy-maven-plugin 1.0-beta3 >Reporter: Jonathan Baker > > When trying to run the pmd plugin to fail our build on a mixed java and > groovy project, I am unable to exclude groovy-generated java stubs. It seems > as though all of the exclude patterns are package and filename filters only. > If this is true, then the only way to exclude groovy-generated java sources > would be to move all of our groovy files into a package that contains the > word groovy, or to name all of our groovy classes ClassNameGroovy.groovy. > This seems unacceptible. The example on the webage for usage shows something > like this: > > **/generated/*.java > > This implies that we could do something similar like this: > > **/groovy-stubs/*.java > > But that doesn't seem to work because it ends up looking for > target/groovy-stubs/main/groovy-stubs/*.java because the patterns are all > relative to the source roots. -- 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-54) add targetPath support on the webResources plugin parameter
[ http://jira.codehaus.org/browse/MWAR-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126034 ] Brian Weiner commented on MWAR-54: -- Everyone is having the same problem I was having. The fix is in 2.0.2 of the plugin, not maven. So specify the version like so: org.apache.maven.plugins maven-war-plugin 2.0.2 and It'll work fine. > add targetPath support on the webResources plugin parameter > --- > > Key: MWAR-54 > URL: http://jira.codehaus.org/browse/MWAR-54 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Reporter: Marvin King >Assignee: Marvin King > Fix For: 2.0.2 > > Attachments: MWAR-54-maven-war-plugin.patch > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > -- 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-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126037
]
John Casey commented on MNG-3221:
-
I've found a more general approach to prevent this looping problem. My approach
should also detect multi-mojo forking cycles, because it adds phase tracking to
the forkEntryPoints stack, and modifies the behavior in cases of
MojoDescriptor.getExecutionGoal() != null where this wasn't checked before.
I've tested it vs. the test scenario above, and where it failed prior to this
fix, it's fine now.
I still need to figure out how/if I can make an integration test out of a
simplified version of this test scenario, that won't bring down the whole test
run with an infinite loop...I'm open to ideas here.
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
>Assignee: John Casey
> Fix For: 2.0.9
>
> Attachments: infinite-loop.diff, MNG-3221-maven-uml-plugin.diff,
> MNG-3221-r633352.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjec
[jira] Closed: (MNG-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3221.
---
Resolution: Fixed
The bug is fixed, and I've made a note on my personal TODO list to find a way
to integration-test this.
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
>Assignee: John Casey
> Fix For: 2.0.9
>
> Attachments: infinite-loop.diff, MNG-3221-maven-uml-plugin.diff,
> MNG-3221-r633352.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
[jira] Created: (MNG-3429) Toolchain classes not being picked up in uber jar
Toolchain classes not being picked up in uber jar - Key: MNG-3429 URL: http://jira.codehaus.org/browse/MNG-3429 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Shane Isbell Priority: Minor The toolchain classes are not being picked up in the packaging of the uber jar. The toolchain classes need to be located under the maven/lib directory to work. -- 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-3430) Toolchain doesn't match Toolchain extensions
Toolchain doesn't match Toolchain extensions Key: MNG-3430 URL: http://jira.codehaus.org/browse/MNG-3430 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Shane Isbell Priority: Minor Toolchain uses null key within storing toolchains in Maven Session, which causes extensions not to match. Specifically, this problem occurs in the DefaultToolchainManager.storeToolchainToBuildContext method. When storing into context context.put( getStorageKey( toolchain.getType() ), toolchain.getModel() ); toolchain.getType() always returns null. Using toolchain.getModel().getType() will return the correct type and fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3431) Pom Extensions not supported for Toolchains
Pom Extensions not supported for Toolchains --- Key: MNG-3431 URL: http://jira.codehaus.org/browse/MNG-3431 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Shane Isbell Priority: Minor When I add a pom extension referening a jar containing an implementation of a toolchain and toolchain factory, the toolchain plugin does not pick up my extensions. I get an exception on mvn install: Caused by: java.lang.ClassNotFoundException: org.apache.maven.dotnet.extensions.toolchain.DotnetToolchainFactory -- 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-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126054 ] Daniel Uribe commented on MNG-3283: --- Any new developments on this issue? It doesn't seem to be same issue as MNG-2277, and it is still not working on 2.0.8. In the comments for that issue, Brian said that this is normal behavior. I would have to agree with Alfie that if a plugin is bound to a lower phase than the one specified in the @requiresDependencyResolution, it doesn't seem to make sense that it would try to resolve dependencies for a higher phase which hasn't even been executed. Elaborating on top of the example outlined by Alfie, if the project having the dependency uses the antrun plugin for the generate-sources phase, it specifies a @requiresDependencyResolution of test, which is definitely higher than the generate-resources used by the eclipse plugin. Since running the eclipse plugin will only execute phases below generate-resources, it will never reach the stage of creating the package (jar, war, etc) for the project that it has a dependency for, hence failing. Wouldn't it make sense to consider that when a plug-in is explicitly bound to a phase, to use that for dependency resolution? > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: http://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick >Assignee: Brian Fox > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-85) Refactoring of dependency and dependency management report
Refactoring of dependency and dependency management report -- Key: MPIR-85 URL: http://jira.codehaus.org/browse/MPIR-85 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Nick Stolwijk Attachments: refactor.patch I've tried to refactor the code from MPIR-83 a bit, because it used a lot of copied code. Important improvements: - Created a AbstractProjectInfoRenderer and AbstractDependencyRenderer. If this patch is accepted, I want to write all the renderers out of the inforeports in separate classes, with more code sharing. This is a start of that. - I changed the unit tests, because the expected and actual were reversed. This is the case in many of the info report unit tests. Please tell me what you think of it. I know it is only a start. -- 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-3394) Plugin versions inherited via cannot be overriden by . section of sub modules
[ http://jira.codehaus.org/browse/MNG-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126060 ] Shane Isbell commented on MNG-3394: --- I've look at the code. There is a problem in the DefaultPluginManager.verifyVersionedPlugin. The method correctly determines the version of the plugin but then it makes a last invocation of pluginCollector.getPluginDescriptor( plugin ), which over rides the correct version of the plugin. There is a comment in the code of pluginCollector.getPluginDescriptor, which seems to touch on this problem: // TODO: include version, but can't do this in the plugin manager as it is not resolved to the right version // at that point. Instead, move the duplication check to the artifact container, or store it locally based on // the unresolved version? I'll keep digging to see how to fix it. > Plugin versions inherited via cannot be overriden by > . section of sub modules > > > Key: MNG-3394 > URL: http://jira.codehaus.org/browse/MNG-3394 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Critical > Fix For: 2.0.9 > > Attachments: plugin-management-version.zip > > > See the comments in the module POM of the attached demo project for more > explanation. -- 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-1640) No changes and no committer name extracted from SVN
[ http://jira.codehaus.org/browse/CONTINUUM-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated CONTINUUM-1640: Fix Version/s: 1.2 > No changes and no committer name extracted from SVN > --- > > Key: CONTINUUM-1640 > URL: http://jira.codehaus.org/browse/CONTINUUM-1640 > Project: Continuum > Issue Type: Bug > Components: SCM >Affects Versions: 1.1 > Environment: Windows XP, Java 1.5, SVN 1.4.3 >Reporter: Timur Evdokimov > Fix For: 1.2 > > > When continuum detects changes and makes builds, no data is extracted on > change date and committer. > It always looks like this > > SCM Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > (here are files) > It is the same machine (SVN/continuum) so we rule out ime difference > immediately. > Moreover I've checked in continuum logs, there is "svn --non-interactive log" > command executed, and when I type this command in, proper dates and commiters > are displayed. > looking at org.apache.maven.continuum.scm.DefaultContinuumScm, I've found > that change date/commiters are taken from ScmResult that comes from this > method > scmResult = scmManager.getProviderByRepository( repository > ).update( repository, fileSet, tag, getLatestUpdateDate( project ) ); > result = convertScmResult( scmResult ); > Maven SVN SCM Manager returns no changes in scmResult.getChanges() > Where this svn log command is coming from then? Not from Maven SCM but from > continuum itself? -- 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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126063
]
Vincent Siveton commented on MJAVADOC-116:
--
Damien, it seems that it is due to @requiresDependencyResolution, not the
Javadoc plugin.
Could you confirm that the error comes from DefaultPluginManager ?
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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-3051) settings.xml doesn't handle profile from pom.xml
[
http://jira.codehaus.org/browse/MNG-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3051.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: Reviewed Pending Version Assignment)
> settings.xml doesn't handle profile from pom.xml
>
>
> Key: MNG-3051
> URL: http://jira.codehaus.org/browse/MNG-3051
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.6
>Reporter: Den Orlov
>Assignee: Brett Porter
> Attachments: nonworking-settings.xml, pom.xml, working-settings.xml
>
>
> I have profile specified in pom.xml (attached). And I try to specify it in
> settings.xml's (attache as nonworking-settings.xml) Accordng
> to help:active-profiles I get:
> {noformat}
> mvn help:active-profiles
> Active Profiles for Project 'test:test:jar:1.0-SNAPSHOT':
> There are no active profiles.
> {noformat}
> When I specify the same profile name in settings.xml (attached as
> working-settings.xml) maven see both profiles (from pom.xml and from
> settings.xml):
> {noformat}
> mvn help:active-profiles
> Active Profiles for Project 'test:test:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - env-test (source: pom)
> - env-test (source: settings.xml)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3432) [regression] Integration test it0042 is broken
[ http://jira.codehaus.org/browse/MNG-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3432: -- Fix Version/s: 2.1-alpha-1 > [regression] Integration test it0042 is broken > -- > > Key: MNG-3432 > URL: http://jira.codehaus.org/browse/MNG-3432 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > junit.framework.AssertionFailedError: Expected file was > not found: /var/tmp/it0042/test-component-c/target/my-test -- 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-3432) [regression] Integration test it0042 is broken
[regression] Integration test it0042 is broken -- Key: MNG-3432 URL: http://jira.codehaus.org/browse/MNG-3432 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 This is currently being demonstrated locally and in Continuum. The error starts with: junit.framework.AssertionFailedError: Expected file was not found: /var/tmp/it0042/test-component-c/target/my-test -- 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-3434) [regression] Integration test it0103 is broken
[regression] Integration test it0103 is broken -- Key: MNG-3434 URL: http://jira.codehaus.org/browse/MNG-3434 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.1-alpha-1 Reporter: Brett Porter This is currently being demonstrated locally and in Continuum. The error starts with: org.apache.maven.it.VerificationException: Exit code was non-zero: 1; log = + Error stacktraces are turned on. WAGON_VERSION: 1.0-beta-2 url = http://repo1.maven.org/maven2 Downloading: http://repo1.maven.org/maven2/org/apache/maven/its/it0103/level1/1/level1-1.pom [ERROR] Failed to resolve parent-POM from repository. Parent POM Information: Group-Id: org.apache.maven.its.it0103 Artifact-Id: level1 Version: 1 Local Repository: /export/home/build/.m2/repository Remote Repositories: central -& http://repo1.maven.org/maven2 Reason: Unable to download the artifact from any repository org.apache.maven.its.it0103:level1:pom:1 from the specified remote repositories: central (http://repo1.maven.org/maven2) Project Id: [inherited]:level3:jar:1 >From file: /var/tmp/it0103/level1/level2/level3/pom.xml Error stacktrace: org.apache.maven.reactor.MavenExecutionException: Error scanning for extensions: Error building model lineage in order to pre-scan for extensions: Cannot find artifact for parent POM: org.apache.maven.its.it0103:level1::1 for project [inherited]:level3:jar:1 at /var/tmp/it0103/level1/level2/level3/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:281) at org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:105) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:162) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:895) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) Caused by: org.apache.maven.extension.ExtensionScanningException: Error building model lineage in order to pre-scan for extensions: Cannot find artifact for parent POM: org.apache.maven.its.it0103:level1::1 for project [inherited]:level3:jar:1 at /var/tmp/it0103/level1/level2/level3/pom.xml at org.apache.maven.extension.DefaultBuildExtensionScanner.buildModelLineage(DefaultBuildExtensionScanner.java:428) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:136) at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:106) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:277) ... 17 more Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find artifact for parent POM: org.apache.maven.its.it0103:level1::1 for project [inherited]:level3:jar:1 at /var/tmp/it0103/level1/level2/level3/pom.xml at org.apache.maven.project.build.model.DefaultModelLineageBuilder.resolveParentFromRepositories(DefaultModelLineageBuilder.java:
[jira] Updated: (MNG-3433) [regression] Integration test it0074 is broken
[ http://jira.codehaus.org/browse/MNG-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3433: -- Fix Version/s: 2.1-alpha-1 > [regression] Integration test it0074 is broken > -- > > Key: MNG-3433 > URL: http://jira.codehaus.org/browse/MNG-3433 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > org.apache.maven.it.VerificationException: Exit code was > non-zero: 100; log = > + Error stacktraces are turned on. > WAGON_VERSION: 1.0-beta-2 > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-compiler-plugin using meta-version: LATEST > [INFO] Using version: 2.1-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-compiler-plugin > [INFO] Searching repository for plugin with prefix: 'clean'. > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-clean-plugin using meta-version: LATEST > [INFO] Using version: 2.3-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-clean-plugin > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-eclipse-plugin using meta-version: LATEST > [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for > updates from central > [INFO] Using version: 2.5-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-eclipse-plugin > [INFO] Scanning for projects... > [INFO] Starting forked execution [fork id: 2000253950] > [INFO] Compiling 1 source file to /var/tmp/it0074/target/classes > [INFO] Ending forked execution [fork id: 2000253950] > [INFO] Using as WTP server : null > [INFO] Adding default classpath contaigner: > org.eclipse.jdt.launching.JRE_CONTAINER > [INFO] Using source status cache: > /var/tmp/it0074/target/mvn-eclipse-cache.properties > --- > constituent[0]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-core-2.1-SNAPSHOT.jar > constituent[1]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-lifecycle-2.1-SNAPSHOT.jar > constituent[2]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/backport-util-concurrent-3.0.jar > constituent[3]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jcl104-over-slf4j-1.5.0.jar > constituent[4]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-workspace-2.1-SNAPSHOT.jar > constituent[5]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-container-default-1.0-alpha-44.jar > constituent[6]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-common-1.0-beta-2.jar > constituent[7]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/doxia-sink-api-1.0-alpha-9.jar > constituent[8]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-utils-1.4.5.jar > constituent[9]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/xml-im-exporter-1.1.jar > constituent[10]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-http-shared-1.0-beta-2.jar > constituent[11]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/commons-cli-1.0.jar > constituent[12]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jsch-0.1.27.jar > constituent[13]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-1.0-beta-2.jar > constituent[14]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/slf4j-simple-1.5.0.jar > constituent[15]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-profile-2.1-SNAPSHOT.jar > constituent[16]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-interactivity-api-1.0-alpha-6.jar > constituent[17]: > file:/export/home/build/data/continuum/checkouts/514/target
[jira] Commented: (MPIR-85) Refactoring of dependency and dependency management report
[ http://jira.codehaus.org/browse/MPIR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126065 ] Vincent Siveton commented on MPIR-85: - IMHO it is a good work. Thanks! I have some comments on the code: * I dont like AbstractDependencies#getScope(Object) Why not using getScope() directly ? * could you provide some test cases for new comparator classes? Some comments on the Maven code convention: * we don't use final at all, specially in methods definition/signature * could you separated public/protected/private in each class to make the code more readingness? * could you comment a minimum with javadoc, specially abstract classes? Btw it is $Id: $ (with colon) for the @version tag I think you could go ahead. > Refactoring of dependency and dependency management report > -- > > Key: MPIR-85 > URL: http://jira.codehaus.org/browse/MPIR-85 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Stolwijk > Attachments: refactor.patch > > > I've tried to refactor the code from MPIR-83 a bit, because it used a lot of > copied code. > Important improvements: > - Created a AbstractProjectInfoRenderer and AbstractDependencyRenderer. > If this patch is accepted, I want to write all the renderers out of the > inforeports in separate classes, with more code sharing. This is a start of > that. > - I changed the unit tests, because the expected and actual were reversed. > This is the case in many of the info report unit tests. > Please tell me what you think of it. I know it is only a start. -- 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-3433) [regression] Integration test it0074 is broken
[regression] Integration test it0074 is broken -- Key: MNG-3433 URL: http://jira.codehaus.org/browse/MNG-3433 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 This is currently being demonstrated locally and in Continuum. The error starts with: org.apache.maven.it.VerificationException: Exit code was non-zero: 100; log = + Error stacktraces are turned on. WAGON_VERSION: 1.0-beta-2 [INFO] Attempting to resolve a version for plugin: org.apache.maven.plugins:maven-compiler-plugin using meta-version: LATEST [INFO] Using version: 2.1-SNAPSHOT of plugin: org.apache.maven.plugins:maven-compiler-plugin [INFO] Searching repository for plugin with prefix: 'clean'. [INFO] Attempting to resolve a version for plugin: org.apache.maven.plugins:maven-clean-plugin using meta-version: LATEST [INFO] Using version: 2.3-SNAPSHOT of plugin: org.apache.maven.plugins:maven-clean-plugin [INFO] Attempting to resolve a version for plugin: org.apache.maven.plugins:maven-eclipse-plugin using meta-version: LATEST [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for updates from central [INFO] Using version: 2.5-SNAPSHOT of plugin: org.apache.maven.plugins:maven-eclipse-plugin [INFO] Scanning for projects... [INFO] Starting forked execution [fork id: 2000253950] [INFO] Compiling 1 source file to /var/tmp/it0074/target/classes [INFO] Ending forked execution [fork id: 2000253950] [INFO] Using as WTP server : null [INFO] Adding default classpath contaigner: org.eclipse.jdt.launching.JRE_CONTAINER [INFO] Using source status cache: /var/tmp/it0074/target/mvn-eclipse-cache.properties --- constituent[0]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-core-2.1-SNAPSHOT.jar constituent[1]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-lifecycle-2.1-SNAPSHOT.jar constituent[2]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/backport-util-concurrent-3.0.jar constituent[3]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jcl104-over-slf4j-1.5.0.jar constituent[4]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-workspace-2.1-SNAPSHOT.jar constituent[5]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-container-default-1.0-alpha-44.jar constituent[6]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-common-1.0-beta-2.jar constituent[7]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/doxia-sink-api-1.0-alpha-9.jar constituent[8]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-utils-1.4.5.jar constituent[9]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/xml-im-exporter-1.1.jar constituent[10]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-http-shared-1.0-beta-2.jar constituent[11]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/commons-cli-1.0.jar constituent[12]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jsch-0.1.27.jar constituent[13]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-1.0-beta-2.jar constituent[14]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/slf4j-simple-1.5.0.jar constituent[15]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-profile-2.1-SNAPSHOT.jar constituent[16]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-interactivity-api-1.0-alpha-6.jar constituent[17]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-reporting-api-2.1-SNAPSHOT.jar constituent[18]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/commons-httpclient-2.0.2.jar constituent[19]: file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSH
[jira] Updated: (MNG-3434) [regression] Integration test it0103 is broken
[ http://jira.codehaus.org/browse/MNG-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3434: -- Fix Version/s: 2.1-alpha-1 > [regression] Integration test it0103 is broken > -- > > Key: MNG-3434 > URL: http://jira.codehaus.org/browse/MNG-3434 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > org.apache.maven.it.VerificationException: Exit code > was non-zero: 1; log = > + Error stacktraces are turned on. > WAGON_VERSION: 1.0-beta-2 > url = http://repo1.maven.org/maven2 > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/its/it0103/level1/1/level1-1.pom > [ERROR] > Failed to resolve parent-POM from repository. > Parent POM Information: > Group-Id: org.apache.maven.its.it0103 > Artifact-Id: level1 > Version: 1 > Local Repository: /export/home/build/.m2/repository > Remote Repositories: > central -& http://repo1.maven.org/maven2 > Reason: Unable to download the artifact from any repository > org.apache.maven.its.it0103:level1:pom:1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > Project Id: [inherited]:level3:jar:1 > From file: /var/tmp/it0103/level1/level2/level3/pom.xml > Error stacktrace: > org.apache.maven.reactor.MavenExecutionException: Error scanning for > extensions: Error building model lineage in order to pre-scan for extensions: > Cannot find artifact for parent POM: org.apache.maven.its.it0103:level1::1 > for project [inherited]:level3:jar:1 at > /var/tmp/it0103/level1/level2/level3/pom.xml > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:281) > at > org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:105) > at > org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:162) > at > org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:895) > at > org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) > at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.extension.ExtensionScanningException: Error > building model lineage in order to pre-scan for extensions: Cannot find > artifact for parent POM: org.apache.maven.its.it0103:level1::1 for project > [inherited]:level3:jar:1 at /var/tmp/it0103/level1/level2/level3/pom.xml > at > org.apache.maven.extension.DefaultBuildExtensionScanner.buildModelLineage(DefaultBuildExtensionScanner.java:428) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:136) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.checkModulesForExtensions(DefaultBuildExtensionScanner.java:330) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:196) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:106) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:277) > ...
[jira] Created: (MNG-3435) fix for MNG2277 has not been merged to trunk, causing an integration test failure
fix for MNG2277 has not been merged to trunk, causing an integration test failure - Key: MNG-3435 URL: http://jira.codehaus.org/browse/MNG-3435 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Fix For: 2.1-alpha-1 -- 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-3435) fix for MNG2277 has not been merged to trunk, causing an integration test failure
[ http://jira.codehaus.org/browse/MNG-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3435: -- Assignee: Brian Fox Fix Version/s: 2.1-alpha-1 > fix for MNG2277 has not been merged to trunk, causing an integration test > failure > - > > Key: MNG-3435 > URL: http://jira.codehaus.org/browse/MNG-3435 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: Brian Fox > Fix For: 2.1-alpha-1 > > -- 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: (MPIR-85) Refactoring of dependency and dependency management report
[ http://jira.codehaus.org/browse/MPIR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126067 ] Vincent Siveton commented on MPIR-85: - Another thought for the getScope() issue: you could also create a wrapper for Artifact and Dependency > Refactoring of dependency and dependency management report > -- > > Key: MPIR-85 > URL: http://jira.codehaus.org/browse/MPIR-85 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Stolwijk > Attachments: refactor.patch > > > I've tried to refactor the code from MPIR-83 a bit, because it used a lot of > copied code. > Important improvements: > - Created a AbstractProjectInfoRenderer and AbstractDependencyRenderer. > If this patch is accepted, I want to write all the renderers out of the > inforeports in separate classes, with more code sharing. This is a start of > that. > - I changed the unit tests, because the expected and actual were reversed. > This is the case in many of the info report unit tests. > Please tell me what you think of it. I know it is only a start. -- 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-3435) fix for MNG2277 has not been merged to trunk, causing an integration test failure
[ http://jira.codehaus.org/browse/MNG-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3435. -- Resolution: Duplicate Duplicate of http://jira.codehaus.org/browse/MNG-3260 this was intentional so we didn't propagate the hack. > fix for MNG2277 has not been merged to trunk, causing an integration test > failure > - > > Key: MNG-3435 > URL: http://jira.codehaus.org/browse/MNG-3435 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: Brian Fox > Fix For: 2.1-alpha-1 > > -- 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-3435) fix for MNG2277 has not been merged to trunk, causing an integration test failure
[ http://jira.codehaus.org/browse/MNG-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3435: --- Fix Version/s: (was: 2.1-alpha-1) > fix for MNG2277 has not been merged to trunk, causing an integration test > failure > - > > Key: MNG-3435 > URL: http://jira.codehaus.org/browse/MNG-3435 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >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] Updated: (MNG-3260) 2.1: aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3260: --- Fix Version/s: (was: 2.1) 2.1-alpha-1 Something needs to be done in alpha-1 to maintain compatibility with 2.0.x. The fix was not merged because it was already so different that it needed a new piece of code in 2.1 (and was a hack). > 2.1: aggregating plugins in submodules of the reactor return all projects > causing a chicken/egg issue > - > > Key: MNG-3260 > URL: http://jira.codehaus.org/browse/MNG-3260 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API, Plugins and Lifecycle, Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.1-alpha-1 > > > eg, assembly:attached > when this is put in maven-core, and a build is run from the root project with > a clean repo, it fails, as the original project sorter doesn't consider the > dependencies, building plugin-tools after maven-core. > However, hitting the aggregator when building maven-core then tries to > resolve all of the projects as dependencies. -- 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-1679) Adding Null values for Project's Build Definition directs to a blank page
[ http://jira.codehaus.org/browse/CONTINUUM-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1679: Assignee: Olivier Lamy Affects Version/s: 1.1 Fix Version/s: 1.2 Component/s: Web - UI Patch Submitted: [Yes] > Adding Null values for Project's Build Definition directs to a blank page > - > > Key: CONTINUUM-1679 > URL: http://jira.codehaus.org/browse/CONTINUUM-1679 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1 >Reporter: Maria Catherine Tan >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.2 > > Attachments: CONTINUUM-1679-continuum-webapp.patch > > > To reproduce: > 1. Select a Project Group > 2. Go to Build Definitions tab > 3. Click Add > 4. Leave Pom.xml field blank > 5. Click Save -- 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: (MPMD-61) When running build using "-f /pom.xml" the site is stored in working directory instead of project directory
[
http://jira.codehaus.org/browse/MPMD-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126071
]
Sean Gay commented on MPMD-61:
--
After reading this issue I implemented a work-around that seems to solve my
problems for multi-module builds. Simply place the following line in your
configuration for the PMD plugin.
{code}
${project.build.directory}/site
{code}
> When running build using "-f /pom.xml" the site is stored in
> working directory instead of project directory
>
>
> Key: MPMD-61
> URL: http://jira.codehaus.org/browse/MPMD-61
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.2
> Environment: Windows XP, Java 1.5, Maven 2.0.7
>Reporter: Peter Hayes
> Attachments: output-directory.patch, pmd-multi-module.zip
>
>
> I setup a multi-module build and included the pmd check goal to run during
> the verify phase. When I execute a build from the top level directory
> specifying -f /pom.xml, the plugin creates a target/site/... directory
> in the current working directory. This directory should be in the project
> directory and now fails to clean.
> I have attached a sample project. To reproduce :
> cd pmd-multi-module
> mvn -f ./root/pom.xml install
> Note that after the build there is a target directory in the current working
> directory with the pmd.html and other files within it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3436) updateInterval checking for releases causes major slow-down
updateInterval checking for releases causes major slow-down --- Key: MNG-3436 URL: http://jira.codehaus.org/browse/MNG-3436 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.1-alpha-1 Reporter: John Casey One change that crept into maven-artifact recently without my full understanding enabled the updateInterval calculation for release artifacts. Since releases are considered immutable by Maven, update-interval calculations should never cause released artifacts to be re-resolved. NOTE: This does NOT apply to release metadata, as the meta-versions RELEASE and LATEST may change with successive releases to a particular project...release metadata should be checked according to the updateInterval in the releases section of the repository definition. -- 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-3436) updateInterval checking for releases causes major slow-down
[ http://jira.codehaus.org/browse/MNG-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3436. --- Resolution: Fixed Fix Version/s: 2.1-alpha-1 fixed. > updateInterval checking for releases causes major slow-down > --- > > Key: MNG-3436 > URL: http://jira.codehaus.org/browse/MNG-3436 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > > One change that crept into maven-artifact recently without my full > understanding enabled the updateInterval calculation for release artifacts. > Since releases are considered immutable by Maven, update-interval > calculations should never cause released artifacts to be re-resolved. > NOTE: This does NOT apply to release metadata, as the meta-versions RELEASE > and LATEST may change with successive releases to a particular > project...release metadata should be checked according to the updateInterval > in the releases section of the repository definition. -- 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-1954) Upload Click 1.4 bundles
Upload Click 1.4 bundles Key: MAVENUPLOAD-1954 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1954 Project: maven-upload-requests Issue Type: Task Reporter: Malcolm Edgar Please upload the following Click 1.4 maven bundles: http://click.sourceforge.net/click-maven-bundle/click-1.4-bundle.jar http://click.sourceforge.net/click-maven-bundle/click-nodeps-1.4-bundle.jar http://click.sourceforge.net/click-maven-bundle/click-extras-1.4-bundle.jar Thanks for your help regards Malcolm Edgar -- 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-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126082 ] Jesus Ramos commented on MNG-3228: -- Seems this behaviour is present only in Windows. When using Maven profiles with activation keys in Mac OS X, Solaris, or any other *NIX, it works as expected (of course, you still have to run MVN from the same dir the parent pom is located in). > Maven profile activation does not work when profile is defined in inherited > 'parent' pom > > > Key: MNG-3228 > URL: http://jira.codehaus.org/browse/MNG-3228 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: tony nys > Fix For: Reviewed Pending Version Assignment > > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- 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-2234) activeProfile in ~/.m2/settings.xml is ignored when profiles section is missing or empty
[ http://jira.codehaus.org/browse/MNG-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2234. - Assignee: Brett Porter (was: Jason van Zyl) Resolution: Fixed Fix Version/s: (was: 2.1-alpha-1) 2.0.9 > activeProfile in ~/.m2/settings.xml is ignored when profiles section is > missing or empty > > > Key: MNG-2234 > URL: http://jira.codehaus.org/browse/MNG-2234 > Project: Maven 2 > Issue Type: Bug > Components: Profiles, Settings >Affects Versions: 2.0.4 >Reporter: Manfred Geiler >Assignee: Brett Porter > Fix For: 2.0.9 > > > When i have this settings.xml file in my user home dir, the activeProfile > setting is simply ignored by Maven: > > > env-test > > > Adding an empty profiles section does not help: > > > > > env-test > > > Well, adding a dummy profile makes it work: > > > > dummy > > > > env-test > > > Funny, isn't it? > Regards, > Manfred -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1955) upload xSocket 2.0-beta-1
upload xSocket 2.0-beta-1 - Key: MAVENUPLOAD-1955 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1955 Project: maven-upload-requests Issue Type: Wish Reporter: greg please also upload the xSocket extensions http://xsocket.sourceforge.net/download/xSocket-http-2.0-alpha-3-bundle.jar http://xsocket.sourceforge.net/download/xSocket-multiplexed-2.0-alpha-3-bundle.jar Thank you very much Greg -- 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-3437) Always updating local repository from remote repository
Always updating local repository from remote repository --- Key: MNG-3437 URL: http://jira.codehaus.org/browse/MNG-3437 Project: Maven 2 Issue Type: Improvement Components: Settings Reporter: sachin kamdar With the following settings in the settings.xml file, ... inhouse-repo Inhouse M2 Repo http://inhouse.maven.repo true always warn ... * Dev A has a copy of demo-1.0.0.jar in his local repository * Dev B makes a code change to demo project and packages the jar without updating the version in the POM (which I think is a BAD BAD thing). * Dev B then deploys a changed demo-1.0.0.jar into Inhouse Remote Repository. * When Dev A does his next build, despite of the always setting the local repository doesn't get the newer copy from the Inhouse Remote Repository. Is this kind of expected? Does maven only looks at the version number of an artifact to determines if they are different? And if all this is true then under what circumstances would always fetch a newer artifact? Is there any way I can get Maven to always update an artifact from Inhouse Remote Repository into the local repository even though the version numbers are same? -- 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-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126092 ] tony nys commented on MNG-3228: --- how can it be OS dependent. ? The scenario works fine for a simple maven project without 'parent'. The activation keys work fine Only in the 'parent' child scenario it does not work. The goal is to have all profiles defined in the parent pom, and every child pom inherits this pom. We don't want to put all properties in every pom, this is the reason for existence of the parent pom > Maven profile activation does not work when profile is defined in inherited > 'parent' pom > > > Key: MNG-3228 > URL: http://jira.codehaus.org/browse/MNG-3228 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: tony nys > Fix For: Reviewed Pending Version Assignment > > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- 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
