Re: Dealing with .jars that have overlapping .classes

[Curtis Rueden]

Hi Kevin,

My projects handles it as follows:

1) Death to uber-JARs; use component JARs whenever they exist. If they
don't exist, consider forking the project to create them, or at least
shading the embedded dependencies. (E.g.:
https://github.com/scijava/jython-shaded)

2) Use excludes to avoid bogus transitive dependencies. For example, no one
should depend on xml-apis, since those classes come with Java. But lots of
projects do. So just exclude xml-apis:xml-apis in your dependencyManagement
section for all afflicted projects. Probably also xalan:xalan, maybe
xerces, etc.

3) Contact project maintainers upstream to inform them when you find these
situations. Many build systems simply do not alert the maintainers that
anything like this is happening. So they may just be clueless (though
Stephen Colbourne is pretty awesome—I would be surprised if he doesn't know
about the joda overlap in this case... but still, may as well ask about
it). E.g.: we had one dependency where the project's gradle build system
was putting *two copies of each class* into the final JAR artifact! Guess
how much maven-enforcer-plugin liked that? :-)

4) Finally, if you have to do it, just add some class excludes to your
maven-enforcer-configuration. Especially for cases like joda, chances are
the two copies of the classes are identical, so having both on the
classpath will work just fine, pragmatically.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> 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
> 
>

Re: Dealing with .jars that have overlapping .classes

[Aldrin Leal]

Use a dependencyManagement section in order to declare the versions we
really need.

Create intermediary jars using shade in cases we really need both versions
of the same jar

Use the DOES-NOT-EXIST trick

for dependencies meant to completely wipe

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Fri, Apr 22, 2016 at 1:23 PM, Kevin Burton  wrote:

> We have a rather complex classpath in our app... sometimes maven computes
> the wrong classpath because one package changes classpath order and has a
> dependency on an earlier jar.
>
> To avoid this we usually analyze our classpath between builds and our
> builds break if a classpath change isn't approved.
>
> One of the BIG problems here is when we get overlapping classes.
>
> Right now this is happening with joda time and joda convert.  WE have about
> 10 classes that are in both .jars.
>
> First. It seems irresponsible for project maintainers to release artifacts
> like this. If there are shared .classes just publish a new -core artifact.
>
> Just being pragmatic.. I'm not sure the BEST way to handle this.
>
> One strategy is to make sure that each lib is the LATEST .. but sometimes
> that's not possible.
>
> How do you guys handle this?
>
> --
>
> 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
> 
>

Dealing with .jars that have overlapping .classes

[Kevin Burton]

We have a rather complex classpath in our app... sometimes maven computes
the wrong classpath because one package changes classpath order and has a
dependency on an earlier jar.

To avoid this we usually analyze our classpath between builds and our
builds break if a classpath change isn't approved.

One of the BIG problems here is when we get overlapping classes.

Right now this is happening with joda time and joda convert.  WE have about
10 classes that are in both .jars.

First. It seems irresponsible for project maintainers to release artifacts
like this. If there are shared .classes just publish a new -core artifact.

Just being pragmatic.. I'm not sure the BEST way to handle this.

One strategy is to make sure that each lib is the LATEST .. but sometimes
that's not possible.

How do you guys handle this?

-- 

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

Re: Maven & Continuous Delivery

[Benson Margulies]

On Thu, Apr 21, 2016 at 10:20 PM, Dan Tran  wrote:
> does it upload the pom with its version fully translated?

All it does is arrange to trigger the 'version with a property'
functionality that was added quite some time ago. If that
functionality uploaded resolved poms, it uploads resolved poms. If
not, I guess, not.


>
> Thanks
>
> -D
>
> On Thu, Apr 21, 2016 at 6:40 PM, Benson Margulies 
> wrote:
>
>> On Thu, Apr 21, 2016 at 2:52 PM, Dan Tran  wrote:
>> > Hi Benson
>> >
>> > Sounds promissing
>> >
>> > does it support jenkins env BUILD_NUM?
>>
>> I doubt it. I dislike Jenkins and avoid having anything to do with it.
>> Feel free to make a PR.
>>
>> > does it push the actual version to maven repo at install/deploy time?
>>
>> if you run mvn deploy, your artifacts will be deployed.
>>
>>
>> >
>> > Thanks
>> >
>> > -Dan
>> >
>> > On Thu, Apr 21, 2016 at 4:00 AM, Benson Margulies > >
>> > wrote:
>> >
>> >> https://github.com/basis-technology-corp/auto-version-maven-extension
>> >>
>> >> On Sat, Apr 16, 2016 at 2:23 PM, Jeff Jensen
>> >>  wrote:
>> >> >>
>> >> >> 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, 

Keytool-maven-plugin creates failed PKCS12 keystore

[DJViking]

I am using keytool-maven-plugin to create a PKCS#12 keystore, but skip if it
already exist. This keystore is used with continous builds. Somehow the
resulting self-signed keystore.p12 cannot be used to verify a released JAR
that has been signed with a PKCS12 keystore containing a purchased
certificate.

By using the PKCS12 keystore created by keytool-maven-plugin I am getting
this error when building:
[ERROR] Failed to execute goal
org.codehaus.mojo:webstart-maven-plugin:1.0-beta-6:jnlp-single (default) on
project myProject: Could not verify jar

If I create a PKCS12 keystore manually I have no problem building:
keytool -genkey -keyalg RSA -alias alias -keystore keystore.p12 -storetype
pkcs12 -storepass ** -validity 360 -keysize 2048

So is it a bug in keytool-maven-plugin or something missing from my
configuration?


  org.codehaus.mojo
  keytool-maven-plugin
  1.5



generateKeyPair

generate-resources



${user.home}/keystore.p12
CN=${hostname}.company.no, OU=Systems, O=Company
AS, L=Oslo, ST=Oslo, C=NO
alias
storepass
pkcs12
true
true





--
View this message in context: 
http://maven.40175.n5.nabble.com/Keytool-maven-plugin-creates-failed-PKCS12-keystore-tp5866163.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: Why did the Maven Site Plugin 3.4.1 vanished

[Oliver B. Fischer]

I found this version number in our POMs before upgrading to 3.5.1. Maybe 
it was only a error in our POMs.


Thx,

Oliver

Am 22.04.16 um 00:28 schrieb Hervé BOUTEMY:

Hi,

3.4.1? This version never existed
http://svn.apache.org/viewvc/maven/plugins/tags/

Didn't you look for 3.5.1?

Regards,

Hervé

Le jeudi 21 avril 2016 23:52:25 Oliver B. Fischer a écrit :

Hi,

I just recognized that version 3.4.1 of the Maven Site Plugin vanished
from Maven Central. Does someone how why?

Oliver


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



--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf


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