[jira] [Commented] (MDEP-559) Java 9 bytecode cannot be parsed

[Ben Alex (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934034#comment-15934034
 ] 

Ben Alex commented on MDEP-559:
---

To assist with reproduction I have created a minimal project at 
https://github.com/benalexau/java9-test.

> Java 9 bytecode cannot be parsed
> 
>
> Key: MDEP-559
> URL: https://issues.apache.org/jira/browse/MDEP-559
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9 
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T21:17:27+11:00)
> Maven home: /opt/maven
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-9-jdk
> Default locale: en_AU, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-1-arch", arch: "amd64", family: "unix"
>Reporter: Ben Alex
>
> Attempting to run analyze-only against source compiled with Java 9 results in:
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.0:analyze-only (config-dependency) @ 
> lmdbjava ---
> [DEBUG] Configuring mojo 
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only from 
> plugin realm 
> ClassRealm[plugin>org.apache.maven.plugins:maven-dependency-plugin:3.0.0, 
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@3b764bce]
> [DEBUG] Configuring mojo 
> 'org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only' with 
> basic configurator -->
> [DEBUG]   (f) analyzer = default
> [DEBUG]   (f) baseDir = /home/bpa/projects/lmdbjava
> [DEBUG]   (f) failOnWarning = true
> [DEBUG]   (f) ignoreNonCompile = false
> [DEBUG]   (f) outputDirectory = /home/bpa/projects/lmdbjava/target
> [DEBUG]   (f) outputXML = false
> [DEBUG]   (f) project = MavenProject: org.lmdbjava:lmdbjava:0.0.6-SNAPSHOT @ 
> /home/bpa/projects/lmdbjava/dependency-reduced-pom.xml
> [DEBUG]   (f) scriptableFlag = $$%%%
> [DEBUG]   (f) scriptableOutput = false
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) usedDependencies = [org.lmdbjava:lmdbjava-native-linux-x86_64, 
> org.lmdbjava:lmdbjava-native-windows-x86_64, 
> org.lmdbjava:lmdbjava-native-osx-x86_64]
> [DEBUG]   (f) verbose = false
> [DEBUG] -- end configuration --
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 7.256 s
> [INFO] Finished at: 2017-03-17T17:32:20+11:00
> [INFO] Final Memory: 40M/132M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only 
> (config-dependency) on project lmdbjava: Execution config-dependency of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed. 
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only 
> (config-dependency) on project lmdbjava: Execution config-dependency of goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
>   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:863)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:547)
>   at 
> 

[jira] [Commented] (MDEPLOY-131) use default repository when no url specified

[Richard Sand (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15934013#comment-15934013
 ] 

Richard Sand commented on MDEPLOY-131:
--

Hi Robert - i admit my frustration is showing. But my question is still 
unanswered - forget my use case for a moment. Forget I mentioned anything about 
deploying multiple shaded artifacts. Just tell me your opinion on the following:

1) the deploy module does not have the ability to inherit the URL from the 
project - this is a useful feature to have and is doable with a dozen lines of 
code and an option to enable it
2) the patch is here already
3) including me, there are 5 people who have asked for this feature on this 
ticket

Why would you *not* accept it?



> use default repository when no url specified
> 
>
> Key: MDEPLOY-131
> URL: https://issues.apache.org/jira/browse/MDEPLOY-131
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>  Components: deploy:deploy-file
>Reporter: raymond domingo
>  Labels: contributers-welcome
> Attachments: DeployFileMojo.java, 
> maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff
>
>
> When using the deploy goal there is no need to specify the url of the 
> repository.
> When using deploy-file you DO need to specify the url. This is a problem, 
> because during development I like to deploy to snapshot repository and when 
> releasing i deploy to release repository and I can't add this logic to the 
> pom.
> Thas is why I like the url paramter to become optional (backwards compatible) 
> and add default behaviour when it is null. It should just like the deploy 
> plugin use the default repository. Snapshot for snapshots and release for 
> none snapshot versions.
> I added a patch file fixing this.
> I also added complete source of patched Mojo



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEP-559) Java 9 bytecode cannot be parsed

[Ben Alex (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933940#comment-15933940
 ] 

Ben Alex commented on MDEP-559:
---

With ASM 6.0_ALPHA as per the following snipped -X output:

{noformat}
[DEBUG] org.apache.maven.plugins:maven-dependency-plugin:jar:3.0.0:
[DEBUG]org.ow2.asm:asm:jar:6.0_ALPHA:runtime
[DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
[DEBUG]org.apache.maven:maven-model:jar:3.0:compile
[DEBUG]org.apache.maven:maven-core:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
[DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
[DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
[DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
[DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
[DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.14:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG]   org.codehaus.plexus:plexus-component-annotations:jar:1.6:compile
[DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
[DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
[DEBUG]org.apache.maven:maven-repository-metadata:jar:3.0:compile
[DEBUG]org.apache.maven.reporting:maven-reporting-api:jar:3.0:compile
[DEBUG]org.apache.maven.reporting:maven-reporting-impl:jar:2.3:compile
[DEBUG]   org.apache.maven.shared:maven-shared-utils:jar:0.6:compile
[DEBUG]  com.google.code.findbugs:jsr305:jar:2.0.1:compile
[DEBUG]   org.apache.maven.doxia:doxia-core:jar:1.2:compile
[DEBUG]  xerces:xercesImpl:jar:2.9.1:compile
[DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
[DEBUG]  org.apache.httpcomponents:httpclient:jar:4.0.2:compile
[DEBUG] org.apache.httpcomponents:httpcore:jar:4.0.1:compile
[DEBUG]   commons-validator:commons-validator:jar:1.3.1:compile
[DEBUG]  commons-beanutils:commons-beanutils:jar:1.7.0:compile
[DEBUG]  commons-digester:commons-digester:jar:1.6:compile
[DEBUG]  commons-logging:commons-logging:jar:1.0.4:compile
[DEBUG]commons-io:commons-io:jar:2.5:compile
{noformat}

The exception changes to:

{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only 
(config-dependency) on project lmdbjava: Execution config-dependency of goal 
org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed. 
RuntimeException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only 
(config-dependency) on project lmdbjava: Execution config-dependency of goal 
org.apache.maven.plugins:maven-dependency-plugin:3.0.0:analyze-only failed.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
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:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:547)
at 

[jira] [Created] (MNG-6190) maven-resolver-provider's DefaultArtifactDescriptorReader has mismatched constructor and initService methods

[Laird Nelson (JIRA)]

Laird Nelson created MNG-6190:
-

 Summary: maven-resolver-provider's DefaultArtifactDescriptorReader 
has mismatched constructor and initService methods
 Key: MNG-6190
 URL: https://issues.apache.org/jira/browse/MNG-6190
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.5.0-alpha-1
Reporter: Laird Nelson


In {{DefaultArtifactDescriptorReader.java}}, the constructor annotated with 
{{@Inject}} differs in the parameters it takes from its {{initService()}} 
method.

This discrepancy means among other things that its {{versionRangeResolver}} 
field is never initialized when a DI container is doing injection.

Here is the relevant code, starting at line 112, with a comment where the 
problem is:
{code}
@Inject
DefaultArtifactDescriptorReader( RemoteRepositoryManager 
remoteRepositoryManager, VersionResolver versionResolver,
 ArtifactResolver artifactResolver, 
ModelBuilder modelBuilder,
 RepositoryEventDispatcher 
repositoryEventDispatcher, LoggerFactory loggerFactory )
{
setRemoteRepositoryManager( remoteRepositoryManager );
setVersionResolver( versionResolver );
// XXX <-- Note: no versionRangeResolver
setArtifactResolver( artifactResolver );
setModelBuilder( modelBuilder );
setLoggerFactory( loggerFactory );
setRepositoryEventDispatcher( repositoryEventDispatcher );
}

public void initService( ServiceLocator locator )
{
setLoggerFactory( locator.getService( LoggerFactory.class ) );
setRemoteRepositoryManager( locator.getService( 
RemoteRepositoryManager.class ) );
setVersionResolver( locator.getService( VersionResolver.class ) );
setVersionRangeResolver( locator.getService( VersionRangeResolver.class 
) );
setArtifactResolver( locator.getService( ArtifactResolver.class ) );
setRepositoryEventDispatcher( locator.getService( 
RepositoryEventDispatcher.class ) );
modelBuilder = locator.getService( ModelBuilder.class );
if ( modelBuilder == null )
{
setModelBuilder( new DefaultModelBuilderFactory().newInstance() );
}
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (MNG-6074) Maven should produce an error if no model version has been set in a POM file used to build an effective model.

[Christian Schulte (JIRA)]

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

Christian Schulte closed MNG-6074.
--
   Resolution: Not A Problem
 Assignee: (was: Christian Schulte)
Fix Version/s: (was: 3.5.0-candidate)

> Maven should produce an error if no model version has been set in a POM file 
> used to build an effective model.
> --
>
> Key: MNG-6074
> URL: https://issues.apache.org/jira/browse/MNG-6074
> Project: Maven
>  Issue Type: Improvement
>Reporter: Christian Schulte
>Priority: Critical
>
> Maven currently only validates the model version to equal {{4.0.0}} when set. 
> The XML element is optional. Starting with Maven 3.4.0 a warning message 
> should be printed whenever no model version has been set so that it becomes 
> possible to use that version to decide about Maven behaviour. For example: In 
> Maven 3.5 we could add support for a new model version {{4.1.0}} which may be 
> used to decide about how Maven 3.5 should behave. Behaviour for model version 
> {{4.0.0}} will be the same as in Maven 3.4. Behaviour for model version 
> {{4.1.0}} could be different. For this the model version needs to be set.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933604#comment-15933604
 ] 

Robert Scholte commented on MRELEASE-979:
-

My bad, will restore it.

> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MINDEXER-102) Forward port OSGI related index-reader changes to master (Changes relative to MINDEXER-100 branch)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINDEXER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933588#comment-15933588
 ] 

ASF GitHub Bot commented on MINDEXER-102:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/16

MINDEXER-102 - indexer-reader OSGI changes forward ported to master

Forward ports index-reader changes from MINDEXER-97. 

Requires/includes  MINDEXER-100, which forward ports other changes from 5.x 
to master. 

New commit is 
https://github.com/sesuncedu/maven-indexer/commit/171f0902f9424c8fed8bc6ca4f62eec6fa1759c6

Does not include MINDEXER-101, which forwards ports other OSGI related 
changes from MINDEXER-97. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-102

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-indexer/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit 3f85beae30e75e982d28dce11ba4c0121254fcf7
Author: Tamas Cservenak 
Date:   2015-10-30T23:10:13Z

MINDEXER-94: Temp file cleanup on errors

(cherry picked from commit 7a0e7ad)

commit 897a6b011945e13d5fdbf34ddcbb2c9d0a0ad345
Author: Tamas Cservenak 
Date:   2015-10-31T00:05:08Z

Add Idea iml files to rat exclude

(cherry picked from commit 0f17245)

commit d4fb8373171bc343e98cf3c7dbbc7bef37ca8cec
Author: Tamas Cservenak 
Date:   2015-10-31T00:15:45Z

MINDEXER-95: Suboptimal indexing execution in updater

(cherry picked from commit c193888)

(sesunc...@gmail.com:
Removed call to optimize in NexusIndexWriter.
Merged config setup in NexusIndexWriter.
Kept increased gzip block size in IndexDataReader.

commit 5645ce868e3aadbff44a6a86e44b6ce5b2549123
Author: Tamas Cservenak 
Date:   2015-10-31T00:29:30Z

MINDEXER-96: Indexer reader

(cherry picked from commit af8783d)

commit 2848b0d2b72b7c1a2ea2df695f9bbebfda53e184
Author: Tamas Cservenak 
Date:   2015-11-03T11:28:41Z

Added index writer, that writes single chunk for now

(cherry picked from commit b9c4d90)

commit 26cbb0df8d3f358a7456086e9a18ab774725461b
Author: Tamas Cservenak 
Date:   2015-11-03T13:23:32Z

MINDEXER-96: Indexer reader and writer

(cherry picked from commit 5c75bba)

commit db9ab5080495058f50ccb2dcdb4d197feddc8466
Author: Tamas Cservenak 
Date:   2015-11-03T15:38:26Z

INDEXER-96: Fix iterators

(cherry picked from commit be227e2)

commit 6c905500423a324750f8c5256e6bd69b0083c640
Author: Tamas Cservenak 
Date:   2015-11-05T09:53:26Z

Cleanup

(cherry picked from commit c3431b6)

commit 6fc7a9661f3c5349a74f2f7eedbd25bb2d4eb43c
Author: Tamas Cservenak 
Date:   2015-11-05T12:53:34Z

Make the reader an osgi bundle

(cherry picked from commit 4c5d1d6)

commit 732fdbf82efe9f9412cd8d47c13e7431af4b9728
Author: Tamas Cservenak 
Date:   2015-11-05T14:36:13Z

rename helper class to avoid name clash with other utilities

(cherry picked from commit 4333789)

commit 62cdc3bd3cc7b18c54ee5b02f92f43ac28bbbac0
Author: Tamas Cservenak 
Date:   2015-11-11T20:11:06Z

Fix classifier separator

(cherry picked from commit ea1205e)

commit b680ab2bbc798f378ac7a65c738e0c9a2fe81813
Author: Tamas Cservenak 
Date:   2015-11-12T10:30:50Z

Remove Transform, let user use any lib it wants to for iterable manipulation

Also, UTs got new TestUtils based on Guava

(cherry picked from commit e0570bf)

commit 4efc41f7310f61c23c1e7b91ce0055d581eb56f9
Author: Simon Spero 
Date:   2017-03-19T21:41:07Z

Minor build and test-resource fixes.

commit 171f0902f9424c8fed8bc6ca4f62eec6fa1759c6
Author: Simon Spero 
Date:   2017-03-20T21:10:05Z

MINDEXER-102 Forward port OSGI related index-reader changes to master 
(Changes relative to MINDEXER-100)




> Forward port OSGI related index-reader changes to master (Changes relative to 
> MINDEXER-100 branch) 
> ---
>
> Key: MINDEXER-102
> URL: https://issues.apache.org/jira/browse/MINDEXER-102
> Project: Maven Indexer
>  Issue Type: Task
>Affects Versions: 6.0
>Reporter: Simon Spero
> Fix For: 6.0
>
>
> Forward port the OSGI related changes to 

[jira] [Commented] (MRELEASE-979) Support NamingPolicies to manage Branch and Tag names

[Henning Schmiedehausen (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933562#comment-15933562
 ] 

Henning Schmiedehausen commented on MRELEASE-979:
-

why does this change comment out all the integration tests in the pom? 

> Support NamingPolicies to manage Branch and Tag names
> -
>
> Key: MRELEASE-979
> URL: https://issues.apache.org/jira/browse/MRELEASE-979
> Project: Maven Release Plugin
>  Issue Type: Improvement
>  Components: branch, prepare, update-versions
>Affects Versions: 2.5.3
>Reporter: Henning Schmiedehausen
> Fix For: 3.0.0
>
>
> The newly introduced VersionPolicy facility allows managing the development 
> and release versions of projects when releasing, branching and updating 
> versions.
> Most organizations will also have a policy around how branches and tags are 
> named (which often have to match specific versioning patterns). The current 
> VersionPolicy implementations do not allow this but it should be possible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MINDEXER-102) Forward port OSGI related index-reader changes to master (Changes relative to MINDEXER-100 branch)

[Simon Spero (JIRA)]

Simon Spero created MINDEXER-102:


 Summary: Forward port OSGI related index-reader changes to master 
(Changes relative to MINDEXER-100 branch) 
 Key: MINDEXER-102
 URL: https://issues.apache.org/jira/browse/MINDEXER-102
 Project: Maven Indexer
  Issue Type: Task
Affects Versions: 6.0
Reporter: Simon Spero
 Fix For: 6.0


Forward port the OSGI related changes to index-reader from MINDEXER-97 .
Changes must be made relative to MINDEXER-100 branch



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINDEXER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933528#comment-15933528
 ] 

ASF GitHub Bot commented on MINDEXER-101:
-

GitHub user sesuncedu opened a pull request:

https://github.com/apache/maven-indexer/pull/15

MINDEXER-101 Forward port OSGI improvements to master branch

Forward port most OSGI related changes from 5.x to master branch.

Does not include changes to index-reader, as that requires MINDEXER-100 to 
be applied.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/maven-indexer MINDEXER-101

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-indexer/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit 963eb1a2d5a72b9d9fde87188d71b7c834a8bf41
Author: Simon Spero 
Date:   2017-03-20T20:48:46Z

MINDEXER-101 Forward port OSGI improvements (MINDEXER-97) to master




> Forward port OSGI improvements (MINDEXER-97) to master
> --
>
> Key: MINDEXER-101
> URL: https://issues.apache.org/jira/browse/MINDEXER-101
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Simon Spero
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master

[Simon Spero (JIRA)]

Simon Spero created MINDEXER-101:


 Summary: Forward port OSGI improvements (MINDEXER-97) to master
 Key: MINDEXER-101
 URL: https://issues.apache.org/jira/browse/MINDEXER-101
 Project: Maven Indexer
  Issue Type: Task
Reporter: Simon Spero






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MDEPLOY-131) use default repository when no url specified

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933389#comment-15933389
 ] 

Robert Scholte commented on MDEPLOY-131:


Hi Richard,

I think we need to cool down things. When reading your story for the first time 
I had the same idea as Karl Heinz. I consider suggesting a solution which 
matches the current Maven behavior as a great help.
Reading your situation over again, I see your situation:
1 sourceproject results in multiple artifacts (jar + pom), meaning different 
artifactIds. 

I think the situation is too rare to apply the patch. A custom plugin makes 
more sense.
Maybe there's good news: [~stephenconnolly] is working on a proposal for the 
next major version of Maven. And one of the suggestions is to have a pom for 
every uploaded artifact. Mapping this to your situation you *could* attach 
every artifact with the same artifactId, but with a separate classifier.
Another option I'm thinking of right is to have multiple pom-files if the root 
of your project. Maybe even with an aggregator

pom.xml (aggregator with modules pointing to every pom below)
pom-default.xml 
pom-jcl.xml
pom-jul.xml

this way there's no need for multiple separate calls, no need for separate 
commandline arguments.

> use default repository when no url specified
> 
>
> Key: MDEPLOY-131
> URL: https://issues.apache.org/jira/browse/MDEPLOY-131
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>  Components: deploy:deploy-file
>Reporter: raymond domingo
>  Labels: contributers-welcome
> Attachments: DeployFileMojo.java, 
> maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff
>
>
> When using the deploy goal there is no need to specify the url of the 
> repository.
> When using deploy-file you DO need to specify the url. This is a problem, 
> because during development I like to deploy to snapshot repository and when 
> releasing i deploy to release repository and I can't add this logic to the 
> pom.
> Thas is why I like the url paramter to become optional (backwards compatible) 
> and add default behaviour when it is null. It should just like the deploy 
> plugin use the default repository. Snapshot for snapshots and release for 
> none snapshot versions.
> I added a patch file fixing this.
> I also added complete source of patched Mojo



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MWAR-404) true is not honored

[Francis ANDRE (JIRA)]

[ 
https://issues.apache.org/jira/browse/MWAR-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1592#comment-1592
 ] 

Francis ANDRE commented on MWAR-404:


That's the same result with the 3.0.0 version
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building webapp Maven Webapp 0.0.1
[INFO] 
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ webapp ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ webapp ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
webapp ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\src\test\resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ webapp 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ webapp ---
[INFO] 
[INFO] --- maven-war-plugin:3.0.0:war (default-war) @ webapp ---
[INFO] Packaging webapp
[INFO] Assembling webapp [webapp] in 
[C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\target\webapp]
[INFO] Processing war project
[INFO] Copying webapp resources 
[C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\src\main\webapp]
[INFO] Webapp assembled in [130 msecs]
[INFO] Building war: C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\target\webapp.war
[INFO] 
[INFO] --- maven-install-plugin:2.4:install (default-install) @ webapp ---
[INFO] Installing C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\target\webapp.war to 
C:\Users\FrancisANDRE\.m2\repository\zsample\webapp\0.0.1\webapp-0.0.1.war
[INFO] Installing C:\MXW\DEMOS\MI-4.1.1\zsample.webapp\pom.xml to 
C:\Users\FrancisANDRE\.m2\repository\zsample\webapp\0.0.1\webapp-0.0.1.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 5.807 s
[INFO] Finished at: 2017-03-20T20:10:26+01:00
[INFO] Final Memory: 12M/300M
[INFO] 


> true is not honored
> --
>
> Key: MWAR-404
> URL: https://issues.apache.org/jira/browse/MWAR-404
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.2
> Environment: Win7 Pro SP1, 
> C:\MXW\DEMOS\MI-4.1.1\MI_Install_Builder>C:\ASF\apache-maven-3.2.5\bin\mvn 
> --version
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
> 2014-12-14T18:29:23+01:00)
> Maven home: C:\ASF\apache-maven-3.2.5
> Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_45\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Francis ANDRE
> Attachments: zsample.webapp.zip
>
>
> In the zsample.webapp.zip project joined, the 
> src/main/webapp/WEB-INF/geronimo-web.xml contains a filtered version as
>   ${foo}
> While the element true is set in the pom 
> and the foo property is set to 4.1.1, it appears that the resulting 
> geronimo-web.xm is not filtered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARCHETYPE-520) Following mirror configuration from settings.xml for downloading archetype metadata

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1590#comment-1590
 ] 

Robert Scholte commented on ARCHETYPE-520:
--

I'm working on some new features to the [mock repository 
manager|https://github.com/mojohaus/mrm] to have an isolated environment which 
works for archetype as well.
If you want to test right now: install mrm yourself
https://git-wip-us.apache.org/repos/asf/maven-archetype.git has a branch called 
ARCHETYPE-520. IIUC that contains an integration-test which matches this 
usecase.
That should confirm that the mirror is working as expected, unless you can show 
me otherwise.


> Following mirror configuration from settings.xml for downloading archetype 
> metadata
> ---
>
> Key: ARCHETYPE-520
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-520
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Johannes Siebel
> Attachments: maven-archetype-delay.TXT, settings.xml
>
>
> Since using the maven-archetype-plugin with version 3.0.0 the plugin tries to 
> connect to _both_ our internal nexus and to {{http://repo.maven.apache.org}} 
> for downloading Maven artifacts used by Archetypes. Since we are using a 
> proxy, the generation of the archetype is delayed until the download of the 
> Maven artifacts times out.
> We'd expect the archetype to only contact our own artifact repository, 
> without trying to connect to {{http://repo.maven.apache.org}} at all.
> I've attached a snippet with the debug output of the archetype:generate goal 
> and the configuration of our mirror.
> We assume this problem is related to ARCHETYPE-358.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MRELEASE-983) Documentation for release plugin has still not been corrected.

[Justin Grant (JIRA)]

Justin Grant created MRELEASE-983:
-

 Summary: Documentation for release plugin has still not been 
corrected.
 Key: MRELEASE-983
 URL: https://issues.apache.org/jira/browse/MRELEASE-983
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: prepare
Affects Versions: 2.5.3
Reporter: Justin Grant
Priority: Minor


Per MRELEASE-707, the documentation at 
http://maven.apache.org/maven-release/maven-release-plugin/usage.html has still 
not been corrected, even though the issue was marked as "closed".  It is not an 
unreasonable expectation as this is supported by the SCM plugin: 
http://maven.apache.org/components/scm/maven-scm-plugin/status-mojo.html and 
the other Maven Lifecycle plugins: 
https://maven.apache.org/scm/maven-scm-plugin/validate-mojo.html

I'm still a little unclear as to why this is so ridiculous that you would take 
this information as a parameters (for example, cases of releasing to a 
different repository than is in your pom), but the documentation should be 
corrected either way.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MWAR-404) true is not honored

[Karl Heinz Marbaise (JIRA)]

[ 
https://issues.apache.org/jira/browse/MWAR-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15933150#comment-15933150
 ] 

Karl Heinz Marbaise commented on MWAR-404:
--

Please use an up to date version of maven-war-plugin cause 2.2 is of 2012 
..and check if the issue still exists...

> true is not honored
> --
>
> Key: MWAR-404
> URL: https://issues.apache.org/jira/browse/MWAR-404
> Project: Maven WAR Plugin
>  Issue Type: Bug
>  Components: filtering
>Affects Versions: 2.2
> Environment: Win7 Pro SP1, 
> C:\MXW\DEMOS\MI-4.1.1\MI_Install_Builder>C:\ASF\apache-maven-3.2.5\bin\mvn 
> --version
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
> 2014-12-14T18:29:23+01:00)
> Maven home: C:\ASF\apache-maven-3.2.5
> Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_45\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Francis ANDRE
> Attachments: zsample.webapp.zip
>
>
> In the zsample.webapp.zip project joined, the 
> src/main/webapp/WEB-INF/geronimo-web.xml contains a filtered version as
>   ${foo}
> While the element true is set in the pom 
> and the foo property is set to 4.1.1, it appears that the resulting 
> geronimo-web.xm is not filtered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MLINKCHECK-29) Does not work on Windows

[Archimedes Trajano (JIRA)]

Archimedes Trajano created MLINKCHECK-29:


 Summary: Does not work on Windows
 Key: MLINKCHECK-29
 URL: https://issues.apache.org/jira/browse/MLINKCHECK-29
 Project: Maven Linkcheck Plugin
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Windows
Maven 3.3.9
Reporter: Archimedes Trajano


The version of LinkCheck does not work with windows because it uses an older 
version of the DefaultInvoker that does not recognize that mvn.cmd is the new 
command in Windows rather than .bat.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SCM-811) m2 release plugin shows SCM git password if fatal occured during git push

[Michael Osipov (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932336#comment-15932336
 ] 

Michael Osipov commented on SCM-811:


{noformat}
fatal: Authentication failed for 
'https://myuser:passw...@github.com/Dohbedoh/ci-sandbox.git/'
{noformat}

comes from Git directly. What shall we do?

> m2 release plugin shows SCM git password if fatal occured during git push
> -
>
> Key: SCM-811
> URL: https://issues.apache.org/jira/browse/SCM-811
> Project: Maven SCM
>  Issue Type: Improvement
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.4
> Environment: RHEL6, Windows
>Reporter: Vasilii Ruzov
>Assignee: Olivier Lamy (*$^¨%`£)
> Fix For: 1.9.5
>
>
> I'm running
> mvn release:prepare -Dusername=myuser -Dpassword=mypassword
> and see lines in output:
> {quote}[INFO] Executing: cmd.exe /X /C "git push 
> https://myuser:@myserver.com:8081/scm/project/project.git 
> refs/heads/master:refs/heads/master"
> {quote}
> but if for some reason git push failed(e.g. I made a mistake typing password) 
> then I see in log
> {quote}
> [ERROR] fatal: unable to access 
> 'https://myuser:mypassw...@myserver.com:8081/scm/project/project.git/': SSL 
> certificate problem: self signed certificate in certificate chain
> {quote}
> So I see *PLAINTEXT* password. As I use this step on Teamcity it causes 
> security problems when someone else can see my password if build failed. I 
> tried both on Linux and Windows machines.
> I use maven-release-plugin version 2.5.3.
> http://stackoverflow.com/questions/33831383/maven-release-plugin-shows-plaintext-password-on-git-push-error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MWAR-404) true is not honored

[Francis ANDRE (JIRA)]

Francis ANDRE created MWAR-404:
--

 Summary: true is not honored
 Key: MWAR-404
 URL: https://issues.apache.org/jira/browse/MWAR-404
 Project: Maven WAR Plugin
  Issue Type: Bug
  Components: filtering
Affects Versions: 2.2
 Environment: Win7 Pro SP1, 
C:\MXW\DEMOS\MI-4.1.1\MI_Install_Builder>C:\ASF\apache-maven-3.2.5\bin\mvn 
--version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
2014-12-14T18:29:23+01:00)
Maven home: C:\ASF\apache-maven-3.2.5
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_45\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Francis ANDRE
 Attachments: zsample.webapp.zip

In the zsample.webapp.zip project joined, the 
src/main/webapp/WEB-INF/geronimo-web.xml contains a filtered version as

${foo}

While the element true is set in the pom and 
the foo property is set to 4.1.1, it appears that the resulting geronimo-web.xm 
is not filtered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MRESOLVER-20) Create re-packaged uber JAR with basic dependencies to perform resolution against Maven central

[Graeme Rocher (JIRA)]

Graeme Rocher created MRESOLVER-20:
--

 Summary: Create re-packaged uber JAR with basic dependencies to 
perform resolution against Maven central
 Key: MRESOLVER-20
 URL: https://issues.apache.org/jira/browse/MRESOLVER-20
 Project: Maven Resolver
  Issue Type: Wish
Reporter: Graeme Rocher


Apache Groovy's @Grab annotation currently uses Ivy for resolution. It would be 
preferable if Ivy was removed and replaced by Apache Maven Resolver, however 
one challenge to that is Ivy is a single JAR whilst Apache Maven Resolver has a 
whole graph of dependencies requiring additional dependency management.

See http://docs.groovy-lang.org/latest/html/documentation/grape.html

Would it be a possible to release as part of the release process a single JAR 
designed to be embedded into systems like @Grab?

We could also use this same JAR in the Grails project which has a CLI that uses 
Aether to resolve dependencies from central and a configured list HTTPS 
repositories.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (MNG-6189) WARN if maven-site-plugin configuration contains reportPlugins element

[JIRA]

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

Hervé Boutemy closed MNG-6189.
--
Resolution: Fixed

> WARN if maven-site-plugin configuration contains reportPlugins element
> --
>
> Key: MNG-6189
> URL: https://issues.apache.org/jira/browse/MNG-6189
> Project: Maven
>  Issue Type: Improvement
>  Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 3.5.0-alpha-1
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: 3.5.0-alpha-2
>
>
> with MNG-4162, a bunch of reporting logic was removed from Maven core.
> This was globally successful, but not on one topic: it was expected to remove 
> pom's {{reporting}} section and replace it with a normal {{reportPlugins}} 
> parameter in maven-site-plugin configuration.
> We later discovered that with this normal parameter, we missed one crucial 
> feature: report plugins inheritance, which would require a new mechanism 
> MSITE-484
> Then we reverted our instructions in maven-site-plugin documentation 
> MSITE-647: the new {{reportPlugins}} parameter is now just an implementation 
> detail, but should not be used by end-users, {{reporting}} section remains 
> the way to configure report plugins MSITE-684
> Now adding a warning in Maven core when it detects a {{reportPlugins}} 
> parameter in a maven-site-plugin configuration is easy to do, will help users 
> come back to normal {{reporting}} configuration, and will permit future 
> enhancements (we need to finally completely clean-up the situation we created 
> with this story...)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (MSHARED-628) support maven-model ReportPlugin in addition to local copy

[JIRA]

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

Hervé Boutemy closed MSHARED-628.
-
Resolution: Fixed

> support maven-model ReportPlugin in addition to local copy
> --
>
> Key: MSHARED-628
> URL: https://issues.apache.org/jira/browse/MSHARED-628
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-reporting-exec
>Affects Versions: maven-reporting-exec-1.3
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
> Fix For: maven-reporting-exec-1.4
>
>
> removing {{}} section was abandoned because of MSITE-484
> then having a local ReportPlugin that is a copy of 
> {{org.apache.maven.model.ReportPlugin}} to completely decouple from core is 
> not really useful: we should finally use original 
> {{org.apache.maven.model.ReportPlugin}}.
> Supporting this class will permit maven-site-plugin removal or 
> {{reportPlugins}} and MPDF-48



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise updated MNG-6069:
-
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
   3.5.0

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.0
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (MNG-6069) Migrate to non deprecated parts of Commons CLI

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise reassigned MNG-6069:


Assignee: Karl Heinz Marbaise

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.0
>
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARCHETYPE-520) Following mirror configuration from settings.xml for downloading archetype metadata

[JIRA]

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932214#comment-15932214
 ] 

Jörg Sesterhenn commented on ARCHETYPE-520:
---

[~rfscholte]: Just to be clear on that - the mirrors are used at our site as 
well. They are just not used exclusively which is the problem.
Did you use the  * setting in your tests? (How) can we run 
these integration tests at our site to see if we get the same result?

> Following mirror configuration from settings.xml for downloading archetype 
> metadata
> ---
>
> Key: ARCHETYPE-520
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-520
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Johannes Siebel
> Attachments: maven-archetype-delay.TXT, settings.xml
>
>
> Since using the maven-archetype-plugin with version 3.0.0 the plugin tries to 
> connect to _both_ our internal nexus and to {{http://repo.maven.apache.org}} 
> for downloading Maven artifacts used by Archetypes. Since we are using a 
> proxy, the generation of the archetype is delayed until the download of the 
> Maven artifacts times out.
> We'd expect the archetype to only contact our own artifact repository, 
> without trying to connect to {{http://repo.maven.apache.org}} at all.
> I've attached a snippet with the debug output of the archetype:generate goal 
> and the configuration of our mirror.
> We assume this problem is related to ARCHETYPE-358.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)