[jira] Updated: (MNG-2387) on 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. > on 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-tabpanel&focusedCommentId=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:
>
>
> macosx
>
>
> mac os x
>
>
>
> Mac OS X
>
>
>
> 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
[jira] Updated: (MNG-1957) 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
> 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, provides only one operator '!' which means negation, but
> it would be great if i can use '+' and ~ operator:
> 1.5+
> 1.1 ~ 1.4
> ~ 1.3
> 1.4 ~
--
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-tabpanel&focusedCommentId=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}
>
> jboss
> activation
> 4.0.4.GA
> system
>
> ${jboss.home}/server/default/lib/activation.jar
>
> {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}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
> 1.0
> jar
>
>
> javax.servlet
> jstl
> 1.1.2
> jar
>
[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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
>
[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 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-tabpanel&focusedCommentId=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 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-tabpanel&focusedCommentId=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}
localrepo
local module directory
file://lib
true
true
{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:
>
> local (Maven 1)
> Local module repository (lib)
> file://lib
> ..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-tabpanel&focusedCommentId=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}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
> 1.0
> jar
>
>
> javax.servlet
>
[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-3890) Transitive dependencies override explicitly set scope.
[
http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-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] 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) on in settings is misleading
[ http://jira.codehaus.org/browse/MNG-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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! ;-) > on 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-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 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
