[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201674#action_201674
]
Johannes Martin commented on MNG-4368:
--------------------------------------
I don't think the problem Tamás is experiencing has anything to do with this problem and the
fix implemented.
The problem here was that install ALWAYS copied files to their destination. The fix changed
this to copy the files only if their timestamp is newer than the destination's timestamp.
Tamás problem is that files are not copied even though their timestamp is newer than the destiniation's
(assuming that "do build" means "mvn clean install").
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
POM allows duplicate plugin configuration
-----------------------------------------
Key: MNG-4487
URL: http://jira.codehaus.org/browse/MNG-4487
Project: Maven 2
Issue Type: Improvement
Affects Versions: 2.0.9
Reporter: Ken Wong
Priority: Minor
I have a project that uses FlexMOJO to compile the swc and then optimize and create a swf.
If you look at the following pom extract, you will see that I defined the configuration for
the same plugin twice (flexmojos-maven-plugin). There was no error but having the duplicate
definition caused maven to be confused and the locale and namespace parameters ended up being
'lost'. If I comment out the 2nd part, then it works. If having duplicate definition confuses
maven, it would be nice to have it throw an error when it sees duplicate configuration for
the same plugin, instead of yielding confusing result.
build>
<plugins>
<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<configuration>
<compiledLocales>
<locale>en_US</locale>
<locale>es_ES</locale>
<locale>ja_JP</locale>
</compiledLocales>
resourceBundlePath>
<namespaces>
<namespace>
<uri>http://www.stoneriver.com/2009/uicore</uri>
<manifest>${basedir}/src/manifest.xml</manifest>
</namespace>
</namespaces>
<includeNamespaces>
<namespace>http://www.stoneriver.com/2009/uicore</namespace>
</includeNamespaces>
</configuration>
</plugin>
<plugin>
<groupId>org.sonatype.flexmojos</groupId>
<artifactId>flexmojos-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>optimize</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
--
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
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638
]
Laird Nelson commented on MNG-4479:
-----------------------------------
Perhaps consider applying the fix to the 2.1 branch?
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin
key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> I have a plugin that makes use of the implementation attribute in its configuration.
That is, one of its parameters is a plexus tag that specifies an implementation class to
use.
> The implementation class comes from a jar that is the plugin's dependency, but that dependency
is included as part of the plugin configuration, not as part of the stock plugin.
> This setup works fine when I bind the plugin's configuration via an execution to a normal
phase (generate-sources as it happens).
> When I bind the plugin's configuration to the default-cli execution, plexus cannot configure
the component, claiming that the classname it encounters in the "implementation" attribute
cannot be found (even though, again, if I bind it to the generate-sources phase instead, via
another execution, same configuration, everything works fine.
> I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw
take is that it looks like dependency resolution in the default-cli execution is somehow performed
differently than when the plugin is run bound to a phase.
--
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
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638
]
Laird Nelson edited comment on MNG-4479 at 12/7/09 7:07 PM:
------------------------------------------------------------
Perhaps consider applying the fix to the 2.2.1 branch?
was (Author: ljnelson):
Perhaps consider applying the fix to the 2.1 branch?
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin
key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> I have a plugin that makes use of the implementation attribute in its configuration.
That is, one of its parameters is a plexus tag that specifies an implementation class to
use.
> The implementation class comes from a jar that is the plugin's dependency, but that dependency
is included as part of the plugin configuration, not as part of the stock plugin.
> This setup works fine when I bind the plugin's configuration via an execution to a normal
phase (generate-sources as it happens).
> When I bind the plugin's configuration to the default-cli execution, plexus cannot configure
the component, claiming that the classname it encounters in the "implementation" attribute
cannot be found (even though, again, if I bind it to the generate-sources phase instead, via
another execution, same configuration, everything works fine.
> I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw
take is that it looks like dependency resolution in the default-cli execution is somehow performed
differently than when the plugin is run bound to a phase.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201629#action_201629
]
Tamás Cservenák commented on MNG-4368:
--------------------------------------
Brett, for now, I believe that having separate settings.xml (with separate local repo path)
will solve my problem. Will be PITA, but can live with it.
Paul, I do have separate checkouts. This is about local repository (~/.m2/repository), not
having files installed properly. Even with my example above, where I did wrote "svn switch",
you can do following instead to reproduce it:
checkout _all_ (checkout repo root, if you have /trunk, /tags, etc in root) and simply do
this instead of switch:
cd trunk
do build
cd ../branches/branchX
cd build
cd ../../trunk
do build
Same problem (if the branchX has newer POM than trunk, as I wrote above). And my cmd was always
"mvn clean install" (so did clean target dirs). And T0, T1 and T2 builds were running sequentially,
one by one.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201624#action_201624
]
Paul Benedict edited comment on MNG-4368 at 12/7/09 5:00 PM:
-------------------------------------------------------------
I think the problem here is that you are dirtying your target directory while performing all
these switches. I don't mean to sound anything but polite, but I have never seen anyone ever
do that; separate checkout directories are the norm for concurrent work. If you switch back
and forth, you should clean the target first.
was (Author: paul4christ79):
I think the problem here is that you are dirtying your target directory while performing
all these switches. I don't mean to sound anything but polite, but I have never seen anyone
ever do that; separate checkout directories are the norm. If you switch back and forth, you
should clean the target first.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201624#action_201624
]
Paul Benedict commented on MNG-4368:
------------------------------------
I think the problem here is that you are dirtying your target directory while performing all
these switches. I don't mean to sound anything but polite, but I have never seen anyone ever
do that; separate checkout directories are the norm. If you switch back and forth, you should
clean the target first.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201620#action_201620
]
Brett Porter commented on MNG-4368:
-----------------------------------
I still believe the answer to be workspaces in the local repository, but that proposal didn't
get any traction.
Having read the list now, I think there was a pragmatic solution proposed with regards to
the timestamps, that combined with an option to override, would provide a suitable alternative
here.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
mvn site command creates css, images, but no html files
-------------------------------------------------------
Key: MSITE-439
URL: http://jira.codehaus.org/browse/MSITE-439
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Environment: maven-site-plugin:2.0.1 with Apache Maven 3.0-alpha-5
Reporter: John Cheng
I read about http://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html and MNG-4162, but
I am not sure if what I am seeing is the expected behavior, or if it should be reported as
a bug.
To reproduce, use Maven 3.0 alpha 5. Create the maven-archetype-webapp project, and try to
generate a site for it.
mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp
cd my-webapp
mvn site
ls -l target/site
Expected to see index.html, etc.,
The result I see is a css folder and a image folder, but nothing else. Is there a way to generate
a site using Maven 3?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201618#action_201618
]
Tamás Cservenák commented on MNG-4368:
--------------------------------------
The fact is, that I did full rebuild, and was completely puzzled after T2 why my build fails
with - well, let's say "strange" at least - error. All three builds (T0, T1 and T2) were full
builds.
And as I noted the same thing on MavenDev list: if maven "best practice" requires you to have
_different_ version on _every existing branch_, how this fit Git or any other Distributed
SCM? Who will coordinate these versions, that may exist in multiple Git repositories out there?
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201617#action_201617
]
Brett Porter commented on MNG-4368:
-----------------------------------
Even if this is reverted, the above will run into problems if you don't do a complete rebuild
every time you switch branches. I would advocate renaming the version on your branches (using
the versions plugin, or created with release:branch, for example), if they are not actually
the same development version of things.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201617#action_201617
]
Brett Porter edited comment on MNG-4368 at 12/7/09 4:16 PM:
------------------------------------------------------------
Even if this is reverted, the above will run into problems if you don't do a complete rebuild
every time you switch branches. I would advocate renaming the version on your branches (using
the versions plugin, or created with release:branch, for example), if they are not actually
the same development version of things.
However, an option to force installation would be a helpful thing to add.
was (Author: brettporter):
Even if this is reverted, the above will run into problems if you don't do a complete
rebuild every time you switch branches. I would advocate renaming the version on your branches
(using the versions plugin, or created with release:branch, for example), if they are not
actually the same development version of things.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201614#action_201614
]
Arnaud Heritier edited comment on MJAVADOC-276 at 12/7/09 3:56 PM:
-------------------------------------------------------------------
Same thing for me with maven 2.2.1 and javadoc plugin 2.6.1. The release fails because it
doesn't find artifacts it didn't yet build.
My config was :
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate-jar</goal>
</goals>
</execution>
</executions>
</plugin>
{code}
was (Author: aheritier):
Same thing for me. The release fails because it doesn't find artifacts it didn't yet build.
My config was :
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate-jar</goal>
</goals>
</execution>
</executions>
</plugin>
{code}
> Initial builds of a multi-module project fail
> ---------------------------------------------
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
> Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
> Reporter: Anthony Whitford
> Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I released... I went
from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT build failed ({{mvn clean install
site}}) because Javadoc fails when run from the top-level parent. When it is building _module
A_, the javadoc complains that _module B_ and _module C_ are missing -- of course they are,
they haven't been built yet. Note that running {{mvn clean install}} from _module A_ works
fine -- the behavior is limited to running from the top-level parent -- AND, if you run a
{{mvn install}} for _module B_ and _module C_, then you have given it what it needs and so
you won't see the error.
> The attached example exhibits the problem. It was created from the _j2ee-simple_ archetype
-- I only added the explicit javadoc plugin declaration to the top level pom to control the
version being used. To recreate the problem, unzip and simply: {{mvn clean install site}}.
You will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in repository
central (http://repo1.maven.org/maven2)
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects -DartifactId=logging -Dversion=1.0
-Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=root.project.projects -DartifactId=logging -Dversion=1.0
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> ----------
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case {{root.project.projects:logging:jar:1.0}})
is necessary to build the javadoc for the project... Since this is the first time that this
is being built, the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so I'm convinced
that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I don't think
so.)
--
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
[ http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201614#action_201614
]
Arnaud Heritier commented on MJAVADOC-276:
------------------------------------------
Same thing for me. The release fails because it doesn't find artifacts it didn't yet build.
My config was :
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>aggregate</id>
<goals>
<goal>aggregate-jar</goal>
</goals>
</execution>
</executions>
</plugin>
{code}
> Initial builds of a multi-module project fail
> ---------------------------------------------
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
> Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
> Reporter: Anthony Whitford
> Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I released... I went
from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT build failed ({{mvn clean install
site}}) because Javadoc fails when run from the top-level parent. When it is building _module
A_, the javadoc complains that _module B_ and _module C_ are missing -- of course they are,
they haven't been built yet. Note that running {{mvn clean install}} from _module A_ works
fine -- the behavior is limited to running from the top-level parent -- AND, if you run a
{{mvn install}} for _module B_ and _module C_, then you have given it what it needs and so
you won't see the error.
> The attached example exhibits the problem. It was created from the _j2ee-simple_ archetype
-- I only added the explicit javadoc plugin declaration to the top level pom to control the
version being used. To recreate the problem, unzip and simply: {{mvn clean install site}}.
You will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in repository
central (http://repo1.maven.org/maven2)
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects -DartifactId=logging -Dversion=1.0
-Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=root.project.projects -DartifactId=logging -Dversion=1.0
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> ----------
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case {{root.project.projects:logging:jar:1.0}})
is necessary to build the javadoc for the project... Since this is the first time that this
is being built, the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so I'm convinced
that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I don't think
so.)
--
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
[ http://jira.codehaus.org/browse/MRESOURCES-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201613#action_201613
]
Andrew Williams commented on MRESOURCES-110:
--------------------------------------------
Yes, it strips the next character if the escapeString is not followed by a filter character.
Very annoying!
> escapeString is broken - break filtered output
> ----------------------------------------------
>
> Key: MRESOURCES-110
> URL: http://jira.codehaus.org/browse/MRESOURCES-110
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Affects Versions: 2.4, 2.4.1
> Environment: Maven 2.0.9, WinXP
> Reporter: Marco Rothe
> Priority: Critical
>
> If the escapeString parameter is specified in plugin configuration this will break the
filtered output.
> For example the configuration
> <plugin>
> <artifactId>maven-resources-plugin</artifactId>
> <version>2.4.1</version>
> <configuration>
> <escapeString>!</escapeString>
> </configuration>
> </plugin>
> an file to filter (an XML file)
> <?xml version="1.0" encoding="UTF-8"?>
> <root>
> <!-- This is a comment ... until filtering ... -->
> <broken-tag>Why are my !\${\}\! static.content broken if the escapeString occure
?!?</broken-tag>
> <broken-tag>Content with replacement: ${replaceThis} !</broken-tag>
> <broken-tag>Content with escaped replacement: Do not !${replaceThis} !</broken-tag>
> </root>
> and a property
> <properties>
> <replaceThis>I am the replacement</replaceThis>
> </properties>
> from pom or profile.xml
> result in
> <?xml version="1.0" encoding="UTF-8"?>
> <root>
> <!- This is a comment ... until filtering ... -->
> <broken-tag>Why are my !${\}\!static.content broken if the escapeString occure
?!</broken-tag>
> <broken-tag>Content with replacement: I am the replacement !/broken-tag>
> <broken-tag>Content with escaped replacement: Do not ${replaceThis} !/broken-tag>
> </root>
> Note the broken comment and tags!
> If using Resources-Plugin 2.3 the output is like expected:
> <?xml version="1.0" encoding="UTF-8"?>
> <root>
> <!-- This is a comment ... until filtering ... -->
> <broken-tag>Why are my !\${\}\! static.content broken if the escapeString occure
?!?</broken-tag>
> <broken-tag>Content with replacement: I am the replacement !</broken-tag>
> <broken-tag>Content with escaped replacement: Do not ${replaceThis} !</broken-tag>
> </root>
> Got even worse when using a complex escape string like <escapeString>static</escapeString>
(I know it's a silly example ;)). The result is
> <?xml version=".0" encoding="UTF-8"?>
> <root>
> <!-- This is acomment ... until filtering ... -->
> <broken-tag>Why are my !\${\}\! staticcontent broken if the escapeSring occure
?!?</broken-tag>
> <broken-tag>Content with replacement: I am the replacement !</broken-tag>
> <broken-tag>Content with escapedreplacement: Do not !I am the replacement !</broken-tag>
> </root>
> Note the missing characters all over the file ... :-/
> So the actual state of the escapeString feature is unpredictable and nearly useless.
--
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
[ http://jira.codehaus.org/browse/MRELEASE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff French updated MRELEASE-238:
---------------------------------
Attachment: release.txt
I'm also getting the problem with beta-8 and beta-9, and was asked to upload the results of
my 'mvn -X release:prepare'. The beta-5 version does work for me.
> release:prepare hangs at cvs update
> -----------------------------------
>
> Key: MRELEASE-238
> URL: http://jira.codehaus.org/browse/MRELEASE-238
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Affects Versions: 2.0-beta-6
> Reporter: Lothar Hegebart
> Priority: Blocker
> Attachments: release.txt
>
>
> release:prepare just hangs indefinitely, no more information given by -X and -e
> when i define version 2.0-beta-5 as plugin version it works just 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
[ http://jira.codehaus.org/browse/MNG-4486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4486.
----------------------------------
Resolution: Duplicate
Assignee: Benjamin Bentmann
> Maven appears to ignore http 301; downloads html as jar
> -------------------------------------------------------
>
> Key: MNG-4486
> URL: http://jira.codehaus.org/browse/MNG-4486
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1
> Environment: WinXP and Solaris10
> Reporter: David Biesack
> Assignee: Benjamin Bentmann
>
> Our Maven builds are configured with just two repositories,
> http://repo1.maven.org/maven2 and http://scala-tools.org/repo-releases
> (We use Artifactory as a central repo cache)
> But since Friday, I've noticed builds failing because builds are trying to
> download jms-1.1.jar from maven-repository.dev.java.net even though that is not in our
repo path
> or configuration.
> when I run with -X I see a failure trying to download jmx-1.1.jar from central,
> followed by:
> Downloading:
> https://maven-repository.dev.java.net/nonav/repository/javax.jms/jars/jms-1.1.jar
> 347b downloaded
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> 'd0b7ce08d257e8fefdc6ad0f0f0368635bbeb3d0'; remote = '<!DOCTYPE' - RETRYING
> Worse, what gets downloaded is not a jar but some html. Maven seems to
> ignore the 301 status and thinks this is a jar. The contents are:
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>301 Moved Permanently</title>
> </head><body>
> <h1>Moved Permanently</h1>
> <p>The document has moved <a href="
> http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
> <hr>
> <address>Apache Server at maven-repository.dev.java.net Port
> 443</address>
> </body></html>
> http://repo2.maven.org/maven2/javax/jms/jms/1.1/ contains a pom.xml but no jar.
> However, http://repository.jboss.com/maven2/javax/jms/jms/1.1/ has the jar.
> my project does not even depend on jms directly; it appears to be one of the
> internal Maven compile or site targets that cause it to get loaded, but I'm not sure
which.
> In artifactory's config, we specify:
> <remoteRepositories>
> <remoteRepository>
> <key>repo1</key>
> <handleReleases>true</handleReleases>
> <handleSnapshots>false</handleSnapshots>
> <excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
> <url>http://repo1.maven.org/maven2</url>
> <proxyRef>SASproxy</proxyRef>
> </remoteRepository>
> <remoteRepository>
> <key>scala-tools.org</key>
> <handleReleases>true</handleReleases>
> <handleSnapshots>false</handleSnapshots>
> <url>http://scala-tools.org/repo-releases</url>
> <proxyRef>SASproxy</proxyRef>
> </remoteRepository>
> </remoteRepositories>
> My ~/.m2/settings.xml is empty and /usr/local/maven/conf/settings.xml simply
> points to my Artifactory server, no other repos in the profile:
> <profiles>
> <profile>
> <id>artifactory</id>
> <activation><activeByDefault>true</activeByDefault></activation>
> <repositories>
> <repository>
> <id>central</id>
> <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> <repository>
> <id>snapshots</id>
> <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
> <releases>
> <enabled>false</enabled>
> </releases>
> </repository>
> </repositories>
> <pluginRepositories>
> <pluginRepository>
> <id>central</id>
> <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </pluginRepository>
> <pluginRepository>
> <id>snapshots</id>
> <url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
> <releases>
> <enabled>false</enabled>
> </releases>
> </pluginRepository>
> </pluginRepositories>
> </profile>
> </profiles>
> I was able to workaround this by downloading jms-1.1.jar and putting it in our
> Artifactory repo, but I think that is simply masking a problem, so this will
> probably pop back up.
> Perhaps the problem is at central; I don't know if it every had a jms-1.1.jar;
> as I said, we did not depend on it directly, so we suspect some other
> plugin now uses it that did not, or the jar was incorrectly removed
> from central. But the fact that Maven downloaded the html as a jar
> caused problems, because after each build failure, I had to manually
> clean up my bad ~/.m2/repository
--
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
Maven appears to ignore http 301; downloads html as jar
-------------------------------------------------------
Key: MNG-4486
URL: http://jira.codehaus.org/browse/MNG-4486
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.2.1
Environment: WinXP and Solaris10
Reporter: David Biesack
Our Maven builds are configured with just two repositories,
http://repo1.maven.org/maven2 and http://scala-tools.org/repo-releases
(We use Artifactory as a central repo cache)
But since Friday, I've noticed builds failing because builds are trying to
download jms-1.1.jar from maven-repository.dev.java.net even though that is not in our repo
path
or configuration.
when I run with -X I see a failure trying to download jmx-1.1.jar from central,
followed by:
Downloading:
https://maven-repository.dev.java.net/nonav/repository/javax.jms/jars/jms-1.1.jar
347b downloaded
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'd0b7ce08d257e8fefdc6ad0f0f0368635bbeb3d0'; remote = '<!DOCTYPE' - RETRYING
Worse, what gets downloaded is not a jar but some html. Maven seems to
ignore the 301 status and thinks this is a jar. The contents are:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="
http://download.java.net/maven/1/javax.jms/jars/jms-1.1.jar">here</a>.</p>
<hr>
<address>Apache Server at maven-repository.dev.java.net Port
443</address>
</body></html>
http://repo2.maven.org/maven2/javax/jms/jms/1.1/ contains a pom.xml but no jar.
However, http://repository.jboss.com/maven2/javax/jms/jms/1.1/ has the jar.
my project does not even depend on jms directly; it appears to be one of the
internal Maven compile or site targets that cause it to get loaded, but I'm not sure which.
In artifactory's config, we specify:
<remoteRepositories>
<remoteRepository>
<key>repo1</key>
<handleReleases>true</handleReleases>
<handleSnapshots>false</handleSnapshots>
<excludesPattern>org/artifactory/**,org/jfrog/**</excludesPattern>
<url>http://repo1.maven.org/maven2</url>
<proxyRef>SASproxy</proxyRef>
</remoteRepository>
<remoteRepository>
<key>scala-tools.org</key>
<handleReleases>true</handleReleases>
<handleSnapshots>false</handleSnapshots>
<url>http://scala-tools.org/repo-releases</url>
<proxyRef>SASproxy</proxyRef>
</remoteRepository>
</remoteRepositories>
My ~/.m2/settings.xml is empty and /usr/local/maven/conf/settings.xml simply
points to my Artifactory server, no other repos in the profile:
<profiles>
<profile>
<id>artifactory</id>
<activation><activeByDefault>true</activeByDefault></activation>
<repositories>
<repository>
<id>central</id>
<url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>snapshots</id>
<url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
<pluginRepository>
<id>snapshots</id>
<url>http://aclmvn.unx.sas.com:8192/artifactory/repo</url>
<releases>
<enabled>false</enabled>
</releases>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
I was able to workaround this by downloading jms-1.1.jar and putting it in our
Artifactory repo, but I think that is simply masking a problem, so this will
probably pop back up.
Perhaps the problem is at central; I don't know if it every had a jms-1.1.jar;
as I said, we did not depend on it directly, so we suspect some other
plugin now uses it that did not, or the jar was incorrectly removed
from central. But the fact that Maven downloaded the html as a jar
caused problems, because after each build failure, I had to manually
clean up my bad ~/.m2/repository
--
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
[ http://jira.codehaus.org/browse/ARCHETYPE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201597#action_201597
]
Bruce Albrecht commented on ARCHETYPE-202:
------------------------------------------
We have an internal repository that requires authentication (thank you, paranoid security
drones), and it fails to retrieve archetype-catalog.xml also.
> Can't download archetype-catalog.xml via proxy connection
> ---------------------------------------------------------
>
> Key: ARCHETYPE-202
> URL: http://jira.codehaus.org/browse/ARCHETYPE-202
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
> Affects Versions: 2.0-alpha-2
> Environment: Windows XP 2002 SP3, Maven version 2.0.9, Java 1.6.0_06, internet
connection via proxy.
> Reporter: Leonid E. Egorov
> Priority: Minor
>
> According "Your first Cocoon application using Maven 2" (http://cocoon.apache.org/2.2/1159_1_1.html)
after execution:
> mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org user should enter
into dialog about selecting archetype but nothing happen. Error message:
> D:\MySolutions\java\cocoon\demo>mvn archetype:generate -DarchetypeCatalog=http://cocoon.apache.org
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Maven Default Project
> [INFO] task-segment: [archetype:generate] (aggregator-style)
> [INFO] ------------------------------------------------------------------------
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [archetype:generate]
> [INFO] Generating project in Interactive mode
> [WARNING] Error reading archetype catalog http://cocoon.apache.org
> org.apache.maven.wagon.TransferFailedException: Error transferring file
> at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104)
> at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
> at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74)
> at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:203)
> at org.apache.maven.archetype.ui.DefaultArchetypeSelector.getArchetypesByCatalog(DefaultArchetypeSelector.java:249)
> at org.apache.maven.archetype.ui.DefaultArchetypeSelector.selectArchetype(DefaultArchetypeSelector.java:74)
> at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:180)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:227)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.net.NoRouteToHostException: No route to host: connect
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
> at java.net.Socket.connect(Socket.java:519)
> at java.net.Socket.connect(Socket.java:469)
> at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
> at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
> at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
> at sun.net.www.http.HttpClient.New(HttpClient.java:306)
> at sun.net.www.http.HttpClient.New(HttpClient.java:323)
> at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:788)
> at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:729)
> at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:654)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:977)
> at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:83)
> ... 24 more
> [INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> Choose a number: : Choose archetype:
> Choose a number: : Завершить
выполнение
пакетного
файла [Y(да)/N(нет)]?
^C
> D:\MySolutions\java\cocoon\demo>mvn --version
> Maven version: 2.0.9
> Java version: 1.6.0_06
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> D:\MySolutions\java\cocoon\demo>
> It's look like no proxy using for downloading catalog file from cocoon site.
--
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
[ http://jira.codehaus.org/browse/MENFORCER-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201596#action_201596
]
jieryn commented on MENFORCER-19:
---------------------------------
Brian, I think that is exactly what we should do. Let's utilize the code in dependency:analyze-dep-mgmt
for an enforcer rule with failBuild=true and ignoreDirect=false ;; either that or let's close
this JIRA. :-)
> Add an option to enforce dependencyManagement
> ---------------------------------------------
>
> Key: MENFORCER-19
> URL: http://jira.codehaus.org/browse/MENFORCER-19
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
> Reporter: Carlos Sanchez
>
> Add something to the dependencyManagement section like
> <enforce>true</enforce>
> to make build fail if a subproject uses a different version
> Currently a subproject can specify the version of a dependency already defined in dependencyManagement,
which is error prone
--
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
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571
]
Karl M. Davis edited comment on MRELEASE-491 at 12/7/09 10:18 AM:
------------------------------------------------------------------
This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT
parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as
invalid and refuse to build the child project.
Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1).
My guess is that this problem is caused by another library that the release plugin makes
use of-- maybe maven-model? I'm not sure, though, if it's safe to "peg" the version of that
plugin in my POM.
was (Author: karlmdavis):
This issue is particularly frustrating as it prevents me from using m2eclipse with any
non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId
element as invalid and refuse to build the child project.
Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1).
My guess is that this problem is caused by another library that the release plugin makes
use of.
> Releasing publich nodes with mergeID, but this node only for internal use and not valid
with XSD
> ------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-491
> URL: http://jira.codehaus.org/browse/MRELEASE-491
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-9
> Reporter: Hafga
> Attachments: poms.zip
>
>
> If you release a POM this plugin will add mergeId node. This node only allowed for internal
use. But this version of POM will publish to repository: http://maven.apache.org/ref/2.1.0/maven-model/maven.html
> <resources>
> <resource>
> <mergeId>resource-0</mergeId>
> <directory>src/main/resources</directory>
> </resource>
> </resources>
> <testResources>
> <testResource>
> <mergeId>resource-1</mergeId>
> <directory>src/test/resources</directory>
> </testResource>
> </testResources>
--
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
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571
]
Karl M. Davis edited comment on MRELEASE-491 at 12/7/09 10:11 AM:
------------------------------------------------------------------
This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT
parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as
invalid and refuse to build the child project.
Also, reverting back to 2.0-beta-7 does not seem to resolve this problem for me (Maven v2.2.1).
My guess is that this problem is caused by another library that the release plugin makes
use of.
was (Author: karlmdavis):
This issue is particularly frustrating as it prevents me from using m2eclipse with any
non-SNAPSHOT parent POMs I might have released. m2eclipse will flag the parent POM's mergeId
element as invalid and refuse to build the child project.
> Releasing publich nodes with mergeID, but this node only for internal use and not valid
with XSD
> ------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-491
> URL: http://jira.codehaus.org/browse/MRELEASE-491
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-9
> Reporter: Hafga
> Attachments: poms.zip
>
>
> If you release a POM this plugin will add mergeId node. This node only allowed for internal
use. But this version of POM will publish to repository: http://maven.apache.org/ref/2.1.0/maven-model/maven.html
> <resources>
> <resource>
> <mergeId>resource-0</mergeId>
> <directory>src/main/resources</directory>
> </resource>
> </resources>
> <testResources>
> <testResource>
> <mergeId>resource-1</mergeId>
> <directory>src/test/resources</directory>
> </testResource>
> </testResources>
--
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
[ http://jira.codehaus.org/browse/MRELEASE-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201571#action_201571
]
Karl M. Davis commented on MRELEASE-491:
----------------------------------------
This issue is particularly frustrating as it prevents me from using m2eclipse with any non-SNAPSHOT
parent POMs I might have released. m2eclipse will flag the parent POM's mergeId element as
invalid and refuse to build the child project.
> Releasing publich nodes with mergeID, but this node only for internal use and not valid
with XSD
> ------------------------------------------------------------------------------------------------
>
> Key: MRELEASE-491
> URL: http://jira.codehaus.org/browse/MRELEASE-491
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Affects Versions: 2.0-beta-9
> Reporter: Hafga
> Attachments: poms.zip
>
>
> If you release a POM this plugin will add mergeId node. This node only allowed for internal
use. But this version of POM will publish to repository: http://maven.apache.org/ref/2.1.0/maven-model/maven.html
> <resources>
> <resource>
> <mergeId>resource-0</mergeId>
> <directory>src/main/resources</directory>
> </resource>
> </resources>
> <testResources>
> <testResource>
> <mergeId>resource-1</mergeId>
> <directory>src/test/resources</directory>
> </testResource>
> </testResources>
--
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
[ http://jira.codehaus.org/browse/MRELEASE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201562#action_201562
]
Youri De Bondt edited comment on MRELEASE-3 at 12/7/09 9:43 AM:
----------------------------------------------------------------
-DpreparationGoals="clean install" doesn't work for me.
I have to perform a clean install first, then release:prepare (which will check if the modules
are installed, and also runs clean install)
was (Author: ydbondt):
-DpreparationGoals="clean install" doesn't work for me.
I have to perform a clean install first, then release:prepare which will check if the modules
are installed, and finaly perform the clean install again.
> release:prepare should not require multimodule artifacts to be in the local repository
> --------------------------------------------------------------------------------------
>
> Key: MRELEASE-3
> URL: http://jira.codehaus.org/browse/MRELEASE-3
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Reporter: John Casey
> Fix For: Future
>
>
> Currently, if you try to run release:prepare on a multimodule project after removing
any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare
needs the multimodule artifacts installed in the local repository before it can succeed.
> To reproduce, comment the following line in it2002/test.sh:
> mvn clean install
> NOTE: This may have to do with the version resolution code, which is used to resolve
SNAPSHOT versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.codehaus.org/browse/MRELEASE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201562#action_201562
]
Youri De Bondt commented on MRELEASE-3:
---------------------------------------
-DpreparationGoals="clean install" doesn't work for me.
I have to perform a clean install first, then release:prepare which will check if the modules
are installed, and finaly perform the clean install again.
> release:prepare should not require multimodule artifacts to be in the local repository
> --------------------------------------------------------------------------------------
>
> Key: MRELEASE-3
> URL: http://jira.codehaus.org/browse/MRELEASE-3
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Reporter: John Casey
> Fix For: Future
>
>
> Currently, if you try to run release:prepare on a multimodule project after removing
any of that build's artifacts from the local repository, it will fail. Investigate why release:prepare
needs the multimodule artifacts installed in the local repository before it can succeed.
> To reproduce, comment the following line in it2002/test.sh:
> mvn clean install
> NOTE: This may have to do with the version resolution code, which is used to resolve
SNAPSHOT versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201551#action_201551
]
Tamás Cservenák commented on MNG-4368:
--------------------------------------
This is _completely wrong_, and makes Maven3 very cumbersome (if not completely broken) to
work on branches, especially with regarding POMs. What happens:
Check out a trunk of your project (let's suppose all files are modified today T0):
* svn checkout
* mvn clean install
Then, tomorrow T1 do a branch of your project, and _modify_ for example the POM of your project
in branch.
* svn branch it
* mvn clean install
Then, next day T2, return to trunk and continue work (but for example's sake, do _not_ modify
the POM you changed in branch).
* svn switch back to trunk
* mvn clean instal
Obviously T0 < T1 < T2
But, the change done in T1 will be _*not replaceable*_ by the 2nd trunk build (mvn clean install
in T2 will *NOT* replace the pom in local repo), and potentionally will result in very spurious
errors (ie. in branch you remove/add deps, change parent, etc).
Please, undo this! Thanks.
Interestingly, this will fit nicely with Git (git will "touch" the file when switching back
from branch to "master")
http://git.or.cz/gitwiki/GitSvnComparsion
http://git.or.cz/gitwiki/GitFaq#Whyisn.27tGitpreservingmodificationtimeonfiles.3F
But in general, on "install" goal Maven should install the files I told it to install.
> DefaultArtifactInstaller should only overwrite files if timestamp has changed
> -----------------------------------------------------------------------------
>
> Key: MNG-4368
> URL: http://jira.codehaus.org/browse/MNG-4368
> Project: Maven 2
> Issue Type: Improvement
> Environment: Linux, JDK 1.5
> Reporter: Johannes Martin
> Fix For: 2.2.2, 3.0-alpha-3
>
>
> install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller
to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby
overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller
used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build
process.
--
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
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed DOXIASITETOOLS-32.
-----------------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.1.2
Assignee: Vincent Siveton
need to sync
> Deployed decoration-1.0.1.xsd
> -----------------------------
>
> Key: DOXIASITETOOLS-32
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-32
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
> Affects Versions: 1.1.2
> Reporter: Vincent Siveton
> Assignee: Vincent Siveton
> Fix For: 1.1.2
>
>
> Due to DOXIASITETOOLS-31, we need to deployed a new version of decoration-1.0.1.xsd
--
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
[ http://jira.codehaus.org/browse/ARCHETYPE-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201522#action_201522
]
Stephan Behnke commented on ARCHETYPE-58:
-----------------------------------------
I can't quite follow - is this feature now implemented or not? If yes, what's the final syntax?
> Allows for additional properties in velocity context and also conditional processing
of source, resources etc
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARCHETYPE-58
> URL: http://jira.codehaus.org/browse/ARCHETYPE-58
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Generator
> Affects Versions: 1.0-alpha-4
> Reporter: Philip Dodds
> Fix For: 2.0-alpha-1
>
> Attachments: ARCHETYPE-58-a-slightly-different-kind-of-patch, properties_and_conditions.patch
>
>
> Need the ability to add new properties to the velocity context during the processing
of an archetype through archetype-core.
> Also need the ability to determine whether to optionally include a resource, source etc
based on a conditional test on a property.
> Consider for example adding properties and optional tests as follows:
> <archetype>
> <id>servicemix-se</id>
> <sources>
> <conditional>
> <source>src/main/java/MyBootstrap.java</source>
> <propertyEqual property="generateBootstrap" value="true"/>
> </conditional>
> <source>src/main/java/MyComponent.java</source>
> <source>src/main/java/MyEndpoint.java</source>
> </sources>
> <testSources>
> <source>src/test/java/MySpringComponentTest.java</source>
> </testSources>
> <testResources>
> <resource>src/test/resources/spring.xml</resource>
> <resource>src/test/resources/log4j.properties</resource>
> </testResources>
> <contextProperties>
> <property name="pluginRepositoryId" value="apache.snapshots"/>
> <property name="pluginRepositoryName" value="Maven Central Plugins Development
Repository"/>
> <property name="pluginRepositoryUrl" value="http://cvs.apache.org/maven-snapshot-repository"/>
> <property name="pluginRepositorySnapshotsEnabled" value="true"/>
> <property name="pluginRepositoryReleasesEnabled" value="true"/>
> <property name="generateBootstrap" value="false"/>
> </contextProperties>
> </archetype>
> The example above shows that we want to be able to gather additional properties and then
in the sources conditionally determine whether we want to include it.
> I will attach a patch that already implements the contextProperties as shown above and
has 80% of the code in place for the conditional inclusion of files.
--
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
[ http://jira.codehaus.org/browse/MASSEMBLY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201515#action_201515
]
Benjamin Bentmann commented on MASSEMBLY-416:
---------------------------------------------
Grzegorz, regarding your last comment, please fill this as a new issue.
> outputDirectory default value in fileSet seems changed; now seems to use directory name
of fileSet sourcedir
> ------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-416
> URL: http://jira.codehaus.org/browse/MASSEMBLY-416
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.2-beta-5
>
> Attachments: massembly-416-1.0-SNAPSHOT-jar-with-dependencies.jar, massembly-416-2.jar,
massembly-416-jar-listing.txt, massembly-416.zip
>
>
> From Grzegorz Slowikowski on the dev@maven mailing list ([VOTE] maven-assembly-plugin
2.2-beta-4 thread):
> {noformat}
> Hi
> With this configuration:
> <pluginRepositories>
> <pluginRepository>
> <id>maven-staging-031</id>
> <name>maven-staging-031</name>
> <url>https://repository.apache.org/content/repositories/maven-staging-031</url>
> </pluginRepository>
> </pluginRepositories>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.2-beta-4</version>
> <configuration>
> <descriptorRefs>
> <descriptorRef>jar-with-dependencies</descriptorRef>
> </descriptorRefs>
> </configuration>
> <executions>
> <execution>
> <id>make-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> I have "target" folder/package inside jar-with-dependencies archive which contains copies
of my project classes (they are in the normal
> package structure within this archive too).
> ...
> {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
[ http://jira.codehaus.org/browse/MASSEMBLY-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201500#action_201500
]
Grzegorz Slowikowski commented on MASSEMBLY-416:
------------------------------------------------
In version 2.2-beta-5 from staging repo:
https://repository.apache.org/content/repositories/maven-041/
class files are not duplicated anymore, but there is one minor difference between this version
and 2.2-beta-4 - not files from "META-INF/maven/" package (pom.xml, pom.properties) of the
current artifact are missing in the assembly jar, there are only such files from dependencies.
This is probably side effect of "<useProjectArtifact>false</useProjectArtifact>"
line added to the tamplate.
> outputDirectory default value in fileSet seems changed; now seems to use directory name
of fileSet sourcedir
> ------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-416
> URL: http://jira.codehaus.org/browse/MASSEMBLY-416
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-3
> Reporter: John Casey
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.2-beta-5
>
> Attachments: massembly-416-1.0-SNAPSHOT-jar-with-dependencies.jar, massembly-416-2.jar,
massembly-416-jar-listing.txt, massembly-416.zip
>
>
> From Grzegorz Slowikowski on the dev@maven mailing list ([VOTE] maven-assembly-plugin
2.2-beta-4 thread):
> {noformat}
> Hi
> With this configuration:
> <pluginRepositories>
> <pluginRepository>
> <id>maven-staging-031</id>
> <name>maven-staging-031</name>
> <url>https://repository.apache.org/content/repositories/maven-staging-031</url>
> </pluginRepository>
> </pluginRepositories>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.2-beta-4</version>
> <configuration>
> <descriptorRefs>
> <descriptorRef>jar-with-dependencies</descriptorRef>
> </descriptorRefs>
> </configuration>
> <executions>
> <execution>
> <id>make-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> I have "target" folder/package inside jar-with-dependencies archive which contains copies
of my project classes (they are in the normal
> package structure within this archive too).
> ...
> {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
[ http://jira.codehaus.org/browse/MPH-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201498#action_201498
]
Keith David Winkler commented on MPH-53:
----------------------------------------
Still happens in version 2.2.1
Effective pom specifies resources plugin 2.3
"mvn help:describe -Dplugin=resources" downloads and lists help for version 2.4.1
In any case this FAQ entry seems wrong: http://maven.apache.org/general.html#plugin-version
> mvn help:describe returns the version that is specified in metadata instead of the one
in the parent pom
> ---------------------------------------------------------------------------------------------------------
>
> Key: MPH-53
> URL: http://jira.codehaus.org/browse/MPH-53
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
> Affects Versions: 2.0.1
> Environment: windows xp
> tested with mvn 2.0.8 & 2.0.9
> Reporter: Rintcius Blok
>
> mvn help:describe returns a different version than mvn help:effective-pom returns:
> > mvn help:describe -Dplugin=surefire
> ...
> [INFO] [help:describe]
> [INFO] Plugin: 'org.apache.maven.plugins:maven-surefire-plugin:2.2'
> -----------------------------------------------
> Group Id: org.apache.maven.plugins
> Artifact Id: maven-surefire-plugin
> Version: 2.2
> Goal Prefix: surefire
> However, when I run:
> > mvn help:effective-pom
> I get
> ...
> <pluginManagement>
> <plugins>
> <plugin>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.4.3</version>
> <configuration>
> <testFailureIgnore>true</testFailureIgnore>
> <includes>
> <include>**/*Test.java</include>
> </includes>
> <format>html</format>
> </configuration>
> </plugin>
> </plugins>
> </pluginManagement>
> ...
> My pom structure is quite simple: just a parent pom.xml with the pluginmanagement section
as above and a child pom using that. I have tested with both maven 2.0.8 and 2.0.9.
> See the discussion here: http://www.nabble.com/Wrong-output-of-mvn-help%3Adescribe--td19168212.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
Informational messages could be clearer regarding goal execution
----------------------------------------------------------------
Key: MNG-4485
URL: http://jira.codehaus.org/browse/MNG-4485
Project: Maven 2
Issue Type: Improvement
Components: Errors
Affects Versions: 3.0-alpha-5
Reporter: Paul Benedict
Priority: Trivial
As the lifecycle of projects are executed, these type of informational messages are emitted:
{{[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ project-name ---}}
Based on my own team, I think there are three things to note:
* The {{plugin:version::goal}} can easily be confused with the the dependency {{artifactId:version:classifier}}
format. Seriously. ;-)
* I don't think the @ symbol is natural to describe the project.
* The execution name probably could be suppressed unless DEBUG was on.
How about?
{{[INFO] --- maven-clean-plugin:2.3 executing goal "clean" for project Project Name ---}}
--
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
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated DOXIASITETOOLS-32:
------------------------------------------
Fix Version/s: (was: 1.1.2)
1.2
> Deployed decoration-1.0.1.xsd
> -----------------------------
>
> Key: DOXIASITETOOLS-32
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-32
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
> Affects Versions: 1.1.2
> Reporter: Vincent Siveton
> Fix For: 1.2
>
>
> Due to DOXIASITETOOLS-31, we need to deployed a new version of decoration-1.0.1.xsd
--
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
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4479.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0-alpha-2
The problem is related to interpolation. As such a workaround is to use a constant value for
the group-/artifactId of the plugin, i.e. your test project passes if you replace {{<groupId>${project.groupId}</groupId>}}
with {{<groupId>mavenbugs</groupId>}} in the plugin declaration.
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin
key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> I have a plugin that makes use of the implementation attribute in its configuration.
That is, one of its parameters is a plexus tag that specifies an implementation class to
use.
> The implementation class comes from a jar that is the plugin's dependency, but that dependency
is included as part of the plugin configuration, not as part of the stock plugin.
> This setup works fine when I bind the plugin's configuration via an execution to a normal
phase (generate-sources as it happens).
> When I bind the plugin's configuration to the default-cli execution, plexus cannot configure
the component, claiming that the classname it encounters in the "implementation" attribute
cannot be found (even though, again, if I bind it to the generate-sources phase instead, via
another execution, same configuration, everything works fine.
> I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw
take is that it looks like dependency resolution in the default-cli execution is somehow performed
differently than when the plugin is run bound to a phase.
--
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
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4479:
-----------------------------------
Affects Version/s: 2.1.0-M1
2.1.0
2.2.0
Assignee: Benjamin Bentmann
Summary: [regression] Project-level plugin dependencies ignored for direct CLI
invocation if plugin key uses properties (was: Dependency resolution for plugins with default-cli
execution happens too late)
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin
key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Attachments: mng-4479.zip
>
>
> I have a plugin that makes use of the implementation attribute in its configuration.
That is, one of its parameters is a plexus tag that specifies an implementation class to
use.
> The implementation class comes from a jar that is the plugin's dependency, but that dependency
is included as part of the plugin configuration, not as part of the stock plugin.
> This setup works fine when I bind the plugin's configuration via an execution to a normal
phase (generate-sources as it happens).
> When I bind the plugin's configuration to the default-cli execution, plexus cannot configure
the component, claiming that the classname it encounters in the "implementation" attribute
cannot be found (even though, again, if I bind it to the generate-sources phase instead, via
another execution, same configuration, everything works fine.
> I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw
take is that it looks like dependency resolution in the default-cli execution is somehow performed
differently than when the plugin is run bound to a phase.
--
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
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201467#action_201467
]
Paul Benedict commented on MNG-3472:
------------------------------------
I do not think this is Maven's responsibility in the slightest. Rather, it should be the responsibility
of CI tools like Hudson or Continuum to clear out older contents; I would make an RFE over
at those projects. As a last resort, you have help from your operating system: disk quotas
and custom batch processes.
> configuration possibilities to limit size of local repository
> -------------------------------------------------------------
>
> Key: MNG-3472
> URL: http://jira.codehaus.org/browse/MNG-3472
> Project: Maven 2
> Issue Type: Improvement
> Components: Settings
> Affects Versions: 2.0.8
> Reporter: manuel aldana
>
> it would be great to make repository-size configurable, for instance by setting the maximum
number of downloads of a snapshot-version to be kept. thus the explosion of local repository
size can be reduced.
> especially when you are working with many in-house multi-module projects which are marked
as snapshots before released , can increase repository size significantly.
> see mailing-list discussion: http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.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
[ http://jira.codehaus.org/browse/MECLIPSE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MECLIPSE-625.
--------------------------------------
Resolution: Not A Bug
Assignee: Benjamin Bentmann
As written in [the description of this JIRA project|http://jira.codehaus.org/browse/MECLIPSE],
this is about {{mvn eclipse:eclipse}}, not M2Eclipse. For issues with M2E, please fill them
at https://issues.sonatype.org/browse/MNGECLIPSE.
> ClassNotFoundException when running junit test ("Run As"|"Junit Test")
> ----------------------------------------------------------------------
>
> Key: MECLIPSE-625
> URL: http://jira.codehaus.org/browse/MECLIPSE-625
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Environment: Linux x86_64, Eclipse 3.5, M2Eclipse pluing 0.9.9.200911171109
> Reporter: Peter De Maeyer
> Assignee: Benjamin Bentmann
> Priority: Blocker
>
> I have a project module A which depends on another project module B.
> When I try to run a JUnit test ("Run As"|"Junit Test") in project A, I get a ClassNotFoundException
for the all classes that are in project B.
> At compile time it finds the dependencies in project module B, but not at runtime???
> I've found another report of the same problem here:
> http://blog.andrewbeacock.com/2008/11/classnotfoundexception-when-running.html
> The stack trace looks like this:
> ---
> java.lang.NoClassDefFoundError: org/de/maeyer/search/MatcherTest
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:632)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClass(RemoteTestRunner.java:693)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClasses(RemoteTestRunner.java:429)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.ClassNotFoundException: org.de.maeyer.search.MatcherTest
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
> ... 17 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.codehaus.org/browse/MASSEMBLY-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MASSEMBLY-456.
---------------------------------------
Resolution: Fixed
Fix Version/s: 2.2-beta-5
Assignee: Benjamin Bentmann
Fixed in [r887709|http://svn.apache.org/viewvc?view=revision&revision=887709].
> Usage of archiver or container descriptor handler configuration crashes with LinkageError
on Maven 3.0-alpha-5
> --------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-456
> URL: http://jira.codehaus.org/browse/MASSEMBLY-456
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-4
> Reporter: Benjamin Bentmann
> Assignee: Benjamin Bentmann
> Fix For: 2.2-beta-5
>
>
> Due to the refactored ClassWorlds used in Maven 3.x, the methods
> - PlexusContainer.getContainerRealm()
> - ComponentConfiguration.configureComponent()
> have different return/parameter types in Maven 3, causing a linkage error at runtime
for something like
> {code:xml}
> <plugin>
> <artifactId>maven-assembly-plugin</artifactId>
> <configuration>
> <archiverConfig>
> <duplicateBehavior>skip</duplicateBehavior>
> </archiverConfig>
> </configuration>
> </plugin>
> {code}
--
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
ClassNotFoundException when running junit test ("Run As"|"Junit Test")
----------------------------------------------------------------------
Key: MECLIPSE-625
URL: http://jira.codehaus.org/browse/MECLIPSE-625
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Environment: Linux x86_64, Eclipse 3.5, M2Eclipse pluing 0.9.9.200911171109
Reporter: Peter De Maeyer
Priority: Blocker
I have a project module A which depends on another project module B.
When I try to run a JUnit test ("Run As"|"Junit Test") in project A, I get a ClassNotFoundException
for the all classes that are in project B.
At compile time it finds the dependencies in project module B, but not at runtime???
I've found another report of the same problem here:
http://blog.andrewbeacock.com/2008/11/classnotfoundexception-when-running.html
The stack trace looks like this:
---
java.lang.NoClassDefFoundError: org/de/maeyer/search/MatcherTest
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:632)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClass(RemoteTestRunner.java:693)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClasses(RemoteTestRunner.java:429)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.ClassNotFoundException: org.de.maeyer.search.MatcherTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
... 17 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.codehaus.org/browse/MASSEMBLY-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MASSEMBLY-456:
----------------------------------------
Description:
Due to the refactored ClassWorlds used in Maven 3.x, the methods
- PlexusContainer.getContainerRealm()
- ComponentConfiguration.configureComponent()
have different return/parameter types in Maven 3, causing a linkage error at runtime for something
like
{code:xml}
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<archiverConfig>
<duplicateBehavior>skip</duplicateBehavior>
</archiverConfig>
</configuration>
</plugin>
{code}
was:
Due to the refactored ClassWorlds used in Maven 3.x, the methods
- PlexusContainer.getContainerRealm()
- ComponentConfiguration.configureComponent()
have different return/parameter types in Maven 3, causing a linkage error at runtime.
> Usage of archiver or container descriptor handler configuration crashes with LinkageError
on Maven 3.0-alpha-5
> --------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-456
> URL: http://jira.codehaus.org/browse/MASSEMBLY-456
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-4
> Reporter: Benjamin Bentmann
>
> Due to the refactored ClassWorlds used in Maven 3.x, the methods
> - PlexusContainer.getContainerRealm()
> - ComponentConfiguration.configureComponent()
> have different return/parameter types in Maven 3, causing a linkage error at runtime
for something like
> {code:xml}
> <plugin>
> <artifactId>maven-assembly-plugin</artifactId>
> <configuration>
> <archiverConfig>
> <duplicateBehavior>skip</duplicateBehavior>
> </archiverConfig>
> </configuration>
> </plugin>
> {code}
--
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