[jira] (MNG-5590) ${basedir} and ${project.basedir} do not behave the same
[
https://jira.codehaus.org/browse/MNG-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-5590.
---
Resolution: Duplicate
Assignee: Robert Scholte
> ${basedir} and ${project.basedir} do not behave the same
>
>
> Key: MNG-5590
> URL: https://jira.codehaus.org/browse/MNG-5590
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.5, 3.1.1
>Reporter: Henning Schmiedehausen
>Assignee: Robert Scholte
> Attachments: pom.xml
>
>
> According to http://maven.apache.org/ref/3.1.1/maven-model-builder/, the
> $\{basedir} property is deprecated and replaced by $\{project.basedir}.
> However the two are not the same. Consider the attached pom.
> When using $\{basedir}/pom.xml in profile activation, running
> "help:active-profiles" will list
> - profile-test (source: pom)
> When using $\{project.basedir}/pom.xml, it will not list the profile as
> activated.
> It seems that the $\{project.} properties get set after profile
> activation and evaluation (which makes sense because the profiles might
> affect these values), but profile activation requires them to be set before
> that has happened.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-283) Multiple level filtering not behaving as expected and not consistant behaviour between ${} replacement and @@ replacement
[
https://jira.codehaus.org/browse/MSHARED-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-283.
--
Resolution: Won't Fix
Assignee: Robert Scholte
IMO there should be a clear separation of source files and target files. Source
files are properties files and $\{\*} expressions can be resolved within the
same file. Target files are the files to be filtered. You should use $\{\*}
here as well, but if that leads to complex expression you can use @\*@ as well.
This is also inline with pom.xml filtering: @*@ within this file won't be
filtered.
> Multiple level filtering not behaving as expected and not consistant
> behaviour between ${} replacement and @@ replacement
> -
>
> Key: MSHARED-283
> URL: https://jira.codehaus.org/browse/MSHARED-283
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Affects Versions: maven-filtering-1.1
>Reporter: David Jones
>Assignee: Robert Scholte
> Attachments: maven-filtering-test-case.diff, MSHARED-283.patch,
> MSHARED-283-v2.patch
>
>
> Filter (defined in a property file) can be composed of other properties as
> shown in myproperty1 and myproperty2 below:
> {noformat}
> part1=part1
> part2=part2
> myproperty1=${part1}-${part2}
> myproperty2=@part1@-@part2@
> {noformat}
> It is possible to define a second filter file to overwrite some properties:
> {noformat}
> part1=part1OVERWRITE
> {noformat}
> When filtering using the two filter files the resulting value of myproperty1
> and myproperty2 should be as follows:
> {noformat}
> myproperty1=part1OVERWRITE-part2
> myproperty2=part1OVERWRITE-part2
> {noformat}
> It is expected that the composite property should take the overwritten part1
> from the second property file while part2 should be taken from the first
> property file.
> In addition the choice of delimeter @@ vs $\{*} should not have any effect on
> the behaviour.
> However tests have shown that myproperty2 is being replaced correctly while
> myproperty1 is NOT.
> MRESOURCES-157 also demonstrates this with a maven project which tests the
> same thing.
> The attached patch file (maven-filtering-test-case.diff) adds a new test
> (which currently fails) which demonstrates the issue described
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5219) Regression from M2: Installing non-existing artifact is silently ignored
[
https://jira.codehaus.org/browse/MNG-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5219:
---
Fix Version/s: 3.2.2
> Regression from M2: Installing non-existing artifact is silently ignored
>
>
> Key: MNG-5219
> URL: https://jira.codehaus.org/browse/MNG-5219
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3, 3.0.4
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/kozelka/opt/apache-maven-3.0.3
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.38-13-generic", arch: "amd64", family: "unix"
>Reporter: Petr Kozelka
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
> Attachments: MNG-fail-install-ifnotfound.patch, pom.xml
>
>
> Maven 2.2.1 used to fail during "install" phase when an attached artifact did
> not exist.
> This is no longer true with version 3.0.3.
> To reproduce the bug, store attached pom.xml into an empty directory and try:
> a) maven 2.2.1 - use command "mvn clean install -e" to see the stacktrace:
> {noformat}
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing /TESTDIR/pom.xml to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.pom
> [INFO] Installing /TESTDIR/target/nonexistent.nonsense to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.nonsense
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error installing artifact: File /TESTDIR/target/nonexistent.nonsense
> does not exist
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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: org.apache.maven.plugin.MojoExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
> Error installing artifact: File /TESTDIR/target/nonexistent.nonsense does not
> exist
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:133)
> ... 19 more
> Caused by: java.io.IOException: File /TESTDIR/target/nonexistent.nonsense
> does not exist
> at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1003)
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.instal
[jira] (MNG-5219) Regression from M2: Installing non-existing artifact is silently ignored
[
https://jira.codehaus.org/browse/MNG-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341497#comment-341497
]
Jason van Zyl commented on MNG-5219:
A better way to handle this generally might be to disallow a non-existent
artifact to be attached in the first place and throw an exception in
MavenProject#addAttachedArtifact. This will force users to attach artifacts
only after they have been created, but I don't think that's a bad thing.
> Regression from M2: Installing non-existing artifact is silently ignored
>
>
> Key: MNG-5219
> URL: https://jira.codehaus.org/browse/MNG-5219
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3, 3.0.4
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Maven home: /home/kozelka/opt/apache-maven-3.0.3
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: ANSI_X3.4-1968
> OS name: "linux", version: "2.6.38-13-generic", arch: "amd64", family: "unix"
>Reporter: Petr Kozelka
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
> Attachments: MNG-fail-install-ifnotfound.patch, pom.xml
>
>
> Maven 2.2.1 used to fail during "install" phase when an attached artifact did
> not exist.
> This is no longer true with version 3.0.3.
> To reproduce the bug, store attached pom.xml into an empty directory and try:
> a) maven 2.2.1 - use command "mvn clean install -e" to see the stacktrace:
> {noformat}
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing /TESTDIR/pom.xml to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.pom
> [INFO] Installing /TESTDIR/target/nonexistent.nonsense to
> /LOCALREPO/test/mvn/install/test-mvn-install/1-SNAPSHOT/test-mvn-install-1-SNAPSHOT.nonsense
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error installing artifact: File /TESTDIR/target/nonexistent.nonsense
> does not exist
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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: org.apache.maven.plugin.MojoExecutionException: Error installing
> artifact: File /TESTDIR/target/nonexistent.nonsense does not exist
> at
> org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
> Error installing artifact: File /TESTDIR/target/nonexistent.nonsense does not
> exist
> at
> org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:119)
> at
> org.apache.maven.plugin
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[ https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341500#comment-341500 ] Jason van Zyl commented on MNG-5587: Here I think the -e option should just be on by default. If something goes wrong let's make the user do less to get the useful information. So if something goes wrong then emit a stack trace if there is one is the right thing to do. > When the build fails emit any errors without the user having to specify -e or > -X > > > Key: MNG-5587 > URL: https://jira.codehaus.org/browse/MNG-5587 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.2.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5474) combine.children="merge" has reversed ordering of combine.children="append"
[
https://jira.codehaus.org/browse/MNG-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341502#comment-341502
]
Jason van Zyl commented on MNG-5474:
I think it makes sense that the order be preserved in the same way. I can't
think of a reason not to.
> combine.children="merge" has reversed ordering of combine.children="append"
> ---
>
> Key: MNG-5474
> URL: https://jira.codehaus.org/browse/MNG-5474
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.5
>Reporter: Tobias Oberlies
>Priority: Minor
> Fix For: 3.2.2
>
>
> I have a configuration parameter that has a list of child elements (which
> themselves contain configuration elements). The child elements have distinct
> names, but their order matters. They each denote a pre-condition, and I want
> to be able to specify which one wins in case multiple pre-conditions apply.
> Obviously, I want more specific configuration (e.g. execution level > plugin
> level) to win. As a plugin, I only get the merged configuration as list
> (using the parameter type PlexusConfiguration). So to achieve the desired
> precedence, I need to rely on the order of the child elements.
> I was surprised to see that {{combine.children="merge"}} and
> {{combine.children="append"}} give opposite results. For the former, more
> specific configuration is a the top whereas for the latter, the more specific
> configuration is at the end of the list.
> Example:
> {noformat}
>
>
> ...
> ...
> ...
> ...
>
>
> {noformat}
> {noformat}
>
>
> ...
> ...
> ...
> ...
>
>
> {noformat}
> I think that {{combine.children="merge"}} should also be in parent-first
> order.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5474) combine.children="merge" has reversed ordering of combine.children="append"
[
https://jira.codehaus.org/browse/MNG-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-5474:
---
Fix Version/s: 3.2.2
> combine.children="merge" has reversed ordering of combine.children="append"
> ---
>
> Key: MNG-5474
> URL: https://jira.codehaus.org/browse/MNG-5474
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.5
>Reporter: Tobias Oberlies
>Priority: Minor
> Fix For: 3.2.2
>
>
> I have a configuration parameter that has a list of child elements (which
> themselves contain configuration elements). The child elements have distinct
> names, but their order matters. They each denote a pre-condition, and I want
> to be able to specify which one wins in case multiple pre-conditions apply.
> Obviously, I want more specific configuration (e.g. execution level > plugin
> level) to win. As a plugin, I only get the merged configuration as list
> (using the parameter type PlexusConfiguration). So to achieve the desired
> precedence, I need to rely on the order of the child elements.
> I was surprised to see that {{combine.children="merge"}} and
> {{combine.children="append"}} give opposite results. For the former, more
> specific configuration is a the top whereas for the latter, the more specific
> configuration is at the end of the list.
> Example:
> {noformat}
>
>
> ...
> ...
> ...
> ...
>
>
> {noformat}
> {noformat}
>
>
> ...
> ...
> ...
> ...
>
>
> {noformat}
> I think that {{combine.children="merge"}} should also be in parent-first
> order.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341503#comment-341503 ] Jason van Zyl commented on MNG-5207: I made a small repo with a script here: https://github.com/takari/MNG-5207 Clone the git repo and run ./build.sh, which displays the version of Maven, runs the prepare script and then executes Maven. If you can take a look and see what might be wrong because the build fails for me: https://gist.github.com/jvanzyl/9020379 > [Regression] Maven 3 fails to calculate proper build order with dependencies > with classifiers > - > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Jörg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: Issues to be reviewed for 4.x > > Attachments: mng5207-it.tgz, MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5448) Putting dll/so-type dependencies on java.library.path by default
[ https://jira.codehaus.org/browse/MNG-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341506#comment-341506 ] Jason van Zyl commented on MNG-5448: What does the NAR plugin do here? I consider that the standard way of dealing with native code in Maven. > Putting dll/so-type dependencies on java.library.path by default > > > Key: MNG-5448 > URL: https://jira.codehaus.org/browse/MNG-5448 > Project: Maven 2 & 3 > Issue Type: Story >Reporter: Markus KARG > > Many people are using Maven to build products that are using native > dependencies (e. g. using JNI directly or indirectly). These people have to > declare in some way this dependency, so Maven will download the DLL/SO to > [target]. But what they also need is to tell Java that the target folder has > to be scanned for the DLL/SO, hence they need to set java.library path. > There are several solutions but all of them lack one thing: They are no > default but always do "tricks". This is a problem, because: > * m2e needs to tell Eclipse where to find DLLs. > * There might be other tools that want to read or write the POM. > * How should different tools understand that DLL dependencies are to be put > on java.library.path if there is no STANDARD way to find this information in > the POM? > The only "real" solution would be that Maven 3.1 clearly defines the one and > only unique way! > In my opinion the way clearly means: > * Clearly define that any dll and > exe dependencies MUST be put to [target/native] and > that [target/native] MUST be part of java.library.path! > That way, it will become most simple to use any DLL/SO as a dependency, > either Maven-built or not. And it will be absolutely clear to m2e and any > other tools that such dependencies must be told to Eclipse and other > environments as to be put on the java.library.path! > I do not say that it must exactly work THIS way, but what I really like to > say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way > to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found > on java.library.path in turn. > This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that > is a dependency only serves the single and simple purpose of BEING on > java.library.path -- otherwise one would not have made it a dependency! > I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes > pretty much sense to do the same with DLL/SO dependency and java.library.path! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5448) Putting dll/so-type dependencies on java.library.path by default
[ https://jira.codehaus.org/browse/MNG-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341512#comment-341512 ] Andreas Aronsson commented on MNG-5448: --- Seems NAR generates a pretty long path. They discuss the NAR in the thread leading up to this issue: http://maven.40175.n5.nabble.com/How-to-tell-Maven-to-put-DLL-dependency-into-java-library-path-td5748568.html I think the last reply may be the answer for this issue. If that looks allright it would be nice to have in docs for NAR I guess. > Putting dll/so-type dependencies on java.library.path by default > > > Key: MNG-5448 > URL: https://jira.codehaus.org/browse/MNG-5448 > Project: Maven 2 & 3 > Issue Type: Story >Reporter: Markus KARG > > Many people are using Maven to build products that are using native > dependencies (e. g. using JNI directly or indirectly). These people have to > declare in some way this dependency, so Maven will download the DLL/SO to > [target]. But what they also need is to tell Java that the target folder has > to be scanned for the DLL/SO, hence they need to set java.library path. > There are several solutions but all of them lack one thing: They are no > default but always do "tricks". This is a problem, because: > * m2e needs to tell Eclipse where to find DLLs. > * There might be other tools that want to read or write the POM. > * How should different tools understand that DLL dependencies are to be put > on java.library.path if there is no STANDARD way to find this information in > the POM? > The only "real" solution would be that Maven 3.1 clearly defines the one and > only unique way! > In my opinion the way clearly means: > * Clearly define that any dll and > exe dependencies MUST be put to [target/native] and > that [target/native] MUST be part of java.library.path! > That way, it will become most simple to use any DLL/SO as a dependency, > either Maven-built or not. And it will be absolutely clear to m2e and any > other tools that such dependencies must be told to Eclipse and other > environments as to be put on the java.library.path! > I do not say that it must exactly work THIS way, but what I really like to > say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way > to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found > on java.library.path in turn. > This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that > is a dependency only serves the single and simple purpose of BEING on > java.library.path -- otherwise one would not have made it a dependency! > I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes > pretty much sense to do the same with DLL/SO dependency and java.library.path! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5587) When the build fails emit any errors without the user having to specify -e or -X
[ https://jira.codehaus.org/browse/MNG-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341513#comment-341513 ] Andreas Aronsson commented on MNG-5587: --- -e on by default would save me a good deal of typing, yes. Normally added to all maven jobs in my jenkinses. > When the build fails emit any errors without the user having to specify -e or > -X > > > Key: MNG-5587 > URL: https://jira.codehaus.org/browse/MNG-5587 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.2.2 > > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5448) Putting dll/so-type dependencies on java.library.path by default
[ https://jira.codehaus.org/browse/MNG-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341516#comment-341516 ] Markus KARG commented on MNG-5448: -- What I proposed is that Maven learns to deal with binary dependencies in a very sophisticated and simple-to-use way. NAR does not do that. It puts up a heavy load on the user and the runtime system. Until today, nobody was able to provide a simple and easy to apply config example how NAR could solve the issue I expressed in the above feature request. Hence I really beg that Maven will provide a dll DEPENDENCY support (this is about DEPENDENCIES, not about PRODUCING binary packages)! :-) If someone knows a dead-simple solution _with_ NAR, then please post the config NOW AND HERE so we can all be happy without a change in Maven. ;-) Regards -Markus > Putting dll/so-type dependencies on java.library.path by default > > > Key: MNG-5448 > URL: https://jira.codehaus.org/browse/MNG-5448 > Project: Maven 2 & 3 > Issue Type: Story >Reporter: Markus KARG > > Many people are using Maven to build products that are using native > dependencies (e. g. using JNI directly or indirectly). These people have to > declare in some way this dependency, so Maven will download the DLL/SO to > [target]. But what they also need is to tell Java that the target folder has > to be scanned for the DLL/SO, hence they need to set java.library path. > There are several solutions but all of them lack one thing: They are no > default but always do "tricks". This is a problem, because: > * m2e needs to tell Eclipse where to find DLLs. > * There might be other tools that want to read or write the POM. > * How should different tools understand that DLL dependencies are to be put > on java.library.path if there is no STANDARD way to find this information in > the POM? > The only "real" solution would be that Maven 3.1 clearly defines the one and > only unique way! > In my opinion the way clearly means: > * Clearly define that any dll and > exe dependencies MUST be put to [target/native] and > that [target/native] MUST be part of java.library.path! > That way, it will become most simple to use any DLL/SO as a dependency, > either Maven-built or not. And it will be absolutely clear to m2e and any > other tools that such dependencies must be told to Eclipse and other > environments as to be put on the java.library.path! > I do not say that it must exactly work THIS way, but what I really like to > say is that Maven MUST provide ONE and EXACTLY ONE clear and unambiguous way > to tell ANY POM-reading tool that a dependency is a DLL/SO and MUST be found > on java.library.path in turn. > This is NOT up to the POM author, as it is pretty clear that ANY DLL/SO that > is a dependency only serves the single and simple purpose of BEING on > java.library.path -- otherwise one would not have made it a dependency! > I mean, ANY JAR dependency is put on the CLASSPATH already, so it makes > pretty much sense to do the same with DLL/SO dependency and java.library.path! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-174) NullPointerException at MavenArtifactRepository.java:219
[
https://jira.codehaus.org/browse/MDEPLOY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341524#comment-341524
]
Markus KARG commented on MDEPLOY-174:
-
Sorry for letting you wait.
What exactly do you want me to do / to post)? Instructions please. :-)
Thanks
-Markus
> NullPointerException at MavenArtifactRepository.java:219
>
>
> Key: MDEPLOY-174
> URL: https://jira.codehaus.org/browse/MDEPLOY-174
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Markus KARG
>Priority: Minor
>
> My POM.xml is rather empty, mostly contains only this:
> {code:xml}
>
> maven-deploy-plugin
> 2.8.1
>
> ${project.groupId}
> ${project.artifactId}
> ${project.version}
> zip
> ../target/dist/DITA-OT2.0.M1_minimal_bin.zip
>
>
>
> deploy
>
> deploy-file
>
>
>
>
> {code}
> When I do "mvn -X deploy" the result is a crash of Maven:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default) on
> project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default)
> on project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.protocol(MavenArtifactRepository.java:219)
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.(MavenArtifactRepository.java:79)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:129)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:78)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:67)
> at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-174) NullPointerException at MavenArtifactRepository.java:219
[
https://jira.codehaus.org/browse/MDEPLOY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341525#comment-341525
]
Robert Scholte commented on MDEPLOY-174:
I found the cause:
[DeployFileMojo.java@rev1354969|http://svn.apache.org/viewvc/maven/plugins/trunk/maven-deploy-plugin/src/main/java/org/apache/maven/plugin/deploy/DeployFileMojo.java?r1=1354969&r2=1354968&pathrev=1354969]
was a translation from javadoclettags to annotations (MDEPLOY-151)
The url suddenly misses it's required marker. I'll add it.
> NullPointerException at MavenArtifactRepository.java:219
>
>
> Key: MDEPLOY-174
> URL: https://jira.codehaus.org/browse/MDEPLOY-174
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Markus KARG
>Priority: Minor
>
> My POM.xml is rather empty, mostly contains only this:
> {code:xml}
>
> maven-deploy-plugin
> 2.8.1
>
> ${project.groupId}
> ${project.artifactId}
> ${project.version}
> zip
> ../target/dist/DITA-OT2.0.M1_minimal_bin.zip
>
>
>
> deploy
>
> deploy-file
>
>
>
>
> {code}
> When I do "mvn -X deploy" the result is a crash of Maven:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default) on
> project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default)
> on project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.protocol(MavenArtifactRepository.java:219)
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.(MavenArtifactRepository.java:79)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:129)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:78)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:67)
> at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> [ERROR]
> {noformat}
[jira] (MDEPLOY-174) [REGRESSION] url not required anymore, causing a NullPointerException
[
https://jira.codehaus.org/browse/MDEPLOY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEPLOY-174:
---
Summary: [REGRESSION] url not required anymore, causing a
NullPointerException (was: NullPointerException at
MavenArtifactRepository.java:219)
> [REGRESSION] url not required anymore, causing a NullPointerException
> -
>
> Key: MDEPLOY-174
> URL: https://jira.codehaus.org/browse/MDEPLOY-174
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Markus KARG
>Priority: Minor
>
> My POM.xml is rather empty, mostly contains only this:
> {code:xml}
>
> maven-deploy-plugin
> 2.8.1
>
> ${project.groupId}
> ${project.artifactId}
> ${project.version}
> zip
> ../target/dist/DITA-OT2.0.M1_minimal_bin.zip
>
>
>
> deploy
>
> deploy-file
>
>
>
>
> {code}
> When I do "mvn -X deploy" the result is a crash of Maven:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default) on
> project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default)
> on project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.protocol(MavenArtifactRepository.java:219)
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.(MavenArtifactRepository.java:79)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:129)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:78)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:67)
> at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEPLOY-174) [REGRESSION] url not required anymore, causing a NullPointerException
[
https://jira.codehaus.org/browse/MDEPLOY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEPLOY-174.
--
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Robert Scholte
Fixed in [r1568656|http://svn.apache.org/r1568656]
> [REGRESSION] url not required anymore, causing a NullPointerException
> -
>
> Key: MDEPLOY-174
> URL: https://jira.codehaus.org/browse/MDEPLOY-174
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Markus KARG
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.9
>
>
> My POM.xml is rather empty, mostly contains only this:
> {code:xml}
>
> maven-deploy-plugin
> 2.8.1
>
> ${project.groupId}
> ${project.artifactId}
> ${project.version}
> zip
> ../target/dist/DITA-OT2.0.M1_minimal_bin.zip
>
>
>
> deploy
>
> deploy-file
>
>
>
>
> {code}
> When I do "mvn -X deploy" the result is a crash of Maven:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default) on
> project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default)
> on project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.protocol(MavenArtifactRepository.java:219)
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.(MavenArtifactRepository.java:79)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:129)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:78)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:67)
> at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5563) Ensuring only the available parameters are allowed
[
https://jira.codehaus.org/browse/MNG-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341527#comment-341527
]
Jason van Zyl commented on MNG-5563:
Maybe moving toward configuration per goal will allow us to make sure exactly
what is required is provided. This would allow validation where our current
model there is no real way to do this.
> Ensuring only the available parameters are allowed
> --
>
> Key: MNG-5563
> URL: https://jira.codehaus.org/browse/MNG-5563
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Reporter: Savas Ali Tokmen
> Fix For: Issues to be reviewed for 4.x
>
>
> I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3 plugin;
> and would have an improvement request with regards to how parameters are
> managed.
> Currently, what happens is that if a user unwillingly puts a parameter in the
> wrong place then the plugin execution continues as is. One of the latest such
> issues one of the users has had can be found on
> http://cargo.996258.n3.nabble.com/Maven-plugin-and-javaagent-tp18075.html
> As an example, I can write the below POM and build still works (even thought
> the MOJO has no parameter called "foo"):
> {noformat}
>
> org.codehaus.cargo
> cargo-maven2-plugin
> 1.4.6
>
>
> bar
>
>
>
> {noformat}
> It would be good for the MOJO developer to be ablo instruct by MOJO to fail
> if there is an unknown parameter in the configuration.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1958) we need a var that always points to the root direcotry in multi module builds
[
https://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-1958:
---
Fix Version/s: (was: Issues to be reviewed for 4.x)
3.2.2
Assignee: Jason van Zyl
> we need a var that always points to the root direcotry in multi module builds
> -
>
> Key: MNG-1958
> URL: https://jira.codehaus.org/browse/MNG-1958
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Reactor and workspace
>Reporter: Mark Proctor
>Assignee: Jason van Zyl
> Fix For: 3.2.2
>
>
> ${basedir} always points to the local module. There are cases, when having a
> local relative repository, when it would be usefull to have a var that always
> pointed to the root project, ${rootdir}.
> In such a case you may want to think of having the names ${rootdir}
> ${moduledir}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2205) "provided" scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341528#comment-341528
]
Jason van Zyl commented on MNG-2205:
It is unlikely we will change the behavior of the provided scope, but it would
be possible to create a new 'provided-transitive' if we really wanted this.
Changing the definition of existing scopes would be problematic.
> "provided" scope dependencies must be transitive
>
>
> Key: MNG-2205
> URL: https://jira.codehaus.org/browse/MNG-2205
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Reporter: David Boden
>Priority: Critical
> Fix For: 3.x / Backlog
>
> Attachments: transitivetest.zip
>
>
> A provided scope dependency can also be thought of as "compile-only".
> Project A requires Sybase JConnect on the runtime classpath. Project A
> declares a "provided" dependency on Sybase JConnect.
> Project B depends upon Project A. Project B declares a "compile" dependency
> on Project A.
> Project C depends upon Project B. Project C declares a "compile" dependency
> on Project B.
> {noformat}
> C
> | - compile dependency
> B
> | - compile dependency
> A
> | - provided dependency
> Sybase JConnect
> {noformat}
> So, does Project C transitively depend on Sybase JConnect. Yes, of course!
> The "provided" dependency needs to be transitive.
> Ultimately, when Project C gets deployed, Sybase JConnect needs to be
> somewhere on the runtime classpath in order for the application to function.
> It's valid for Project C to assume that Sybase JConnect is available and use
> JDBC all over the Project C code. Project C is safe to do this because it can
> happily deduce that Sybase JConnect will be there in the runtime environment
> because Project A NEEDS IT.
> I've got Use Cases all over my aggregated build which make it absolutely
> critical and common sense that provided scope dependencies are transitive.
> For the (very rare) odd case where you don't want to inherit provided
> dependencies, you can them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4715) version expression constant
[
https://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-4715:
---
Fix Version/s: (was: Issues to be reviewed for 3.x)
3.2.2
Assignee: Jason van Zyl
> version expression constant
> ---
>
> Key: MNG-4715
> URL: https://jira.codehaus.org/browse/MNG-4715
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Dependencies, POM
>Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
> Environment: eclipse linux xp
>Reporter: Faruk
>Assignee: Jason van Zyl
>Priority: Critical
> Fix For: 3.2.2
>
> Attachments: untitled.JPG
>
>
> early versions, we define modules versions with expressions, and set them to
> the parent pom,
> simply;
> {code:xml}
>
> 1.0.1
> 1.0.1
>
> {code}
> and then, we give this property to modules pom as expression ,
> {code:xml}
> ik-plug
> jar
> ${ibb-core-util.versionn}
> {code}
> but know , it gives an error you know like this,
> {noformat}
> [WARNING] Some problems were encountered while building the effective model
> for ibb-parent:ibb-modules-parent:pom:1.0.0
> [WARNING] 'version' contains an expression but should be a constant. @
> ibb-parent:ibb-modules-parent:${ibb-core-jars.version},
> C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
> {noformat}
> but I think that, this enhancement is causes wrong result,
> think that , if we have i project already developing about 3 years, this
> project has a lot of modules, and this modules have sub modules , and this
> sub modules already bound to some other modules not define in your pom, but
> your updates must be affect them, at this situation, developer want to write
> the existing version numbers with properties to parent pom, and want to
> manage them like this. at the attach file below , the close projects are
> belongs to open projects, but they are the different team developing this. I
> cant force the other developers to cache their versions, I must use this
> versions as initial step
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341529#comment-341529 ] Jason van Zyl commented on MNG-3283: What goals are people trying to run for this case. All of these failures are happening because of the logic present in the ReactorReader and the implicit definition of resolution in Maven in that an artifact is not resolved unless a file can be found for the artifact trying to be resolved. I believe what people expect is that in the reactor the project is there so it should therefore be resolved. No file is attached to the artifact until the maven-compiler-plugin runs and attaches the target/classes directory or after the package phase when the archive is created. It is possible to change this logic but I'm curious how people are using it. If it's for eclipse project file generation then I would recommend using m2eclipse for a number of reasons. The maven-eclipse-plugin reimplements all sorts of weird logic to acccount the fact that Maven doesn't consider an artifact resolved until a file is attached. For a custom that I'm helping to migrate to Maven we created a new version of the ReactorReader and a modified maven-eclipse-plugin to deal with this specific case. But we plan not to use this at all once the full conversion is completed. Again, I would use m2e if this is the problem you're running into. If there are other cases I'm interested. > Plugins that require dependency resolution in early phases cause dependency > resolution issue > > > Key: MNG-3283 > URL: https://jira.codehaus.org/browse/MNG-3283 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle, Reactor and > workspace >Affects Versions: 2.0.7 >Reporter: Alfie Kirkpatrick > Fix For: Issues to be reviewed for 3.x > > Attachments: maven-dependency-bug.zip > > > What we're seeing is that some multi-project configurations succeed on > 'mvn package' but fail on 'mvn generate-sources'. They are failing when > one project in the reactor references another project in the reactor > which is not installed in the local repo. It seems that the referenced > project has not quite "made it" into the reactor this early in the phase > lifecycle. But it does work correctly if you target a later phase at the > outset which is really confusing. > The problem only occurs when a plugin binds itself to the > generate-sources phase and has @requiresDependencyResolution, presumably > because this is what triggers resolution of the referenced dependency > too early in the lifecycle, and hence the error. > We are seeing this problem when trying to run 'mvn eclipse:eclipse' > because this only executes the generate-sources phase by default and we > have other mojos which genuinely do generate source, such as java2wsdl. > A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. > Attached is a really simple project that exhibits this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2570) Maven needs to support multiple logging levels
[ https://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341530#comment-341530 ] Jason van Zyl commented on MNG-2570: Anything here should now be adjusted to the fact that we're using SLF4J. > Maven needs to support multiple logging levels > -- > > Key: MNG-2570 > URL: https://jira.codehaus.org/browse/MNG-2570 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: Issues to be reviewed for 3.x > > Attachments: MNG-2570-maven-embedder.patch > > > The current logging levels are essentially verbose (default) and debug (-X). > We need a slightly less verbose output so that things like compiler warnings > and other output is actually visable to the developer. Currently it gets > buried in all the noise. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3559: --- Fix Version/s: (was: Issues to be reviewed for 3.x) 3.2.2 > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: https://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak >Assignee: Jason van Zyl > Fix For: 3.2.2 > > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=341531#comment-341531 ] Jason van Zyl commented on MNG-3559: I fixed this in an implementation of the ReactorReader for a customer so this one migth be relatively easy to fix. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: https://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak >Assignee: Jason van Zyl > Fix For: 3.2.2 > > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
