Maven CI Friendly Versions

[Eric B]

Many years ago Karl Heinz Marbaise had written a blog about the beginning
of Maven 3.5's support of CI versioning numbers with the specific
parameters that are interpolated by maven.  I always used to refer new
developers to that blog that were trying to understand the complexities of
using Maven and versioning in a CI environment.

It used to be hosted at: http://blog.soebes.de/blog/2017/04/02/maven
-pom-files-without-a-version-in-it/

But that site is now unfortunately dead (404).

I had always found that it was a very good intro to the problem and helped
clarify things well, including the need for using the flatten-plugin, etc.

Does anyone know if that blog is still available, but posted elsewhere, or
alternatively any good sites to help newcomers to the CICD problems with
Maven?  Clearly, there is the default documentation on Maven itself (
https://maven.apache.org/maven-ci-friendly.html) but is anything additional
that I can reference newcomers to?

Specifically, I am looking for best-practices for automated Jenkins
builds/pipelines/etc when integrated with CI variables.

Thanks!

Eric

Re: How to hide internal build details from deployed pom.xml ?

[Eric B]

Take a look at the maven-flatten-plugin.  It can do exactly what you are
describing, reducing a pom to only the dependency definitions required.

Eric

On Thu, Apr 19, 2018, 5:24 PM ,  wrote:

> Hi
>
>
>
> We have a maven project with many modules and a complex structure. The
> master pom inherited by all the modules is filled up with plugin
> configuration in pluginManagement. I’m looking for a way to hide these
> details from the pom.xml delivered with our artefacts: the applications
> using our libraries are not interested in the internal configuration of our
> components and all the details of our build. I think that the dependency
> information of the pom.xml should be sufficient for users of our libraries.
>
>
>
> Is it possible to have a pom.xml generated and deployed with our artefacts
> which does not contain all this ‘internal’ stuff ? Or has someone an idea
> how we should structure our projects to achieve the same effect ?
>
>
>
> Thanks in advance for any idea.
>
>
>
> Regards,
>
> Pierre
>
>
>
>
>
>
> Remarque concernant la sécurité:
> Ce courriel provenant de PostFinance est signé. Vous trouverez d'autres
> informations à ce sujet sous:
> https://www.postfinance.ch/e-signature.
> Ne divulguez jamais vos éléments de sécurité à des tiers.
>

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

[Eric B]

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...  But the new feature
won't be available until at least April or May.

With respect to running the whole Pipeline on a single executor with a
local maven repo was what I was thinking of doing.  But I still don't know
how to get it to deploy only at the last step without rebuilding again.  If
my last step just calls the deploy goal, then it will still rebuild the
entire artifact - not just grab whatever is in the local repo and deploy
it.  And I'm looking to avoid rebuilding the artifact since I want the
original artifact (the one sitting in the local m2 folder) to be the one
pushed to the repo.

Any suggestions?

Thanks,

Eric


On Wed, Feb 14, 2018 at 10:37 AM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> I am not sure why Nexus does not Support staging repos, I thought this is
> one of its defining Features? Certainly the ASF is using Nexus this way.
>
> Anyway, another solution is to use a Feature of the CI to run a whole
> Pipeline on a single executor and have this executor have a local maven
> repo instance (this is a good idea anyway). Then you can avoid to deploy at
> all (only install) until your last step.
>
> In my cases it Comes up not so often as the last Pipeline steps to release
> a product depend on Long ago released artifact versions with their own
> lifecylce.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Robert Patrick
> Gesendet: Mittwoch, 14. Februar 2018 16:01
> An: Maven Users List
> Betreff: RE: Looking for recommendations how to best use Maven in a
> muti-stagePipeline build to only deploy at the end
>
> 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 <users@maven.apache.org>
> Subject: Looking for recommendations how to best use Maven in a muti-stage
> Pipeline build to only deploy at the end
>
> I'm looking for recommendations for the best way to use Maven in a
> multi-stage Jenkins pipeline build to deploy only at the end.  At the
> moment, I'm using Sonatype Nexus 3.x, which means i don't have the benefit
> of staging repos.   Consequently, I have to ensure that the only released
> versions of my libraries/application are final - they've passed QA.
> Additionally, the team wants to ensure that the version numbers are always
> incremental and every version in the repo is a consumable version (ie: I
> cannot deploy a version 1.2.3 which has not passed QA/Acceptance Tests, and
> furthermore, I cannot deploy a 1.2.2 followed by a 1.2.4).
>
> What that requirement translates to is that I have to ensure that the
> binary built is fully tested before promoting it to Nexus. (and that I
> shouldn't be appending build numbers to the maven version number).
>
> In my mind, I would like to do something the following in a Pipeline build:
>
> stage('build') { steps { sh 'mvn clean install'} }
>
> stage('Confirm deploy to QA'){
>
> steps {
>
> checkpoint 'test server deployed'
>
> script {
>
> env.DEPLOY_TO_QA_TEST = input message: 'User input required',
>
> submitter: 'authenticated',
>
> parameters: [choice(name: 'Deploy to acceptance test server', choices:
> 'no\nyes', description: 'Choose "yes" if you want to deploy the QA test
> server')]
>
> }
>
> }
>
> }
>
> stage('deployQA') {
>
> when {
>
> environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'
>
> }
>
> steps{
>
> /* deploy the build to a QA environment */  }
>
> }
>
>
> stage('Confirm deploy to UAT'){ // prompt user }
>
> stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance
> Testing enviornment */}
>
>
> stage('Confirm publish to Nexus'){ // prompt user }
>
> stage('publish') {
>
> steps {
>
>   // mvn deploy -DskipTests (just deploy - don't rebuild)
>
> }
>
> }
>
>
> B

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

[Eric B]

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).

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?

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 <users@maven.apache.org>
> Subject: Looking for recommendations how to best use Maven in a muti-stage
> Pipeline build to only deploy at the end
>
> I'm looking for recommendations for the best way to use Maven in a
> multi-stage Jenkins pipeline build to deploy only at the end.  At the
> moment, I'm using Sonatype Nexus 3.x, which means i don't have the benefit
> of staging repos.   Consequently, I have to ensure that the only released
> versions of my libraries/application are final - they've passed QA.
> Additionally, the team wants to ensure that the version numbers are always
> incremental and every version in the repo is a consumable version (ie: I
> cannot deploy a version 1.2.3 which has not passed QA/Acceptance Tests, and
> furthermore, I cannot deploy a 1.2.2 followed by a 1.2.4).
>
> What that requirement translates to is that I have to ensure that the
> binary built is fully tested before promoting it to Nexus. (and that I
> shouldn't be appending build numbers to the maven version number).
>
> In my mind, I would like to do something the following in a Pipeline build:
>
> stage('build') { steps { sh 'mvn clean install'} }
>
> stage('Confirm deploy to QA'){
>
> steps {
>
> checkpoint 'test server deployed'
>
> script {
>
> env.DEPLOY_TO_QA_TEST = input message: 'User input required',
>
> submitter: 'authenticated',
>
> parameters: [choice(name: 'Deploy to acceptance test server', choices:
> 'no\nyes', description: 'Choose "yes" if you want to deploy the QA test
> server')]
>
> }
>
> }
>
> }
>
> stage('deployQA') {
>
> when {
>
> environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'
>
> }
>
> steps{
>
> /* deploy the build to a QA environment */  }
>
> }
>
>
> stage('Confirm deploy to UAT'){ // prompt user }
>
> stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance
> Testing enviornment */}
>
>
> stage('Confirm publish to Nexus'){ // prompt user }
>
> stage('publish') {
>
> steps {
>
>   // mvn deploy -DskipTests (just deploy - don't rebuild)
>
> }
>
> }
>
>
> Basically, I want to design my Jenkins pipeline to be my staging process.
> The problem I have is I'm not sure how I can only deploy at the end of the
> pipeline.  When maven runs the deploy lifecycle, it will run through all
> the other stages and reassemble my binaries, which technically are not
> longer

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

[Eric B]

I'm looking for recommendations for the best way to use Maven in a
multi-stage Jenkins pipeline build to deploy only at the end.  At the
moment, I'm using Sonatype Nexus 3.x, which means i don't have the benefit
of staging repos.   Consequently, I have to ensure that the only released
versions of my libraries/application are final - they've passed QA.
Additionally, the team wants to ensure that the version numbers are always
incremental and every version in the repo is a consumable version (ie: I
cannot deploy a version 1.2.3 which has not passed QA/Acceptance Tests, and
furthermore, I cannot deploy a 1.2.2 followed by a 1.2.4).

What that requirement translates to is that I have to ensure that the
binary built is fully tested before promoting it to Nexus. (and that I
shouldn't be appending build numbers to the maven version number).

In my mind, I would like to do something the following in a Pipeline build:

stage('build') { steps { sh 'mvn clean install'} }

stage('Confirm deploy to QA'){

steps {

checkpoint 'test server deployed'

script {

env.DEPLOY_TO_QA_TEST = input message: 'User input required',

submitter: 'authenticated',

parameters: [choice(name: 'Deploy to acceptance test server', choices:
'no\nyes', description: 'Choose "yes" if you want to deploy the QA test
server')]

}

}

}

stage('deployQA') {

when {

environment name: 'DEPLOY_TO_QA_TEST', value: 'yes'

}

steps{

/* deploy the build to a QA environment */  }

}


stage('Confirm deploy to UAT'){ // prompt user }

stage {'deployUAT') { /* deploy the build to a PreProd/User Acceptance
Testing enviornment */}


stage('Confirm publish to Nexus'){ // prompt user }

stage('publish') {

steps {

  // mvn deploy -DskipTests (just deploy - don't rebuild)

}

}


Basically, I want to design my Jenkins pipeline to be my staging process.
The problem I have is I'm not sure how I can only deploy at the end of the
pipeline.  When maven runs the deploy lifecycle, it will run through all
the other stages and reassemble my binaries, which technically are not
longer the same as those that were approved.  So consequently, my binary
hashes that were approved earlier in the pipeline are not the same hashes
that are deployed in Nexus.

I realize that i can probably do some work and use the Reproducible Build
plugin (https://zlika.github.io/reproducible-build-maven-plugin/), but that
too comes with drawbacks (I want build timestamps in my Manifest files, and
zip entries, etc).

Am I sunk?  Is my only hope to wait until Sonatype releases Staging repos
for Nexus 3.x sometime in Q2?  Or is there some other way I can work around
this?

How is everyone else handling this situation?

Thanks for sharing.

Eric

Re: Changing the maven project version without changing the pom.xml.

[Eric B]

As of maven 3.5, there are 3 special parameters that you can use to specify
the pom version: revision, Shaw and changelist.  There have already been a
couple of threads on that topic on this list.

http://maven.40175.n5.nabble.com/Continuous-Delivery-with-Maven-now-possible-tp5907567.html

http://maven.40175.n5.nabble.com/Special-version-parameters-sha1-tp5916900.html


As well, khmarbaise  has written a blog on it as well.

http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/

You can also get additional info from the maven docs how to use it:
https://maven.apache.org/maven-ci-friendly.html

I'm still working out the kinks and details for my own projects as well.

Thanks

Eric

On Nov 29, 2017 4:28 AM, "Mayur Kankanwadi"  wrote:

> Hi All,
>
> I am trying to accomplish setting the maven project version without
> changing the pom.xml, so that the same pom.xml can be used across various
> branches and the maven build is intelligent enough to figure out the
> version name itself.
> For this I am currently implementing a maven plugin which sets the
> MavenProject instance version during the Validate phase. But am not seeing
> the same being reflected in the final artifact, which is a jar.
> How should I set this version without changing the pom.xml? The maven
> versions plugin sets the version, but in the process changes the pom.xml,
> which in case of multiple branches will become an overhead, as it is a two
> step process.
> Also is there any document which can explain the maven-core architecture?
> The current javadocs are too concise and there is no guide which can show
> the relation between the various core objects.
>
> Thanks in advance.
> --Mayur.
>

Is it poor practice to use Maven repo (ie: Nexus) to store non maven artifacts?

[Eric B]

I have a need to store some binary objects (ex: zip files) in a central
repository that can be easily accessed by a build or deployment system.
Both Chef and/or Docker need access to these binary objects in order to
build out the environment needed for my application.

The binary objects are not code or libraries.  They are purely a zip file
of static resources (ex: gifs or help documentation/templates/etc, GeoIP
database, etc).  I need them somewhere centrally accessible so that my
deployment system can easily retrieve them and explode them in the
container/environment to make accessible to my application.

At the moment, they are being hosted in a "raw" Nexus repo.  But the
problem with a raw repo is that there is no classification of
artifacts/versioning/etc.  So I am considering giving them all a GAV id and
putting it in the Maven repo as a maven artifact.

But is this poor practice?  I've always considered Maven artifacts as
"code-related" - that is artifacts that are the output of some code
development.  Could be compiled sources, javadocs, generated artifacts,
etc.  But putting in these static binaries just seems "wrong".  However, I
don't really see a good alternative.

I realize that this "can" be done.  I guess my question is rather "should"
it be done?  How is everyone else handling these types of resources?

Thanks,

Eric

Re: Special parameters - sha1

[Eric B]

Hi Bernd,

Thanks for the insight.  I understand what you mean, and to be honest, not
entirely sure how to deal with that yet.  At the moment, it isn't a huge
deal for me since my project is fairy self contained.  I have an API module
which I need to version independently, but other than that, there are no
artifacts produced that are consumed outside of my project... yet.

But my issue is that I really dont know how to best handle this situation.
At the moment, I am forced to build my release branch in snapshot mode
which is aggravating.  I'm on Nexus 3 which doesn't support staging repos
yet, and I've already generated at least 20+ builds from this release
branch.  I can't keep rolling my semantic version number each time ... My
business stakeholders would have a fit seeing version 5.0.63 being released
instead of 5.0.0.

Are there other recommended processes to use instead? Nexus 2 staging repos
dealt with all this very neatly, but with that not coming to v3 for at
least 2 more quarters I need to put together a more functional solution.

Thanks

Eric

On Nov 16, 2017 12:50 AM, "Bernd Eckenfels" <e...@zusammenkunft.net> wrote:

> Hello,
>
> If you have a POM with dependencies to other modules which are built on
> each change, you typically want to make sure you use those updated
> dependencies when you compile your projects.
>
> With regularly changing version numbers and without using SNAPSHOT
> dependencies you will need to find a solution for this. You could use
> version ranges, but then you are not much different then using SNAPSHOT
> builds. This is one of the main reasons why we are doing manual releases -
> and managing the dependency versions by hand.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric Benzacar <e...@benzacar.ca>
> Sent: Thursday, November 16, 2017 5:05:45 AM
> To: Maven Users List
> Cc: i...@soebes.de
> Subject: Re: Special  parameters - sha1
>
> I'm not sure what you mean when you say:
>
> "How are you planning to deal with the changed version numbers of
> dependencies?"
>
> At which stage are you referring to?  Which dependencies with changed
> version numbers?
>
> Thanks,
>
> Eric
>
> On Wed, Nov 15, 2017 at 1:11 AM, Bernd Eckenfels <e...@zusammenkunft.net>
> wrote:
>
> > You have to remember that POMs are also the model to describe artifacts,
> > that why you should stay clear of profiles (especially if the influence
> > artifact coordinates).
> >
> > Personally I have good experience with actually releasing things, but if
> > you want to keep the build identifier, then I would agree, that handling
> > this in the build job is probably the best. You can have even two
> > Parameterized jobs.
> >
> > How are you planning to deal with the changed version numbers of
> > dependencies?
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > From: Eric B <ebenza...@gmail.com>
> > Sent: Wednesday, November 15, 2017 4:30:06 AM
> > To: i...@soebes.de; Maven Users List
> > Subject: Re: Special  parameters - sha1
> >
> > Hi,
> >
> > Thanks for the additional insight.  I think I understand better now how
> > this works.   I'll try to explain my use case, and perhaps someone can
> > provide some ideas for best practices.
> >
> > I started a pom refactoring because I wanted to add the enforcer-plugin
> for
> > a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
> > dev purposes, we have defined that anything in a release/ branch
> (Gitflow)
> > is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
> > Additionally, we use semantic versioning, so our versions read 4.7.0,
> > 4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a
> release
> > branch needs to have a unique version.  I don't want to update the
> version
> > number for each build, so each build has to have a build number or sha1
> > attached to the version.
> >
> > My build pipeline is very basic for the moment; it's a simple Jenkins
> > freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it
> as
> > simple as possible and always pass the same parameters to the maven build
> > process (to make it easier for others to understand).
> >
> > I'm passing the following parameters to the maven build:
> >  -DbranchType=release
> >  -DbuildNumber=
> >
> > maven.config:
> > -Drevision=5.0.0
> >
> >
> >
> > My thought process is I could do the following - for the normal use case
> > (ie:

Re: Special parameters - sha1

[Eric B]

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=

maven.config:
-Drevision=5.0.0



My thought process is I could do the following - for the normal use case
(ie: dev branch):
${revision}${changelist}

  -SNAPSHOT



For a release:

  relelase
  

   branchType
   release

  
   
  
  ${buildNumber}
   




But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>> ${revision}-${sha1}
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> ${revision}-${sha1}
>>
>> 
>>   ${buildNumber}
>> 
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=9
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case to design it as:
>>
>> ${artifactVersion}
>> 
>>${revision}
>> 
>>
>> 
>>buildNumber
>>
>>   ${revision}-${sha1}
>>
>> 
>>
>>
>> What is the reason for this limitation?  Is there any chance that this
>> limitation will be removed in the future?
>>
>
> The question is why do you need a profile for this? You can define
> defaults in .mvn/maven.config ...and during a CI build you can give other
> information via command line ?
>
> I don't see the need for a profile ? Maybe you can elaborate a little bit
> more what the real problem is ? ...
>
>
> Kind regards
> Karl Heinz Marbaise
>

Re: Is there a plugin that allows me to modify existing jar manifest?

[Eric B]

Thanks Maxim.  Will take a look at how you are using the assembly.xml to
accomplish that.

Much appreciated.

Eric

On Nov 13, 2017 10:03 PM, "Maxim Solodovnik" <solomax...@gmail.com> wrote:

> Hello Eric,
>
> we are using assembly plugin to achieve this:
> https://github.com/apache/openmeetings/blob/master/
> openmeetings-screenshare/pom.xml#L158
>
> On Tue, Nov 14, 2017 at 8:53 AM, Eric B <ebenza...@gmail.com> wrote:
>
> > Martin,
> >
> > Thanks, but the jar-plugin only allows to build a jar from the current
> > project (and set appropriate Manifest entries).  I'm looking to modify an
> > existing jar.  I could use the dependency plugin to retrieve the jar, and
> > unpack it, then point the jar-plugin to the unpacked dependency and have
> it
> > repkg the dependency from the unpacked classes, but was hoping for
> > something a little less manual.  For multiple dependencies, I would need
> to
> > write a different execution config for the jar-plugin which becomes quite
> > bloatsome for my pom.  I was just hoping for a cleaner/easier approach.
> >
> > I started looking at the shade plugin with a manifest transformer, but
> that
> > too becomes individual execution configs.
> >
> > Thanks,
> >
> > Eric
> >
> > On Mon, Nov 13, 2017 at 8:03 PM, Martin Gainty <mgai...@hotmail.com>
> > wrote:
> >
> > >
> > >
> > > 
> > > From: Eric B <ebenza...@gmail.com>
> > > Sent: Monday, November 13, 2017 5:51 PM
> > > To: Maven Users List
> > > Subject: Is there a plugin that allows me to modify existing jar
> > manifest?
> > >
> > > I'm looking to modify an existing third-party JAR's Manifest file in my
> > > maven build.  Specifically, I have an Applet which has a dependency on
> > > these third party jars, and need to add some entries/permissions to the
> > > Manifest before I sign them for my Applet to use.
> > >
> > > I'm looking to add the following:
> > >
> > >all-permissions
> > > *
> > >
> > > * > > Library-Allowable-Codebase>
> > > true
> > > MyApp
> > >
> > > *
> > >
> > > MG>Eric...did you try  configuration parameter of
> > > maven-jar-plugin ?
> > > https://maven.apache.org/plugins/maven-jar-plugin/examples/
> > > manifest-customization.html
> > > Apache Maven JAR Plugin – Manifest customization<https://maven.ap
> > > ache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
> >
> > > maven.apache.org
> > > The default contents of the manifest is described in the documentation
> > for
> > > Maven Archiver. Starting with version 2.1, the maven-jar-plugin uses
> > Maven
> > > Archiver 3.1.1 ...
> > >
> > > MG>https://maven.apache.org/shared/maven-archiver/index.html
> > > Apache Maven Archiver – Reference<https://maven.apache
> > > .org/shared/maven-archiver/index.html>
> > > maven.apache.org
> > > Apache Maven Archiver. The Maven Archiver is mainly used by plugins to
> > > handle packaging. The version numbers referenced in the Since column on
> > > this page are the ...
> > >
> > >
> > >
> > >
> > > I realize that these aren't particularly secure parameters, but right
> now
> > > I'm just trying to see what it will take to get this working.
> > >
> > > Is there a plugin that will allow me to modify an existing jar?  I'm
> > using
> > > the dependency plugin to retrieve them from Maven, but once I have them
> > > locally, I'm not sure what to use to update the MANIFEST.  Is this
> > > something the assembly plugin can do easily?  I've looked at the
> assmbly
> > > descriptor reference, but don't see where/how it can be leveraged for
> > this.
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: Special parameters - sha1

[Eric B]

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B <ebenza...@gmail.com>
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special  parameters - sha1
>
> Following a long thread on this list, and a blog by khmarbaise (
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-
> without-a-version-in-it/),
> I'm still a little confused as to exactly what is allowed in the special
> version tags for a maven pom.
>
> I know and realize that the 3 allowable tags are:
>  - ${revision}
>  - ${sha1}
>  - ${changelist}
>
> However, from the thread and the blog, it seems that these properties
> cannot be dependent on any other properties.
>
> For example, this is fine:
>${revision}-${sha1}
> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>
>
> However, based on the further docs at
> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>
> ${revision}-${sha1}
>
> 
>  ${buildNumber}
> 
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=9
>
>
> Is anyone able to shed some light as to why this would be the case?  Why
> can a property not be used to compute on of the 3 special vars?
>
> My use case is that I want to supply the build number to all my builds, but
> only append it to the version if a specific profile is enabled.  In my
> mind, it would be simple - make the sha1 property empty by default, and in
> my specific profile, set it to the buildnumber.   But based on my
> understanding, this would fail.
>
> Is my only option in that case to design it as:
>
> ${artifactVersion}
> 
>   ${revision}
> 
>
> 
>   buildNumber
>   
>  ${revision}-${sha1}
>   
> 
>
>
> What is the reason for this limitation?  Is there any chance that this
> limitation will be removed in the future?
>
> Thanks,
>
> Eric
>

Special parameters - sha1

[Eric B]

Following a long thread on this list, and a blog by khmarbaise (
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
I'm still a little confused as to exactly what is allowed in the special
version tags for a maven pom.

I know and realize that the 3 allowable tags are:
 - ${revision}
 - ${sha1}
 - ${changelist}

However, from the thread and the blog, it seems that these properties
cannot be dependent on any other properties.

For example, this is fine:
   ${revision}-${sha1}
where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e


However, based on the further docs at
https://maven.apache.org/maven-ci-friendly.html, this design would fail:

${revision}-${sha1}


 ${buildNumber}



and call it as -Drevision=1.2.3 -DbuildNumber=9


Is anyone able to shed some light as to why this would be the case?  Why
can a property not be used to compute on of the 3 special vars?

My use case is that I want to supply the build number to all my builds, but
only append it to the version if a specific profile is enabled.  In my
mind, it would be simple - make the sha1 property empty by default, and in
my specific profile, set it to the buildnumber.   But based on my
understanding, this would fail.

Is my only option in that case to design it as:

${artifactVersion}

  ${revision}



  buildNumber
  
 ${revision}-${sha1}
  



What is the reason for this limitation?  Is there any chance that this
limitation will be removed in the future?

Thanks,

Eric

Re: Is there a plugin that allows me to modify existing jar manifest?

[Eric B]

Martin,

Thanks, but the jar-plugin only allows to build a jar from the current
project (and set appropriate Manifest entries).  I'm looking to modify an
existing jar.  I could use the dependency plugin to retrieve the jar, and
unpack it, then point the jar-plugin to the unpacked dependency and have it
repkg the dependency from the unpacked classes, but was hoping for
something a little less manual.  For multiple dependencies, I would need to
write a different execution config for the jar-plugin which becomes quite
bloatsome for my pom.  I was just hoping for a cleaner/easier approach.

I started looking at the shade plugin with a manifest transformer, but that
too becomes individual execution configs.

Thanks,

Eric

On Mon, Nov 13, 2017 at 8:03 PM, Martin Gainty <mgai...@hotmail.com> wrote:

>
>
> ____
> From: Eric B <ebenza...@gmail.com>
> Sent: Monday, November 13, 2017 5:51 PM
> To: Maven Users List
> Subject: Is there a plugin that allows me to modify existing jar manifest?
>
> I'm looking to modify an existing third-party JAR's Manifest file in my
> maven build.  Specifically, I have an Applet which has a dependency on
> these third party jars, and need to add some entries/permissions to the
> Manifest before I sign them for my Applet to use.
>
> I'm looking to add the following:
>
>all-permissions
> *
>
> * Library-Allowable-Codebase>
> true
> MyApp
>
> *
>
> MG>Eric...did you try  configuration parameter of
> maven-jar-plugin ?
> https://maven.apache.org/plugins/maven-jar-plugin/examples/
> manifest-customization.html
> Apache Maven JAR Plugin – Manifest customization<https://maven.ap
> ache.org/plugins/maven-jar-plugin/examples/manifest-customization.html>
> maven.apache.org
> The default contents of the manifest is described in the documentation for
> Maven Archiver. Starting with version 2.1, the maven-jar-plugin uses Maven
> Archiver 3.1.1 ...
>
> MG>https://maven.apache.org/shared/maven-archiver/index.html
> Apache Maven Archiver – Reference<https://maven.apache
> .org/shared/maven-archiver/index.html>
> maven.apache.org
> Apache Maven Archiver. The Maven Archiver is mainly used by plugins to
> handle packaging. The version numbers referenced in the Since column on
> this page are the ...
>
>
>
>
> I realize that these aren't particularly secure parameters, but right now
> I'm just trying to see what it will take to get this working.
>
> Is there a plugin that will allow me to modify an existing jar?  I'm using
> the dependency plugin to retrieve them from Maven, but once I have them
> locally, I'm not sure what to use to update the MANIFEST.  Is this
> something the assembly plugin can do easily?  I've looked at the assmbly
> descriptor reference, but don't see where/how it can be leveraged for this.
>
> Thanks,
>
> Eric
>

Is there a plugin that allows me to modify existing jar manifest?

[Eric B]

I'm looking to modify an existing third-party JAR's Manifest file in my
maven build.  Specifically, I have an Applet which has a dependency on
these third party jars, and need to add some entries/permissions to the
Manifest before I sign them for my Applet to use.

I'm looking to add the following:

   all-permissions
*

*
true
MyApp

*

I realize that these aren't particularly secure parameters, but right now
I'm just trying to see what it will take to get this working.

Is there a plugin that will allow me to modify an existing jar?  I'm using
the dependency plugin to retrieve them from Maven, but once I have them
locally, I'm not sure what to use to update the MANIFEST.  Is this
something the assembly plugin can do easily?  I've looked at the assmbly
descriptor reference, but don't see where/how it can be leveraged for this.

Thanks,

Eric

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric B]

Thanks.  The extension is precisely what I'm looking for.

Eric

On Nov 9, 2017 3:47 AM, "Pascal" <pascal.gr...@gmail.com> wrote:

> >  interpolation of these special parameters must happen prior to the
> execution of any plugins
>
> That's exactly correct. It's why I built
> https://github.com/pascalgn/properties-maven-extension which is
> implemented
> as an extension and runs before any plugins will be executed.
> Maybe it can help you.
>
> 2017-11-09 3:11 GMT+01:00 Eric B <ebenza...@gmail.com>:
>
> > I tried removing the empty sha1 declaration as well but that didn't work
> > either.
> >
> > I'm guessing it's due to sequencing - that the interpolation of these
> > special parameters must happen prior to the execution of any plugins, but
> > would love confirmation of that.  Additionally would love to know if
> there
> > is a workaround for this situation.
> >
> > Thanks
> >
> > Eric
> >
> > On Nov 8, 2017 6:35 PM, "Laird Nelson" <ljnel...@gmail.com> wrote:
> >
> > > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar <e...@benzacar.ca> wrote:
> > >
> > > > But when I actually run the build all the interpolated version
> numbers
> > > > ignore the ${sha1} property as generated by the buildnumber-m-p, even
> > > > though I bound the create to the validate phase.
> > > >
> > >
> > > [snip]
> > >
> > > A snippet of my pom:
> > > >
> > > > 
> > > > test
> > > > org.project
> > > > ${revision}${sha1}${changelist}
> > > > 
> > > > 
> > > >
> > >
> > > Blind guess: since the buildnumber-maven-plugin is going to set
> > properties
> > > using internal machinery, and you've told it the one to set should be
> > named
> > > sha1, is it possible that this empty property of the same name is
> > shadowing
> > > the one set by the plugin, or that perhaps the plugin won't set it
> since
> > > it's already (effectively) specified?
> > >
> > > Best,
> > > Laird
> > > --
> > > https://about.me/lairdnelson
> > >
> >
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric B]

I tried removing the empty sha1 declaration as well but that didn't work
either.

I'm guessing it's due to sequencing - that the interpolation of these
special parameters must happen prior to the execution of any plugins, but
would love confirmation of that.  Additionally would love to know if there
is a workaround for this situation.

Thanks

Eric

On Nov 8, 2017 6:35 PM, "Laird Nelson"  wrote:

> On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar  wrote:
>
> > But when I actually run the build all the interpolated version numbers
> > ignore the ${sha1} property as generated by the buildnumber-m-p, even
> > though I bound the create to the validate phase.
> >
>
> [snip]
>
> A snippet of my pom:
> >
> > 
> > test
> > org.project
> > ${revision}${sha1}${changelist}
> > 
> > 
> >
>
> Blind guess: since the buildnumber-maven-plugin is going to set properties
> using internal machinery, and you've told it the one to set should be named
> sha1, is it possible that this empty property of the same name is shadowing
> the one set by the plugin, or that perhaps the plugin won't set it since
> it's already (effectively) specified?
>
> Best,
> Laird
> --
> https://about.me/lairdnelson
>

Am stuck - I need to pass -noverify to my build for one module, but another module requires that it not be there.

[Eric B]

I'm running into a problem with my build which includes an AspectJ 1.8
module, and not sure how to resolve this.

I have a multi-module maven build.  One of my modules requires running an
ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
Consequently, I run the entire maven build using the -noverify flag.

$ cat .mvn/jvm.config
-noverify -Xmx2048m -Xms1024m -Djava.awt.headless=true


But my last module being build is a module of aspects.  When I try to
compile & weave using the aspectj-maven-plugin, I get the following error
thrown:

[ERROR] Failed to execute goal
org.codehaus.mojo:aspectj-maven-plugin:1.10:compile (default) on project
adams-aspects: AJC compiler errors:
[ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
generation for woven code is required to avoid verify errors on a Java 1.7
or higher runtime
[ERROR] when weaving type webapp.tiles.AthleteBasedForm
[ERROR] when weaving classes
[ERROR] when weaving
[ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
[ERROR] ...
[ERROR] ...



org.codehaus.mojo
aspectj-maven-plugin
1.10

true
1.8
1.8
1.8


org.project
web
war






compile







So I'm a bit in a bind.   I can't figure out any way to reconcile both
requirements - that module1 needs to run an antrun plugin with the
-noverify parameter, and the aspectj plugin that needs to run it without.

I've looked to see if there is any way to fork either plugin, but don't see
an ability to do that.

Is there some way I can fork the antrun plugin and append the -noverify
parameter to the jvm params?  I've looked at updating the build.xml, but it
uses a custom Taskdef, so I'm not 100% how that can be done.


My antrun-plugin configuration is:
















Or alternatively, is there some other plugin that I leverage to fork a
maven plugin?

Thanks,

Eric

Re: When time do we need to delete .m2/repository

[Eric B]

I have my jenkins jobs designed to use private m2 repos per job.  I dont
find the need to delete them since the only transient changes are the
snapshots, which get reevaluated at every build anyhow.

Thanks

Eric


On Sep 11, 2017 2:43 PM, "Stephen Connolly" 
wrote:

On Fri 8 Sep 2017 at 11:22, Baptiste Mathus  wrote:

> Le 7 sept. 2017 17:00, "Tushar Kapila"  a écrit :
>
> I had to delete a directory once as i had pressed Ctrl-C while it was
> downloading jars and a 0kb jar was created. This was in 2013, maybe it
> downloads to a temp file and then create the final file? It took sometime
> to debug. Builds were failing for no reason only on that test box, but
> working fine on my dev box, lots of fun.
>
> > If you don't, and
> > you have static (persistent) agents, very bad things will happen at some
> point.
>
> Can you explain this? What agents?
>
>
> Hehe, I was talking about Jenkins agents, sorry just realized I mixed my
> MLs. I thought I was reading Jenkinsci-users one :).


Bad Ba(p)tiste™

;-)


>
>
> On Thu, Sep 7, 2017 at 1:59 PM, Baptiste Mathus  wrote:
>
> > 2017-09-07 9:17 GMT+02:00 Guang Chao :
> >
> > > On Fri, Sep 1, 2017 at 11:31 AM, mingleizhang 
> > > wrote:
> > >
> > > > Hello friends here.
> > > >
> > > >
> > > >  I would like ask a question ,it probably looks silly, but I
> still
> > > > want to know. As the subject said, when time do we need to delete
> > > > .m2/repository files ? Does anyone improve my mind ? Thank you very
> > much!
> > > >
> > > >
> > > >
> > > There is no need to do this unless you are out of disk space. It will
> > cause
> > > no harm, but maven will redownload all dependencies again. So that
will
> > > slow you down a bit.
> > >
> >
> > I am actually going to say the contrary. You should, at I'd even say,
you
> > *must* wipe out Maven repositories on a regular basis. If you don't, and
> > you have static (persistent) agents, very bad things will happen at some
> > point.
> >
> > So, yeah, redownloading it is going to add some time to build, but this
> is
> > a matter of speed vs. reproducibility, so better target
> reproduciblity/non
> > flakiness then see how to optimize, not the contrary.
> >
> > And obviously, *NEVER, EVER share that .m2/repository between running
> > builds*.
> >
> >
> > >
> > >
> > > > Thanks
> > > > Rice.
> > >
> > >
> > >
> > >
> > > --
> > > Guang 
> > >
> >
>
>
>
> --
> Regards
> Tushar Kapila
>
--
Sent from my phone

Re: Customize the bundleFilename template used by the maven-ear-plugin?

[Eric B]

Yeah - I was actually just about to respond to my own mail to indicate
exactly that.   I don't know how I missed that the first time through the
doc - I think I was looking for a property named something differently.

That's exactly what I was looking for.

Thanks!

Eric

On Tue, Jun 20, 2017 at 1:25 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi,
>
> Have you checked the documentation about.. fileNameMapping
>
> the following from the docs:
>
> The file name mapping to use for all dependencies included in the EAR
> file. The following values are valid standard, {code no-version}, full,
> no-version-for-ejb. The standard means the filename is the artifactId incl.
> the version of the artifact. The no-version means the files is only the
> artifactId without the version. The full means the filename is the
> groupId+artifactId+version of the artifact. The no-version-for-ejb means
> the filename is the artifactId without the version in case of EJB type.
>
>
> Are you looking for something like that?
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> On 20/06/17 19:21, Eric B wrote:
>
>> Is there a way to customize the filename used by the maven-ear-plugin for
>> the different modules but in a general template way?
>>
>> At the moment, the bundleFilename by default seems to be:
>> ${artifactId}-${version}.${packaging}
>>
>> I would like to prepend it with a $[groupId} as well.
>> ${groupId}-${artifactId}-${version}.${packaging}
>>
>> where the groupId/artifactId/version/packaging belong to the module in
>> question.
>>
>>
>> However, I do not want to manually specify each module bundleFilename
>> manually.
>>
>> Is there a way to configure this using parameterization?
>>
>> ex:
>> 
>> maven-ear-plugin
>> 
>>
>> ${groupId}-${artifactId}-${version}.
>> ${packaging}
>> ??
>> 
>> 
>>
>>
>> Anything remotely similar exist, or anyway to achieve a similar
>> functionality?  If I use ${groupId}/etc in the module definition, it
>> actually uses the ${project.groupId} instead of the webmodule.groupId.
>>
>> Thanks,
>>
>> Eric
>>
>>

Customize the bundleFilename template used by the maven-ear-plugin?

[Eric B]

Is there a way to customize the filename used by the maven-ear-plugin for
the different modules but in a general template way?

At the moment, the bundleFilename by default seems to be:
${artifactId}-${version}.${packaging}

I would like to prepend it with a $[groupId} as well.
${groupId}-${artifactId}-${version}.${packaging}

where the groupId/artifactId/version/packaging belong to the module in
question.


However, I do not want to manually specify each module bundleFilename
manually.

Is there a way to configure this using parameterization?

ex:

   maven-ear-plugin
   

${groupId}-${artifactId}-${version}.${packaging}
??
   



Anything remotely similar exist, or anyway to achieve a similar
functionality?  If I use ${groupId}/etc in the module definition, it
actually uses the ${project.groupId} instead of the webmodule.groupId.

Thanks,

Eric

Re: Jenkins Maven build not seeing my .mvn folder?

[Eric B]

Thanks for the links and the info, but after reading MNG-5889, I'm even
more confused.

Am I to understand that MNG-5889 is specifically regarding Maven to look
for the .mvn folder in the directory of the invoked pom file rather than in
the current working directory?  Will this break my current structure in
which my .mvn folder is in my project root rather than the parent-pom
folder?

What is the "right" structure for something like this?

Thanks,

Eric

On Tue, Jun 6, 2017 at 2:31 PM, Arnaud Héritier <aherit...@gmail.com> wrote:

> It is https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5889
>
>
> Le mar. 6 juin 2017 à 20:27, Arnaud Héritier <aherit...@gmail.com> a
> écrit :
>
> > The problem with extensions is different. And I don't think we'll fix it.
> > The problem .mvn and usage of -f is a maven bug fixed in 3.5.0 or 3.5.1
> >
> > Le mar. 6 juin 2017 à 19:36, Pascal <pascal.gr...@gmail.com> a écrit :
> >
> >> The existing bug to support core extensions:
> >> https://issues.jenkins-ci.org/browse/JENKINS-30058
> >>
> >> As I said, the only solution so far is to use a Freestyle project. You
> can
> >> find more details in the bug comments.
> >>
> >> Pascal
> >>
> >>
> >> 2017-06-06 19:27 GMT+02:00 Pascal <pascal.gr...@gmail.com>:
> >>
> >> > Hello,
> >> >
> >> > I fear you have done everything correctly and the issue is with the
> >> > Jenkins Maven plugin. There is already a bug report in the Jenkins
> Maven
> >> > Plugin, but it's hard to find. If I recall how to find it, I will post
> >> it
> >> > here.
> >> >
> >> > Unfortunately, it does not look like an easy bug, so you cannot use
> the
> >> > "Maven" Job type in Jenkins together with the .mvn folder feature.
> >> However,
> >> > what you can do is create a Freestyle Job and add a build step "Call
> >> Maven
> >> > goals".
> >> >
> >> > Cheers,
> >> >
> >> > Pascal
> >> >
> >> >
> >> > 2017-06-06 18:13 GMT+02:00 Eric B <ebenza...@gmail.com>:
> >> >
> >> >> Hi,
> >> >>
> >> >> I'm cross posting this to StackOverflow (
> >> >> https://stackoverflow.com/q/44394234/827480) b/c I'm not truly
> >> convinced
> >> >> this is a maven question per say.  Rather I think it is more
> something
> >> due
> >> >> to my Jenkins job config that is causing some issues, but I am hoping
> >> that
> >> >> maven users here may have encountered this in Jenkins as well.
> Either
> >> >> that, or maybe someone can point out that I'm using the .mvn folder
> >> >> incorrectly.
> >> >>
> >> >> Essentially, I have a multi-module maven project that is set up as:
> >> >>
> >> >> |.mvn
> >> >>  \-maven.config
> >> >>  \-jvm.config
> >> >> |superpom
> >> >>  \-pom.xml (main project parent pom, includes module defns)
> >> >> |module1
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >> >>  \src
> >> >>   \...
> >> >> |module2
> >> >>  \-pom.xml (parent points to ../superpom/pom.xml)
> >> >>  \src
> >> >>   \...
> >> >>
> >> >> My maven.config file is defined as:
> >> >>
> >> >> -Dsign.alias=cert
> >> >> -Dsign.storepass=changeit
> >> >> -Dsign.keypass=changeit
> >> >> -Dcheckstyle.skip=true
> >> >> -Dcobertura.skip=true
> >> >> -Dpmd.skip=true
> >> >> -DskipTests=true
> >> >> -DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
> >> >> -DuserName=test
> >> >> -Dpassword=test
> >> >> -f superpom/pom.xml
> >> >>
> >> >> If I run my maven build from the command line, everything builds as
> >> >> expected. ie:
> >> >>
> >> >> [project]$ mvn clean install
> >> >>
> >> >> However, when I configure my jenkins job, it is failing as though it
> is
> >> >> not
> >> >> seeing/reading the .mvn/ folder/files. In fact, to be honest, I'm not
> >> >> entirely sure how to configure my maven project in Jenkins. If I
> leave
> >

Jenkins Maven build not seeing my .mvn folder?

[Eric B]

Hi,

I'm cross posting this to StackOverflow (
https://stackoverflow.com/q/44394234/827480) b/c I'm not truly convinced
this is a maven question per say.  Rather I think it is more something due
to my Jenkins job config that is causing some issues, but I am hoping that
maven users here may have encountered this in Jenkins as well.  Either
that, or maybe someone can point out that I'm using the .mvn folder
incorrectly.

Essentially, I have a multi-module maven project that is set up as:

|.mvn
 \-maven.config
 \-jvm.config
|superpom
 \-pom.xml (main project parent pom, includes module defns)
|module1
 \-pom.xml (parent points to ../superpom/pom.xml)
 \src
  \...
|module2
 \-pom.xml (parent points to ../superpom/pom.xml)
 \src
  \...

My maven.config file is defined as:

-Dsign.alias=cert
-Dsign.storepass=changeit
-Dsign.keypass=changeit
-Dcheckstyle.skip=true
-Dcobertura.skip=true
-Dpmd.skip=true
-DskipTests=true
-DdatabaseUrl=jdbc:sqlserver://localhost:1433;databaseName=TEMP
-DuserName=test
-Dpassword=test
-f superpom/pom.xml

If I run my maven build from the command line, everything builds as
expected. ie:

[project]$ mvn clean install

However, when I configure my jenkins job, it is failing as though it is not
seeing/reading the .mvn/ folder/files. In fact, to be honest, I'm not
entirely sure how to configure my maven project in Jenkins. If I leave my
ROOT pom definition as blank, then Jenkins complains it doesn't have a
pom.xml file.

If I specify my root pom as superpom/pom.xml then it isn't loading any of
my config files.

To be safe, I've even tried adding my .mvn folder in my superpom folder,
but that too is ignored.

jenkins.log:

[superpom] $ /var/jenkins_home/tools/hudson.model.JDK/JDK_7/bin/java
-cp 
/var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-agent-1.8.1.jar:/var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.3.9/boot/plexus-classworlds-2.5.2.jar:/var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.3.9/conf/logging
jenkins.maven3.agent.Maven33Main
/var/jenkins_home/tools/hudson.tasks.Maven_MavenInstallation/Maven_3.3.9
/var/jenkins_home/war/WEB-INF/lib/remoting-3.7.jar
/var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven33-interceptor-1.8.1.jar
/var/jenkins_home/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.8.1.jar
38679
<===[JENKINS REMOTING CAPACITY]===>channel started
using settings config with name Settings.xml
Replacing all maven server entries not found in credentials list is true
Executing Maven:  -B -f
/var/jenkins_home/workspace/JB4(Maven)/superpom/pom.xml
-Dmaven.repo.local=/var/jenkins_home/workspace/JB4(Maven)/.repository
-s /tmp/settings4167440206098086967.xml clean install
[INFO] Scanning for projects...


I'm not sure if I am using the .mvn folder incorrectly, if there is
something wrong with my Jenkins job configuration.

Am I doing this right?  Am I missing a step somewhere?

Thanks,

Eric

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric B]

Right... That will give me a build number, but I still need to figure a way
to provide the version number to the build.  That one had me stumped.

Thanks

Eric

On May 9, 2017 10:46 PM, "Bernd Eckenfels"  wrote:

> You can use the Jenkins environment variable for the build number of a job
> as a read-only parameter.  And I think ${env.BUILD_NUMBER} should also work
> on the command line.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric Benzacar 
> Sent: Wednesday, May 10, 2017 3:32:43 AM
> To: Maven Users List; i...@soebes.de
> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>
> Thanks for the detailed explanation.
>
> A couple of questions come to mind:
>
> 1) can the  element only contain a variables, or can it be a
> combination of fixed + variable?
> for instance:
> 1.2-${changelist}
>
> I see in your examples that it only is a combination of variables with no
> additional text.
>
>
> 2) How do you handle your CD build definitions, given the need to pass the
> revision number at build time?  Do you end up creating new build
> definitions for each version, edit the existing build definition for a new
> version, or is there a way to create a generic build definition that can
> handle this case?
>
> I'm using Jenkins and my biggest annoyance is the need to update/modify my
> Jenkins job definitions.  I could potentially create parameterized build
> defn, where the user enters the rev #, but that is just going to be error
> prone.  I'm trying to remove as much of the human element from this as
> possible.
>
> Is there a way to design the job definition so that I don't have to specify
> this information?  I realize that I can use the mvn.config file to specify
> the revision value but what is the advantage of using that and changing
> that file for each version rather than just changing the pom file itself?
> Isn't it just shifting the problem from one place to another?
>
> Thanks,
>
> Eric
>
>
> On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > I think it is needed to explain that in more detail (means also to
> improve
> > the ci documentation).
> >
> >
> > Let me start with the following:
> >
> > You can only use those three names "revision", "changelist" and "sha1" in
> > a version tag of the pom file cause they are handled special (the
> > foundation of its handling is given by the explanation of Bernd Eckenfeld
> > Thanks to Bernd).
> >
> > This means in consequence the given part will not work as expected (at
> the
> > moment):
> >
> > com.soebes.examples.j2ee
> parent > >
> > ${revision}
> > pom
> > 
> >   1.2.1-${buildNumber}
> >   SNAPSHOT
> > 
> >
> >
> > If you like to make combinations you can do it like this for example:
> > (https://github.com/khmarbaise/javaee/tree/maven350-properties):
> >
> >   com.soebes.examples.j2ee
> >   parent
> >   ${revision}${sha1}${changelist}
> >   pom
> >
> >   
> > 1.6
> > 1.6
> > 1.3.1
> > -SNAPSHOT
> > 
> >   
> >
> > or to pickup the previous example which should look like this:
> >
> > com.soebes.examples.j2ee
> parent > >
> > ${revision}${changelist}
> > pom
> > 
> >   1.2.1
> >   -SNAPSHOT
> > 
> >
> > So now your build will work as expected.
> >
> > If you like to switch to release you simply do that by using the
> following:
> >
> > mvn -Dchangelist= clean package (This will define changelist as empty).
> >
> > Or if you like to give a buildNumber from commandline:
> >
> > mvn -Dchangelist=-23-SNAPSHOT clean package
> >
> > So to make it more convenient you can define the versions like this:
> >
> >   com.soebes.examples.j2ee
> >   parent
> >   ${revision}${sha1}${changelist}
> >   pom
> >
> >   
> > 1.6
> > 1.6
> > 1.3.1
> > -SNAPSHOT
> > 
> >   
> >
> > So now I can build via (be carefull with the separator between version
> and
> > buildnumber "-"):
> >
> > mvn -Dsha1=-123 clean package
> >
> > By the above you can now define many combinatations on the command line:
> >
> > mvn -Dchangelist= clean package
> >
> > This means the command line overwrites the values of the properties which
> > are defined in the pom file (properties section).
> >
> > You can of course remove the properties (properties section) from the pom
> > file at all and only define the information on command line (works in
> > Eclipse). But you can also define those things in ".mvn/maven.config" via
> > the appropriate "-D...".
> >
> >
> > So now lets come to the point about flatten-maven-plugin:
> >
> > Assume you are using above proerties in kind of flavour...now you are
> > using my example( https://github.com/khmarbaise/
> > javaee/tree/maven350-properties) without the flatten-maven-plugin in the
> > build:
> >
> > mvn install
> >
> > The result of that would be having a folder in your local cache like etc.
> > where you find a jar file and of course a pom file: (I 

Re: Continuous Delivery with Maven now possible?

[Eric B]

Hi Dan,

Can you point me to Karl's blog please? I looked for it, but can't seem to
find it.

Thanks!

Eric

On May 3, 2017 8:56 PM, "Dan Tran" <dant...@gmail.com> wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B <ebenza...@gmail.com> wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Continuous Delivery with Maven now possible?

[Eric B]

Hi Karl,

Can you provide a little more information how you are doing this? Or do you
have a blog about it somewhere? It's something I desperately need to insert
into my build pipeline but haven't had the time to work on yet.  So far,
the best I've been able to think of is to use a parameter for a build
number, have Jenkins assign a build number, pass it to maven, and have the
version reflect the build number using the external parameter.  But I
really don't like that idea as the version is now dependent on a variable,
which I find is contrary to the whole concept.

The other option is to have Jenkins took the build number in the pom using
the release plugin or the version plugin, commit the new pom, and then
build from a newly checked out code.  My issue there is that I'm having
Jenkins do a lot of scm manipulations which are more subject to failing
(ie: version updates, commit, tag, push, etc).

Finally, I'm trying to think of a good way of rolling all this into Nexus
staging repos and only promoting a build out of a staging repo once it
passes the pre prod environment and is certified for prod.

Any ideas, thoughts, feedback and/or tips would be greatly appreciated.

Thanks,

Eric

On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:

> Hi Dan,
>
> I'm trying to do something in this direction starting next week...
>
> Apart from that already tested it with Eclipse Neon without any
> issue...(at the moment only test projects with 10-15 modules)...
>
> But it works at the moment..
>
> In the meantime I have found one issue which is related to
> maven-enforcer-plugin where I already opened an issue for it [1]..
>
> Kind regards
> Karl Heinz
>
> [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>
> On 03/05/17 20:39, Dan Tran wrote:
>
>> Hi
>>
>> I have been experimenting with suggestion from Karl [1] with small multi
>> module maven project.
>>
>>
>> Is there any one actually bring this to production for large scale project
>> yet? Love to learn from your experience integration specially with
>> Jenkins,
>> IDE ( eclipse,  intellij, Netbean)
>>
>> this allows us to stop using maven-release-plugin
>>
>> Thanks
>>
>> -Dan
>>
>> [1]
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Using maven-ejb-plugin and creating an EAR

[Eric B]

Hi,

I've got a JEE project that has EJBs being accessed both locally and
remotely.  But I'm not entirely sure how to use the ejb-plugin and the
ear-plugin to create my ear.

At the moment, I'm using the ejb-plugin to create my EJB artifact:

4.0.0
root.project
ejbs
ejb
1.0
enterprise java beans

...
...



maven-ejb-plugin

3.0


true








I am then including the generated ejb in my WAR as follows:
4.0.0
root.project.servlets
servlet
war
servlet
...


root.project
ejbs
${project.version}
ejb

...
...



Finally, in my EAR, I have the following:
4.0.0
root.project
ear
ear
1.0
ear assembly


root.project
ejbs
ejb


root.project.servlets
servlet
war





maven-ear-plugin

lib/
true


true








The EAR builds properly. The issue that I have is that is that the EJB
module is added in both the root of my EAR and in the
servlet.war/WEB-INF/lib folder. The classloader then finds 2 copies of the
classes in my application - one from the WAR and the one from the EAR.

Obviously, this is not right. But I am not sure what the right way to do
this is. Am I obliged to generate an ejb-client and include the ejb-client
in my WAR only? However, then I will still have 2 copies of the interface -
one in the ejb jar and one in the ejb-client.jar. How does this improve the
situation of duplicate classes in the classloader?

Furthermore, I noticed that the ejb-plugin doesn't just put the EJB
interfaces in the client package.  By default it puts any Bean inner
classes as well as utility classes, etc.  I realize that I can manually
configure the plugin to specify exactly which classes to include or
exclude, but that seems like it is not following the maven conventions over
configuration principles.

What are the best practices and approaches for using EJBs with Maven?  What
is the best way to build a WAR/EAR with Maven?

Thanks,

Eric

Re: maven-artifact-transfer not able to resolve SNAPSHOT artifact

[Eric B]

Dan,

It's this the same type of problem that I am encountering here:
http://stackoverflow.com/q/43220923/827480 ?

For me I'm not sure of the genesis of the problem, but I suspect it is
something to do with maven not having a default snapshot repo to retrieve
artifacts.  But I don't know if you are seeing the same behaviour or if my
issue is at all related to your question.

Thanks

Eric


On Apr 3, 2017 1:55 AM, "Dan Tran"  wrote:

Hi,

I am very sure maven-artifact-transfer is not the issue.

The real issue is MavenSession.ProjectBuildingRequest.RemoteRepositories,
needed by maven-artifact-transfer, has snapshot resolution disable


For my case, I am using maven setting's mirror to route all pom's
repositories to my internal maven repository.

This also means I have only one remoteRepository with this content from my
debugger

  id: xxx
  url: http://my.internal.repo/public
   layout: default
snapshots: [enabled => false, update => daily]
 releases: [enabled => true, update => daily]

What could have caused this?

I  am seeing this issue on all maven 3.1+

Thanks

-Dan

Re: Maven https repos broken?

[Eric B]

Is it possible that a new appliance has been inserted in your network
configuration that is doing man-in-the-middle packet inspection?

I've seen several organisations recently start implementing SSL resigning
with a private root certificate that is pushed onto all PCs in a domain via
the GPO.  But java didn't recognize the PC trust store and needs to have
the same root certificate installed in its own trust store.

Easy way to test/validate is to check the https site/certificate in Browser
and see if it is truly signed by a known CA or if it is signed by a
different CA.

If it isn't a trusted CA, but you recognize the CA as your own
organisation, then you need to install the root certificate in the Java
cacerts = trust store for java).

Hope this helps.

Thanks

Eric

On Nov 18, 2016 1:01 PM, "David Delbecq"  wrote:

> Hello,
>
> I had no problem using maven for about the whole day and downloading
> artefacts, but suddently my builds started to fail with ssl certificate
> issue. The repo "repo.maven.apache.org" is answering with a certificate
> dedicated to "repo1.maven.org". I have tried  mirror https://uk.maven.org
>  and it exposes the same behaviour. Browser confirms the problem and
> refuses to let me go to those https pages. Is there some maintenance in
> progress that explains this situation?
>
> [DEBUG] Lifecycle default -> [validate, initialize, generate-sources,
> process-sources, generate-resources, process-resources, compile,
> process-classes, generate-test-sources, process-test-sources,
> generate-test-resources, process-test-resources, test-compile,
> process-test-classes, test, prepare-package, package, pre-integration-test,
> integration-test, post-integration-test, verify, install, deploy]
> [DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
> [DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
> [DEBUG] Using transporter WagonTransporter with priority -1.0 for
> https://repo.maven.apache.org/maven2
> [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
> https://repo.maven.apache.org/maven2
> Downloading:
> https://repo.maven.apache.org/maven2/org/apache/maven/
> plugins/maven-compiler-plugin/3.6.0/maven-compiler-plugin-3.6.0.pom
> [DEBUG] Writing tracking file
> /home/ddelbecq/.m2/repository/org/apache/maven/plugins/
> maven-compiler-plugin/3.6.0/maven-compiler-plugin-3.6.0.pom.lastUpdated
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 1.039 s
> [INFO] Finished at: 2016-11-18T18:51:45+01:00
> [INFO] Final Memory: 20M/481M
> [INFO]
> 
> [ERROR] Plugin org.apache.maven.plugins:maven-compiler-plugin:3.6.0 or one
> of its dependencies could not be resolved: Failed to read artifact
> descriptor for org.apache.maven.plugins:maven-compiler-plugin:jar:3.6.0:
> Could not transfer artifact
> org.apache.maven.plugins:maven-compiler-plugin:pom:3.6.0 from/to central (
> https://repo.maven.apache.org/maven2): Host name 'repo.maven.apache.org'
> does not match the certificate subject provided by the peer (CN=
> repo1.maven.org, O="Sonatype, Inc", L=Fulton, ST=MD, C=US) -> [Help 1]
> org.apache.maven.plugin.PluginResolutionException: Plugin
> org.apache.maven.plugins:maven-compiler-plugin:3.6.0 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-compiler-plugin:jar:3.6.0
> at
> org.apache.maven.plugin.internal.DefaultPluginDependenciesResol
> ver.resolve(DefaultPluginDependenciesResolver.java:117)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.
> getPluginDescriptor(DefaultMavenPluginManager.java:180)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.
> getMojoDescriptor(DefaultMavenPluginManager.java:284)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(
> DefaultBuildPluginManager.java:241)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanC
> alculator.setupMojoExecution(DefaultLifecycleExecutionPlanC
> alculator.java:170)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanC
> alculator.setupMojoExecutions(DefaultLifecycleExecutionPlanC
> alculator.java:155)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanC
> alculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanC
> alculator.java:131)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanC
> alculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanC
> alculator.java:145)
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.
> resolveBuildPlan(BuilderCommon.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> LifecycleModuleBuilder.java:110)
> at
> 

Re: mvn -U dependency:sources re-downloads released sources JARs

[Eric B]

I would suggest that the help documentation is wrong.  To my knowledge,
Maven always tries to update the snapshots at every invocation - precisely
the concept of the snapshot.  For full releases, however, Maven won't try
to re-download releases if they are already in the local repo, or if it has
already tried to find (and failed) a release within a predetermined elapsed
time.

I've always understood the -U parameter to force maven to check for
different versions than what already exists in the local repo, and to force
Maven to recheck for the existance of a dependency, even it has already
tried and failed.

Thanks,

Eric


On Tue, May 17, 2016 at 11:04 AM, Adam Mitchell 
wrote:

> Whilst that's true of the maven documentation, when you start digging into
> how it's used during artifact resolution it acts as an override for a
> repository's update policy.
>
> (from 3.3.9 release)
>
> It ends up set on
> org.apache.maven.artifact.repository.RepositoryRequest#isForceUpdate()
>
> /**
>  * Indicates whether remote repositories should be re-checked for
> updated artifacts/metadata regardless of their
>  * configured update policy.
>  *
>  * @return {@code true} if remote repositories should be re-checked
> for updated artifacts/metadata, {@code false}
>  * otherwise.
>  */
> boolean isForceUpdate();
>
> /**
>  * Enables/disabled forced checks for updated artifacts/metadata on
> remote repositories.
>  *
>  * @param forceUpdate {@code true} to forcibly check the remote
> repositories for updated artifacts/metadata, {@code
>  *false} to use the update policy configured on each
> repository.
>  * @return This request, never {@code null}.
>  */
> RepositoryRequest setForceUpdate( boolean forceUpdate );
>
> Or in the case where you end up in aether, it sets your repository session
> to always update:
> org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory:114
> else if ( request.isUpdateSnapshots() )
> {
> session.setUpdatePolicy( RepositoryPolicy.UPDATE_POLICY_ALWAYS
> );
> }
>
> The net result is the same.
>
> Though I admit that I wouldn't expect this to necessarily re-download
> source code unless the metadata was corrupt/missing, it certainly has more
> meaning that just update snapshots.
>
> Quite possibly a bug in maven-core then.
>
>
>
>
> | Adam Mitchell | Java Software Architect | Tel: +44 (0)207 633 3570 |
> Mobile:  | Skype:  | www.playtech.com
>
> This communication contains information which is privileged and
> confidential and is exclusively intended only for the individual or entity
> named above (recipient(s)). If you are not the intended recipient(s) or the
> person responsible for delivering it to the intended recipient(s), you are
> hereby notified that any review, disclosure, dissemination, distribution or
> reproduction of this communication message in any way or act is prohibited.
> If you receive this communication by mistake please notify the sender
> immediately and then destroy any copies of it. Please note that the sender
> monitors e-mails sent or received. Thank you.
> -Original Message-
> From: Thomas Broyer [mailto:t.bro...@gmail.com]
> Sent: 17 May 2016 11:03
> To: Maven Users List 
> Subject: Re: mvn -U dependency:sources re-downloads released sources JARs
>
> On Tue, May 17, 2016 at 11:29 AM Adam Mitchell  >
> wrote:
>
> > -U is force update, it tells maven to ignore locally cached artifacts
> > and to download them afresh, what behaviour were you expecting?
> >
>
> -U stands for "update-snapshots" and aims at downloading only "missing
> releases" (and "updated snapshots", of course).
>
> $ mvn -h
>
> usage: mvn [options] [] []
>
> Options:
> […]
>  -U,--update-snapshots  Forces a check for missing
> releases and updated snapshots on
> remote repositories $ mvn -v
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T17:41:47+01:00)
> Maven home: /mnt/ssd/tbr/tools/maven
> Java version: 1.8.0_91, vendor: Oracle Corporation Java home:
> /usr/lib/jvm/java-8-oracle/jre Default locale: fr_FR, platform encoding:
> UTF-8 OS name: "linux", version: "4.4.0-22-generic", arch: "amd64", family:
> "unix"
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

How can I define the classloader for maven-antrun-plugin task?

[Eric B]

I recently posted this on StackOverflow, but I've had no traction to the
question there at all.  I'm hoping that this list will have a bit more
feedback for me.

I'm having some significant issues converting an ant build to a maven build
due to an ant task that does not exist as a plugin. The AntTask is part of
the defunct Kodo persistence library (JDO) that is used to byte enhance the
entities.

In the build.xml, I have the following target defined:

  
  
 
 
 
 
  

where ${compile.dir} is defined as the directory where javac compiles its
files, and compiled.classpath is a list of all libs, etc that are required
for the plugin.

I have translated that to the following maven-antrun-plugin definition:


maven-antrun-plugin
1.8

... list of all the dependencies required for the plugin to run ...



kodo

run

compile
























I would have thought it would work the same. And generally speaking, it
seems to. It finds all the required dependencies and is able to run.

Except in one spot.

In the AntTask definition, there is the following code:

ClassLoader loader = getClass().getClassLoader();
loader.getResource(rsrc);

where the getClass().getClassLoader() is inspected via a debugger to be:

ClassRealm[plugin>org.apache.maven.plugins:maven-antrun-plugin:1.8,
parent: sun.misc.Launcher$AppClassLoader@18b4aac2]

and rsrc points to a filename that is found in /src/main/resources, or more
specifically in target/classes.

However, when the loader tries to load rsrc, it fails to find the file, as
the AntRun classloader has no visibility on that folder.

When I debug the same task in a true Ant call (not maven), I see the
classloader as being:

AntClassLoader[C:\dev\Projects\jigger\jigger_ejb\dist\compile;C:\dev\Projects\jigger\lib_ext\kodo4\jdo.jar;C:\dev\Projects\jigger\lib_ext\kodo4\jpa.jar;C:\dev\Projects\jigger\lib_ext\kodo4\kodo-api.jar;..
all the libs in the ${compiled.classpath} var]

Which has a true visibility on the compile (ie: target/classes) folder, and
hence is able to load the required resource.

Modifying the AntTask is not really an option or particularly desired.

Is there anyway I can specify a different classloader to the
maven-antrun-plugin such that it is able to load/find my resource? I've
tried all the possible combinations I can think of, but no matter which
classpath I indicate to the task, the classloader always remains the same -
the antrun classloader which has no visibility on my target folder.

Baring that, is there any other option I have to make this work??
Thanks,

Eric

Re: Publishing to Central

[Eric B]

I tend to agree with Christopher.  In fact I originally thought it was a
blog post that described everything in the videos... not just a pointer to
the videos.  I was even more disappointed when I couldn't get access
without signing up, etc.

Sometimes it is a lot easier to read/skim a blog than have to watch 20m of
video.
On Apr 27, 2016 7:10 PM, "Christopher"  wrote:

> It looks like the videos are "members only" and you need a community access
> code to view them. Is that intended? The blog post is a nice pointer to the
> videos, but it's kinda useless without the videos themselves.
>
> On Wed, Apr 27, 2016 at 2:49 PM Manfred Moser 
> wrote:
>
> > Hi all,
> >
> > I recently recorded some videos that explain some of the rules and steps
> > around publishing to Central. Now I finally got around to writing a blog
> > post.
> >
> > Check it out here
> >
> >
> >
> http://www.simpligility.com/2016/04/easy-publishing-to-the-central-repository/
> >
> > And as usual find the rest of the docs on the site at
> > http://central.sonatype.org/
> >
> > Hth
> >
> > Manfred
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: variable doesn't work for version

[Eric B]

The first question I have to ask is what you are trying to accomplish with
your continuous-delivery?  Are you trying to put snapshot versions into a
production/release state?

The biggest issue I have noticed with teams is the misunderstanding of how
SNAPSHOTs work, or their purpose in the development process.  Either teams
want to release applications in SNAPSHOT mode, or release code that is
essentially in SNAPSHOT (ie: development) mode, but with fixed version
numbers.  But instead of changing version numbers, they use something like
a timestamp to increment version numbers automatically.  But at the end of
it all, it kind of contravenes maven's versioning concept.

Normally, if your artifact is a work in progress, you should just be using
a SNAPSHOT.  If you are looking to make a real release, then you should be
promoting your code from a SNAPSHOT to a fixed version.  Generally, the
concept of continuous-delivery should only apply when in a SNAPSHOT mode,
since anything else isn't changing (ie: a fixed release doesn't need to be
re-delivered).

So then that begs the question why you need to constantly change your
version numbers during your development phase?

And if the goal is truly to have fixed versions for some other team to have
access to a "stable" version of your artifact (ie: they can be guaranteed
that it isn't going to change as you continue to develop), you could always
use something like the maven-release-plugin to promote from SNAPSHOT to a
fixed version, and then re-open the next version as a SNAPSHOT.  (Although
I know there are many dissenters against the release-plugin).

Thanks,

Eric



On Mon, Mar 7, 2016 at 7:15 PM, Gary Gregory <garydgreg...@gmail.com> wrote:

> Is there a Maven-way to do continuous delivery then? As opposed
> to continuous integration.
>
> Our current hack is to use the date as the maintenance version as a
> variable for example 3.1.20160102
>
> G
>
> On Mon, Mar 7, 2016 at 11:18 AM, Eric B <ebenza...@gmail.com> wrote:
>
> > I personally have a pet-peeve of using system variables to define version
> > numbers; I find it is counter productive to the building of maven
> > artifacts.  There is no traceability to determine  the actual version of
> an
> > artifact once it has been built.  At least having a fixed version number
> in
> > the  element shows up in the META-INF/maven/../pom.* files.
> >
> > Is using a variable for the version even a good idea?
> >
> > Thanks,
> >
> > Eric
> >
> >
> > On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > only specific properties are permitted for expansion in XPath paths
> that
> > > match the following regex
> /project/(parent/)?(groupId|artifactId|version)
> > >
> > > On 2 March 2016 at 05:39, Raghu <raghunath...@yahoo.com.invalid>
> wrote:
> > >
> > > > I have a POM with parent node as below: 
> > > > com.test pom.parent
> > > > ${test.version}
> > > > ../scripts/pom.xml 
> > > > This used to work till maven 3.3.3 version - mvn clean install.
> > However,
> > > > the version 3.3.9 throws error though. When I change the version to a
> > > value
> > > > instead of the variable, it works fine.
> > > > Won't maven support variable for version? Or is it a bug with 3.3.9?
> > > > Appreciate your response...
> > > > - regards,raghu
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: variable doesn't work for version

[Eric B]

I personally have a pet-peeve of using system variables to define version
numbers; I find it is counter productive to the building of maven
artifacts.  There is no traceability to determine  the actual version of an
artifact once it has been built.  At least having a fixed version number in
the  element shows up in the META-INF/maven/../pom.* files.

Is using a variable for the version even a good idea?

Thanks,

Eric


On Mon, Mar 7, 2016 at 4:04 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> only specific properties are permitted for expansion in XPath paths that
> match the following regex /project/(parent/)?(groupId|artifactId|version)
>
> On 2 March 2016 at 05:39, Raghu  wrote:
>
> > I have a POM with parent node as below: 
> > com.test pom.parent
> > ${test.version}
> > ../scripts/pom.xml 
> > This used to work till maven 3.3.3 version - mvn clean install. However,
> > the version 3.3.9 throws error though. When I change the version to a
> value
> > instead of the variable, it works fine.
> > Won't maven support variable for version? Or is it a bug with 3.3.9?
> > Appreciate your response...
> > - regards,raghu
>

Re: Installation issue

[Eric B]

Is mvn.sh in your path? Alternatively, if you go to the mvn/bin folder can
you run it via ./mvn.sh -version?
On Feb 18, 2016 6:06 PM, "Patric Hindenberger" <
patric.hindenber...@gmail.com> wrote:

> Hello
>
> i try to install MAVEN on MAC OS X EL CAPITAN and have downloaded and
> extracted the most recent maven- files.
> I have set up the $JAVA_HOME correctly to
> /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home
>
>
>
> But if i try to double check the install i get by
>
> mvn --version
>
>
>
> the result
>
>
>
> -bash: mvn: command not found
>
>
> Does somebody has a hint to me?
>
>
> Thx
> Patric
>
>

Re: How to include extra files with maven-source-plugin?

[Eric B.]

 Wayne Fay wayne...@gmail.com wrote in message 
 news:52bab8690904071513q6dc03722tbf6c57a788458...@mail.gmail.com...
  I'm not quite sure I understand what you mean... It's not really sample
  code; it is the jsp code for the application that I am building. 
  Currently
  just the compiled jsp's are being included in the source jar. I'd like 
  the
  original source jsps to be included as well.

 So what you're saying is the following:
 1. You have a packagingwar/packaging project.
 2. You have JSP files in src/main/webapp.
 3. You're using the m-source-p to package up your source code.
 4. Those JSP files are not being added to the source code jar.
 Instead, they are coming in as Java files after being compiled by
 Jspc.

Correct.  I've looked at the jspc-maven-plugin but couldn't find anywhere 
that it might be removing the original jsp's from the file list, so I 
actually commented out the entire plugin from my pom to see if that would 
make a difference.  The only difference it makes is that the jsps now don't 
get compiled - pretty much as expected.  However, I would then have thought 
/ expected that the src/main/webapp directory would then appear in 
my -sources.jar file, but they still dont.  It seems as though only the 
src/main/java and src/main/resources directories show up in the sources.jar 
file.  Which now makes me even more confused.

From looking at the source code for the m-source-p plugin, it shows that the 
list of source files comes from MavenProject.getCompiledSources() or 
MavenProject.getResources().  I guess that by default, Maven only includes 
src/main/java as the getCompiledSources(), and I can't figure out how to add 
to that list.  But then again, am not sure that I would want to, as I assume 
the compiler plugin uses that list as the list of files to compile. 
Similarly, the getResrouces() gets the list of resources from teh build 
arguments.  So by default, src/main/resources, plus anything additional that 
I would put in the build/build section of the pom.  But then, all those 
resrouces end up in the war unless I explicitly ignore them.

It would seem to me that the sources under src/main/webapp should be 
included in the source jar.  I find it really surprising that noone else has 
encountered this problem before

Thanks,

Eric 




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

How to include extra files with maven-source-plugin?

[Eric B.]

Hi,

I'm using the maven-source-plugin with a basic configuration:
   plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-source-plugin/artifactId
executions
 execution
  goals
   goaljar/goal
   goaltest-jar/goal
  /goals
 /execution
/executions
   /plugin


However, I'd like to include some extra external files in my sources.jar 
file but am not quite sure how to do this (for reference purposes).  From 
what I can tell the source-plugin gets it resource list from the build 
resources.  However, I don't want to put the resources directly in the build 
information, or they will make their way into my war and try to be compiled.

I've tried to use the maven-resources-plugin to copy the files, but quite 
frankly, I'm not sure where to copy them so that the source-plugin picks 
them up, nor do I quite understand from which phase the resource-plugin 
should be called.

Can anyone point me in the right direction?

Thanks!

Eric







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

Re: How to include extra files with maven-source-plugin?

[Eric B.]

 Wayne Fay wayne...@gmail.com wrote in message 
 news:52bab8690904071004o5150adafl8aa4a53d7f8c7...@mail.gmail.com...
  However, I'd like to include some extra external files in my sources.jar
  file but am not quite sure how to do this (for reference purposes). From
  what I can tell the source-plugin gets it resource list from the build
  resources. However, I don't want to put the resources directly in the 
  build
  information, or they will make their way into my war and try to be 
  compiled.

 Perhaps put them in src/site somewhere? Or under src/test/java? You
 don't really tell us enough about what the resources are to say for
 sure. Its also possible that there is no good place, so you just put
 them in src/main/java/examples and then specify that directory to be
 excluded from usual compiling etc.

Actually, they are already part of my source tree.  They are all my jsp 
source files.
My tree looks like the following:
src
-main
-java
-resources
-webapp

My java  resources files show up in my sources.jar, however, the contents 
of the webapp are mysteriously missing.  I have the compiled version of my 
jsps (as .java) files that are included in the source jar, however, i'd 
obviously prefer having a copy of the non-compiled/original jsps in the 
sources as well.

I don't know if it has anything to do with the maven-war-plugin settings 
which specifically excludes the **/*.jsp files from my war, but I figured 
the war plugin was seperate from the source plugin, and shoulnd't be sharing 
configuration information.

My jspc plugin is configured as the following:
   !-- war jspc plugin --
   plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
 execution
  goals
   goalcompile/goal
  /goals
 /execution
/executions
configuration
 source1.5/source
 target1.5/target
 setCompiletrue/setCompile
 showSuccessfalse/showSuccess
 verbosetrue/verbose
 listErrorstrue/listErrors
/configuration
   /plugin


Any ideas?

Thanks!

Eric





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

Re: How to include extra files with maven-source-plugin?

[Eric B.]

Wayne Fay wayne...@gmail.com wrote in message 
news:52bab8690904071035w265d4dfbwe7b4fa1b1121e...@mail.gmail.com...
 I don't know if it has anything to do with the maven-war-plugin settings
 which specifically excludes the **/*.jsp files from my war, but I figured
 the war plugin was seperate from the source plugin, and shoulnd't be 
 sharing
 configuration information.

 I don't know for sure either, but go ahead and comment that out and
 try your build again to see what happens.

Nope.  Not surprisingly, no change.  The only way I have managed to get them 
in the sources jar is to explicitly add
build

  !-- include the webapp as a resources   --
  resources
   resource
directorysrc/main/webapp/directory
   /resource
  /resources
/build

in the pom.xml, however, that ends up copying all the files over into the 
classes/ folder, which then also end up in my war.  And unfortunately they 
end up directly in the classes/ folder, not under classes/webapp, so I can't 
even exclude them in my war plugin.

According to the java sources for the sources plugin, it gets its resource 
list from MavenProject.getResources(), which is infact the 
build.getResources() list.  Is there anyway to modify the build resources 
for that particular plugin only?

Any ideas?

Thanks,

Eric 




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

Re: How to include extra files with maven-source-plugin?

[Eric B.]

Stephen Connolly stephen.alan.conno...@gmail.com wrote in message 
news:88c1b40904071005m3b1b53feg3b0edf4222b4...@mail.gmail.com...
 [Hack alert]
 You could put them in a separate folder tree

 e.g.

 src/main/example-java/

 and then use the build-helper-maven-plugin to add this as an extra source
 directory *but bind the execution to a phase in the lifecycle after 
 compile
 but before package*

 [/Hack alert]


Sounds like the right idea.  I looked up the build-helper-maven-plugin and 
tried to configure it properly, but it doesn't seem to be doing anything.  I 
added the following to my pom.xml:
  !-- copy resources --
   plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
 execution
  idadd-source/id
  phaseprepare-package/phase
  goals
   goaladd-source/goal
  /goals
  configuration
   sources
sourcesrc/main/webapp/source
   /sources
  /configuration
 /execution
/executions
   /plugin

I now expected everything in src/main/webapp to appear my my sources.jar 
file, but none of them do.

Am I missing something obvious here?  Am I chasing my tail somehow?

Thanks!

Eric




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

Re: How to include extra files with maven-source-plugin?

[Eric B.]

 Wayne Fay wayne...@gmail.com wrote in message 
 news:52bab8690904071352j405c495fpb240864012d1c...@mail.gmail.com...
  According to the java sources for the sources plugin, it gets its 
  resource
  list from MavenProject.getResources(), which is infact the
  build.getResources() list. Is there anyway to modify the build resources
  for that particular plugin only?

 I'd suggest you rethink this entirely. Go back to square 1 -- perhaps
 there's a completely different way of doing this, with the sample code
 in another project that isn't compiled perhaps?

I'm not quite sure I understand what you mean...  It's not really sample 
code; it is the jsp code for the application that I am building.  Currently 
just the compiled jsp's are being included in the source jar.  I'd like the 
original source jsps to be included as well.

Thanks,

Eric




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

Re: How to use maven-release-plugin to build/release from a branch?

[Eric B.]

 Ringo De Smet ringo.des...@gmail.com wrote in message 
 news:e20d07ca0903170558v19147b9av5f1848e1af0f5...@mail.gmail.com...
 Eric,

 2009/3/16 Eric B. ebe...@hotmail.com:
  Hi,
 
  How can I use the release:perform goal in the maven-release-plugin to 
  build
  my module located in a CVS branch?
 
  I have tried mvn release:perform -DtagBase=B_2_0_0 hoping / expect that 
  it
  would pass the tagBase command along to CVS to checkout the sources from
  that tag. Unfortunately, it doesn't:
 

 From the maven-release-plugin docs, I deduce that tagBase is only used
 when your SCM is Subversion. I have never had any problems so far with
 making a release on a CVS branch.

I came to the same conclusion as well.  I looked through the plugin code, 
and only found that tagBase is used for SVN as well; the scmVersion and 
scmVersionType aren't used by the release plugin.

 How did you create the tag? You ran
 mvn release:prepare right? If you ran it and it is successfull, you
 should be able to just run mvn release:perform without any further
 arguments. The release plugin should pickup all the required release
 information from the file release.properties created by the prepare
 step.

I think that might be where my problem / confusion lies.  In the past, I 
would always tag my code, then checkout without any cvs tracking information 
and build from that.  I think my problem is that I am still trying to do the 
same thing, hoping / expecting that the plugin would be able to 
prepare/perform from a given tag, and not necesarily from a sandbox.

Thanks,

Eric




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

Maven-scm-plugin define -Dmaven.scm.provider.cvs.implementation in pom?

[Eric B.]

Hi,

I've been trying to figure out if there is a way to specify the 
maven.scm.provider.cvs.implementation in the pom or in a profile, but 
haven't been able to find anything.  I know I can 
specify -Dmaven.scm.provider.cvs.implementation=cvs_native on the command 
line, but would like to do it from the pom.

I did find http://jira.codehaus.org/browse/SCM-303, but I am running scm 
2.0-beta-8 and I still cant seem to get it to work.

Does anyone have any ideas?

Thanks,

Eric




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

How to use maven-release-plugin to build/release from a branch?

[Eric B.]

Hi,

How can I use the release:perform goal in the maven-release-plugin to build
my module located in a CVS branch?

I have tried mvn release:perform -DtagBase=B_2_0_0 hoping / expect that it
would pass the tagBase command along to CVS to checkout the sources from
that tag.  Unfortunately, it doesn't:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
[INFO] 
[INFO] Building DAME Common Utilities
[INFO]task-segment: [release:perform] (aggregator-style)
[INFO] 
[INFO] [release:perform]
[INFO] Checking out the project to perform the release ...
[INFO] Executing: cmd.exe /X /C cvs -z3 -f -d
:pserver:e...@cvs.local.ca:/dame5 -q checkout -d checkout eric-test
[INFO] Working directory: E:\Eric\Desktop\temp\cvs\eric-test\target
[INFO] Executing goals 'deploy'...



Of course, since my pom.xml is only in my B_2_0_0 branch, when cvs does the
checkout, mvn is unable to find the pom.xml and fails accordingly.


I have configured my pom.xml as follows:
...
  scm
connectionscm:cvs:pserver:e...@cvs.local.ca:/dame5:eric-test/connection
tagnewBranch2/tag
  /scm
...
   build
...
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
version1.1/version
configuration
  connectionTypeconnection/connectionType
/configuration
  /plugin

  plugin
   groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-release-plugin/artifactId
 version2.0-beta-8/version
 configuration
connectionUrl${project.scm.connection}/connectionUrl
 /configuration
   /plugin
/plugins
  /build


Am I missing something?  Is this somthing that is not supported by the 
maven-release-plugin?

Thanks,

Eric




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