[jira] [Created] (MPOM-141) Upgrade maven-assembly-plugin to 3.0.0.

2016-12-17 Thread Christian Schulte (JIRA)
Christian Schulte created MPOM-141:
--

 Summary: Upgrade maven-assembly-plugin to 3.0.0.
 Key: MPOM-141
 URL: https://issues.apache.org/jira/browse/MPOM-141
 Project: Maven POMs
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MPOM-140) Upgrade maven-assembly-plugin to 3.0.0.

2016-12-17 Thread Christian Schulte (JIRA)
Christian Schulte created MPOM-140:
--

 Summary: Upgrade maven-assembly-plugin to 3.0.0.
 Key: MPOM-140
 URL: https://issues.apache.org/jira/browse/MPOM-140
 Project: Maven POMs
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.

2016-12-16 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6135.
--
   Resolution: Fixed
Fix Version/s: 3.4.0

> Maven plugins and core extensions are not dependencies, they should be 
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.

2016-12-16 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6135:
---
Summary: Maven plugins and core extensions are not dependencies, they 
should be resolved the same way as projects.  (was: Maven plugins are not 
dependencies, they should be resolved the same way as projects.)

> Maven plugins and core extensions are not dependencies, they should be 
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOLVER-11) Project dependency collection result should contain repositories.

2016-12-15 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOLVER-11.
--
Resolution: Fixed

> Project dependency collection result should contain repositories.
> -
>
> Key: MRESOLVER-11
> URL: https://issues.apache.org/jira/browse/MRESOLVER-11
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The resolution result provided when performing project dependency collection 
> is lacking the repositories from the collection request. Components the 
> project root node is passed to (transformers, for example), expect this 
> information to be provided.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOLVER-11) Project dependency collection result should contain repositories.

2016-12-15 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOLVER-11:
--

 Summary: Project dependency collection result should contain 
repositories.
 Key: MRESOLVER-11
 URL: https://issues.apache.org/jira/browse/MRESOLVER-11
 Project: Maven Resolver
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
 Fix For: Maven Artifact Resolver 1.2.0


The resolution result provided when performing project dependency collection is 
lacking the repositories from the collection request. Components the project 
root node is passed to (transformers, for example), expect this information to 
be provided.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MNG-6135) Maven plugins are not dependencies, they should be resolved the same way as projects.

2016-12-15 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-6135:
--

 Summary: Maven plugins are not dependencies, they should be 
resolved the same way as projects.
 Key: MNG-6135
 URL: https://issues.apache.org/jira/browse/MNG-6135
 Project: Maven
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Critical






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.

2016-12-15 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOLVER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15750898#comment-15750898
 ] 

Christian Schulte commented on MRESOLVER-10:


Added with 
[commit|https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d].

> New class 'TransitiveDependencyManager' supporting transitive dependency 
> management.
> 
>
> Key: MRESOLVER-10
> URL: https://issues.apache.org/jira/browse/MRESOLVER-10
> Project: Maven Resolver
>  Issue Type: New Feature
>  Components: resolver
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from 
> transitive dependencies to maintain backwards compatibility with Maven 2. The 
> {{TransitiveDependencyManager}} will correctly use that dependency management 
> (it could also be named {{DefaultDependencyManager}}).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.

2016-12-15 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOLVER-10.
--
Resolution: Fixed

> New class 'TransitiveDependencyManager' supporting transitive dependency 
> management.
> 
>
> Key: MRESOLVER-10
> URL: https://issues.apache.org/jira/browse/MRESOLVER-10
> Project: Maven Resolver
>  Issue Type: New Feature
>  Components: resolver
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The {{ClassicDependencyManager}} ignores the dependency management from 
> transitive dependencies to maintain backwards compatibility with Maven 2. The 
> {{TransitiveDependencyManager}} will correctly use that dependency management 
> (it could also be named {{DefaultDependencyManager}}).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOLVER-10) New class 'TransitiveDependencyManager' supporting transitive dependency management.

2016-12-15 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOLVER-10:
--

 Summary: New class 'TransitiveDependencyManager' supporting 
transitive dependency management.
 Key: MRESOLVER-10
 URL: https://issues.apache.org/jira/browse/MRESOLVER-10
 Project: Maven Resolver
  Issue Type: New Feature
  Components: resolver
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Minor
 Fix For: Maven Artifact Resolver 1.2.0


The {{ClassicDependencyManager}} ignores the dependency management from 
transitive dependencies to maintain backwards compatibility with Maven 2. The 
{{TransitiveDependencyManager}} will correctly use that dependency management 
(it could also be named {{DefaultDependencyManager}}).




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MASSEMBLY-841) Maven Assembly Plugin throws IllegalStateException when looking for project modules

2016-12-14 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MASSEMBLY-841.
---
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: (was: 3.0.0)
   3.0.1

Thanks.

> Maven Assembly Plugin throws IllegalStateException when looking for project 
> modules
> ---
>
> Key: MASSEMBLY-841
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-841
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5, 3.0.0
>Reporter: Sean Usher
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.0.1
>
>
> In my project, we have multiple modules, some of which also contain other 
> modules.
> When building one specific module (which itself had child modules) from the 
> root pom file, the build would fail when maven-assembly-plugin threw an 
> IllegalStateException, but building from the module's pom.xml file directly, 
> the build succeeded.
> I narrowed this down to the candidateIterator being set to null after 
> .remove() is called, and that iterator not being updated to the next item 
> before using it as a candidate for other projects.
> This change ensures that after removing the item from the iterator, that we 
> move to the next item before doing anymore comparisons.
> This is the stacktrace from the maven-assembly-plugin failure:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (default) on 
> project Flatternscore_by_tenantid_daily: Execution def
> ault of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single 
> failed. IllegalStateException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (default) on 
> projec
> t Flatternscore_by_tenantid_daily: Execution default of goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed.
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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:116)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default of goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single 
> failed.
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.IllegalStateException
> at 
> java.util.LinkedHashMap$LinkedHashIterator.remove(LinkedHashMap.java:722)
> at 
> org.apache.maven.plugin.assembly.utils.ProjectUtils.getProjectModules(ProjectUtils.java:128)
> at 
> org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase.getModuleProjects(ModuleSetAssemblyPhase.java:566)
> at 
> 

[jira] [Updated] (MNG-5761) Dependency management is not transitive.

2016-12-13 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-5761:
---
Fix Version/s: (was: 3.5.0)
   3.4.0

> Dependency management is not transitive.
> 
>
> Key: MNG-5761
> URL: https://issues.apache.org/jira/browse/MNG-5761
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.2.5
>Reporter: Jeff Schnitzer
>Assignee: Christian Schulte
>Priority: Critical
>  Labels: requires-aether-release
> Fix For: 3.4.0
>
> Attachments: MNG-5761.zip
>
>
> A detailed description of the issue is here:
> http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies
> The short of it is that maven appears to be using the wrong 
>  version in a transitive dependency.  There are two 
> relevant  sections in the build, one pulled in by guice 
> and one pulled in by gwizard-parent. These are the dependency paths from the 
> top:
> gwizard-example -> gwizard-config -> gwizard-parent
> gwizard-example -> gwizard-config -> guice -> guice-parent
> gwizard-parent's dependencyManagement specifies guava 18
> guice-parent's dependencyManagement specifies guava 16
> Guava 16 is winning. This seems highly undesirable, and in fact it breaks our 
> build. I would expect that in a version # fight, "closest to the top" should 
> win.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

2016-12-13 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746426#comment-15746426
 ] 

Christian Schulte commented on MNG-6082:


There is one last issue I will need to commit to master. After that, time has 
come to start working on the release notes and the website in general to 
document all of what is on master cleanly with examples. Once that is done, we 
have something to talk about. I need to finish that one last issue and then 
will need an awful lot of time documenting all of that. Once that documentation 
is in place, everyone can read about what is coming with 3.4 and this maybe 
will lead to further work on master. Without that documentation there is 
nothing to talk about. Takes time.


> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

2016-12-13 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746384#comment-15746384
 ] 

Christian Schulte commented on MNG-6082:


Hard worded? Pussy :-) It is totally bollocks and worth nothing now. See the 
'Activity' tab what has changed recently. Plenty of issues were linked to this 
one. I removed those links because the issues were fixed without bumping the 
model version. I then wanted to delete this issue but couldn't. Closed it 
'Won't Fix'. Someone with permissions can safely delete it.


> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management.

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOLVER-9.
-
   Resolution: Fixed
Fix Version/s: Maven Artifact Resolver 1.2.0

Fixed with 
[this|https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=1ee92862c67ec98564c4d8be1207355960f1dd5d]
 commit.

> DefaultDependencyCollector does not correctly handle dependency management.
> ---
>
> Key: MRESOLVER-9
> URL: https://issues.apache.org/jira/browse/MRESOLVER-9
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> During dependency processing the 'DependencySelector' is called to decide if 
> a dependency is to be selected. The call to 
> 'DependencySelector.selectDependency( dependency )' is performed with the 
> unmanagement dependency but needs to be performed with the managed 
> dependency. With the fix applied, the result no longer contains dependencies 
> whose scope or optionality has been managed to not be part of the result 
> (correct behaviour). Without the fix applied, the result contains 
> dependencies with a managed scope or optionality not filtered out by the 
> 'DependencySelector' in use (incorrect behaviour).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOLVER-9) DefaultDependencyCollector does not correctly handle dependency management.

2016-12-10 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOLVER-9:
-

 Summary: DefaultDependencyCollector does not correctly handle 
dependency management.
 Key: MRESOLVER-9
 URL: https://issues.apache.org/jira/browse/MRESOLVER-9
 Project: Maven Resolver
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Critical


During dependency processing the 'DependencySelector' is called to decide if a 
dependency is to be selected. The call to 'DependencySelector.selectDependency( 
dependency )' is performed with the unmanagement dependency but needs to be 
performed with the managed dependency. With the fix applied, the result no 
longer contains dependencies whose scope or optionality has been managed to not 
be part of the result (correct behaviour). Without the fix applied, the result 
contains dependencies with a managed scope or optionality not filtered out by 
the 'DependencySelector' in use (incorrect behaviour).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOLVER-8) Mode selection (transitive vs. direct) implemented inconsistently in classes 'ScopeDependencySelector' and 'OptionalDependencySelector'.

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOLVER-8.
-
Resolution: Fixed

> Mode selection (transitive vs. direct) implemented inconsistently in classes 
> 'ScopeDependencySelector' and 'OptionalDependencySelector'.
> 
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The classes 'ScopeDependencySelector' and 'OptionalDependencySelector' 
> inconsistently detected the mode of operation (direct or transitive). Whereas 
> the 'ScopeDependencySelector' honours the kind of resolution having been 
> requested (dependency vs. POM), the 'OptionalDependencySelector' does not 
> honour this difference. As both classes implement the 'DependencySelector', 
> they should select the mode of operation (direct vs. transitive) consistently.
> This is what things looked liked before the fix:
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( this.transitive || context.getDependency() == null )
> {
> return this;
> }
> return new ScopeDependencySelector( true, included, excluded );
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( depth >= 2 )
> {
> return this;
> }
> return new OptionalDependencySelector( depth + 1 );
> }
> {code}
> {panel}
> This is what both classes look like after the fix. No difference in mode 
> selection any more.
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> ScopeDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new ScopeDependencySelector( true, this.included, 
> this.excluded );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new ScopeDependencySelector( false, this.included, 
> this.excluded );
> }
> return child;
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> OptionalDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new OptionalDependencySelector( true );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new OptionalDependencySelector( false );
> }
> return child;
> }
> {code}
> {panel}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOLVER-8) Mode selection (transitive vs. direct) implemented inconsistently accross 'ScopeDependencySelector' and 'OptionalDependencySelector'.

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOLVER-8:
--
Summary: Mode selection (transitive vs. direct) implemented inconsistently 
accross 'ScopeDependencySelector' and 'OptionalDependencySelector'.  (was: 
Direct dependencies incorrectly detected as transitive.)

> Mode selection (transitive vs. direct) implemented inconsistently accross 
> 'ScopeDependencySelector' and 'OptionalDependencySelector'.
> -
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The classes 'ScopeDependencySelector' and 'OptionalDependencySelector' 
> inconsistently detected the mode of operation (direct or transitive). Whereas 
> the 'ScopeDependencySelector' honours the kind of resolution having been 
> requested (dependency vs. POM), the 'OptionalDependencySelector' does not 
> honour this difference. As both classes implement the 'DependencySelector', 
> they should select the mode of operation (direct vs. transitive) consistently.
> This is what things looked liked before the fix:
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( this.transitive || context.getDependency() == null )
> {
> return this;
> }
> return new ScopeDependencySelector( true, included, excluded );
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( depth >= 2 )
> {
> return this;
> }
> return new OptionalDependencySelector( depth + 1 );
> }
> {code}
> {panel}
> This is what both classes look like after the fix. No difference in mode 
> selection any more.
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> ScopeDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new ScopeDependencySelector( true, this.included, 
> this.excluded );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new ScopeDependencySelector( false, this.included, 
> this.excluded );
> }
> return child;
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> OptionalDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new OptionalDependencySelector( true );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new OptionalDependencySelector( false );
> }
> return child;
> }
> {code}
> {panel}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOLVER-8) Mode selection (transitive vs. direct) implemented inconsistently in classes 'ScopeDependencySelector' and 'OptionalDependencySelector'.

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOLVER-8:
--
Summary: Mode selection (transitive vs. direct) implemented inconsistently 
in classes 'ScopeDependencySelector' and 'OptionalDependencySelector'.  (was: 
Mode selection (transitive vs. direct) implemented inconsistently accross 
'ScopeDependencySelector' and 'OptionalDependencySelector'.)

> Mode selection (transitive vs. direct) implemented inconsistently in classes 
> 'ScopeDependencySelector' and 'OptionalDependencySelector'.
> 
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The classes 'ScopeDependencySelector' and 'OptionalDependencySelector' 
> inconsistently detected the mode of operation (direct or transitive). Whereas 
> the 'ScopeDependencySelector' honours the kind of resolution having been 
> requested (dependency vs. POM), the 'OptionalDependencySelector' does not 
> honour this difference. As both classes implement the 'DependencySelector', 
> they should select the mode of operation (direct vs. transitive) consistently.
> This is what things looked liked before the fix:
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( this.transitive || context.getDependency() == null )
> {
> return this;
> }
> return new ScopeDependencySelector( true, included, excluded );
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( depth >= 2 )
> {
> return this;
> }
> return new OptionalDependencySelector( depth + 1 );
> }
> {code}
> {panel}
> This is what both classes look like after the fix. No difference in mode 
> selection any more.
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> ScopeDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new ScopeDependencySelector( true, this.included, 
> this.excluded );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new ScopeDependencySelector( false, this.included, 
> this.excluded );
> }
> return child;
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> OptionalDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new OptionalDependencySelector( true );
> }
> if ( context.getDependency() == null && child.transitive )
> {
> child = new OptionalDependencySelector( false );
> }
> return child;
> }
> {code}
> {panel}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOLVER-8) Direct dependencies incorrectly detected as transitive.

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOLVER-8:
--
Description: 
The classes 'ScopeDependencySelector' and 'OptionalDependencySelector' 
inconsistently detected the mode of operation (direct or transitive). Whereas 
the 'ScopeDependencySelector' honours the kind of resolution having been 
requested (dependency vs. POM), the 'OptionalDependencySelector' does not 
honour this difference. As both classes implement the 'DependencySelector', 
they should select the mode of operation (direct vs. transitive) consistently.

This is what things looked liked before the fix:

{panel:title=ScopeDependencySelector}
{code}
public DependencySelector deriveChildSelector( DependencyCollectionContext 
context )
{
if ( this.transitive || context.getDependency() == null )
{
return this;
}

return new ScopeDependencySelector( true, included, excluded );
}
{code}
{panel}

{panel:title=OptionalDependencySelector}
{code}
public DependencySelector deriveChildSelector( DependencyCollectionContext 
context )
{
if ( depth >= 2 )
{
return this;
}

return new OptionalDependencySelector( depth + 1 );
}
{code}
{panel}

This is what both classes look like after the fix. No difference in mode 
selection any more.

{panel:title=ScopeDependencySelector}
{code}
public DependencySelector deriveChildSelector( DependencyCollectionContext 
context )
{
ScopeDependencySelector child = this;

if ( context.getDependency() != null && !child.transitive )
{
child = new ScopeDependencySelector( true, this.included, this.excluded 
);
}
if ( context.getDependency() == null && child.transitive )
{
child = new ScopeDependencySelector( false, this.included, 
this.excluded );
}

return child;
}
{code}
{panel}

{panel:title=OptionalDependencySelector}
{code}
public DependencySelector deriveChildSelector( DependencyCollectionContext 
context )
{
OptionalDependencySelector child = this;

if ( context.getDependency() != null && !child.transitive )
{
child = new OptionalDependencySelector( true );
}
if ( context.getDependency() == null && child.transitive )
{
child = new OptionalDependencySelector( false );
}

return child;
}
{code}
{panel}



  was:
The 'DefaultDependencyCollector' updates the state of the 
'DependencyCollectionContext' when recursively processing dependencies but does 
never return the context to the former state. This context is passed to various 
methods when deriving child components ('DependencyManager.deriveChildManager', 
'DependencySelector.deriveChildSelector', 
'DependencyTraverser.deriveChildTraverser', 'VersionFilter.deriveChildFilter') 
which fail to correctly detect the depth/transitivity of the context passed due 
to that context never getting reset after recursion.



> Direct dependencies incorrectly detected as transitive.
> ---
>
> Key: MRESOLVER-8
> URL: https://issues.apache.org/jira/browse/MRESOLVER-8
> Project: Maven Resolver
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: Maven Artifact Resolver 1.2.0
>
>
> The classes 'ScopeDependencySelector' and 'OptionalDependencySelector' 
> inconsistently detected the mode of operation (direct or transitive). Whereas 
> the 'ScopeDependencySelector' honours the kind of resolution having been 
> requested (dependency vs. POM), the 'OptionalDependencySelector' does not 
> honour this difference. As both classes implement the 'DependencySelector', 
> they should select the mode of operation (direct vs. transitive) consistently.
> This is what things looked liked before the fix:
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( this.transitive || context.getDependency() == null )
> {
> return this;
> }
> return new ScopeDependencySelector( true, included, excluded );
> }
> {code}
> {panel}
> {panel:title=OptionalDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> if ( depth >= 2 )
> {
> return this;
> }
> return new OptionalDependencySelector( depth + 1 );
> }
> {code}
> {panel}
> This is what both classes look like after the fix. No difference in mode 
> selection any more.
> {panel:title=ScopeDependencySelector}
> {code}
> public DependencySelector deriveChildSelector( DependencyCollectionContext 
> context )
> {
> ScopeDependencySelector child = this;
> if ( context.getDependency() != null && !child.transitive )
> {
> child = new 

[jira] [Assigned] (MNG-6110) Upgrade Aether to Maven Resolver 1.2

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reassigned MNG-6110:
--

Assignee: Christian Schulte

> Upgrade Aether to Maven Resolver 1.2
> 
>
> Key: MNG-6110
> URL: https://issues.apache.org/jira/browse/MNG-6110
> Project: Maven
>  Issue Type: Dependency upgrade
>  Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Harald Wellmann
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> Replace Aether by Maven Resolver to make use of the latest bugfixes and 
> enhancements related to dependency collection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6082) Introduction of model version 4.1.0

2016-12-10 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6082.
--
Resolution: Won't Fix
  Assignee: (was: Christian Schulte)

> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-756) escapeString doesn't work correctly for the 2nd filtering

2016-12-07 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729085#comment-15729085
 ] 

Christian Schulte commented on MASSEMBLY-756:
-

May I ask what the escape string is set to? Is it set to a single backslash? I 
am asking because this {code}\\${id}{code} would need to become {code}\\value 
of id{code} after filtering! That's what the {{maven-resources-plugin}} would 
produce intentionally. Having said that, the description of the issue is wrong 
and should read:

The result should be:
{code}property.C=prefix \\value of id text-in-the-middle \\value of id 
suffix{code}

To get the expected result, the input would need to look like:
{code}property.double_escaped=prefix \${id} text-in-the-middle \${id} 
suffix{code}

Note: The filtering does not know about anything file format specific. Escaping 
the backslash in a properties resource file is wrong here. The filtering does 
not know anything about any file format specific escaping rules intentionally.


> escapeString doesn't work correctly for the 2nd filtering
> -
>
> Key: MASSEMBLY-756
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-756
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.5.3
>Reporter: Vítor Moreira
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: escapeString.zip
>
>
> If we have a filter file with some escapeString, there are situations that 
> escaping doesn't work.
> For example, you have a filter file with two escaped filters:
> {code}property.double_escaped=prefix \\${id} text-in-the-middle \\${id} 
> suffix{code}
> And that property is used in a config file, for example:
> {code}property.C=${property.double_escaped}{code}
> The result should be:
> {code}property.C=prefix ${id} text-in-the-middle ${id} suffix{code}
> And not this:
> {code}property.C=prefix ${id} text-in-the-middle \{id} suffix{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MASSEMBLY-756) escapeString doesn't work correctly for the 2nd filtering

2016-12-07 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15729086#comment-15729086
 ] 

Christian Schulte commented on MASSEMBLY-756:
-

May I ask what the escape string is set to? Is it set to a single backslash? I 
am asking because this {code}\\${id}{code} would need to become {code}\\value 
of id{code} after filtering! That's what the {{maven-resources-plugin}} would 
produce intentionally. Having said that, the description of the issue is wrong 
and should read:

The result should be:
{code}property.C=prefix \\value of id text-in-the-middle \\value of id 
suffix{code}

To get the expected result, the input would need to look like:
{code}property.double_escaped=prefix \${id} text-in-the-middle \${id} 
suffix{code}

Note: The filtering does not know about anything file format specific. Escaping 
the backslash in a properties resource file is wrong here. The filtering does 
not know anything about any file format specific escaping rules intentionally.


> escapeString doesn't work correctly for the 2nd filtering
> -
>
> Key: MASSEMBLY-756
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-756
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.5.3
>Reporter: Vítor Moreira
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: escapeString.zip
>
>
> If we have a filter file with some escapeString, there are situations that 
> escaping doesn't work.
> For example, you have a filter file with two escaped filters:
> {code}property.double_escaped=prefix \\${id} text-in-the-middle \\${id} 
> suffix{code}
> And that property is used in a config file, for example:
> {code}property.C=${property.double_escaped}{code}
> The result should be:
> {code}property.C=prefix ${id} text-in-the-middle ${id} suffix{code}
> And not this:
> {code}property.C=prefix ${id} text-in-the-middle \{id} suffix{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Issue Comment Deleted] (MASSEMBLY-756) escapeString doesn't work correctly for the 2nd filtering

2016-12-07 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MASSEMBLY-756:

Comment: was deleted

(was: May I ask what the escape string is set to? Is it set to a single 
backslash? I am asking because this {code}\\${id}{code} would need to become 
{code}\\value of id{code} after filtering! That's what the 
{{maven-resources-plugin}} would produce intentionally. Having said that, the 
description of the issue is wrong and should read:

The result should be:
{code}property.C=prefix \\value of id text-in-the-middle \\value of id 
suffix{code}

To get the expected result, the input would need to look like:
{code}property.double_escaped=prefix \${id} text-in-the-middle \${id} 
suffix{code}

Note: The filtering does not know about anything file format specific. Escaping 
the backslash in a properties resource file is wrong here. The filtering does 
not know anything about any file format specific escaping rules intentionally.
)

> escapeString doesn't work correctly for the 2nd filtering
> -
>
> Key: MASSEMBLY-756
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-756
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.5.3
>Reporter: Vítor Moreira
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: escapeString.zip
>
>
> If we have a filter file with some escapeString, there are situations that 
> escaping doesn't work.
> For example, you have a filter file with two escaped filters:
> {code}property.double_escaped=prefix \\${id} text-in-the-middle \\${id} 
> suffix{code}
> And that property is used in a config file, for example:
> {code}property.C=${property.double_escaped}{code}
> The result should be:
> {code}property.C=prefix ${id} text-in-the-middle ${id} suffix{code}
> And not this:
> {code}property.C=prefix ${id} text-in-the-middle \{id} suffix{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (MRESOURCES-230) Can't escape the escape string

2016-12-05 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722026#comment-15722026
 ] 

Christian Schulte edited comment on MRESOURCES-230 at 12/5/16 11:27 AM:


It is not possible to fix this without breaking backwards compatibility. For 
example: Properties resources use the backslash themselves for escaping. They 
rely on filtering to preserve any escape not specific to maven. IN = two 
bachslashes must lead to OUT = two backslashes for those resources. If an 
update makes it OUT = one backslash, those resources are broken after 
filtering. That's why it has been done intentionally. Only escape what is known 
to maven filtering - leave the rest as is. Solution is to use an escape string 
(that's a string not only a single character) not conflicting with anything 
else in the file. For example: You could set the escape string to {{§§§}} or 
something unlikely to conflict with anything in the file.


was (Author: schulte77):
It is not possible to fix this without breaking backwards compatibility. For 
example: Properties resources use the backslash themselves for escaping. They 
rely on filtering to preserve any escape not specific to maven. {{IN = '\\'}} 
must lead to {{OUT = '\\'}} for those resources. If an update makes it {{OUT = 
'\' }}, those resources are broken after filtering. That's why it has been done 
intentionally. Only escape what is known to maven filtering - leave the rest as 
is. Solution is to use an escape string (that's a string not only a single 
character) not conflicting with anything else in the file. For example: You 
could set the escape string to {{§§§}} or something unlikely to conflict with 
anything in the file.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (MRESOURCES-230) Can't escape the escape string

2016-12-05 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722026#comment-15722026
 ] 

Christian Schulte edited comment on MRESOURCES-230 at 12/5/16 11:27 AM:


It is not possible to fix this without breaking backwards compatibility. For 
example: Properties resources use the backslash themselves for escaping. They 
rely on filtering to preserve any escape not specific to maven. {{IN = '\\'}} 
must lead to {{OUT = '\\'}} for those resources. If an update makes it {{OUT = 
'\' }}, those resources are broken after filtering. That's why it has been done 
intentionally. Only escape what is known to maven filtering - leave the rest as 
is. Solution is to use an escape string (that's a string not only a single 
character) not conflicting with anything else in the file. For example: You 
could set the escape string to {{§§§}} or something unlikely to conflict with 
anything in the file.


was (Author: schulte77):
It is not possible to fix this without breaking backwards compatibility. For 
example: Properties resources use the backslash themselves for escaping. They 
rely on filtering to preserve any escape not specific to maven. IN = '\\' must 
lead to OUT = '\\' for those resources. If an update makes it OUT = '\', those 
resources are broken after filtering. That's why it has been done 
intentionally. Only escape what is known to maven filtering - leave the rest as 
is. Solution is to use an escape string (that's a string not only a single 
character) not conflicting with anything else in the file. For example: You 
could set the escape string to {{§§§}} or something unlikely to conflict with 
anything in the file.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

2016-12-05 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15722026#comment-15722026
 ] 

Christian Schulte commented on MRESOURCES-230:
--

It is not possible to fix this without breaking backwards compatibility. For 
example: Properties resources use the backslash themselves for escaping. They 
rely on filtering to preserve any escape not specific to maven. IN = '\\' must 
lead to OUT = '\\' for those resources. If an update makes it OUT = '\', those 
resources are broken after filtering. That's why it has been done 
intentionally. Only escape what is known to maven filtering - leave the rest as 
is. Solution is to use an escape string (that's a string not only a single 
character) not conflicting with anything else in the file. For example: You 
could set the escape string to {{§§§}} or something unlikely to conflict with 
anything in the file.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

2016-12-04 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15720452#comment-15720452
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Just upgrade to 3.0.2 when released and do not enable escaping by setting the 
{{escapeString}} parameter. You do not want any escaping to take place, 
correct? That default will have been restored in 3.0.2.


> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-235) Revert enabling escaping by default introduced in 3.0.0.

2016-12-04 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-235.

Resolution: Fixed

> Revert enabling escaping by default introduced in 3.0.0.
> 
>
> Key: MRESOURCES-235
> URL: https://issues.apache.org/jira/browse/MRESOURCES-235
> Project: Maven Resources Plugin
>  Issue Type: Task
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.2
>
>
> As of version 3.0.0, escaping has been enabled by default by making the 
> {{escapeString}} parameter default to the backslash. This has introduced 
> various issues this issue got linked to. For further information see 
> [this|http://www.mail-archive.com/dev@maven.apache.org/msg111416.html] thread 
> on dev@.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-230) Can't escape the escape string

2016-12-04 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-230.

Resolution: Won't Fix

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

2016-12-04 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15719974#comment-15719974
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Escaping got implemented intentionally to only support escaping the delimiter 
strings and pass-through all escape strings not escaping a delimiter. Closing 
this {{wont fix}}.



> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOURCES-235) Revert enabling escaping by default introduced in 3.0.0.

2016-12-04 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOURCES-235:


 Summary: Revert enabling escaping by default introduced in 3.0.0.
 Key: MRESOURCES-235
 URL: https://issues.apache.org/jira/browse/MRESOURCES-235
 Project: Maven Resources Plugin
  Issue Type: Task
Affects Versions: 3.0.1, 3.0.0
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.2


As of version 3.0.0, escaping has been enabled by default by making the 
{{escapeString}} parameter default to the backslash. This has introduced 
various issues this issue got linked to. For further information see 
[this|http://www.mail-archive.com/dev@maven.apache.org/msg111416.html] thread 
on dev@.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOURCES-231) Can't disable escaping

2016-11-24 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-231:
-
Assignee: (was: Christian Schulte)

> Can't disable escaping
> --
>
> Key: MRESOURCES-231
> URL: https://issues.apache.org/jira/browse/MRESOURCES-231
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> The default before 3.0 used to be no escaping which is fine in my use case.
> Unfortunately in 3.0 I can't find anyway to go back to previous behavior.
> I tried
> {code}
> §
> {code}
> and
> {code}
> 
> {code}
> but I still end up with \ characters.
> The reason I tried to disable it is because of MRESOURCES-230.
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-231) Can't disable escaping

2016-11-24 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-231.

Resolution: Not A Problem
  Assignee: Christian Schulte

I just added an integration test testing that it is possible to disable 
escaping by using

{code}

  

{code}

I am waiting for a response on dev@ confirming that this is the way to go.

> Can't disable escaping
> --
>
> Key: MRESOURCES-231
> URL: https://issues.apache.org/jira/browse/MRESOURCES-231
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
>
> The default before 3.0 used to be no escaping which is fine in my use case.
> Unfortunately in 3.0 I can't find anyway to go back to previous behavior.
> I tried
> {code}
> §
> {code}
> and
> {code}
> 
> {code}
> but I still end up with \ characters.
> The reason I tried to disable it is because of MRESOURCES-230.
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6127) Fix plugin execution configuration interference

2016-11-23 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6127.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Thanks!

> Fix plugin execution configuration interference
> ---
>
> Key: MNG-6127
> URL: https://issues.apache.org/jira/browse/MNG-6127
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.3.9
>Reporter: Mario Krizmanic
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> The plugin execution configuration may interfere across maven modules 
> included in a build in case a plugin extension provides a default 
> configuration.
> Because the custom plugin configuration defined in the maven modules is 
> merged to the plugin execution configuration and the merged configuration is 
> re-used during building the other included maven modules, so the other maven 
> modules may be build using the invalid configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOURCES-230) Can't escape the escape string

2016-11-23 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Priority: Critical  (was: Major)

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Priority: Critical
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOURCES-230) Can't escape the escape string

2016-11-23 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Fix Version/s: (was: 3.0.2)

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (MRESOURCES-230) Can't escape the escape string

2016-11-23 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reopened MRESOURCES-230:
--
  Assignee: (was: Christian Schulte)

I am re-opening this because there are test cases testing the escape string 
does not get escaped intentionally. I cannot change these tests. That means I 
cannot fix this issue. Personally, I think it should be possible to escape the 
escape string and would expect this to happen automatically as well. You maybe 
need to start a discussion about this on dev@. Meanwhile I'll try fixing 
MRESOURCES-231 so that there at least is a solution to your problem.


> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MSHARED-599) Escaping the escape string produces incorrect output.

2016-11-21 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MSHARED-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MSHARED-599:
--
Fix Version/s: maven-filtering-3.1.2

> Escaping the escape string produces incorrect output.
> -
>
> Key: MSHARED-599
> URL: https://issues.apache.org/jira/browse/MSHARED-599
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-filtering
>Affects Versions: maven-filtering-3.1.1
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: maven-filtering-3.1.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MSHARED-600) Upgrade of plexus-interpolation to 1.24.

2016-11-21 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MSHARED-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MSHARED-600:
--
Fix Version/s: maven-filtering-3.1.2

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MSHARED-600
> URL: https://issues.apache.org/jira/browse/MSHARED-600
> Project: Maven Shared Components
>  Issue Type: Task
>Affects Versions: maven-filtering-3.1.1
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: maven-filtering-3.1.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MSHARED-600) Upgrade of plexus-interpolation to 1.24.

2016-11-21 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MSHARED-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MSHARED-600.
-
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MSHARED-600
> URL: https://issues.apache.org/jira/browse/MSHARED-600
> Project: Maven Shared Components
>  Issue Type: Task
>Affects Versions: maven-filtering-3.1.1
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MSHARED-600) Upgrade of plexus-interpolation to 1.24.

2016-11-21 Thread Christian Schulte (JIRA)
Christian Schulte created MSHARED-600:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MSHARED-600
 URL: https://issues.apache.org/jira/browse/MSHARED-600
 Project: Maven Shared Components
  Issue Type: Task
Affects Versions: maven-filtering-3.1.1
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MSHARED-599) Escaping the escape string produces incorrect output.

2016-11-21 Thread Christian Schulte (JIRA)
Christian Schulte created MSHARED-599:
-

 Summary: Escaping the escape string produces incorrect output.
 Key: MSHARED-599
 URL: https://issues.apache.org/jira/browse/MSHARED-599
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-filtering
Affects Versions: maven-filtering-3.1.1
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOLVER-8) Direct dependencies incorrectly detected as transitive.

2016-11-13 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOLVER-8:
-

 Summary: Direct dependencies incorrectly detected as transitive.
 Key: MRESOLVER-8
 URL: https://issues.apache.org/jira/browse/MRESOLVER-8
 Project: Maven Resolver
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Critical
 Fix For: Maven Artifact Resolver 1.2.0


The 'DefaultDependencyCollector' updates the state of the 
'DependencyCollectionContext' when recursively processing dependencies but does 
never return the context to the former state. This context is passed to various 
methods when deriving child components ('DependencyManager.deriveChildManager', 
'DependencySelector.deriveChildSelector', 
'DependencyTraverser.deriveChildTraverser', 'VersionFilter.deriveChildFilter') 
which fail to correctly detect the depth/transitivity of the context passed due 
to that context never getting reset after recursion.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-230) Can't escape the escape string

2016-11-13 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-230.

   Resolution: Fixed
Fix Version/s: (was: waiting-for-feedback)
   3.0.2

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MRESOURCES-230) Can't escape the escape string

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Fix Version/s: waiting-for-feedback

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
> Fix For: waiting-for-feedback
>
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (MRESOURCES-230) Can't escape the escape string

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reassigned MRESOURCES-230:


Assignee: Christian Schulte

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>Assignee: Christian Schulte
> Fix For: waiting-for-feedback
>
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered

2016-11-12 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660550#comment-15660550
 ] 

Christian Schulte commented on MRESOURCES-171:
--

The IDE I am using writes unicode escapes into the properties files. There is 
no way to disable that and IMHO it's the way to go. Doing it that way, no 
conversion takes place as it pretty much makes the properties files contain 
ASCII only. We maybe need to think about the filtering to use unicode escapes 
as well. For example: Having a non-ASCII project name the substituted 
$project.name should use unicode escapes. Maybe add a boolean 
{{unicodeEscapes}} parameter to the plugin and make the filtering produce those 
escapes.


> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u 
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to 
> be converted into UTF-8 in the jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Issue Comment Deleted] (MRESOURCES-230) Can't escape the escape string

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MRESOURCES-230:
-
Comment: was deleted

(was: Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT 
version.)

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

2016-11-12 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660533#comment-15660533
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT version.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MRESOURCES-230) Can't escape the escape string

2016-11-12 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MRESOURCES-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660532#comment-15660532
 ] 

Christian Schulte commented on MRESOURCES-230:
--

Could you please test the issue is fixed in the current 3.0.2-SNAPSHOT version.

> Can't escape the escape string
> --
>
> Key: MRESOURCES-230
> URL: https://issues.apache.org/jira/browse/MRESOURCES-230
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: escape string
>Affects Versions: 3.0.1
>Reporter: Thomas Mortagne
>
> I have the following use case in a XML file:
> {code:xml}
>  value="%APPDATA%\XWiki\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> Before 3.0 it used to produce
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> \ is now the default escape character, I'm fine with that but then it should 
> be possible to escape the escape string which is buggy right now.
> The following source
> {code:xml}
>  value="%APPDATA%\XWiki\\${project.version}\data" 
> condition="windowsSevenAndGreater"/>
> {code}
> gives me
> {code:xml}
>  condition="windowsSevenAndGreater"/>
> {code}
> Notice the still doubled \. The first one should be removed from the result.
> I tried escapeWindowsPaths bu it does not seems to be matching my string as a 
> Windows path which is probably another bug.
> Since I can't find any way to disable escaping (see MRESOURCES-231),
> I ended up finding a character I don't have in my file and set it as 
> escapeString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-234) Upgrade of commons-io to 2.5 and correction of invalid scope.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-234.

   Resolution: Fixed
Fix Version/s: 3.0.2

> Upgrade of commons-io to 2.5 and correction of invalid scope.
> -
>
> Key: MRESOURCES-234
> URL: https://issues.apache.org/jira/browse/MRESOURCES-234
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOURCES-234) Upgrade of commons-io to 2.5 and correction of invalid scope.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOURCES-234:


 Summary: Upgrade of commons-io to 2.5 and correction of invalid 
scope.
 Key: MRESOURCES-234
 URL: https://issues.apache.org/jira/browse/MRESOURCES-234
 Project: Maven Resources Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MWAR-398) Upgrade of plexus-interpolation to 1.24 to correct escaping issue.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MWAR-398:
--

 Summary: Upgrade of plexus-interpolation to 1.24 to correct 
escaping issue.
 Key: MWAR-398
 URL: https://issues.apache.org/jira/browse/MWAR-398
 Project: Maven WAR Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
 Fix For: 3.1.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRESOURCES-233) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRESOURCES-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRESOURCES-233.

Resolution: Fixed

> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MRESOURCES-233
> URL: https://issues.apache.org/jira/browse/MRESOURCES-233
> Project: Maven Resources Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRESOURCES-233) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MRESOURCES-233:


 Summary: Upgrade of plexus-interpolation 1.24 to correct escaping 
issue.
 Key: MRESOURCES-233
 URL: https://issues.apache.org/jira/browse/MRESOURCES-233
 Project: Maven Resources Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte
 Fix For: 3.0.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRRESOURCES-99) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRRESOURCES-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRRESOURCES-99.

Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRRESOURCES-99
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-99
> Project: Maven Remote Resources Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.6
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRRESOURCES-99) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MRRESOURCES-99:


 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MRRESOURCES-99
 URL: https://issues.apache.org/jira/browse/MRRESOURCES-99
 Project: Maven Remote Resources Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 1.6






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MRAR-66) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MRAR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MRAR-66.
-
   Resolution: Fixed
Fix Version/s: 3.0.0

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MRAR-66
> URL: https://issues.apache.org/jira/browse/MRAR-66
> Project: Maven Rar Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MRAR-66) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MRAR-66:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MRAR-66
 URL: https://issues.apache.org/jira/browse/MRAR-66
 Project: Maven Rar Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MPIR-350) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MPIR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MPIR-350.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPIR-350
> URL: https://issues.apache.org/jira/browse/MPIR-350
> Project: Maven Project Info Reports Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.10
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MPIR-350) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MPIR-350:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MPIR-350
 URL: https://issues.apache.org/jira/browse/MPIR-350
 Project: Maven Project Info Reports Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 2.10






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MPDF-79) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MPDF-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MPDF-79.
-
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MPDF-79
> URL: https://issues.apache.org/jira/browse/MPDF-79
> Project: Maven PDF Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 1.4
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MPDF-79) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MPDF-79:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MPDF-79
 URL: https://issues.apache.org/jira/browse/MPDF-79
 Project: Maven PDF Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 1.4






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MINVOKER-212) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINVOKER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MINVOKER-212.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MINVOKER-212
> URL: https://issues.apache.org/jira/browse/MINVOKER-212
> Project: Maven Invoker Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MINVOKER-212) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MINVOKER-212:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MINVOKER-212
 URL: https://issues.apache.org/jira/browse/MINVOKER-212
 Project: Maven Invoker Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MEJB-107) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MEJB-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MEJB-107.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEJB-107
> URL: https://issues.apache.org/jira/browse/MEJB-107
> Project: Maven EJB Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MEJB-107) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MEJB-107:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MEJB-107
 URL: https://issues.apache.org/jira/browse/MEJB-107
 Project: Maven EJB Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MEAR-245) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MEAR-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MEAR-245.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MEAR-245
> URL: https://issues.apache.org/jira/browse/MEAR-245
> Project: Maven Ear Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MEAR-245) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MEAR-245:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MEAR-245
 URL: https://issues.apache.org/jira/browse/MEAR-245
 Project: Maven Ear Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MDOAP-48) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MDOAP-48:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MDOAP-48
 URL: https://issues.apache.org/jira/browse/MDOAP-48
 Project: Maven DOAP Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MCHANGES-377) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MCHANGES-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MCHANGES-377.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHANGES-377
> URL: https://issues.apache.org/jira/browse/MCHANGES-377
> Project: Maven Changes Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MCHANGES-377) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MCHANGES-377:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MCHANGES-377
 URL: https://issues.apache.org/jira/browse/MCHANGES-377
 Project: Maven Changes Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MDEP-544) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MDEP-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MDEP-544.
--
Resolution: Fixed

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MDEP-544
> URL: https://issues.apache.org/jira/browse/MDEP-544
> Project: Maven Dependency Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MDEP-544) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MDEP-544:
--

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MDEP-544
 URL: https://issues.apache.org/jira/browse/MDEP-544
 Project: Maven Dependency Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial
 Fix For: 3.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MCHECKSTYLE-331) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MCHECKSTYLE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MCHECKSTYLE-331.
-
   Resolution: Fixed
Fix Version/s: 2.18

> Upgrade of plexus-interpolation to 1.24.
> 
>
> Key: MCHECKSTYLE-331
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-331
> Project: Maven Checkstyle Plugin
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 2.18
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MCHECKSTYLE-331) Upgrade of plexus-interpolation to 1.24.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MCHECKSTYLE-331:
-

 Summary: Upgrade of plexus-interpolation to 1.24.
 Key: MCHECKSTYLE-331
 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-331
 Project: Maven Checkstyle Plugin
  Issue Type: Task
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MACR-41) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MACR-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MACR-41.
-
   Resolution: Fixed
Fix Version/s: 3.0.1

> Upgrade of plexus-interpolation 1.24 to correct escaping issue.
> ---
>
> Key: MACR-41
> URL: https://issues.apache.org/jira/browse/MACR-41
> Project: Maven ACR Plugin
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MACR-41) Upgrade of plexus-interpolation 1.24 to correct escaping issue.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MACR-41:
-

 Summary: Upgrade of plexus-interpolation 1.24 to correct escaping 
issue.
 Key: MACR-41
 URL: https://issues.apache.org/jira/browse/MACR-41
 Project: Maven ACR Plugin
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MNG-6114) Elements from the global settings should be ordered before elements from the user settings.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6114:
---
Summary: Elements from the global settings should be ordered before 
elements from the user settings.  (was: Profiles from the global settings 
should be ordered before profiles from the user settings.)

> Elements from the global settings should be ordered before elements from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6114.
--
   Resolution: Fixed
Fix Version/s: 3.4.0

> Profiles from the global settings should be ordered before profiles from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

2016-11-12 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660194#comment-15660194
 ] 

Christian Schulte commented on MNG-6114:


See [this 
thread|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCAK8jvqx5y987xjTNq4V-%2BYCQHP9xWeGNOMK5us%3Dp0m9OwYVSjg%40mail.gmail.com%3E]
 on dev@.


> Profiles from the global settings should be ordered before profiles from the 
> user settings.
> ---
>
> Key: MNG-6114
> URL: https://issues.apache.org/jira/browse/MNG-6114
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MNG-6114) Profiles from the global settings should be ordered before profiles from the user settings.

2016-11-12 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-6114:
--

 Summary: Profiles from the global settings should be ordered 
before profiles from the user settings.
 Key: MNG-6114
 URL: https://issues.apache.org/jira/browse/MNG-6114
 Project: Maven
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-2478) add "resources-filtered" filtered resource directories to super POM

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-2478.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].

> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
>  Issue Type: New Feature
>  Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>
> The super POM contains default folders for resources that are NOT filtered 
> (src/main/resources and src/test/resources). If one (additionally) needs a 
> filtered resources folder, it needs to override the default and therefore has 
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the 
> super POM. This should also fit to the philosophy of maven that aims to have 
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make 
> things more obvious to the user maybe "resources-filtered" would be better. 
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>   
> src/main/resources
>   
>   
>   
> src/main/resources-filtered
> true
>   
>   
> 
> 
>   
> src/test/resources
>   
>   
>   
> src/test/resources-filtered
> true
>   
>   
> {code}
> Update: The folder name has been changed to "resources-filtered".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-5940.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].


> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven 
> super pom:
> {code:xml}
>   
> true
> maven-source-plugin
> 
>   
> attach-sources
> 
>   jar
> 
>   
> 
>   
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into 
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6054) Removal of super pom plugin management.

2016-11-12 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6054.
--
   Resolution: Fixed
 Assignee: Christian Schulte
Fix Version/s: 3.4.0

Part of 3.4. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwwC7gpBe3u%2BsK8dPs5St3trAsgMXwUWvL7ksrj4tmqSQ%40mail.gmail.com%3E].


> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0

2016-11-12 Thread Christian Schulte (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15660123#comment-15660123
 ] 

Christian Schulte commented on MNG-6082:


It won't pass the release vote. See [this 
mail|http://mail-archives.apache.org/mod_mbox/maven-dev/201610.mbox/%3CCA%2BnPnMwCxMGwRf5fgspetRWj894hLcgFdFPT_P8TDbgoG_7xaA%40mail.gmail.com%3E]
 on dev@.


> Introduction of model version 4.1.0
> ---
>
> Key: MNG-6082
> URL: https://issues.apache.org/jira/browse/MNG-6082
> Project: Maven
>  Issue Type: New Feature
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Critical
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6070.
--
Resolution: Not A Problem
  Assignee: Christian Schulte

This was caused when the central repository was removed from the 4.0.0 super 
POM during development of Maven 3.4. The central repository has been restored 
in the 4.0.0 super POM recently so this is no longer an issue and should not 
appear in any release notes.


> Default profile in settings.xml must not use an id possibly already in use. 
> 
>
> Key: MNG-6070
> URL: https://issues.apache.org/jira/browse/MNG-6070
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.4.0
> Environment: ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn --version
> Apache Maven 3.4.0-SNAPSHOT (90f26c279af9738735be8f84f60dcf21b6244e24; 
> 2016-07-23T16:24:50+02:00)
> Maven home: /Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.8.5", arch: "x86_64", family: "Unix"
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Blocker
>
> I have created a simple example project with the following pom file:
> {code:xml}
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd;>
>   4.0.0
>   com.soebes.maven.example
>   example
>   jar
>   1.0-SNAPSHOT
>   
> UTF-8
>   
>   
> 
>   
> 
>   com.soebes.maven.plugins
>   echo-maven-plugin
>   0.3.0
> 
>   
> 
>   
>   
> 
>   
> 
>   performRelease
>   true
> 
>   
>   
> 
>   
> com.soebes.maven.plugins
> echo-maven-plugin
> 
>   
> initialize
> 
>   echo
> 
>   
> 
> 
>   
> Profile: performRelease property is activated 
> '${performRelease}'.
>   
> 
>   
> 
>   
> 
>   
> 
> {code}
> If I use Maven 3.3.9 (also 3.0.5, 3.1.1, 3.2.5) and run it like this:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.401 s
> [INFO] Finished at: 2016-07-23T18:11:47+02:00
> [INFO] Final Memory: 7M/245M
> [INFO] 
> 
> {code}
> If I run the current master of Maven Core (sha: 
> 90f26c279af9738735be8f84f60dcf21b6244e24) I got the following result:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- echo-maven-plugin:0.3.0:echo (default) @ example ---
> [INFO] Profile: performRelease property is activated '${performRelease}'.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.478 s
> [INFO] Finished at: 2016-07-23T18:12:54+02:00
> [INFO] Final Memory: 9M/245M
> [INFO] 
> 
> {code}
> This means the profile will be erroneously activated but the property does 
> not contain a value.
> If I add an id to the profile like this:
> {code:xml}
>   
> 
>   an-other-profile
>   
> 
>   performRelease
>   true
> 
>   
>   ..
> {code}
> It will produce the following (correct) result:
> {code}
> ~/ws-git-maven-bugs/profiles (master *)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 

[jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6070:
---
Assignee: (was: Christian Schulte)

> Default profile in settings.xml must not use an id possibly already in use. 
> 
>
> Key: MNG-6070
> URL: https://issues.apache.org/jira/browse/MNG-6070
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.4.0
> Environment: ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn --version
> Apache Maven 3.4.0-SNAPSHOT (90f26c279af9738735be8f84f60dcf21b6244e24; 
> 2016-07-23T16:24:50+02:00)
> Maven home: /Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.8.5", arch: "x86_64", family: "Unix"
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> I have created a simple example project with the following pom file:
> {code:xml}
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd;>
>   4.0.0
>   com.soebes.maven.example
>   example
>   jar
>   1.0-SNAPSHOT
>   
> UTF-8
>   
>   
> 
>   
> 
>   com.soebes.maven.plugins
>   echo-maven-plugin
>   0.3.0
> 
>   
> 
>   
>   
> 
>   
> 
>   performRelease
>   true
> 
>   
>   
> 
>   
> com.soebes.maven.plugins
> echo-maven-plugin
> 
>   
> initialize
> 
>   echo
> 
>   
> 
> 
>   
> Profile: performRelease property is activated 
> '${performRelease}'.
>   
> 
>   
> 
>   
> 
>   
> 
> {code}
> If I use Maven 3.3.9 (also 3.0.5, 3.1.1, 3.2.5) and run it like this:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.401 s
> [INFO] Finished at: 2016-07-23T18:11:47+02:00
> [INFO] Final Memory: 7M/245M
> [INFO] 
> 
> {code}
> If I run the current master of Maven Core (sha: 
> 90f26c279af9738735be8f84f60dcf21b6244e24) I got the following result:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- echo-maven-plugin:0.3.0:echo (default) @ example ---
> [INFO] Profile: performRelease property is activated '${performRelease}'.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.478 s
> [INFO] Finished at: 2016-07-23T18:12:54+02:00
> [INFO] Final Memory: 9M/245M
> [INFO] 
> 
> {code}
> This means the profile will be erroneously activated but the property does 
> not contain a value.
> If I add an id to the profile like this:
> {code:xml}
>   
> 
>   an-other-profile
>   
> 
>   performRelease
>   true
> 
>   
>   ..
> {code}
> It will produce the following (correct) result:
> {code}
> ~/ws-git-maven-bugs/profiles (master *)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 

[jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6070:
---
Fix Version/s: (was: 3.4.0)

> Default profile in settings.xml must not use an id possibly already in use. 
> 
>
> Key: MNG-6070
> URL: https://issues.apache.org/jira/browse/MNG-6070
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.4.0
> Environment: ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn --version
> Apache Maven 3.4.0-SNAPSHOT (90f26c279af9738735be8f84f60dcf21b6244e24; 
> 2016-07-23T16:24:50+02:00)
> Maven home: /Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.8.5", arch: "x86_64", family: "Unix"
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Blocker
>
> I have created a simple example project with the following pom file:
> {code:xml}
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd;>
>   4.0.0
>   com.soebes.maven.example
>   example
>   jar
>   1.0-SNAPSHOT
>   
> UTF-8
>   
>   
> 
>   
> 
>   com.soebes.maven.plugins
>   echo-maven-plugin
>   0.3.0
> 
>   
> 
>   
>   
> 
>   
> 
>   performRelease
>   true
> 
>   
>   
> 
>   
> com.soebes.maven.plugins
> echo-maven-plugin
> 
>   
> initialize
> 
>   echo
> 
>   
> 
> 
>   
> Profile: performRelease property is activated 
> '${performRelease}'.
>   
> 
>   
> 
>   
> 
>   
> 
> {code}
> If I use Maven 3.3.9 (also 3.0.5, 3.1.1, 3.2.5) and run it like this:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.401 s
> [INFO] Finished at: 2016-07-23T18:11:47+02:00
> [INFO] Final Memory: 7M/245M
> [INFO] 
> 
> {code}
> If I run the current master of Maven Core (sha: 
> 90f26c279af9738735be8f84f60dcf21b6244e24) I got the following result:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- echo-maven-plugin:0.3.0:echo (default) @ example ---
> [INFO] Profile: performRelease property is activated '${performRelease}'.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.478 s
> [INFO] Finished at: 2016-07-23T18:12:54+02:00
> [INFO] Final Memory: 9M/245M
> [INFO] 
> 
> {code}
> This means the profile will be erroneously activated but the property does 
> not contain a value.
> If I add an id to the profile like this:
> {code:xml}
>   
> 
>   an-other-profile
>   
> 
>   performRelease
>   true
> 
>   
>   ..
> {code}
> It will produce the following (correct) result:
> {code}
> ~/ws-git-maven-bugs/profiles (master *)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD 

[jira] [Reopened] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reopened MNG-6070:

  Assignee: (was: Christian Schulte)

> Default profile in settings.xml must not use an id possibly already in use. 
> 
>
> Key: MNG-6070
> URL: https://issues.apache.org/jira/browse/MNG-6070
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.4.0
> Environment: ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn --version
> Apache Maven 3.4.0-SNAPSHOT (90f26c279af9738735be8f84f60dcf21b6244e24; 
> 2016-07-23T16:24:50+02:00)
> Maven home: /Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "Mac OS X", version: "10.8.5", arch: "x86_64", family: "Unix"
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
>
> I have created a simple example project with the following pom file:
> {code:xml}
> http://maven.apache.org/POM/4.0.0; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd;>
>   4.0.0
>   com.soebes.maven.example
>   example
>   jar
>   1.0-SNAPSHOT
>   
> UTF-8
>   
>   
> 
>   
> 
>   com.soebes.maven.plugins
>   echo-maven-plugin
>   0.3.0
> 
>   
> 
>   
>   
> 
>   
> 
>   performRelease
>   true
> 
>   
>   
> 
>   
> com.soebes.maven.plugins
> echo-maven-plugin
> 
>   
> initialize
> 
>   echo
> 
>   
> 
> 
>   
> Profile: performRelease property is activated 
> '${performRelease}'.
>   
> 
>   
> 
>   
> 
>   
> 
> {code}
> If I use Maven 3.3.9 (also 3.0.5, 3.1.1, 3.2.5) and run it like this:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.401 s
> [INFO] Finished at: 2016-07-23T18:11:47+02:00
> [INFO] Final Memory: 7M/245M
> [INFO] 
> 
> {code}
> If I run the current master of Maven Core (sha: 
> 90f26c279af9738735be8f84f60dcf21b6244e24) I got the following result:
> {code}
> ~/ws-git-maven-bugs/profiles (master)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- echo-maven-plugin:0.3.0:echo (default) @ example ---
> [INFO] Profile: performRelease property is activated '${performRelease}'.
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.478 s
> [INFO] Finished at: 2016-07-23T18:12:54+02:00
> [INFO] Final Memory: 9M/245M
> [INFO] 
> 
> {code}
> This means the profile will be erroneously activated but the property does 
> not contain a value.
> If I add an id to the profile like this:
> {code:xml}
>   
> 
>   an-other-profile
>   
> 
>   performRelease
>   true
> 
>   
>   ..
> {code}
> It will produce the following (correct) result:
> {code}
> ~/ws-git-maven-bugs/profiles (master *)$ 
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn initialize
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building example 1.0-SNAPSHOT
> [INFO] 
> 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 

[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6112:
---
Fix Version/s: 3.4.0

> Central repository in the 4.0.0 super POM should declare update policy 
> 'never'.
> ---
>
> Key: MNG-6112
> URL: https://issues.apache.org/jira/browse/MNG-6112
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6112.
--
Resolution: Fixed

> Central repository in the 4.0.0 super POM should declare update policy 
> 'never'.
> ---
>
> Key: MNG-6112
> URL: https://issues.apache.org/jira/browse/MNG-6112
> Project: Maven
>  Issue Type: Bug
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte closed MNG-6113.
--
Resolution: Fixed

> Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 
> super POM.
> -
>
> Key: MNG-6113
> URL: https://issues.apache.org/jira/browse/MNG-6113
> Project: Maven
>  Issue Type: Wish
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6113:
---
Fix Version/s: 3.4.0

> Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 
> super POM.
> -
>
> Key: MNG-6113
> URL: https://issues.apache.org/jira/browse/MNG-6113
> Project: Maven
>  Issue Type: Wish
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MNG-6113) Rename the 'Central Repository' to 'Maven Central Repository' in the 4.0.0 super POM.

2016-11-11 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-6113:
--

 Summary: Rename the 'Central Repository' to 'Maven Central 
Repository' in the 4.0.0 super POM.
 Key: MNG-6113
 URL: https://issues.apache.org/jira/browse/MNG-6113
 Project: Maven
  Issue Type: Wish
Reporter: Christian Schulte
Assignee: Christian Schulte
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.

2016-11-11 Thread Christian Schulte (JIRA)
Christian Schulte created MNG-6112:
--

 Summary: Central repository in the 4.0.0 super POM should declare 
update policy 'never'.
 Key: MNG-6112
 URL: https://issues.apache.org/jira/browse/MNG-6112
 Project: Maven
  Issue Type: Bug
Reporter: Christian Schulte
Assignee: Christian Schulte






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MNG-6054) Removal of super pom plugin management.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MNG-6054:
---
Fix Version/s: (was: 3.4.0)

> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Trivial
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (MNG-6054) Removal of super pom plugin management.

2016-11-11 Thread Christian Schulte (JIRA)

 [ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte reopened MNG-6054:

  Assignee: (was: Christian Schulte)

This has been reverted in 3.4 and postponed to model version 5.0.0.

> Removal of super pom plugin management.
> ---
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Reporter: Christian Schulte
>Priority: Trivial
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


<    1   2   3   4   5   6   7   8   9   10   >