Re: Maven & Continuous Delivery

[Jeff Jensen]

>
> Jason van Zyl also mentioned he was working on CD solution for Maven last
> year, not sure what the progress on this front.


Yes, I've been curious about the progress too.  It's very needed and so
promising.


On Sat, Apr 16, 2016 at 5:49 AM, Dan Tran  wrote:

> Thanks Stephen.
>
> I was excited for a short moment but hitting the reality where I may have
> to deal with hundreds of dev and qa over the confusion of the hidden
> version. Especially, when they have to rebuild a subset of the product. It
> just not working
>
> Jason van Zyl also mentioned he was working on CD solution for Maven last
> year, not sure what the progress on this front.
>
> -Dan
>
>
>
> On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I share your concern. We could fix the concern if we created the
> > transformed pom on disk so that things like GPG signatures were generated
> > correctly, but AIUI the issue there was that the pom could not be put in
> > target as that would break relative paths.
> >
> > I suspect this is also related to the issue of dependency reduced poms
> for
> > shade... or any feature where the pom to be used downstream in the
> reactor
> > needs to differ from the pom on disk.
> >
> > For me, having been burned by not building the effective pom from a clean
> > checkout I actually favour the use of the release plugin, typically for
> CD
> > I just have the next development version the same as the current and if
> you
> > tune your preparationGoals then you can just have one compile test
> cycle...
> >
> > But the fight of that blog is a bit like the idiotic quest people have to
> > run the tests once only with code coverage as part of the single test
> > execution... until you have been burned by the code coverage affecting
> > effective bytecode and preventing the synchronization bug from being
> caught
> > by your tests (plus other test invalidating behaviours I have seen) you
> > will run around trying to get rid of the second test execution...
> >
> > Those who do not understand why we do things will be condemned to repeat
> > our mistakes that made us do things that way.
> >
> > Having said that, it is a good pressure to have people pushing the "why
> do
> > we need to do it this way" envelope... perhaps it is time that we need to
> > ensure that the release plugin has a page outlining our rational for the
> > current default behaviour, common ways to tweak it and stressing that we
> > have provided a framework for releasing and others are welcome to reuse
> the
> > framework in their own release plugins
> >
> > On 16 April 2016 at 06:01, Dan Tran  wrote:
> >
> > > Hi,
> > >
> > > Anyone practicing CD according to this blog?
> > > https://axelfontaine.com/blog/dead-burried.html
> > >
> > > I can build locally, but have a huge concern on the pom deployed at
> maven
> > > repo since it does NOT  have the exact version
> > >
> > > If you do, please share your experience. Any hick up when you introduce
> > > this new practice?
> > >
> > > For our case, we have about 200 modules project and about 100 dev + qa
> > >
> > > Thanks
> > >
> > > -Dan
> > >
> >
>

Re: Maven & Continuous Delivery

[Dan Tran]

Thanks Stephen.

I was excited for a short moment but hitting the reality where I may have
to deal with hundreds of dev and qa over the confusion of the hidden
version. Especially, when they have to rebuild a subset of the product. It
just not working

Jason van Zyl also mentioned he was working on CD solution for Maven last
year, not sure what the progress on this front.

-Dan



On Sat, Apr 16, 2016 at 12:51 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I share your concern. We could fix the concern if we created the
> transformed pom on disk so that things like GPG signatures were generated
> correctly, but AIUI the issue there was that the pom could not be put in
> target as that would break relative paths.
>
> I suspect this is also related to the issue of dependency reduced poms for
> shade... or any feature where the pom to be used downstream in the reactor
> needs to differ from the pom on disk.
>
> For me, having been burned by not building the effective pom from a clean
> checkout I actually favour the use of the release plugin, typically for CD
> I just have the next development version the same as the current and if you
> tune your preparationGoals then you can just have one compile test cycle...
>
> But the fight of that blog is a bit like the idiotic quest people have to
> run the tests once only with code coverage as part of the single test
> execution... until you have been burned by the code coverage affecting
> effective bytecode and preventing the synchronization bug from being caught
> by your tests (plus other test invalidating behaviours I have seen) you
> will run around trying to get rid of the second test execution...
>
> Those who do not understand why we do things will be condemned to repeat
> our mistakes that made us do things that way.
>
> Having said that, it is a good pressure to have people pushing the "why do
> we need to do it this way" envelope... perhaps it is time that we need to
> ensure that the release plugin has a page outlining our rational for the
> current default behaviour, common ways to tweak it and stressing that we
> have provided a framework for releasing and others are welcome to reuse the
> framework in their own release plugins
>
> On 16 April 2016 at 06:01, Dan Tran  wrote:
>
> > Hi,
> >
> > Anyone practicing CD according to this blog?
> > https://axelfontaine.com/blog/dead-burried.html
> >
> > I can build locally, but have a huge concern on the pom deployed at maven
> > repo since it does NOT  have the exact version
> >
> > If you do, please share your experience. Any hick up when you introduce
> > this new practice?
> >
> > For our case, we have about 200 modules project and about 100 dev + qa
> >
> > Thanks
> >
> > -Dan
> >
>

Removing classpath entries for shaded aritfacts

[tic01]

Hello Maven team,

I have the following scenario. I have several libraries which I am building,
and an application which depends on those libraries. While I am building
using the maven-jar-plugin, a manifest is created with several entries,
including the classpath, which naturally include all the libraries.

However, I am also trying to create a shaded version of my application which
shades the libraries I am building. What happens is that the libraries get
shaded fine, but the manifest still has the original classpath created by
the maven-jar-plugin embedded in it.

Is there a way to exclude the included shaded libraries from the manifest of
the shaded application jar?

Thanks



--
View this message in context: 
http://maven.40175.n5.nabble.com/Removing-classpath-entries-for-shaded-aritfacts-tp5865658.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: Maven & Continuous Delivery

[Stephen Connolly]

I share your concern. We could fix the concern if we created the
transformed pom on disk so that things like GPG signatures were generated
correctly, but AIUI the issue there was that the pom could not be put in
target as that would break relative paths.

I suspect this is also related to the issue of dependency reduced poms for
shade... or any feature where the pom to be used downstream in the reactor
needs to differ from the pom on disk.

For me, having been burned by not building the effective pom from a clean
checkout I actually favour the use of the release plugin, typically for CD
I just have the next development version the same as the current and if you
tune your preparationGoals then you can just have one compile test cycle...

But the fight of that blog is a bit like the idiotic quest people have to
run the tests once only with code coverage as part of the single test
execution... until you have been burned by the code coverage affecting
effective bytecode and preventing the synchronization bug from being caught
by your tests (plus other test invalidating behaviours I have seen) you
will run around trying to get rid of the second test execution...

Those who do not understand why we do things will be condemned to repeat
our mistakes that made us do things that way.

Having said that, it is a good pressure to have people pushing the "why do
we need to do it this way" envelope... perhaps it is time that we need to
ensure that the release plugin has a page outlining our rational for the
current default behaviour, common ways to tweak it and stressing that we
have provided a framework for releasing and others are welcome to reuse the
framework in their own release plugins

On 16 April 2016 at 06:01, Dan Tran  wrote:

> Hi,
>
> Anyone practicing CD according to this blog?
> https://axelfontaine.com/blog/dead-burried.html
>
> I can build locally, but have a huge concern on the pom deployed at maven
> repo since it does NOT  have the exact version
>
> If you do, please share your experience. Any hick up when you introduce
> this new practice?
>
> For our case, we have about 200 modules project and about 100 dev + qa
>
> Thanks
>
> -Dan
>

[ANN] Apache Maven Shared Component: Maven Filtering Version 3.1.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Shared Component: Maven Filtering Version 3.1.0.
 
https://maven.apache.org/shared/maven-filtering/

This component has been built from the filtering process/code in Maven
Resources Plugin. The goal is to provide a shared component for all plugins
that needs to filter resources.
 
Important Note since Version 3.0.0:

 * Maven 3.X only
 * JDK 6 minimum requirement

You should specify the version in your project's pom as follows:
 

  org.apache.maven.shared
  maven-filtering
  3.1.0


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/shared/maven-filtering/download.cgi
 
Release Notes Maven Filtering 3.1.0

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334170

Improvements:

 * [MSHARED-495] - Add convenience method to move code into Maven Filtering
 * [MSHARED-496] - Change version from 3.0.1 to 3.1.0-SNAPSHOT to follow semver.
 * [MSHARED-497] - Allow copying of defaultExcluded files like .gitignore etc. 

Enjoy,
 
-The Apache Maven team

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