date:20170726

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

2017-07-26 Thread Dan Tran

Hi Eric


i am using the follow at top level parent

  ${revision}

  
x.y.x-SNAPSHOT
  

In child pom

  
  ...
  ${revision}
  


At jenskins file

  I have a param  releaseVersion by default it is empty

if the releaseVersion is not empty, then pass
-Drevision-${params.releaseVersion} into maven build


This mean i have 3 modes

   - Default SNAPSHOT build
   - User can pass in the release version
   - Auto incremental release build where I update and commit jenkins file
to default release version to 'x.y.z-${BUILD_NUMBER}'.


I have team that will never use auto incremental release build, and they
will manually run the build with a release version of their choice ( mode
#2)


-Dan


On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar  wrote:

> Dan,
>
> Thanks for the update.  I'm at the state where I am trying to integrated CD
> with a large multi-module maven project and trying to get this process
> running smoothly with Jenkins.  For the moment, I'm ok to use a
> split-Continuous Deployment concept - similar to yours.  ie: using
> SNAPSHOTs for development phase, and anything in a release branch becomes
> an release candidate.  Meaning that any commits into the release/ branch
> produce a potentially shippable version.
>
> But that means that I need poms with version numbers as moving targets (ie:
> sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
> Marbaise's suggestions, I am planning on building my poms as follows:
>
> parent pom:
>
> com.benze
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.3.1
> -SNAPSHOT
> 
>   
>
>
> but in my child poms, I'm not sure how to refer to the parent:
>
> webapp
> war
> 
>com.benze
>parent
> ??? 
>../superpom
> 
>
>
>
> How do you refer to the parent pom with a constantly (non-defined) moving
> version?  In the past, without using properties like this, I could use the
> maven-versions-plugin to update the version numbers, but now I don't even
> see how I can do that.  If the revision is defined at the command line in
> Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms?  If
> memory serves, the child cannot use properties for the parent version
> number.
>
> How/where to do you specify your semantic version number?  I remember you
> said you use the buildnumber-m-p for the build number, but that
> how/where/when do you specify the sematic version number?  Do you have to
> manually change it in the poms at RC time?  Is it only defined during the
> build process?
>
> Do you have an example of your pom structure and Jenkinsfile pipeline that
> you can share to help me better grasp how to handle this integration?
>
> Thanks,
>
> Eric
>
>
>
> On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran  wrote:
>
> > Just want to share our final outcomes
> >
> > 1. Use snapshot build during development phase
> >
> > 2. At release candidate phase, switch jenkinsfile to release mode
> >
> > * For small projects, use version less Maven continuous deliver
> > friendly,
> >
> > * For large projects, use  versions-maven-plugin to change version in
> > all poms at pre-build
> >
> > * Automate the process to tag the final RC (we deploy a
> > build.properties to maven repo at each build, use its info to tag the
> SCM)
> >
> > Whenever, the startup performance issue for large project is fixed, we
> will
> > switch to full version less build
> >
> > -Dan
> >
> > On Sun, May 14, 2017 at 7:23 PM, Dan Tran  wrote:
> >
> > > I also noticed it takes about a minute for the build to roll after this
> > >
> > > [INFO] Error stacktraces are turned on.
> > > [INFO] Scanning for projects...
> > >
> > > This is not a good news for local dev build
> > >
> > > here are 2 time summaries running 250+ modules with skipTests and 4
> > thread
> > > smart builder. The first one does not use
> ${revision}
> > >
> > > [INFO] --
> --
> > > 
> > > [INFO] Total time: 04:05 min (Wall Clock)
> > > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > > [INFO] Final Memory: 680M/2078M
> > >
> > > [INFO] --
> --
> > > 
> > > [INFO] Total time: 05:56 min (Wall Clock)
> > > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > > [INFO] Final Memory: 1726M/3561M
> > >
> > >
> > > -D
> > >
> >
>

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

2017-07-26 Thread Eric Benzacar

Dan,

Thanks for the update.  I'm at the state where I am trying to integrated CD
with a large multi-module maven project and trying to get this process
running smoothly with Jenkins.  For the moment, I'm ok to use a
split-Continuous Deployment concept - similar to yours.  ie: using
SNAPSHOTs for development phase, and anything in a release branch becomes
an release candidate.  Meaning that any commits into the release/ branch
produce a potentially shippable version.

But that means that I need poms with version numbers as moving targets (ie:
sometimes with SNAPSHOTs, sometimes without).  Based on Karl Heinz
Marbaise's suggestions, I am planning on building my poms as follows:

parent pom:

com.benze
  parent
  ${revision}${sha1}${changelist}
  pom

1.3.1
-SNAPSHOT

but in my child poms, I'm not sure how to refer to the parent:

webapp
war

   com.benze
   parent
??? 
   ../superpom

How do you refer to the parent pom with a constantly (non-defined) moving
version?  In the past, without using properties like this, I could use the
maven-versions-plugin to update the version numbers, but now I don't even
see how I can do that.  If the revision is defined at the command line in
Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms?  If
memory serves, the child cannot use properties for the parent version
number.

How/where to do you specify your semantic version number?  I remember you
said you use the buildnumber-m-p for the build number, but that
how/where/when do you specify the sematic version number?  Do you have to
manually change it in the poms at RC time?  Is it only defined during the
build process?

Do you have an example of your pom structure and Jenkinsfile pipeline that
you can share to help me better grasp how to handle this integration?

Thanks,

Eric

On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran  wrote:

> Just want to share our final outcomes
>
> 1. Use snapshot build during development phase
>
> 2. At release candidate phase, switch jenkinsfile to release mode
>
> * For small projects, use version less Maven continuous deliver
> friendly,
>
> * For large projects, use  versions-maven-plugin to change version in
> all poms at pre-build
>
> * Automate the process to tag the final RC (we deploy a
> build.properties to maven repo at each build, use its info to tag the SCM)
>
> Whenever, the startup performance issue for large project is fixed, we will
> switch to full version less build
>
> -Dan
>
> On Sun, May 14, 2017 at 7:23 PM, Dan Tran  wrote:
>
> > I also noticed it takes about a minute for the build to roll after this
> >
> > [INFO] Error stacktraces are turned on.
> > [INFO] Scanning for projects...
> >
> > This is not a good news for local dev build
> >
> > here are 2 time summaries running 250+ modules with skipTests and 4
> thread
> > smart builder. The first one does not use ${revision}
> >
> > [INFO] 
> > 
> > [INFO] Total time: 04:05 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:16:32-07:00
> > [INFO] Final Memory: 680M/2078M
> >
> > [INFO] 
> > 
> > [INFO] Total time: 05:56 min (Wall Clock)
> > [INFO] Finished at: 2017-05-14T19:11:00-07:00
> > [INFO] Final Memory: 1726M/3561M
> >
> >
> > -D
> >
>

Re: doxia-ide/eclipse

2017-07-26 Thread Hervé BOUTEMY

404, yes, Jenkins does not create directory index, but the content is a valid 
Eclipse update site...
To avoid the surprise of this 404, I tweaked the Jenkins job to add a minimal 
index.html:
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse/

The site is now updated...

Regards,

Hervé

Le mardi 25 juillet 2017, 11:12:57 CEST Alix Lourme a écrit :
> Hello,
> 
> I changed the job configuration to publish the site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/
> 
> OK
> 
> and it's containing the Eclipse update site: https://builds.apache.org/
> 
> > view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse
> 
> http 404 but no authent/redirection asked => would be OK.
> 
> Best regards
> 
> 2017-07-25 7:51 GMT+02:00 Hervé BOUTEMY :
> > Hi Alix,
> > 
> > Ah, the Jenkins job workspace is not available to anonymous.
> > 
> > I changed the job configuration to publish the site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/
> > and it's containing the Eclipse update site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/eclipse
> > 
> > It should be visible to anonymous: can you check and report, please?
> > 
> > If it's ok, I'll republish the content with updated link to CI result...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 23 juillet 2017, 19:35:19 CEST Alix Lourme a écrit :
> > > Hello Hervé,
> > > 
> > > The Doxia Editor Plugins Eclipse (latest build) update site
> > >  > 
> > eclipse-editor/ws/d
> > 
> > > oxia-ide-eclipse/eclipse-plugins/features/org.apache.
> > 
> > maven.doxia.ide.eclipse
> > 
> > > .feature/target/site/> seems not usable for an anonymous user :-(
> > > 
> > > Best regards
> > > 
> > > 2017-07-22 11:48 GMT+02:00 Hervé BOUTEMY :
> > > > here it is: the site is updated
> > > > and I managed to have the build successful again
> > > > 
> > > > help is still wanted to improve the plugin: most notably Markdown
> > 
> > support
> > 
> > > > is
> > > > missing, since it was added after Doxia 1.3
> > > > 
> > > > but all in all, the situation is better now
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit :
> > > > > I forgot this update site: thanks for the reminder
> > > > > 
> > > > > I'll update the page to make it more visible, and add a "help
> > > > > wanted"
> > > > > text...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit :
> > > > > > Hi,
> > > > > > 
> > > > > > Perhaps this plugin doesn't build, but the Eclipse update site (
> > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK.
> > > > > > This plugin works fine and does the job (on Eclipse Neon.3); even
> > 
> > if
> > 
> > > > is a
> > > > 
> > > > > > little bugged (do not let opened an APT in workbench & delete file
> > 
> > in
> > 
> > > > //).
> > > > 
> > > > > > Personally I didn't found (until now) a better plugin for Maven
> > 
> > site
> > 
> > > > APT
> > > > 
> > > > > > edition.
> > > > > > 
> > > > > > Best regards.
> > > > > > 
> > > > > > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY :
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I used this plugin a few years ago, then it started to misbehave
> > > > > > > when
> > > > > > > upgrading Eclipse version. And now, it even does not build any
> > 
> > more:
> > > > > > > looks
> > > > > > > like something changed in Eclipse ecosystem
> > > > > > > 
> > > > > > > I'll update the page to tell that this plugin does not even
> > > > > > > build
> > > > > > > any
> > > > > > > more:
> > > > > > > help wanted...
> > > > > > > 
> > > > > > > Regards,
> > > > > > > 
> > > > > > > Hervé
> > > > > > > 
> > > > > > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit :
> > > > > > > > Hi All,
> > > > > > > > 
> > > > > > > > I found the eclipse update sites provided in this page do not
> > > > > > > > work:
> > > > > > > > 
> > > > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/
> > > > > > > > 
> > > > > > > > Bruce Wen
> > > > > > > 
> > > > > > > 
> > > > 
> > > > -
> > > > 
> > > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > > 
> > > > > 
> > 
> > -
> > 
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@ma

Re: maven-plugin-testing-harness

2017-07-26 Thread Karl Heinz Marbaise


Hi,

On 26/07/17 20:13, Karl Heinz Marbaise wrote:

Hi,

On 26/07/17 11:49, ahardy42 wrote:

Is there life is in this testing harness still?

I'm looking at
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/




The link to JIRA returns  503 -
http://jira.codehaus.org/browse/MPLUGINTESTING


Outch that are the old links which means there hasn't been a release for 
a longer time ;-(


This is the new location:

https://issues.apache.org/jira/projects/MPLUGINTESTING/




and the link to git repo is 404


https://github.com/apache/maven-plugin-testing

but it's out of date correct...

I have created an appropriate INFRA ticket to fix this[1].


[1]: https://issues.apache.org/jira/browse/INFRA-14716



Thanks to INFRA..already fixed the problem.

Kind regards
Karl Heinz Marbaise



I can imagine there is a big population of maven users out there who 
look at
it and give up, which is a shame because you can't beat a good test 
harness.


Yes this is unfortunately true...





I have managed to put some code together to make my tests run nicely in
IntelliJ and I was wondering if you wanted any documentation or example
code?


Both is appreciated...sure ..




I've still got issues and I've got a live question on StackOverflow:
https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness 



Regards
Adam





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

Re: maven-plugin-testing-harness

2017-07-26 Thread Karl Heinz Marbaise


Hi,

On 26/07/17 11:49, ahardy42 wrote:

Is there life is in this testing harness still?

I'm looking at
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/




The link to JIRA returns  503 -
http://jira.codehaus.org/browse/MPLUGINTESTING


Outch that are the old links which means there hasn't been a release for 
a longer time ;-(


This is the new location:

https://issues.apache.org/jira/projects/MPLUGINTESTING/




and the link to git repo is 404


https://github.com/apache/maven-plugin-testing

but it's out of date correct...

I have created an appropriate INFRA ticket to fix this[1].


[1]: https://issues.apache.org/jira/browse/INFRA-14716



I can imagine there is a big population of maven users out there who look at
it and give up, which is a shame because you can't beat a good test harness.


Yes this is unfortunately true...





I have managed to put some code together to make my tests run nicely in
IntelliJ and I was wondering if you wanted any documentation or example
code?


Both is appreciated...sure ..




I've still got issues and I've got a live question on StackOverflow:
https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness

Regards
Adam




Kind regards
Karl Heinz Marbaise

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

Maven Archiver: Suppress Built-By header

2017-07-26 Thread Andreas Sewe

Hi,

in order to increase build reproduciblity, I am looking for a way to
suppress the Built-By manifest header the Maven Archiver automatically
generates. Unfortunately, I couldn't find a  configuration
option to do this. The following didn't work either (it generated an
empty Built-By header instead):

 
   
 
   
 

Does anyone know whether suppressing these headers is possible *without*
resorting to  and doing everything by hand.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Maven return code 502, ReasonPhrase:notresolvable

2017-07-26 Thread Mehul Sanghvi

Maven version:  3.3.3
Nexus version:   OSS 2.14.o-1

Starting this past Monday, I have been seeing the following:


build 25-Jul-2017 20:27:16 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.3:run (default) on project
xml2jsonMigration: Execution default of goal
org.apache.maven.plugins:maven-antrun-plugin:1.3:run failed: Plugin
org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies
could not be resolved: The following artifacts could not be resolved:
org.apache.maven:maven-plugin-api:jar:2.0.4,
org.apache.maven:maven-project:jar:2.0.4,
org.apache.maven:maven-settings:jar:2.0.4,
org.apache.maven:maven-profile:jar:2.0.4,
org.apache.maven:maven-model:jar:2.0.4,
org.apache.maven:maven-artifact-manager:jar:2.0.4,
org.apache.maven:maven-repository-metadata:jar:2.0.4,
org.apache.maven:maven-artifact:jar:2.0.4,
org.codehaus.plexus:plexus-utils:jar:1.5.6: Could not transfer artifact
org.apache.maven:maven-plugin-api:jar:2.0.4 from/to releases
(http://nexus.myorg.com:8081/nexus/content/groups/releases/): Failed to
transfer file:
http://nexus.myorg.com:8081/nexus/content/groups/releases/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar.
Return code is: 502 ,
ReasonPhrase:notresolvable.


At first it was for an artefact that was located in an internal corporate
Artifactory repository, which I was able to get past by modifying the proxy
settings in the settings.xml file.   It used to be:

*.myorg.com

and I changed it to

*.myorg.com|*.mycorp.com



The error above that I am getting though, is for something that was
working.  And the artefacts are accessible via the web browser.  From a
network standpoint, the Nexus server is one hop away (based on traceroute
information).

This used to work.   There have been no network changes,  not VM changes,
 no updates to Maven.   We did change the version number of our product by
removing the -SNAPSHOT, but that should not cause this error that we are
seeing.

I have tried using the -U command line option, as well as just pointing
maven.repo.local to a new location and avoiding any cacheing issues.


Any pointers/suggestions/thoughts ?

-- 
Mehul N. Sanghvi
email: mehul.sang...@gmail.com

maven-plugin-testing-harness

2017-07-26 Thread ahardy42

Is there life is in this testing harness still? 

I'm looking at
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/ 

The link to JIRA returns  503 -
http://jira.codehaus.org/browse/MPLUGINTESTING

and the link to git repo is 404

I can imagine there is a big population of maven users out there who look at
it and give up, which is a shame because you can't beat a good test harness.

I have managed to put some code together to make my tests run nicely in
IntelliJ and I was wondering if you wanted any documentation or example
code?

I've still got issues and I've got a live question on StackOverflow:
https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness

Regards
Adam



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

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

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

Re: doxia-ide/eclipse

Re: maven-plugin-testing-harness

Re: maven-plugin-testing-harness

Maven Archiver: Suppress Built-By header

Maven return code 502, ReasonPhrase:notresolvable

maven-plugin-testing-harness

8 matches

Site Navigation

Mail list logo

Footer information