Re: ConcurrentContinuous Delivery Maven Builds

Have a Jenkins job that runs at 10pm that picks up the *last green build* of the day and re-does it (skipping tests this time) but goes on to push the war file (or equiv) to the appropriate QA machines servers. That builds ran in parallel earlier in the day, is not longer important. Again, skip

Re: javadoc:jar and generated sources

strange can you provide a test project, please? Regards, Hervé Le mardi 13 mars 2018, 18:56:45 CET Laird Nelson a écrit : > I am finding that the sourcepath for javadoc:jar (when run as part of the > release profile) is different from the sourcepath for javadoc:javadoc in my > project that

Re: ConcurrentContinuous Delivery Maven Builds

@Paul yes the final build artifacts go to QA. I guess I can instrument Maven only deploy the necessary files. But I still need to deploy full snapshot build once a day @Francois, for my case, it very very possible that 2 parallel pipelines pushing same artifact ( different versions) to maven

Re: ConcurrentContinuous Delivery Maven Builds

What do you mean by "pushing maven-metadata.xml which can be corrupted" ? Are you talking about https://issues.apache.org/jira/browse/MDEPLOY-221 which is solved in Maven 3.5.2 (even 3.5.1 I think) ? -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html

old version of dependencies getting included into project

hi, I have a fairly large project which compiles to a war file. I've upgraded the jackson dependency to 2.7.3 but for some reason 2.4.3 and 2.4.0 jar files are included into the war file in addition to the 2.7.3 version. I ran mvn dependency:tree to figure out the reason but the old versions

Re: Looking for recommendations how to best use Maven in a muti-stagePipeline build to only deploy at the end

On Wed, Feb 14, 2018 at 9:31 PM, Eric B wrote: > Bernd, > > Nexus 3.x does not support staging repos b/c they are rewriting the entire > platform to support not just Maven artifacts, but any type of repo-based > artifact. Ex: docker images, npm dependencies, etc... This is

Re: Maven build failure - first install

I found the origin of the problem: The apache-maven-3.5.3 files were in a folder created in c:\Program Files. I changed and created a directory at the root of c:\apache\apache-maven-3.5.3 and the script now works without problems. Thanks for your help -- Sent from:

Re: ConcurrentContinuous Delivery Maven Builds

Continuous Delivery is into QA / UAT, right? Continuous Deployment is into Prod. You need the jars in Artifactory because other teams depend on them? If not then just deploy to QA/UAT and don't drop jars (or anything) into Nexus/Artifactory/WebDAV. - Paul On Wed, Mar 14, 2018 at 4:31 AM, Dan

Re: Maven build failure - first install

As " -DarchetypeVersion=1.1" is specified it should get version 1.1 of the archtype. It's hard to tell why it's not based on the little info provided. I suggest use mvn archtype:generate and you'll get prompted for archetype /Anders On Wed, Mar 14, 2018 at 11:17 AM, Bernd Eckenfels

Re: Maven build failure - first install

Hello, Looks like the tutorial is wrong, I only see a 1.1 version of that archetype. Since you normally cannot remove artifacts from Maven Central it looks like this never worked. You can see the content here:

Maven build failure - first install

Hello, I'm a beginner and follow the course OpenClassroom " Organize and package a Java application with Apache Maven "On this first part I have to create a Maven

ConcurrentContinuous Delivery Maven Builds

Hi I have a requirement to run concurrent maven continuous deliver style. Each new commit/PR triggers new pipeline with unique version. Since maven deployment also pushing maven-metadata.xml which can be corrupted for concurrent pipeplines I wonder if Artifactory or Nexus have some type of