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

[Charles Honton]

If you have a multi-module project and the tests are run as part of the last 
module, you can use the deployAtEnd parameter to delay deploying of artifacts 
until the end of the build.

chas

> On Feb 14, 2018, at 7:15 PM, Eric Benzacar  wrote:
> 
> Robert,
> 
> I think you misunderstood my problem.  It isn't a problem of defining
> different distributionManagement repos; like you said that is fairly easily
> handled using properties or -D parameters.
> 
> It is more the question of what kind of plugin is required to run which
> says:
> - download all the artifacts that this multi-module project previously built
> - deploy all the artifacts that were just downloaded
> 
> I cannot think of how to design/configure a project to accomplish something
> like that.  I'm guessing I would have to create a profile which explicitly
> declares each artifact produced by the multi-module project in order to do
> a dependency:copy, and then similarly, use a build-helper:attach all the
> artifacts that were just downloaded.  But that seems like a painful
> solution.  Am hoping there is something easier?
> 
> Thanks,
> 
> Eric
> 
> 
> On Wed, Feb 14, 2018 at 9:45 PM, Robert Patrick 
> wrote:
> 
>> Inline...
>> 
>> 
>> -Original Message-
>> From: Eric B [mailto:ebenza...@gmail.com]
>> Sent: Wednesday, February 14, 2018 8:27 PM
>> To: Maven Users List 
>> Subject: Re: Looking for recommendations how to best use Maven in a
>> muti-stage Pipeline build to only deploy at the end
>> 
>> Hi Robert,
>> 
>> Thanks for the suggestions.  To be honest, I never thought of using
>> regular repositories as staging repos.  That being said, I do see a hiccup
>> with the option that I'm not sure how to address.  In the case where a
>> build is rejected during the pipelline stage, how do I delete it?  I
>> haven't found a plugin that would allow me to delete a build from a repo.
>> And with a multi-module project, there are many artifacts that would need
>> to be rolled back.  I guess I could simply configure the repo to allow
>> re-deployment of the same artifact to these "stage" repos, but if ever a
>> deployment fails part way through, I end up with a repo in an unstable
>> manner (ie: there is no way to ensure that all modules are promoted at the
>> same time).
>> 
>> [Robert] Typically, I would solve this problem by simply putting
>> expiration dates on artifacts in the staging repositories.  I have never
>> used Nexus but Artifactory allows you to limit artifacts in the repository
>> by size, last time accessed, etc.  No need to keep artifacts in the
>> "staging repositories" for more than say, one month, anyway since they were
>> either good (and promoted all the way to the release repository) or bad
>> (and are not interesting after they fail).
>> 
>> All that being said, the last question would be how to retrieve and
>> redeploy these artifacts from one repo to another?  Changing the
>> distributionManagement settings is simple enough, but how would I instruct
>> maven to download all the modules from a multi-module build and then deploy
>> them?  I guess I could hack a profile in the parent pom where the different
>> modules are defined with a dependency:copy-dependencies goal, but how do I
>> ensure all artifacts that were just downloaded are then deployed to the
>> next repo in the stage?  I would think the only way to do this would be
>> writing my own custom plugin, unless you can think of some other mechanism
>> to accomplish this?
>> 
>> [Robert] Another way to do this is to use properties for the key values
>> for the repository URLs in the  and 
>> sections of the POM.  You simply set a default value for the properties in
>> the root POM (e.g., with appropriate values for the repositories used by
>> the developers) and then override the property values with Maven
>> command-line -Ds (or profiles) in the Jenkins build steps to handle pulling
>> and promoting to the right places...
>> 
>> Thanks,
>> 
>> Eric
>> 
>> 
>> 
>> On Wed, Feb 14, 2018 at 10:01 AM, Robert Patrick <
>> robert.patr...@oracle.com>
>> wrote:
>> 
>>> While Nexus may not support "staging repositories", it certainly
>>> supports more than one repository so why not just create one or more
>>> repositories that serve as staging repositories.  For example,
>>> 
>>> Pipeline Steps:
>>> 1.) Trigger a build based on source check-in and push to stage1 repo
>>> if build "succeeds"
>>> 2.) Pull artifacts from stage1 repo, run stage 2 tests, and push to
>>> stage2 repo if tests succeed.
>>> 3.) Pull artifacts from stage2 repo, run stage 3 tests, and push to
>>> stage3 repo if tests succeed.
>>> 4.) Pull artifacts from stage3 repo, run UAT tests, and push to
>>> release repo if tests succeed.
>>> 
>>> 
>>> 
>>> 
>>> -Original Message-
>>> From: Eric B [mailto:ebenza...@gmail.com]
>>> Sent: Wednesday, February 14, 2018 8:30 AM
>>> To: Maven Users List 
>>> 

Re: Is there a way to make a mojo run after "deploy" completion?

[Charles Honton]

According to 
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Plugins
 
:
"If more than one goal is bound to a particular phase, the order used is that 
those from the packaging are executed first, followed by those configured in 
the POM”
"When multiple executions are given that match a particular phase, they are 
executed in the order specified in the POM, with inherited executions running 
first."

As long as the deploy mojo is specified in the packaging, it will always run 
before your additional mojo specified in your pom. If you specify the deploy 
mojo in your pom, try placing the deploy mojo in your parent pom and your 
notification mojo in your subordinate pom.  Or, order the execution 
declarations in your single pom.

chas


> On Sep 3, 2017, at 9:21 AM, Steinar Bang  wrote:
> 
> I would like to run a mojo to run after deploy has completed
> successfully, to notify some OSGi bundles running in karaf, that they
> should update themselves with new deployed snapshots in a maven
> repository.
> 
> The problem is that the deploy lifecycle phase is the last lifecycle
> phase of the default lifecycle
> http://maven.apache.org/ref/3.5.0/maven-core/lifecycles.html
> 
> Ie. there is no "post-deploy" lifecycle phase to run my mojo in.
> 
> Is there a way to order mojos bound to the same lifecycle, so that my
> mojo will only run after maven-deploy-plugin has done its thing?
> (Preferrably only run my mojo if deployment has been successful, though
> I could live with running it every time)
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

[Charles Honton]

To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin 
(https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html 
) to 
prevent re-releasing unchanged artifacts.

chas

> On Apr 24, 2017, at 1:52 PM, Curtis Rueden  wrote:
> 
> because every release concludes
> with a "bump to next development cycle" commit

Re: Maven password encryption by project

[Charles Honton]

It sounds as though you wish to share a credential set amount multiple users.  
This is an example of what the security community calls “a bad idea”.
 
> On Mar 17, 2017, at 6:38 AM, Alix Lourme  wrote:
> 
> Dear community,
> 
> I'm searching the best practice for password encryption in a maven POM file 
> *by
> project*, could by used by properties (like in ANT or WAGON). Sample :
> ---
> 
>maven-antrun-plugin
>1.8
>
>
>
>
> todir="cert" trust="yes" />
>
>
> 
> ---
> 
> In this case, my *docker.password* could be a properties (pom or
> settings.xml) but must not be in clear text.
> 
> The problem with Maven encryption
> :
> - I have a master password defined in *settings-security.xml* (locally) for
> my user need (like proxy password encryption in MY *settings.xml*)
> - The CI tools contains the same mechanism (own *settings-security.xml*)
> for global needs, like server encryption used in *settings.xml* for jar
> publication in repository ; and I can't retrieve this file
> 
> => I can't use this mechanism for password encryption who works locally and
> on the CI server.
> 
> *Is there a way to have a encryption mechanism for the project's perimeter
> ?* (and not for user's perimeter, current Maven encryption works perfectly
> for that).
> 
> ---
> 
> Using -s and -gs Maven options (=> user/global settings override) could be
> a workaround but :
> - Server item definition or properties defining password must be in clear
> text
> - Using this Maven settings for each build depending the project workspace
> is a little boring
> 
> Perhaps is there a best way like a "private key by project" ... but I
> didn't found entry point about that.
> 
> Thanks in advance. Best regards
> *NB*: This question was firstly on stackoverflow
> ,
> but no really interest ^^.
> -- 
> Alix Lourme


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

Re: [Help] Force maven[-surefire] to run in parallel

[Charles Honton]

You should consider that if the project’s tests were not written with 
multi-threading in mind, they may fail.

> On Mar 15, 2017, at 6:56 AM, Thomas Broyer  wrote:
> 
> Hi,
> 
> On Wed, Mar 15, 2017 at 2:11 PM Luis Henrique de Souza Melo <
> l...@cin.ufpe.br> wrote:
> 
>> Hi,
>> 
>> I am a student at the Federal University of Pernambuco, and our group is
>> having some issues with Maven to run some tests in a huge amount of
>> projects.
>> 
>> We plan to run all theses open-source projects tests in parallel and in
>> sequential using its own maven. However, we cannot change every pom.xml
>> from every module and/or project main pom.xml manually.
>> 
>> Is there any way to force maven and/or surefire to run in parallel using a
>> command line argument, like: mvn test --parallel 3 -fae
>> Or even in sequential mode would help us like: mvn test --sequential -fae
>> 
> 
> All parallelism-related properties can be set using "user properties",
> which means you can set them from the command line (if they haven't been
> set explicitly in the POMs); e.g. for forkCount [1] you can call Maven as
> "mvn -DforkCount=2 test" to set the forkCount property to 2. If the
> properties have been set in the POM, if they have been set using a property
> value (e.g. ${some.property}) then you can override
> the property from the command line (i.e. "mvn -Dsome.property=2 test"). If
> the properties have been set with hard-coded values (e.g.
> 1) then you have no other choice than to edit the
> POMs.
> 
> And then you can tell Maven to parallelize the build with -T.
> 
> Actually, everything seems to be described in the Surefire documentation [2]
> 
> [1]
> https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkCount
> 
> [2]
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html


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

Re: Deploying independently versioned modules

[Charles Honton]

Take a look at maven exists plugin 
[https://chonton.github.io/exists-maven-plugin/0.0.2/ 
].  This has goals to 
prevent deployment or installation of artifacts which already exist.

> On Feb 5, 2017, at 5:38 AM, org.apache.maven.u...@io7m.com wrote:
> 
> Hello.
> 
> For years, I've been developing libraries as sets of modules sharing a
> (semantic) version number. For each project, the project's root Maven
> module defines the version number for all modules in the project. As a
> result, intra-project dependencies can be efficiently declared like
> this:
> 
>  
>${project.groupId}
>a-module
>${project.version}
>  
> 
> My release process for version x.y.z of any project looks like this:
> 
>  $ git flow release start x.y.z
>  $ mvn versions:set -DnewVersion=x.y.z
>  $ git add pom.xml */pom.xml
>  $ git commit -m 'Mark x.y.z'
>  (try a build, wait for CI results, etc, etc, etc)
>  $ git flow release finish
>  $ git push --all
>  $ git push --tags
>  $ mvn clean deploy site site:stage && mvn nexus-staging:rc-list
>  $ mvn nexus-staging:rc-close -DstagingRepositoryId=...
>  $ mvn nexus-staging:rc-release -DstagingRepositoryId=...
> 
> However, I've recently begun migrating to OSGi and in an OSGi context,
> as soon as you have API bundles, it makes more sense to have
> independently semantically-versioned modules. The version number of the
> aggregating root Maven module therefore identifies a set of module
> versions as opposed to dictating a fixed version number for all
> submodules.
> 
> This is all fine, except for step 8 in my release process... If an API
> module has not changed, the version number will not have changed.
> Artifacts are immutable, and therefore I don't want to attempt to
> deploy the same version of a module again. I can try to manually deploy
> by specifying a list of projects with -pl, but this means that my
> release process has to be different for each project. I have rather a
> lot of projects (~70 and counting), so I'd prefer to avoid any
> project-specific procedures in order to preserve my own sanity.
> 
> Is there some way I can get the deploy plugin (or possibly the nexus
> staging plugin) to determine that it doesn't need to deploy a module
> twice?
> 
> M

Re: Don't overwrite existing artifact - how?

[Charles Honton]

As far as preventing overwrite of an existing remote artifact, you can use the 
exists-maven-plugin .  
(https://github.com/chonton/exists-maven-plugin 
) This plugin will check for 
the existence of a current artifact and set a property which can be used to 
‘skip’ later plugin execution.

By default, this plugin sets the maven.deploy.skip property to false if the 
current project’s non-snapshot artifact already exists in the remote 
repository, thus preventing attempted overwrite of final artifacts.  You could 
configure this plugin to set a different property or also prevent SNAPSHOT 
artifacts from being overwritten.

If you have a similar need for install phase, you can create an issue or pull 
request at this project.

chas

> On Nov 28, 2016, at 12:11 AM, Hohl, Gerrit  wrote:
> 
> Hello everyone, :-)
> 
> seems my question was an odd one as I didn't get any replies on it.
> So maybe I modify it a little bit:
> Is it possible - maybe with an own Maven plugin - to check if an artifact is 
> already in the remote / central repository of my company?
> 
> The goal is the following:
> 
> Each check-in into the SCM triggers a build which builds with "install" on 
> the Jenkins build server.
> Except if that version is already in the central Nexus repository of the 
> company.
> A manually triggered build on the Jenkins build server will build with 
> "deploy".
> Except if that version is already in the central Nexus repository of the 
> company.
> 
> This way always the newest version of an artifact would be available for 
> other artifact build processes which depend on it.
> But versions which have been already "released" wouldn't be changed / 
> overwritten.
> Otherwise they would change on the build server because someone forgot to 
> change the version and break other builds on that machine.
> 
> Does someone of you know if it is possible to realize something like that 
> with already existing (and still maintained / developed) plugins?
> Or how a programmatically solution could look like? Means does someone know 
> what the Maven classes for accessing the remote repository are?
> 
> Regards,
> Gerrit
> -Ursprüngliche Nachricht-
> Von: Hohl, Gerrit [mailto:g.h...@aurenz.de] 
> Gesendet: Freitag, 18. November 2016 08:48
> An: users@maven.apache.org
> Betreff: Don't overwrite existing artifact - how?
> 
> Hello everyone, :-)
> 
> 
> 
> is it somehow possible not to "install" an artifact which already exists in 
> the local repository?
> 
> What about artifacts in a remote repository? Is it possible to prevent 
> deployment of such artifacts?
> 
> 
> 
> I don't want to have our build server to accidentally install an artifact a 
> second time just because someone forgot to change the version.
> 
> Even if that artifact isn't deployed to the remote repository it will be used 
> on that build server.
> 
> In the maven-install-plugin description there is no option. But who knows...
> 
> 
> 
> I saw that there is the possibility in Nexus to prevent redeployement for a 
> repository.
> 
> Is there also a way within Maven? Or not because Maven says it's the job of 
> the repository server / service itself.
> 
> In the maven-deploy-plugin description there is no option. But who knows...
> 
> 
> 
> Regards,
> 
> Gerrit
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

Re: Don't overwrite existing artifact - how?

[Charles Honton]

As far as preventing overwrite of an existing remote artifact, you can use the 
exists-maven-plugin .  
(https://github.com/chonton/exists-maven-plugin 
) This plugin will check for 
the existence of a current artifact and set a property which can be used to 
‘skip’ later plugin execution.

By default, this plugin sets the maven.deploy.skip property to false if the 
current project’s non-snapshot artifact already exists in the remote 
repository, thus preventing attempted overwrite of final artifacts.  You could 
configure this plugin to set a different property or also prevent SNAPSHOT 
artifacts from being overwritten.

chas

> On Nov 17, 2016, at 11:48 PM, Hohl, Gerrit  wrote:
> 
> Hello everyone, :-)
> 
> 
> 
> is it somehow possible not to "install" an artifact which already exists
> in the local repository?
> 
> What about artifacts in a remote repository? Is it possible to prevent
> deployment of such artifacts?
> 
> 
> 
> I don't want to have our build server to accidentally install an
> artifact a second time just because someone forgot to change the
> version.
> 
> Even if that artifact isn't deployed to the remote repository it will be
> used on that build server.
> 
> In the maven-install-plugin description there is no option. But who
> knows...
> 
> 
> 
> I saw that there is the possibility in Nexus to prevent redeployement
> for a repository.
> 
> Is there also a way within Maven? Or not because Maven says it's the job
> of the repository server / service itself.
> 
> In the maven-deploy-plugin description there is no option. But who
> knows...
> 
> 
> 
> Regards,
> 
> Gerrit
> 
> 
> 

Plugin embedded configuration property configuration

[Charles Honton]

I'm creating a new plugin where i would like the to have "embedded" 
configuration. 

public abstract class MyAbstractMojo extends AbstractMojo {

@Parameter
private Embedded embedded;

Where the ”embedded" configuration pojo has property injection with default 
values.

@Named
public class Embedded {

@Parameter(property=“embedded.name", defaultValue= "default")
private String name;

@Parameter(property=“embedded.autoCreate", defaultValue= "false")
private Boolean autoCreate;

I expect the configuration xml would look like:

  
my-group/groupId>
my-artifact
${my.version}
 
  
true
  

I have been unsuccessful in getting the property injection or default values to 
work.  Should this work?  What am I missing?

thanks,
chas