Any way to change the color scheme in Maven 3.5.0?

2017-04-07 Thread Francesco Chicchiriccò 
Hi all,
I am using since quite some time Maven 3.5.0-beta-1 and I am very satisfied, 
thanks for the good work!

I was wondering if there is any mean to change the predefined color scheme: 
could you please provide any pointer WRT this?

Thanks.
Regards.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven Embedder 3.3.9 Functional Example Help

2017-04-07 Thread Mitch Turner 
Hello folks,

I am attempting to use maven-embedder:3.3.9 and have thus far been
unsuccessful.

I forked a functioning repo for Maven version 3.1.1 however I would like to
use 3.3.9 or newer.


My attempt to run 3.3.9 is here:
https://github.com/tc-turner/maven-embedder-otg/tree/339

You can see the full stack trace here:
https://github.com/tc-turner/maven-embedder-otg/issues/1


Here is a portion of the stack trace in case it is obvious to you:

mturner-ol:target mturner$ java -jar
maven-embedder-example-1-jar-with-dependencies.jar
[main] WARN Sisu - Error injecting:
org.apache.maven.project.DefaultProjectBuildingHelper
com.google.inject.ProvisionException: Unable to provision, see the
following errors:

1) No implementation for org.apache.maven.classrealm.ClassRealmManager
was bound.
  while locating org.apache.maven.project.DefaultProjectBuildingHelper

1 error
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1025)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at 
org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
at 
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at 
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:65)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
at 
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:133)
at 
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
at 
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:63)
at 
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)



Does anyone have a functional example of using maven-embedder?

Thanks,

Mitchell Turner

[ANN] Apache Maven 3.5.0 Released

2017-04-07 Thread Stephen Connolly 
The Apache Maven team would like to announce the release of Apache Maven
3.5.0.

You can download the appropriate sources etc. from the download page

http://maven.apache.org/download.cgi

Notable changes
===

- ANSI colors added to the console output
- Fix various bugs in mvn scripts regarding spaces, quotations, special
characters, etc. also in combination with .mvn/ -files
- Switch from Eclipse Aether to Maven Artifact Resolver

What happened to Maven 3.4.0?
=

After Maven 3.3.9 was released, the Eclipse Aether project was retired and
the code base was migrated to the Apache Maven project.

The original goal for the 3.4.0 release was to replace Aether with the
exact same code after migration to the Apache Maven project and then
proceed with bug fixes to the resolver code as well as other areas of Maven.

The migration of the code between the two foundations took longer than
expected and as a result there were other changes committed to Maven core
that were outside the scope of intent for 3.4.0.

In order to refocus on the original intent for 3.4.0, the decision was
taken to revert the Maven core history to the point of the 3.3.9 release
and merge in the desired changes one at a time.

Because there had been a lot of communication about different features
being delivered and bugs fixed in Maven 3.4.0 and the new history may not
contain them in the first release, the decision was taken to forever burn
the 3.4.x release line.

More detail on this decision can be read in the mailing list archive[1].

Contributors


The Apache Maven team would like to thank the following contributors,
without whom this release would not have been possible:

Code contributors:

- Alex Henrie
- Andriy
- Archimedes Trajano
- Arlo Louis O'Keeffe
- August Shi
- Christoph Böhme
- Harald Wellmann
- Jason Dillon
- Joseph Walton
- Josh Soref
- Miriam Lee
- Nemo Chen
- Sébastian Le Merdy
- Stuart McCulloch
- Tobias Oberlies
- Robert Patrick

Issue reporters:

- Alex Henrie
- Andreas Sewe
- Andrew Haines
- Andriy
- Anthony Whitford
- Archimedes Trajano
- August Shi
- Ben Caradoc-Davies
- Christoph Böhme
- Daniel Spilker
- Falko Modler
- Fred Bricon
- Harald Wellmann
- Jeffrey Alexander
- Josh Soref
- Kengo TODA
- Konrad Windszus
- Laird Nelson
- Larry Singer
- Meytal Genah
- Mike Drob
- Miriam Lee
- Nemo Chen
- Peter Kjær Guldbæk
- Rahul Thakur
- Richard Raumberger
- Stuart McCulloch
- Tobias Oberlies
- Zac Thompson

Community testers participating in voting for this release series:

-  Grzegorz Grzybek
-  Petr Široký
-  Mark Derricutt,
-  Dejan Stojadinović
-  Thomas Collignon
-  Fred Cooke
-  Raphael Ackermann
-  Elliot Metsger
-  Chas Honton
-  Dennis Kieselhorst

The Apache Maven Project Management Committee would also like to thank all
the committers to the project for their efforts during the chaos that was
the great reset when the 3.4.x release lines were burned.

Release Notes - Maven - Version 3.5.0
=

Bugs:

* [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
* [MNG-5368] - UnsupportedOperationException thrown when version range
is not correct in dependencyManagement definitions
* [MNG-5629] - ClosedChannelException from
DefaultUpdateCheckManager.read
* [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
"&&"
* [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing
quotes
* [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
* [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
* [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash
functions
* [MNG-5895] - Problem with CI friendly usage of ${..} which is already
defined via property in pom file.
* [MNG-5958] - java.lang.String cannot be cast to
org.apache.maven.lifecycle.mapping.LifecyclePhase
* [MNG-5961] - Maven possibly not aware of log4j2
* [MNG-5962] - mvn.cmd fails when the current directory has spaces in
between
* [MNG-5963] - mvn.cmd does not return ERROR_CODE
* [MNG-6022] - mvn.cmd fails if directory contains an ampersand (&)
* [MNG-6053] - Unsafe System Properties copy in
MavenRepositorySystemUtils, causing NPEs
* [MNG-6057] - Problem with CI friendly usage of ${..} reactor order is
changed
* [MNG-6090] - CI friendly properties break submodule builds
* [MNG-6105] - properties.internal.SystemProperties.addSystemProperties()
is not really thread-safe
* [MNG-6109] - PluginDescriptor doesn't read since value of parameter
* [MNG-6117] - ${session.parallel} not correctly set
* [MNG-6144] - DefaultWagonManagerTest#testGetMissingJarForced() passed
incorrect value
* [MNG-6166] - mvn dependency:go-offline fails due to missing
transitive dependency jdom:jdom:jar:1.1
* [MNG-6168] - Fix unclosed streams
* [MNG-6170] - NPE in cases using Multithreaded -T X versions:set
-DnewVersion=1.0-SNAPSHOT
*

RE: dependency question

2017-04-07 Thread Magnanao, Hector 
If the builds for A are always getting a unique build number as a snapshot 
build,  how am I sure that B will always get the latest snapshot of A ?  Is 
there a way to name the A snapshot builds with a unique build number each time 
for this scenario.

-Original Message-
From: Russell Gold [mailto:russell.g...@oracle.com] 
Sent: Thursday, April 6, 2017 2:27 PM
To: Maven Users List 
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: dependency question

2017-04-07 Thread Karl Heinz Marbaise 

Hi Russlel,
On 07/04/17 17:29, Russell Gold wrote:


That’s the way it works: when you specify a snapshot, it takes the latest.


This is not 100% true, cause it depends on the update policy you have 
defined in your settings either explicit or by default the updates will 
be checked every 24 hours...


If you like to force this you can use mvn -U ...or define a different 
updatePolicy in your settings.xml for the appropriate repository.


By using mvn -U you make sure for running this build Maven will check if 
there are newer SNAPSHOT version available for dependencies which have 
defined a SNAPSHOT version


This is working for a single module project...but if you have a multi 
module build (Project C: A1 build before A2) which takes for example 5 
minutes to build ...this is no longer 100% true...


Now let us assume you have another project B which dependends on two 
different artifacts (A1, A2) of Project C ...this means in consequence 
those artifacts are build at two different times...


This means it could happen that your build of Project B consumes A2 from 
build #10 but A1 from build #9 ...



In practical it usually works without any issue using the mvn -U ...but 
you should be aware of this issue...



The only solution which I have found to make 100% sure is to use the 
output during the build of the project A and use those parsed 
informations about the SNAPSHOT versions and inject them into my current 
build ...(https://github.com/khmarbaise/deployment-recorder-extension 
not ready yet)...


Kind regards
Karl Heinz Marbaise




There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to
.

On Apr 7, 2017, at 11:27 AM, Magnanao, Hector  wrote:

If the builds for A are always getting a unique build number as a snapshot 
build,  how am I sure that B will always get the latest snapshot of A ?  Is 
there a way to name the A snapshot builds with a unique build number each time 
for this scenario.

-Original Message-
From: Russell Gold [mailto:russell.g...@oracle.com]
Sent: Thursday, April 6, 2017 2:27 PM
To: Maven Users List 
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.


On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:

I have to 2 java projects a and b in maven.  The B project uses the A build as 
a dependency.  How do I ensure the whenever the A project has a new build,  the 
B project will always use that latest build in A.  A is being built with a 
unique build number each time it gets built.  So is A has build # 10 as the 
newest build,  the B project has to use build #10 of A.


Hector Magnanao Jr.
SCM Analyst
SAP Fieldglass
Skype:  (331) 702-6142
Mobile:  (847) 857-8401
Email: hector.magna...@sap.com






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: dependency question

2017-04-07 Thread Robert Patrick 
For example, if I want to depend on the latest version of the artifact un the 
1.1.x version range, I would put:


test
myartifact
[1.1,1.1.9]


This says give me the latest version whose number is greater than or equal to 
1.1 and less than or equal to 1.1. 9 (where I randomly chose 9 
to be greater than any incremental version I will ever create.  

This version range can also be written [1.1, 1.2) where the close parent 
indicates a non-inclusive range end (i.e., less than 1.2).  The thing to be 
aware of with this syntax is that it also includes any pre-release versions of 
1.2 (e.g., 1.2-alpha-1 is included).  For more information, please see section 
3.4.3 of 
http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
 and http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html 


--
Robert Patrick 
VP, OPC Development, Oracle Corporation
7460 Warren Pkwy, Ste. 300  Office: +1.972.963.2872
Frisco, TX 75034, USA   Mobile: +1.469.556.9450

Professional Oracle WebLogic Server
by Robert Patrick, Gregory Nyberg, and Philip Aston
with Josh Bregman and Paul Done
Book Home Page: http://www.wrox.com/
Kindle Version: http://www.amazon.com/


-Original Message-
From: Magnanao, Hector [mailto:hector.magna...@sap.com] 
Sent: Friday, April 07, 2017 10:28 AM
To: Maven Users List
Subject: RE: dependency question

Can you give me an example of using a range in the pom file as a dependency ?

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Thursday, April 6, 2017 2:34 PM
To: Maven Users List 
Subject: RE: dependency question

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: dependency question

2017-04-07 Thread Russell Gold 
That’s the way it works: when you specify a snapshot, it takes the latest. 

There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to
.
> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector  wrote:
> 
> If the builds for A are always getting a unique build number as a snapshot 
> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
> there a way to name the A snapshot builds with a unique build number each 
> time for this scenario.
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com] 
> Sent: Thursday, April 6, 2017 2:27 PM
> To: Maven Users List 
> Subject: Re: dependency question
> 
> The simplest way is simply to use a snapshot version of A. That way B will 
> always use the latest snapshot. When you finally release A, you can have B 
> point to the released version instead of the snapshot.
> 
>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
>> 
>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>> as a dependency.  How do I ensure the whenever the A project has a new 
>> build,  the B project will always use that latest build in A.  A is being 
>> built with a unique build number each time it gets built.  So is A has build 
>> # 10 as the newest build,  the B project has to use build #10 of A.
>> 
>> 
>> Hector Magnanao Jr.
>> SCM Analyst
>> SAP Fieldglass
>> Skype:  (331) 702-6142
>> Mobile:  (847) 857-8401
>> Email: hector.magna...@sap.com
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: dependency question

2017-04-07 Thread Magnanao, Hector 
Can you give me an example of using a range in the pom file as a dependency ?

-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com] 
Sent: Thursday, April 6, 2017 2:34 PM
To: Maven Users List 
Subject: RE: dependency question

The other way is to use a version range in your dependency, which gives you a 
similar behavior as using a snapshot dependency.  Both approaches have their 
advantages and drawbacks...

-Original Message-
From: Russell Gold 
Sent: Thursday, April 06, 2017 2:27 PM
To: Maven Users List
Subject: Re: dependency question

The simplest way is simply to use a snapshot version of A. That way B will 
always use the latest snapshot. When you finally release A, you can have B 
point to the released version instead of the snapshot.

> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
> 
> I have to 2 java projects a and b in maven.  The B project uses the A build 
> as a dependency.  How do I ensure the whenever the A project has a new build, 
>  the B project will always use that latest build in A.  A is being built with 
> a unique build number each time it gets built.  So is A has build # 10 as the 
> newest build,  the B project has to use build #10 of A.
> 
> 
> Hector Magnanao Jr.
> SCM Analyst
> SAP Fieldglass
> Skype:  (331) 702-6142
> Mobile:  (847) 857-8401
> Email: hector.magna...@sap.com
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: dependency question

2017-04-07 Thread Robert Patrick 
Typically, whenever you run a build that includes a snapshot dependency, Maven 
will go out to the remote repository(ies), if any, and download the 
maven-metadata.xml file for that dependency to compare it against the snapshot 
stored in your local Maven repository to see if there is a newer version that 
needs to be downloaded.  For example, when I run one of our builds, I see this 
in the build output when there is a newer snapshot version:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.4 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.pom
 (3 KB at 12.5 KB/sec)
Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/artifact-2.2-20170406.205529-591.jar
 (43 KB at 25.3 KB/sec)

And this output when there is not:

Downloading: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://myrepomanager.example.com/artifactory/my-repo/test/artifact/2.2-SNAPSHOT/maven-metadata.xml
 (766 B at 1.7 KB/sec)

Whether it downloads and checks the maven-metadata.xml file every time or 
periodically is (at least somewhat) controlled by the repository declaration in 
your POM/settings.xml for the repository's updatePolicy.  For example, this is 
what one of our builds uses:


false
always
fail



-Original Message-
From: Russell Gold 
Sent: Friday, April 07, 2017 10:30 AM
To: Maven Users List
Subject: Re: dependency question

That’s the way it works: when you specify a snapshot, it takes the latest. 

There are some corner cases where it won’t. I think it only checks for a new 
snapshot every few hours or so, so if you are putting out a lot you might 
conceivably miss one. You can reset that if you need to .
> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector  wrote:
> 
> If the builds for A are always getting a unique build number as a snapshot 
> build,  how am I sure that B will always get the latest snapshot of A ?  Is 
> there a way to name the A snapshot builds with a unique build number each 
> time for this scenario.
> 
> -Original Message-
> From: Russell Gold [mailto:russell.g...@oracle.com]
> Sent: Thursday, April 6, 2017 2:27 PM
> To: Maven Users List 
> Subject: Re: dependency question
> 
> The simplest way is simply to use a snapshot version of A. That way B will 
> always use the latest snapshot. When you finally release A, you can have B 
> point to the released version instead of the snapshot.
> 
>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector  wrote:
>> 
>> I have to 2 java projects a and b in maven.  The B project uses the A build 
>> as a dependency.  How do I ensure the whenever the A project has a new 
>> build,  the B project will always use that latest build in A.  A is being 
>> built with a unique build number each time it gets built.  So is A has build 
>> # 10 as the newest build,  the B project has to use build #10 of A.
>> 
>> 
>> Hector Magnanao Jr.
>> SCM Analyst
>> SAP Fieldglass
>> Skype:  (331) 702-6142
>> Mobile:  (847) 857-8401
>> Email: hector.magna...@sap.com
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org