You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Kevin Burton <bu...@spinn3r.com> on 2015/10/13 20:08:58 UTC

Best way to lock in .jar versions between releases.

I want to lock in the effective classpath for our releases.

So if extra .jars or versions of .jars are changed, I want the build to
fail until I manually approve it.

For some reason, our version of cassandra regressed and broke on release.

Still trying to track this down but in the future it would be nice to just
flat out prevent this from happening.

Thoughts?

-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>

Re: Best way to lock in .jar versions between releases.

Posted by Kevin Burton <bu...@spinn3r.com>.
Wow. Lots of questions!

I ended up working around this by just writing a post build script that
generates a build fingerprint of our .jars

I then commit the fingerprint.  If a build changes the fingerprint then we
can't push.

It's kind of ugly but we unfortunately have a post build script anyway....

On Tue, Oct 13, 2015 at 1:15 PM, Wayne Fay <wa...@gmail.com> wrote:

> Forget transitive dependencies. Pretend you're back on Ant. All
> artifacts must be declared. Leave nothing to chance.
>
> Declare all dependencies, including the ones you are currently
> bringing in transitively, in your project's pom.
>
> Set all versions with [1.2.3] to "lock" them down.
>
> There may be another way to do this, but this is what I'd suggest to
> start...
>
> Wayne
>
> On Tue, Oct 13, 2015 at 1:08 PM, Kevin Burton <bu...@spinn3r.com> wrote:
> > I want to lock in the effective classpath for our releases.
> >
> > So if extra .jars or versions of .jars are changed, I want the build to
> > fail until I manually approve it.
> >
> > For some reason, our version of cassandra regressed and broke on release.
> >
> > Still trying to track this down but in the future it would be nice to
> just
> > flat out prevent this from happening.
> >
> > Thoughts?
> >
> > --
> >
> > We’re hiring if you know of any awesome Java Devops or Linux Operations
> > Engineers!
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > <https://plus.google.com/102718274791889610666/posts>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>

Re: Best way to lock in .jar versions between releases.

Posted by Wayne Fay <wa...@gmail.com>.
Forget transitive dependencies. Pretend you're back on Ant. All
artifacts must be declared. Leave nothing to chance.

Declare all dependencies, including the ones you are currently
bringing in transitively, in your project's pom.

Set all versions with [1.2.3] to "lock" them down.

There may be another way to do this, but this is what I'd suggest to start...

Wayne

On Tue, Oct 13, 2015 at 1:08 PM, Kevin Burton <bu...@spinn3r.com> wrote:
> I want to lock in the effective classpath for our releases.
>
> So if extra .jars or versions of .jars are changed, I want the build to
> fail until I manually approve it.
>
> For some reason, our version of cassandra regressed and broke on release.
>
> Still trying to track this down but in the future it would be nice to just
> flat out prevent this from happening.
>
> Thoughts?
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>

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


Re: Best way to lock in .jar versions between releases.

Posted by Ron Wheeler <rw...@artifact-software.com>.
On 13/10/2015 2:08 PM, Kevin Burton wrote:
> I want to lock in the effective classpath for our releases.
>
> So if extra .jars or versions of .jars are changed, I want the build to
> fail until I manually approve it.
>
> For some reason, our version of cassandra regressed and broke on release.
>
> Still trying to track this down but in the future it would be nice to just
> flat out prevent this from happening.
>
> Thoughts?
>
How are you doing your builds?
Is there a difference in your snapshot policy and release policy?

How are you controlling versions - parent POM dependency management?

How many people can deploy to your release repo? Snapshot repo?
If you are the only one, then no one else can trigger a release.
What Maven repo are you using?

Sorry for the questions but the answers might prompt some of the smarter 
people to suggest good solutions.

Ron



-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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


Re: Best way to lock in .jar versions between releases.

Posted by ec...@zusammenkunft.net.
Hello,

How do you construct the effective classpath? Is this a text file, the content of a directory, is it related to a feature definition or is it based on the transitive maven dependencies?

Depending on your answer you  eed to control the project/artifact which defines it. (I am not sure if there is a good dependency-lock solution, but as long as you control the reactor pom no change is to be expected (if you enforce release versions and immutable repo).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Kevin Burton <bu...@spinn3r.com>
To: Maven Users List <us...@maven.apache.org>
Sent: Di., 13 Okt. 2015 20:09
Subject: Best way to lock in .jar versions between releases.

I want to lock in the effective classpath for our releases.

So if extra .jars or versions of .jars are changed, I want the build to
fail until I manually approve it.

For some reason, our version of cassandra regressed and broke on release.

Still trying to track this down but in the future it would be nice to just
flat out prevent this from happening.

Thoughts?

-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
<https://plus.google.com/102718274791889610666/posts>

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