Re: Any way to change the color scheme in Maven 3.5.0?
Hi, Yes, you can customize colors (thanks to some help I got during a Paris HackerGarten Meetup [1]). Here is the link in th ereference documentation: http://maven.apache.org/ref/3.5.0/maven-embedder/ While reading now what I wrote, it should probably be enhanced to be more explicit that styled message API details are particularly useful for color customization => I'll improve immediately this doc for the next minor release :) Regards, Hervé [1] https://www.meetup.com/Paris-Hackergarten/ Le vendredi 7 avril 2017, 12:47:35 CEST Francesco Chicchiriccò a écrit : > 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 - 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
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
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 * [MNG-6171
RE: dependency question
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
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
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
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
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
RE: dependency question
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
Any way to change the color scheme in Maven 3.5.0?
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