[jira] Updated: (MNG-3375) Repository entries with same id are ignored
[ http://jira.codehaus.org/browse/MNG-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torben S. Giesselmann updated MNG-3375: --- Attachment: MNG-3375-IT.tar.gz Here's an IT to test the patch -- instead of a unit test. :D Repository entries with same id are ignored --- Key: MNG-3375 URL: http://jira.codehaus.org/browse/MNG-3375 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Carlos Sanchez Priority: Critical Fix For: 2.0.11 Attachments: MNG-3375-IT.tar.gz, MNG-3375-maven-project.patch If two repository entries have the same id one of them is ignored with no warning or error. IIRC this worked with previous versions of maven, giving the same id allowed you to share the configuration in the settings.xml file (it may have been for deployment only though) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3641) Lack of error checks on profiles
[
http://jira.codehaus.org/browse/MNG-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3641:
---
Attachment: MNG-3641-IT.tar.gz
... and here's the IT. Yay! ;-)
Lack of error checks on profiles
Key: MNG-3641
URL: http://jira.codehaus.org/browse/MNG-3641
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.9
Reporter: Kohsuke Kawaguchi
Fix For: 2.0.11
Attachments: MNG-3641-IT.tar.gz, MNG-3641-maven-project.patch
DefaultProfileManager performs no error checks on the profile IDs So If I
specify bogus profile IDs from plugins (like {{mvn -P no-such-profile}}),
Maven doesn't complain, and it just runs as if nothing was specified. This is
very error prone.
Also, I've seen some documentation that says deactivating a profile is -P
!profile. As far as I can tell from the code, this is wrong, but because of
the lack of error check, such usage just gets ignored, and the user is left
confused as to why the profile isn't deactivated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2387) active on proxy in settings is misleading
[ http://jira.codehaus.org/browse/MNG-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=167029#action_167029 ] Torben S. Giesselmann commented on MNG-2387: Yup, I'll do that next time. Actually I just submitted my very first IT (see MNG-3641): kudos to Benjamin for teaching me the tricks of the trade! So ... no more excuses for me! ;-) active on proxy in settings is misleading - Key: MNG-2387 URL: http://jira.codehaus.org/browse/MNG-2387 Project: Maven 2 Issue Type: Task Components: Settings Reporter: Brett Porter Assignee: Brett Porter Fix For: 2.0.11, 2.1.0 Attachments: MNG-2387-maven-settings.patch see: http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/%3c84fb18c70510171532v1d655221n36b66fb10a018...@mail.gmail.com%3e -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3641) Lack of error checks on profiles
[
http://jira.codehaus.org/browse/MNG-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3641:
---
Attachment: MNG-3641-maven-project.patch
This patch will have Maven print a warning if a profile which should have been
explicitely activated has in fact not been activated.
It's just a warning message, therefore I didn't write a test case. But just out
of curiosity: how _would_ I test whether a warning with a specific message was
logged or not? Is there a pattern for that?
Lack of error checks on profiles
Key: MNG-3641
URL: http://jira.codehaus.org/browse/MNG-3641
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.9
Reporter: Kohsuke Kawaguchi
Fix For: 2.0.11
Attachments: MNG-3641-maven-project.patch
DefaultProfileManager performs no error checks on the profile IDs So If I
specify bogus profile IDs from plugins (like {{mvn -P no-such-profile}}),
Maven doesn't complain, and it just runs as if nothing was specified. This is
very error prone.
Also, I've seen some documentation that says deactivating a profile is -P
!profile. As far as I can tell from the code, this is wrong, but because of
the lack of error check, such usage just gets ignored, and the user is left
confused as to why the profile isn't deactivated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3890) Transitive dependencies override explicitly set scope.
[
http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164457#action_164457
]
Torben S. Giesselmann commented on MNG-3890:
The problem seems to be that artifacts of {{provided}} scope are excluded from
dependency resolution right from the start. Here's the code in
{{DefaultArtifactFactory}}:
{code}
private Artifact createArtifact( String groupId, String artifactId,
VersionRange versionRange, String type,
String classifier, String scope, String
inheritedScope, boolean optional )
{
// TODO: can refactor - inherited scope calculation belongs in the
collector, use scope handler
String desiredScope = Artifact.SCOPE_RUNTIME;
if ( inheritedScope == null )
{
desiredScope = scope;
}
else if ( Artifact.SCOPE_TEST.equals( scope ) ||
Artifact.SCOPE_PROVIDED.equals( scope ) )
{
return null;
}
...
}
{code}
If the {{provided}} dependencies don't show up, then there's no way telling
what must finally be excluded from the dependency tree. The
{{DefaultArtifactCollector}} does everything right in recursively drilling down
to {{test -- c -- b -- a}} and adding all dependencies it finds.
However, after all children of a {{ResolutionNode}} have been processed, all
dependencies of scope {{runtime}} or {{provided}} should be removed from the
list of resolved artifacts. Or at least be added to some sort of exclusion
filter.
Transitive dependencies override explicitly set scope.
--
Key: MNG-3890
URL: http://jira.codehaus.org/browse/MNG-3890
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Stephan Kleine
Priority: Critical
Fix For: 2.0.11
Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2
Transitive dependencies override explicitly set scope.
E.g. a project A depends on Hibernate with default scope and a project B
depends on project A as well as on Hibernate for which it sets the scope
explicitly to provided. Further an EAR project C depends on project B (see
the attached testcase).
Now I would expect that C does not contain any jars for Hibernate and its
dependencies since B explicitly set the scope to provided. Sadly this is
not the case and C contains all hibernate jars. The only way around this I
have found is setting the scope to provided for Hibernate in A as well -
which is just a crude hack that produces other issues.
IMHO this is a bug because Maven should respect the overridden dependency
scope since the current way forces me to set the scope to provided in A which
is just wrong.
Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3890) Transitive dependencies override explicitly set scope.
[
http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3890:
---
Attachment: MMG-3890-core-it-suite.patch
The IT's POM can't be validated because it contains {{}} within a
comment. The patch replaces dashes with {{}} and the IT will run.
Transitive dependencies override explicitly set scope.
--
Key: MNG-3890
URL: http://jira.codehaus.org/browse/MNG-3890
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
Reporter: Stephan Kleine
Priority: Critical
Fix For: 2.0.11
Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2
Transitive dependencies override explicitly set scope.
E.g. a project A depends on Hibernate with default scope and a project B
depends on project A as well as on Hibernate for which it sets the scope
explicitly to provided. Further an EAR project C depends on project B (see
the attached testcase).
Now I would expect that C does not contain any jars for Hibernate and its
dependencies since B explicitly set the scope to provided. Sadly this is
not the case and C contains all hibernate jars. The only way around this I
have found is setting the scope to provided for Hibernate in A as well -
which is just a crude hack that produces other issues.
IMHO this is a bug because Maven should respect the overridden dependency
scope since the current way forces me to set the scope to provided in A which
is just wrong.
Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164239#action_164239
]
Torben S. Giesselmann commented on MNG-3719:
Exactly, the problem came from from merging multiple plugin declarations into
one. I still think the docs should be updated, though.
[regression] plugin execution ordering no longer POM ordered in 2.0.9
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
Environment: Maven 2.0.9, java version 1.5.0_13 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Assignee: Brett Porter
Priority: Critical
Fix For: 2.0.11, 2.1.0-M2
Attachments: MNG-3719-maven-project.patch,
plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this,
but so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are
not executed sequentially and there is no way to indicate dependencies, as
would be expected (note- I'm not expecting that it interpret the step 1...,
..., step 5... IDs, I'm only suggesting that either the plugins be executed
in order that they are found in the XML (most intuitive) or that there be
some concept of priority/ordinal added, or even perhaps (this would be most
ant-like) that plugin executions (and maybe even plugin goal executions) be
allowed to define prequisite execution IDs to be run (even if they are IDs
not defined in the pom, but maybe a parent pom, even though I don't need that
right now).
I know that this could be problematic if a plugin execution from one
lifecycle phase depends on another from another lifecycle phase (and you
could get into circular references that way that would have to be recognized
during pom validation after loading/merging pom.xmls). However, not being
able to at the very least define order of execution of different (or the
same) plugin executions as noted below and in attached project makes it
difficult to chain plugin executions that depend on each other, thereby
reducing the practicality of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven
2.0.9, since there appears to be no way to indicate dependencies of one
execution on another:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
!-- backup original source web.xml in preparation for
chaining of plugin modifications to it --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idstep 1 - backup-original-web.xml-from-src/id
phasegenerate-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=${pom.basedir}/target/
mkdir dir=${pom.basedir}/target/tmpwebxml/
copy
file=${pom.basedir}/src/main/webapp/WEB-INF/web.xml
todir=${pom.basedir}/target/tmpwebxml//
/tasks
/configuration
/execution
/executions
/plugin
plugin
!-- this plugin converts to
${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml --
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idstep 2 - jspc/id
phasegenerate-resources/phase
goals
goalcompile/goal
/goals
/execution
/executions
[jira] Updated: (MNG-3375) Repository entries with same id are ignored
[
http://jira.codehaus.org/browse/MNG-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3375:
---
Attachment: MNG-3375-maven-project.patch
With this patch, Maven will throw an {{InvalidRepositoryException}} if a
repository's ID is not unique and the build will fail. I opted for the build to
fail (instead of just issuing a warning) because running a build against a
completely different repository can be a source of unnecessary build problems.
A simple warning could easily be missed.
Repository entries with same id are ignored
---
Key: MNG-3375
URL: http://jira.codehaus.org/browse/MNG-3375
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Carlos Sanchez
Priority: Critical
Fix For: 2.0.11
Attachments: MNG-3375-maven-project.patch
If two repository entries have the same id one of them is ignored with no
warning or error.
IIRC this worked with previous versions of maven, giving the same id allowed
you to share the configuration in the settings.xml file (it may have been for
deployment only though)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3375) Repository entries with same id are ignored
[
http://jira.codehaus.org/browse/MNG-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164131#action_164131
]
Torben S. Giesselmann commented on MNG-3375:
BTW: I didn't really manage to write a test, because testing the function
involved would require a fully configured / working {{PlexusContainer}} and,
quite frankly, I ran into some problems. ;-) Someone more experienced than me
should be able to construct a working test. Here's what my current test would
look like, maybe someone can make some use of it:
{code}
public void testShouldNotAllowDuplicateRepositoryIds()
{
Repository repo1 = new Repository();
repo1.setId( first );
repo1.setUrl(non-empty-url);
repo1.setLayout(default);
Repository repo2 = new Repository();
repo2.setId( second );
repo2.setUrl(non-empty-url);
repo2.setLayout(default);
Repository dupeRepo = new Repository();
dupeRepo.setId( second );
dupeRepo.setUrl(non-empty-url);
dupeRepo.setLayout(default);
List repoList = new ArrayList();
repoList.add(repo1);
repoList.add(repo2);
DefaultPlexusContainer container = null;
try
{
// TODO: initialize a working PlexusContainer ...
// String basedir = System.getProperty( basedir );
// InputStream configurationStream =
this.getClass().getClassLoader().getResourceAsStream( PlexusContainerTest.xml
);
// container = new DefaultPlexusContainer();
// container.addContextValue( basedir, basedir );
// container.addContextValue( plexus.home, basedir +
/target/plexus-home );
// container.setConfigurationResource( ReaderFactory.newXmlReader(
configurationStream ) );
// container.initialize();
// container.start();
ProjectUtils.buildArtifactRepositories( repoList, new
DefaultArtifactRepositoryFactory(), container );
}
catch ( InvalidRepositoryException e )
{
fail( e.getMessage() );
}
// MNG-3375: exception should be thrown if two repository IDs
are equal
repoList.add(dupeRepo);
try
{
ProjectUtils.buildArtifactRepositories( repoList, new
DefaultArtifactRepositoryFactory(), container );
fail();
}
catch ( InvalidRepositoryException e ) {
// exception should be thrown
}
}
{code}
Repository entries with same id are ignored
---
Key: MNG-3375
URL: http://jira.codehaus.org/browse/MNG-3375
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Carlos Sanchez
Priority: Critical
Fix For: 2.0.11
Attachments: MNG-3375-maven-project.patch
If two repository entries have the same id one of them is ignored with no
warning or error.
IIRC this worked with previous versions of maven, giving the same id allowed
you to share the configuration in the settings.xml file (it may have been for
deployment only though)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2845) Unwanted creation of repository directories
[
http://jira.codehaus.org/browse/MNG-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=164152#action_164152
]
Torben S. Giesselmann commented on MNG-2845:
I can't reproduce the issue, neither with 2.0.9 nor 2.0.11-SNAPSHOT.
Here's my environment:
{quote}
$ mvn -v
Maven version: 2.0.9
Java version: 1.5.0_16
OS name: mac os x version: 10.5.6 arch: i386 Family: unix
{quote}
Eclipse plugin used: {{maven-eclipse-plugin-2.5.1}}
Here's what I added to the pom:
{code}
repositories
repository
idlocalrepo/id
namelocal module directory/name
urlfile://lib/url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
/snapshots
/repository
/repositories
{code}
Could this be environment-specific? Could you provide a sample project showing
the effect?
Unwanted creation of repository directories
---
Key: MNG-2845
URL: http://jira.codehaus.org/browse/MNG-2845
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.5
Environment: Windows XP, JDK 1.4
Reporter: Holger Hoffstätte
Fix For: 2.0.11
My pom contain a convenience repo:
repository
idlocal (Maven 1)/id
nameLocal module repository (lib)/name
urlfile://lib/url
..etc..
Running mvn eclipse:eclipse with maven 2.0.5 will create that directory in
the filesystem; maven 2.0.4 will not. IMHO creating directories without
explicit instruction is a no-no.
Discussion:
http://www.nabble.com/New-%22feature%22-in-2.0.5%3A-maven-creates-repo-directories-%21-tf3261881s177.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163906#action_163906
]
Torben S. Giesselmann commented on MNG-3719:
Since the patch won't make it into 2.0.10, the documentation at
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
should be updated in the meantime. To avoid any confusion, it should be
mentioned that there's a problem. Or remove the comment altogether or change it
to As of 2.0.11.
[regression] plugin execution ordering no longer POM ordered in 2.0.9
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
Environment: Maven 2.0.9, java version 1.5.0_13 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Priority: Critical
Fix For: 2.0.11, 2.1.0-M2
Attachments: MNG-3719-maven-project.patch,
plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this,
but so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are
not executed sequentially and there is no way to indicate dependencies, as
would be expected (note- I'm not expecting that it interpret the step 1...,
..., step 5... IDs, I'm only suggesting that either the plugins be executed
in order that they are found in the XML (most intuitive) or that there be
some concept of priority/ordinal added, or even perhaps (this would be most
ant-like) that plugin executions (and maybe even plugin goal executions) be
allowed to define prequisite execution IDs to be run (even if they are IDs
not defined in the pom, but maybe a parent pom, even though I don't need that
right now).
I know that this could be problematic if a plugin execution from one
lifecycle phase depends on another from another lifecycle phase (and you
could get into circular references that way that would have to be recognized
during pom validation after loading/merging pom.xmls). However, not being
able to at the very least define order of execution of different (or the
same) plugin executions as noted below and in attached project makes it
difficult to chain plugin executions that depend on each other, thereby
reducing the practicality of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven
2.0.9, since there appears to be no way to indicate dependencies of one
execution on another:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
!-- backup original source web.xml in preparation for
chaining of plugin modifications to it --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idstep 1 - backup-original-web.xml-from-src/id
phasegenerate-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=${pom.basedir}/target/
mkdir dir=${pom.basedir}/target/tmpwebxml/
copy
file=${pom.basedir}/src/main/webapp/WEB-INF/web.xml
todir=${pom.basedir}/target/tmpwebxml//
/tasks
/configuration
/execution
/executions
/plugin
plugin
!-- this plugin converts to
${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml --
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idstep 2 - jspc/id
phasegenerate-resources/phase
goals
[jira] Commented: (MNG-3685) Dependency can't be resolved but has been found in the reactor.
[ http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163598#action_163598 ] Torben S. Giesselmann commented on MNG-3685: Could someone provide a sample project? Dependency can't be resolved but has been found in the reactor. --- Key: MNG-3685 URL: http://jira.codehaus.org/browse/MNG-3685 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Jörg Hohwiller Fix For: 2.0.11 Since I upgraded maven to 2.0.9, I get messages like the following endlessly: Downloading: http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't be resolved but has been found in the reactor. This dependency has been excluded from the plugin execution. You should rerun this mojo after executing mvn install. This also happens, if someone checks out the project and does mvn eclipse:eclipse. The process still works but takes extraordinary long to proceed because it scales about n^2 with n beiing the number of modules in your reactor. You should also take into account that mvn install aborts if some tests fail. Sorry to say so, but this behaviour of maven is absolutely inacceptable. I hope there is a chance to fix this in the next release(s). Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2626) System scope dependencies in parent POM cause validation warnings for most plugins and errors in assembly plugin
[
http://jira.codehaus.org/browse/MNG-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163392#action_163392
]
Torben S. Giesselmann commented on MNG-2626:
Has this been fixed? I can't reproduce the problem; works perfectly with
2.0.11-SNAPSHOT.
System scope dependencies in parent POM cause validation warnings for most
plugins and errors in assembly plugin
Key: MNG-2626
URL: http://jira.codehaus.org/browse/MNG-2626
Project: Maven 2
Issue Type: Bug
Components: Errors
Affects Versions: 2.0-alpha-1
Reporter: Brian Topping
Assignee: Jason van Zyl
Priority: Blocker
Fix For: 2.0.11
Attachments: interpolation-good.patch, interpolation.patch,
MNG-2626it.tgz
When system scope dependencies are in a parent POM and the systemPath for
those variables contain a variable to be interpolated as a root path, maven
throws off a lot of spurious warnings that the POM does not validate because
system paths need to be absolute. An example of this in a parent POM (where
${jboss.home} is defined in ~/.m2/settings.xml):
{code:xml}
dependency
groupIdjboss/groupId
artifactIdactivation/artifactId
version4.0.4.GA/version
scopesystem/scope
systemPath${jboss.home}/server/default/lib/activation.jar/systemPath
/dependency
{code}
In discussing this with John and Jason online, both apparently have generic
implementations that can go in at some point, but this is something I would
like to get into 2.0.5. The patch is ~25 lines of new code with one
replaced.
It's marked as blocker because we use the assembly plugin, which fails the
build on the validation problem where most other plugins just enumerate every
system scope dependency. For now, I will distribute the patched version
around the company though :-)
thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3719:
---
Attachment: MNG-3719-maven-project.patch
This patch should fix the execution ordering; all test cases still run as
expected.
[regression] plugin execution ordering no longer POM ordered in 2.0.9
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
Environment: Maven 2.0.9, java version 1.5.0_13 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Priority: Critical
Fix For: 2.0.11
Attachments: MNG-3719-maven-project.patch,
plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this,
but so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are
not executed sequentially and there is no way to indicate dependencies, as
would be expected (note- I'm not expecting that it interpret the step 1...,
..., step 5... IDs, I'm only suggesting that either the plugins be executed
in order that they are found in the XML (most intuitive) or that there be
some concept of priority/ordinal added, or even perhaps (this would be most
ant-like) that plugin executions (and maybe even plugin goal executions) be
allowed to define prequisite execution IDs to be run (even if they are IDs
not defined in the pom, but maybe a parent pom, even though I don't need that
right now).
I know that this could be problematic if a plugin execution from one
lifecycle phase depends on another from another lifecycle phase (and you
could get into circular references that way that would have to be recognized
during pom validation after loading/merging pom.xmls). However, not being
able to at the very least define order of execution of different (or the
same) plugin executions as noted below and in attached project makes it
difficult to chain plugin executions that depend on each other, thereby
reducing the practicality of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven
2.0.9, since there appears to be no way to indicate dependencies of one
execution on another:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
!-- backup original source web.xml in preparation for
chaining of plugin modifications to it --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idstep 1 - backup-original-web.xml-from-src/id
phasegenerate-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=${pom.basedir}/target/
mkdir dir=${pom.basedir}/target/tmpwebxml/
copy
file=${pom.basedir}/src/main/webapp/WEB-INF/web.xml
todir=${pom.basedir}/target/tmpwebxml//
/tasks
/configuration
/execution
/executions
/plugin
plugin
!-- this plugin converts to
${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml --
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idstep 2 - jspc/id
phasegenerate-resources/phase
goals
goalcompile/goal
/goals
/execution
/executions
configuration
injectStringlt;!-- [INSERT JSPC FRAGMENT HERE]
[jira] Updated: (MNG-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[
http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-1957:
---
Attachment: MNG-1957-maven-project.patch
This patch implements the following behavior for JDK version matching:
* current version matching behavior ({{JDK_VERSION.startsWith( jdk )}},
negation through !)
* *version ranges* (by using {{VersionRange}}, upgrade number becomes build
number)
* negation operator ! works for version ranges as well
jdk/jdk clause in the activation section has to provide more complex
expressions.
-
Key: MNG-1957
URL: http://jira.codehaus.org/browse/MNG-1957
Project: Maven 2
Issue Type: Improvement
Components: POM
Affects Versions: 2.0, 2.0.1
Reporter: Trustin Lee
Fix For: 2.0.x
Attachments: MNG-1957-maven-project.patch
For now, jdk/jdk provides only one operator '!' which means negation, but
it would be great if i can use '+' and ~ operator:
jdk1.5+/jdk !-- this will be activated when the current JDK version is
1.5 or above (e.g. 1.6) --
jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version
is between 1.1 and 1.4 --
jdk~ 1.3/jdk !-- this will be activated when the current JDK version is
1.3 or below --
jdk1.4 ~/jdk. !-- the same with 1.5+ --
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2387) active on proxy in settings is misleading
[ http://jira.codehaus.org/browse/MNG-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torben S. Giesselmann updated MNG-2387: --- Attachment: MNG-2387-maven-settings.patch This patch produces the intended behavior: * empty proxy section -- no active proxy * only inactive proxies -- no active proxy * at least one active proxy -- first active proxy is returned Test cases included. active on proxy in settings is misleading - Key: MNG-2387 URL: http://jira.codehaus.org/browse/MNG-2387 Project: Maven 2 Issue Type: Task Components: Settings Reporter: Brett Porter Fix For: 2.0.x Attachments: MNG-2387-maven-settings.patch see: http://mail-archives.apache.org/mod_mbox/maven-users/200510.mbox/%3c84fb18c70510171532v1d655221n36b66fb10a018...@mail.gmail.com%3e -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2523) OS name activation does not work for Mac OS X
[
http://jira.codehaus.org/browse/MNG-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162593#action_162593
]
Torben S. Giesselmann commented on MNG-2523:
Works perfectly for me.
Environment:
* Mac OS X: 10.5.6
* Java: java version 1.5.0_16
* Maven: 2.0.6
Here's some info from {{System.getProperties()}}:
{code}
java.runtime.name: Java(TM) 2 Runtime Environment, Standard Edition
sun.boot.library.path:
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Libraries
java.vm.version: 1.5.0_16-133
java.vm.vendor: Apple Inc.
java.vendor.url: http://www.apple.com/
java.vm.name: Java HotSpot(TM) Client VM
user.country: US
java.runtime.version: 1.5.0_16-b06-284
os.arch: i386
java.vm.specification.vendor: Sun Microsystems Inc.
os.name: Mac OS X
java.class.version: 49.0
os.version: 10.5.6
java.specification.version: 1.5
java.vm.specification.version: 1.0
java.home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
sun.arch.data.model: 32
user.language: en
java.specification.vendor: Sun Microsystems Inc.
java.version: 1.5.0_16
mrj.version: 1050.1.5.0_16-284
{code}
Could anyone else provide some more system details where it's *not* working?
OS name activation does not work for Mac OS X
-
Key: MNG-2523
URL: http://jira.codehaus.org/browse/MNG-2523
Project: Maven 2
Issue Type: Bug
Components: Profiles
Reporter: Jason van Zyl
Fix For: 2.0.x
Using something like:
profiles
profile
idmacosx/id
activation
os
namemac os x/name
/os
/activation
properties
osNameMac OS X/osName
/properties
/profile
/profiles
Does not work on Mac OS X. The profile is never activated.
--
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
