[jira] (MRESOURCES-39) Filtering fails for command line properties
[
https://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350336#comment-350336
]
Deepak Abraham commented on MRESOURCES-39:
--
doesn't work in version 2.6 resources plugin
If I specify a property like so in the pom.xml:
local
I am using this property to specfiy a folder name in the filter property:
org.apache.maven.plugins
maven-resources-plugin
${basedir}/../deploy/etc/filters/${env.name}/env.properties
...
Then I am unable to override this property value through the command prompt,
i.e., mvn install -Denv.name=dev does not work as expected. 'env.name' is still
local instead of dev.
> Filtering fails for command line properties
> ---
>
> Key: MRESOURCES-39
> URL: https://jira.codehaus.org/browse/MRESOURCES-39
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: maven-2.0.4 and maven-2.0.5
> Mac OS X
>Reporter: Matt Brozowski
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 2.3
>
> Attachments: filtering-bug.tar,
> maven-resources-plugin-prop-filtering-r630241.patch
>
>
> When passing a property on the command line to maven using -D it does not
> properly override values passed to filters.
> I have attached a sample project that defines a property in the pom.xml
> called 'filtered' This property is used as a filter in the
> filtered.properties file in src/main/filtered/filtered.properties. I have
> also included a test that gets passed the filtered property as a System
> property via the surefire plugin. It then loaded the filtered.properties
> file and tests to ensure the filters match.
> The tests pass when run as
> mvn test
> BUT if I run as
> mvn -Dfiltered=from-cmd-line teset
> They fail.
> I have also included the antrun plugin print its perspective on the value of
> the property.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-228) cannot assign a value to final variable in lamda
[
https://jira.codehaus.org/browse/MCOMPILER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350347#comment-350347
]
Robert Scholte commented on MCOMPILER-228:
--
Issue can be tracked at https://bugs.openjdk.java.net/browse/JDK-8051958
> cannot assign a value to final variable in lamda
>
>
> Key: MCOMPILER-228
> URL: https://jira.codehaus.org/browse/MCOMPILER-228
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Windows 7 64 bit, Maven 3.2.2, JDK 64 bit 8u5
>Reporter: Robert Kish
>Priority: Minor
> Attachments: FinalExample.java, MCOMPILER-228.patch
>
>
> Code example compiles in Eclipse, but not with Maven Compiler Plugin. Code is
> like below (inside a lamda expression)
> {code}
> final x;
> if (some condition)
> x = a;
> else if (some other condition)
> x = b;
> else
> x = c;
> {code}
> See attached example source.
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project MediaIndexer: Compilation failure: Compilation failure:
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[11,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[14,13]
> cannot assign a value to final variable compareTo
> [ERROR] /C:/MAPS/MediaIndexer/src/main/java/example/FinalExample.java:[17,13]
> cannot assign a value to final variable compareTo
> {noformat}
> The workaround is to remove final for the variable and just ensure that the
> value is assigned in each code path.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
Robert Scholte created MNG-5665: --- Summary: Advanced Lifecycle Handling Key: MNG-5665 URL: https://jira.codehaus.org/browse/MNG-5665 Project: Maven Issue Type: Bug Components: Plugins and Lifecycle Reporter: Robert Scholte These are a couple of improvements, which will improve the behavior of Maven regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5666) Divide build in pre-build, build and post-build
Robert Scholte created MNG-5666:
---
Summary: Divide build in pre-build, build and post-build
Key: MNG-5666
URL: https://jira.codehaus.org/browse/MNG-5666
Project: Maven
Issue Type: Sub-task
Components: Plugins and Lifecycle
Reporter: Robert Scholte
Original proposal
{quote}
PROPOSAL 1: PerProject and PerPhase Executions
I've recently introduced the installAtEnd/deployAtEnd as an experimental
feature which should improve the behavior of Maven without having to wait for
the implementation in Maven Core, which would have a huge impact.
The reason is that you only want to install and/or deploy only after all
modules have been build and verified successfully.
This feature works for most projects, however there are cases which cannot be
solved by the plugin solution and require a change in the handling of
lifecycles in Maven Core.
Up unto the verify-phase you want to execute all phases per project, whereas
the install and deploy should be executed per phase.
Consider a root project with 2 modules, these should be executed like this
root : validate ... verify
module1: validate ... verify
module2: validate ... verify
root : install
module1: install
module2: install
root : deploy
module1: deploy
module2: deploy
{quote}
After one of the google hangout session we came up with the following idea:
divide the build in pre-build, build and post-build
First the {{pre-build}} would do a validate of the whole project.
The {{build}} runs from {{initialize}} up to {{verify}}
The {{post-build}} would handle the distribution, being {{install}}/{{deploy}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5667) Either install or deploy
Robert Scholte created MNG-5667:
---
Summary: Either install or deploy
Key: MNG-5667
URL: https://jira.codehaus.org/browse/MNG-5667
Project: Maven
Issue Type: Sub-task
Components: Plugins and Lifecycle
Reporter: Robert Scholte
Original proposal
{quote}
PROPOSAL 2: Either install or deploy
In general one should either run 'mvn verify' or 'mvn deploy', there's often no
reason to run 'mvn install'. The only reason I can think of is when you have 2
separate projects (not part of the same multimodule), one depending on the
other and you want to test this.
To ensure that your projects build the same as your co-workers, you should
always try to deploy it. However, there are several reasons why a deploy could
fail: network problems, authentication/authorization issues, repository manager
policies, etc. However, this is still after every install-phase, so the local
repository is polluted.
This is as unpleasant as for a developer local repository as for a CI-server
local repo.
The proposal is to "branch" the final phases.
Calling any phase up until the verify will stay the same.
Calling 'mvn install' would call these phases: validate ... verify, install
(nothing new here)
Calling 'mvn deploy' would call these phases: validate ... verify, deploy (no
more install)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5668) post- should always be executed after
Robert Scholte created MNG-5668:
---
Summary: post- should always be executed after
Key: MNG-5668
URL: https://jira.codehaus.org/browse/MNG-5668
Project: Maven
Issue Type: Sub-task
Components: Plugins and Lifecycle
Reporter: Robert Scholte
Original proposal:
{quote}
There are right now 3 phases which also have a pre- and post-,
namely integration-test, clean and site. However, even if one has bound goals
to the post-phases, they're probably never called.
When there's an integration-test starting up some server, you'd probably always
want to kill it no matter what happens during the IT (let say a NPE).
The proposal is to execute the post- as the finally block in Java. If
you really want to execute only the integration-test without the post, the
phase should be marked, e.g. 'mvn [integration-test]', where the brackets lock
the phase.
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5665: Labels: FDPFC (was: ) > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Robert Scholte > Labels: FDPFC > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5665: Labels: FDPFC (was: ) > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Robert Scholte > Labels: FDPFC > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5665: Labels: (was: FDPFC) > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Robert Scholte > Labels: FDPFC > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5666) Divide build in pre-build, build and post-build
[
https://jira.codehaus.org/browse/MNG-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5666:
Component/s: FDPFC
> Divide build in pre-build, build and post-build
> ---
>
> Key: MNG-5666
> URL: https://jira.codehaus.org/browse/MNG-5666
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>
> Original proposal
> {quote}
> PROPOSAL 1: PerProject and PerPhase Executions
>
> I've recently introduced the installAtEnd/deployAtEnd as an experimental
> feature which should improve the behavior of Maven without having to wait for
> the implementation in Maven Core, which would have a huge impact.
> The reason is that you only want to install and/or deploy only after all
> modules have been build and verified successfully.
> This feature works for most projects, however there are cases which cannot be
> solved by the plugin solution and require a change in the handling of
> lifecycles in Maven Core.
> Up unto the verify-phase you want to execute all phases per project, whereas
> the install and deploy should be executed per phase.
> Consider a root project with 2 modules, these should be executed like this
>
> root : validate ... verify
> module1: validate ... verify
> module2: validate ... verify
> root : install
> module1: install
> module2: install
> root : deploy
> module1: deploy
> module2: deploy
> {quote}
> After one of the google hangout session we came up with the following idea:
> divide the build in pre-build, build and post-build
> First the {{pre-build}} would do a validate of the whole project.
> The {{build}} runs from {{initialize}} up to {{verify}}
> The {{post-build}} would handle the distribution, being {{install}}/{{deploy}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5667) Either install or deploy
[
https://jira.codehaus.org/browse/MNG-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5667:
Component/s: FDPFC
> Either install or deploy
>
>
> Key: MNG-5667
> URL: https://jira.codehaus.org/browse/MNG-5667
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>
> Original proposal
> {quote}
> PROPOSAL 2: Either install or deploy
> In general one should either run 'mvn verify' or 'mvn deploy', there's often
> no reason to run 'mvn install'. The only reason I can think of is when you
> have 2 separate projects (not part of the same multimodule), one depending on
> the other and you want to test this.
> To ensure that your projects build the same as your co-workers, you should
> always try to deploy it. However, there are several reasons why a deploy
> could fail: network problems, authentication/authorization issues, repository
> manager policies, etc. However, this is still after every install-phase, so
> the local repository is polluted.
> This is as unpleasant as for a developer local repository as for a CI-server
> local repo.
>
> The proposal is to "branch" the final phases.
> Calling any phase up until the verify will stay the same.
> Calling 'mvn install' would call these phases: validate ... verify, install
> (nothing new here)
> Calling 'mvn deploy' would call these phases: validate ... verify, deploy
> (no more install)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MNG-5665: --- Assignee: Robert Scholte > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: FDPFC, Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Robert Scholte > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5668) post- should always be executed after
[
https://jira.codehaus.org/browse/MNG-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-5668:
---
Assignee: Robert Scholte
> post- should always be executed after
>
>
> Key: MNG-5668
> URL: https://jira.codehaus.org/browse/MNG-5668
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> Original proposal:
> {quote}
> There are right now 3 phases which also have a pre- and post-,
> namely integration-test, clean and site. However, even if one has bound goals
> to the post-phases, they're probably never called.
> When there's an integration-test starting up some server, you'd probably
> always want to kill it no matter what happens during the IT (let say a NPE).
> The proposal is to execute the post- as the finally block in Java. If
> you really want to execute only the integration-test without the post, the
> phase should be marked, e.g. 'mvn [integration-test]', where the brackets
> lock the phase.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5666) Divide build in pre-build, build and post-build
[
https://jira.codehaus.org/browse/MNG-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-5666:
---
Assignee: Robert Scholte
> Divide build in pre-build, build and post-build
> ---
>
> Key: MNG-5666
> URL: https://jira.codehaus.org/browse/MNG-5666
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> Original proposal
> {quote}
> PROPOSAL 1: PerProject and PerPhase Executions
>
> I've recently introduced the installAtEnd/deployAtEnd as an experimental
> feature which should improve the behavior of Maven without having to wait for
> the implementation in Maven Core, which would have a huge impact.
> The reason is that you only want to install and/or deploy only after all
> modules have been build and verified successfully.
> This feature works for most projects, however there are cases which cannot be
> solved by the plugin solution and require a change in the handling of
> lifecycles in Maven Core.
> Up unto the verify-phase you want to execute all phases per project, whereas
> the install and deploy should be executed per phase.
> Consider a root project with 2 modules, these should be executed like this
>
> root : validate ... verify
> module1: validate ... verify
> module2: validate ... verify
> root : install
> module1: install
> module2: install
> root : deploy
> module1: deploy
> module2: deploy
> {quote}
> After one of the google hangout session we came up with the following idea:
> divide the build in pre-build, build and post-build
> First the {{pre-build}} would do a validate of the whole project.
> The {{build}} runs from {{initialize}} up to {{verify}}
> The {{post-build}} would handle the distribution, being {{install}}/{{deploy}}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5667) Either install or deploy
[
https://jira.codehaus.org/browse/MNG-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-5667:
---
Assignee: Robert Scholte
> Either install or deploy
>
>
> Key: MNG-5667
> URL: https://jira.codehaus.org/browse/MNG-5667
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>
> Original proposal
> {quote}
> PROPOSAL 2: Either install or deploy
> In general one should either run 'mvn verify' or 'mvn deploy', there's often
> no reason to run 'mvn install'. The only reason I can think of is when you
> have 2 separate projects (not part of the same multimodule), one depending on
> the other and you want to test this.
> To ensure that your projects build the same as your co-workers, you should
> always try to deploy it. However, there are several reasons why a deploy
> could fail: network problems, authentication/authorization issues, repository
> manager policies, etc. However, this is still after every install-phase, so
> the local repository is polluted.
> This is as unpleasant as for a developer local repository as for a CI-server
> local repo.
>
> The proposal is to "branch" the final phases.
> Calling any phase up until the verify will stay the same.
> Calling 'mvn install' would call these phases: validate ... verify, install
> (nothing new here)
> Calling 'mvn deploy' would call these phases: validate ... verify, deploy
> (no more install)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5665: Component/s: FDPFC > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: FDPFC, Plugins and Lifecycle >Reporter: Robert Scholte > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5668) post- should always be executed after
[
https://jira.codehaus.org/browse/MNG-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-5668:
Component/s: FDPFC
> post- should always be executed after
>
>
> Key: MNG-5668
> URL: https://jira.codehaus.org/browse/MNG-5668
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>
> Original proposal:
> {quote}
> There are right now 3 phases which also have a pre- and post-,
> namely integration-test, clean and site. However, even if one has bound goals
> to the post-phases, they're probably never called.
> When there's an integration-test starting up some server, you'd probably
> always want to kill it no matter what happens during the IT (let say a NPE).
> The proposal is to execute the post- as the finally block in Java. If
> you really want to execute only the integration-test without the post, the
> phase should be marked, e.g. 'mvn [integration-test]', where the brackets
> lock the phase.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5665) Advanced Lifecycle Handling
[ https://jira.codehaus.org/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-5665: Labels: (was: FDPFC) > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://jira.codehaus.org/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: FDPFC, Plugins and Lifecycle >Reporter: Robert Scholte > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-690) Think about WARNING for module dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MASSEMBLY-690:
--
Fix Version/s: 2.4.1
> Think about WARNING for module dependencies
> ---
>
> Key: MASSEMBLY-690
> URL: https://jira.codehaus.org/browse/MASSEMBLY-690
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: moduleSet
>Affects Versions: 2.4
>Reporter: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 2.4.1
>
>
> Currently the maven-assembly-plugin produces a WARNING like this:
> {code}
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-attached) @ dist ---
> [INFO] Reading assembly descriptor: proj1-assembly.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Building zip:
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin.zip
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-not-attached) @
> dist ---
> [INFO] Reading assembly descriptor: proj1-dir.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Copying files to
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin-dir
> [INFO]
>
> {code}
> If you use a moduleSet within your descriptor which should only happen if
> really problem exist. In this
> [case|https://github.com/khmarbaise/massembly/tree/master/massembly-628] it
> does not exist really a problem, cause all versions are fine.
> This means that we need to check the versions? Can we predict this in a
> better way...? Is this really possible within maven-assembly-plugin ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-690) Think about WARNING for module dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise reassigned MASSEMBLY-690:
-
Assignee: Karl-Heinz Marbaise
> Think about WARNING for module dependencies
> ---
>
> Key: MASSEMBLY-690
> URL: https://jira.codehaus.org/browse/MASSEMBLY-690
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: moduleSet
>Affects Versions: 2.4
>Reporter: Karl-Heinz Marbaise
>Assignee: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 2.4.1
>
>
> Currently the maven-assembly-plugin produces a WARNING like this:
> {code}
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-attached) @ dist ---
> [INFO] Reading assembly descriptor: proj1-assembly.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Building zip:
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin.zip
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-not-attached) @
> dist ---
> [INFO] Reading assembly descriptor: proj1-dir.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Copying files to
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin-dir
> [INFO]
>
> {code}
> If you use a moduleSet within your descriptor which should only happen if
> really problem exist. In this
> [case|https://github.com/khmarbaise/massembly/tree/master/massembly-628] it
> does not exist really a problem, cause all versions are fine.
> This means that we need to check the versions? Can we predict this in a
> better way...? Is this really possible within maven-assembly-plugin ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-690) Think about WARNING for module dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MASSEMBLY-690.
-
Resolution: Fixed
Fixed in [r1613503|http://svn.apache.org/r1613503].
> Think about WARNING for module dependencies
> ---
>
> Key: MASSEMBLY-690
> URL: https://jira.codehaus.org/browse/MASSEMBLY-690
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: moduleSet
>Affects Versions: 2.4
>Reporter: Karl-Heinz Marbaise
>Assignee: Karl-Heinz Marbaise
>Priority: Minor
> Fix For: 2.4.1
>
>
> Currently the maven-assembly-plugin produces a WARNING like this:
> {code}
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-attached) @ dist ---
> [INFO] Reading assembly descriptor: proj1-assembly.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Building zip:
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin.zip
> [INFO]
> [INFO] --- maven-assembly-plugin:2.4:single (make-bundles-not-attached) @
> dist ---
> [INFO] Reading assembly descriptor: proj1-dir.xml
> [WARNING] NOTE: Currently, inclusion of module dependencies may produce
> unpredictable results if a version conflict occurs.
> [INFO] Copying files to
> /Users/kama/ws-git/apache/massembly/massembly-628/dist/target/dist-1.0.0-SNAPSHOT-bin-dir
> [INFO]
>
> {code}
> If you use a moduleSet within your descriptor which should only happen if
> really problem exist. In this
> [case|https://github.com/khmarbaise/massembly/tree/master/massembly-628] it
> does not exist really a problem, cause all versions are fine.
> This means that we need to check the versions? Can we predict this in a
> better way...? Is this really possible within maven-assembly-plugin ?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-767) mockito should be under test scope not compile code for accurev provider
Dan Tran created SCM-767: Summary: mockito should be under test scope not compile code for accurev provider Key: SCM-767 URL: https://jira.codehaus.org/browse/SCM-767 Project: Maven SCM Issue Type: Task Components: maven-scm-provider-accurev Affects Versions: 1.9.1 Reporter: Dan Tran will use this opportunity to promote mockito to dedenencyManagement using version 1.9.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-767) mockito should be under test scope not compile code for accurev provider
[ https://jira.codehaus.org/browse/SCM-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-767: - Fix Version/s: 1.9.2 Assignee: Dan Tran > mockito should be under test scope not compile code for accurev provider > > > Key: SCM-767 > URL: https://jira.codehaus.org/browse/SCM-767 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-accurev >Affects Versions: 1.9.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.9.2 > > > will use this opportunity to promote mockito to dedenencyManagement using > version 1.9.5 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-768) TfsBranchCommandTest is failing
Dan Tran created SCM-768: Summary: TfsBranchCommandTest is failing Key: SCM-768 URL: https://jira.codehaus.org/browse/SCM-768 Project: Maven SCM Issue Type: Task Components: maven-scm-provider-tfs Reporter: Dan Tran it is currently failing under 1.9.2-SNAPSHOT -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-768) TfsBranchCommandTest is failing
[ https://jira.codehaus.org/browse/SCM-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-768: - Description: it is currently failing under 1.9.2-SNAPSHOT. Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec <<< FAILURE! - in org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest testCommandline(org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest) Time elapsed: 0.016 sec <<< FAILURE! junit.framework.ComparisonFailure: null expected:<...login:user,password [C:\Users\trand8\dev\maven\maven-scm\maven-scm-providers\maven-scm-provider-tfs\target\scm-test\working-copy] -checkin branch"> but was:<...login:user,password [serverpath] -checkin branch"> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.scm.ScmTestCase.assertCommandLine(ScmTestCase.java:364) at org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest.testCommandline(TfsBranchCommandTest.java:36) was:it is currently failing under 1.9.2-SNAPSHOT > TfsBranchCommandTest is failing > > > Key: SCM-768 > URL: https://jira.codehaus.org/browse/SCM-768 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-tfs >Reporter: Dan Tran > > it is currently failing under 1.9.2-SNAPSHOT. > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec <<< > FAILURE! - in org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest > testCommandline(org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest) > Time elapsed: 0.016 sec <<< FAILURE! > junit.framework.ComparisonFailure: null expected:<...login:user,password > [C:\Users\trand8\dev\maven\maven-scm\maven-scm-providers\maven-scm-provider-tfs\target\scm-test\working-copy] > -checkin branch"> > but was:<...login:user,password [serverpath] -checkin branch"> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > org.apache.maven.scm.ScmTestCase.assertCommandLine(ScmTestCase.java:364) > at > org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest.testCommandline(TfsBranchCommandTest.java:36) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-759) cannot create Branch with TFS-provider: "TF10125: The path must start with $/"
[
https://jira.codehaus.org/browse/SCM-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Tran reopened SCM-759:
--
> cannot create Branch with TFS-provider: "TF10125: The path must start with $/"
> --
>
> Key: SCM-759
> URL: https://jira.codehaus.org/browse/SCM-759
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-tfs
>Affects Versions: 1.9
> Environment: TFS-2010, SP1
>Reporter: Ohad R
>Assignee: Herve Boutemy
> Fix For: 1.9.2
>
>
> Running the maven command:
> mvn release:branch -DbranchName=$/NNG/ORK/maven-branch-10
> invokes finally
> tf branch D:\Dev\projects\NNG\ORK\dev\PLS -checkin $/NNG/ORK/maven-branch-10
> this causes an error:
> {color:red}"TF10125: The path must start with $/"{color}
> After a research I found the *checkin* statement causes this problem, because
> if I comment out the "checkin" argument (in
> {{org.apache.maven.scm.provider.tfs.command.TfsBranchCommand}}), it works
> fine. However, we _do_ want to use the "checkin" statement because we want
> the new branch to be checked-in. I found out that it will be OK to use
> "checkin", only if we use a TFS path (starts with '$/'), instead of
> local-path.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-229) Compilation error should be reported as by javac tool
Leonid Ilyevsky created MCOMPILER-229: - Summary: Compilation error should be reported as by javac tool Key: MCOMPILER-229 URL: https://jira.codehaus.org/browse/MCOMPILER-229 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.1, 3.2 Environment: All Reporter: Leonid Ilyevsky Currently for compilation error the plugin prints out the java file path, with the line number and position number in brackets, and no more details. This is very inconvenient, especially when doing build from command line. Unlike this, if you simply invoke "javac", it will print the whole line from Java file that contains the error, and under that a line with a single "^" symbol pointing to the problematic location on that line. It would be very useful to add this feature, at least as an option (though I believe it should be fine to just fix it so it behaves exactly like javac). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-768) TfsBranchCommandTest is failing
[ https://jira.codehaus.org/browse/SCM-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350365#comment-350365 ] Dan Tran commented on SCM-768: -- it only fails when run under the whose suite, pass as standalone test > TfsBranchCommandTest is failing > > > Key: SCM-768 > URL: https://jira.codehaus.org/browse/SCM-768 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-tfs >Reporter: Dan Tran > > it is currently failing under 1.9.2-SNAPSHOT. > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec <<< > FAILURE! - in org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest > testCommandline(org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest) > Time elapsed: 0.016 sec <<< FAILURE! > junit.framework.ComparisonFailure: null expected:<...login:user,password > [C:\Users\trand8\dev\maven\maven-scm\maven-scm-providers\maven-scm-provider-tfs\target\scm-test\working-copy] > -checkin branch"> > but was:<...login:user,password [serverpath] -checkin branch"> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > org.apache.maven.scm.ScmTestCase.assertCommandLine(ScmTestCase.java:364) > at > org.apache.maven.scm.provider.tfs.command.TfsBranchCommandTest.testCommandline(TfsBranchCommandTest.java:36) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINSTALL-54) [INFO] Error installing artifact's metadata
[
https://jira.codehaus.org/browse/MINSTALL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350366#comment-350366
]
sam hendley commented on MINSTALL-54:
-
Are there any workarounds or any way to disable to this behavior? This issue is
still biting us on 3.04 when we try to run multiple maven jobs at same time
that are producing different versions of the same artifacts.
> [INFO] Error installing artifact's metadata
> ---
>
> Key: MINSTALL-54
> URL: https://jira.codehaus.org/browse/MINSTALL-54
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.2
> Environment: Windows XP
>Reporter: geoff simpson
> Attachments: minstall-54-error-install-artifact.patch
>
>
> {noformat}
> [INFO] Error installing artifact's metadata: Error installing metadata: Error
> updating group repository metadata
> end tag not allowed in epilog but got / (position: END_TAG seen ...\n
> {noformat}
> Looks like there might be an issue with updates to
> {{maven-metadata-local.xml}} during the {{mvn install}} task. we have a build
> server that is multi threaded. we often see this in the
> {code:xml}
>
>
>
> {code}
> {{maven-metadata-local.xml}}.
> maybe a solution is to add {{maven-metadata-local.xml.lock}} to ensure two
> threads don't update the file at the same time
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-767) mockito should be under test scope, not compile scope for accurev provider
[ https://jira.codehaus.org/browse/SCM-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated SCM-767: - Description: will use this opportunity to promote mockito to dedenencyManagement using version 1.9.5, since there are a number of providers also using it during test (was: will use this opportunity to promote mockito to dedenencyManagement using version 1.9.5) Summary: mockito should be under test scope, not compile scope for accurev provider (was: mockito should be under test scope not compile code for accurev provider) > mockito should be under test scope, not compile scope for accurev provider > --- > > Key: SCM-767 > URL: https://jira.codehaus.org/browse/SCM-767 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-accurev >Affects Versions: 1.9.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.9.2 > > > will use this opportunity to promote mockito to dedenencyManagement using > version 1.9.5, since there are a number of providers also using it during test -- This message was sent by Atlassian JIRA (v6.1.6#6162)
