[jdom-interest] V2.x not usable next to V1.x

Fri May 18 08:24:11 PDT 2012

Hi Rolf,

Thank you for detailed reply. Let me address several points below. I'll
probably ramble on too... :)

On Fri, May 18, 2012 at 10:27 AM, Rolf Lear <jdom at tuis.net> wrote:

>
> Where were you for this discussion:
>
> http://markmail.org/message/yjojwj26bwrxj5nx#query:+page:1+mid:buwh5fismpdahuoi+state:results
>
> ;-)
>
> So, the problem is as follows.... Maven imposes naming requirements for
> artifacts.
>

The problem is not that Maven has to give things names, the issue, IMO, is
how does *any* automated build system deal with using multiple versions of
the same component.

By 'build system' here, I am not talking about just compiling and jaring at
the Ant level, I am talking about continuous integration, automatically
dealing with pulling down project dependencies (I use Ant + Ivy at work and
Maven at Apache.) and publishing the build results up the food chain (I use
Ant + Ivy + Bamboo + Artifactory at work, and Maven + Nexus at Apache.)

At work (and to a lesser extent at Apache), I deal with multiple product
lines with multiple branches, each with their own set of large dependency
list.

As you can imagine, doing anything build related by hand is not good.

So here I am building a large application server and I want update my code
to JDOM2. Several of my 3rd party dependencies from various products (some
open source, some not) use JDOM1. They each use different versions of
JDOM1, luckily, overriding all dependencies to use 1.1.1 has not been a
problem.

In Ivy, I cannot say this and expect it to work:

    <dependency org="org.jdom" name="jdom" conf="blah,blah" rev="1.1.1" />
    <dependency org="org.jdom" name="jdom" conf="blah,blah" rev="2.0.1" />

This works OTOH:

    <dependency org="commons-lang" name="commons-lang" conf="blah,blah"
rev="2.6" />
    <dependency org="org.apache.commons" name="commons-lang3"
conf="blah,blah" rev="3.1" />

If you want to use both commons-lang 2.6 and 3.1 at the same time, you need
to pull down both using a different "name" which corresponds to the Maven
"artifact Id"

This example also shows that the "org" was changed but it is irrelevant to
this example. What matters is that you can uniquely identify each artifact.

> 'We' decided that this is JDOM 2.0.0, not JDOM2 1.0.0, and also not JDOM2
> 2.0.0, etc. Thus, the *main* download will be the jar jdom-2.0.0.jar.
>

Great ;) The jar name and project name are your own should not matter.

>
> This means that the maven artifact id *must* be 'jdom', not 'jdom2'.
>

I do not think so. Naming the jar and the artifact are separate issues.

>From the Ivy POV at least, once an artifact is found, Ivy can download it
and rename it on the fly to a custom name pattern (with a version in the
jar name or not, it's up to the user)

> At the time I was not aware how hard/impossible it would be to have both
> jdom 1.x and 2.x sourced from maven....
>

That's the joy of serving people who build large complex systems ;)

>
> Maven is the 'secondary' distribution system for JDOM. The primary JDOM
> source is from www.jdom.org. The jars downloaded from maven should be
> identical to the ones from jdom.org.
>

A jar is a jar, it just need to be uniquely identifiable whether it lives
in an FTP directory, a Maven or Ivy repository.

>
>
> There are about 15k downloads a month from www.jdom.org of 1.x versions of
> JDOM.
> There are about 35k downloads a month from maven-central of 1.x versions
> of JDOM.
>
> There are about 10k downloads a month from www.jdom.org of 2.0.x versions
> of JDOM
> There are about 1k downloads a month from maven-central of 2.0.x versions
> of JDOM.
>
> The maven downloads show an *opposite* distribution of downloads compared
> to www.jdom.org:
>
> Here are maven's statistics for the three months Feb, Mar, Apr:
>
> version,count,%
> "1.1","92301","0.8971452713012695"
> "1.1.2","6406","0.062264904379844666"
> "1.1.3","3425","0.03329024091362953"
> "2.0.0","716","0.006959361489862204"
> "2.0.1","35","3.4019225859083235E-4"
>
> here's the graph....
>
>
> http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F|32349F|67329F|9D329F|9F326A&chtt=Downloads+From+Last%203%20Months|For+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1|1.1.2|1.1.3|2.0.0|2.0.1<http://chart.apis.google.com/chart?cht=p3&chs=400x400&chp=4.71&chco=326A9F%7C32349F%7C67329F%7C9D329F%7C9F326A&chtt=Downloads+From+Last%203%20Months%7CFor+org.jdom:jdom&chds=0,92301&chd=t:92301,6406,3425,716,35&chdl=1.1%7C1.1.2%7C1.1.3%7C2.0.0%7C2.0.1>
>
>
> JDOM 1.1 (released 2007) was downloaded 92K times in 3 months.
> 1.1.2 (released last Aug) downloaded 6.5k times in 3 months.
> 1.1.3 (released in Feb) just 3.5k times in 3 months
>
> Note that Maven does not even have JDOM 1.1.1 (from 2009) .....
>

Uh... Who's fault is that?

>
> So, it shows a distinct 'inertia' in maven users. For all I know they are
> not even aware that JDOM 2.x has happened.... My guess would be that 90% of
> maven users do not pay attention to their code....
>
> In a 'short while' I want to be in the position to say: "JDOM 1.x is no
> longer being maintained". It is not in *my* interests to do it.... it is
> essentially unchanged since 2007. If people have problems in JDOM 1.x I'm
> going to want to say "Upgrade to 2.x". I am targeting about December 2012
> for that....
>
> What all this rambling boils down to is:
>
> 1. I don't want to have to change JDOM's jar file name from jdom-2.0.x.jar
> to jdom2-x.y.z.jar
>

You do not have to do that. You can call the jars whatever you want.

> 2. maven is the 'secondary' distribution system
>
3. you can ask your 'dependency' code to upgrade to jdom 2.x (they should
> be doing it anyway).
>

This is unrealistic for several reasons.
What if a jar using JDOM1 is not longer active?
And closed source to boot?
There are plenty of scenario where JDOM 1 and 2 need to co-exist.

4. The bell has already been rung on this... I can't un-ring this maven
> problem.
>

This can be addresses in future releases.

> 5. maven users are 'lazy' about keeping in touch with their dependencies,
> and this will 'prod' them.
>

What about people who build in Grail, Buildr, Groovy and Scala?

> 6. This is all a maven problem (by design or implementation, I am not
> sure)
>

Au contraire, this is not a Maven problem. This is a generic issue as I
described above when building large systems automatically with complex
dependencies.

7. maven 'users' (including apache commons) are happy to do their own
> thing anyway...
>

True of any user on any build system.

>
> http://search.maven.org/#search|ga|1|a%3A%22org.apache.servicemix.bundles.jdom%22<http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22org.apache.servicemix.bundles.jdom%22>
> 8. maven is a PITA ..... :(
>

True of any build on any build system once it gets large and complex enough.

>
> As you can tell, maven support 'requirement' has not been a happy
> process.... in hindsight I probably should have just said no .... On the
> other hand, now that I have the automated build system working, it is not
> hard to publish to maven, as long as it conforms to JDOM's standards, I'm
> OK.
>
> Now that I have established my 'aversion' to the maven model, can you
> suggest a way out of this predicament that also conforms to the JDOM
> 'standard'... ? I promise to consider any suggestions....
>

I suggest that you publish JDOM2 under the jdom2 artifact id to match the
package name. You can call the jar whatever you want.

Thank you for reading this far!

Gary

> Rolf
>
>
>
> On Fri, 18 May 2012 08:29:28 -0400, Gary Gregory <garydgregory at gmail.com>
> wrote:
> > Hi All,
> >
> > For good or bad, I ended learning more than I care about Maven being the
> > release manager for several Apache Commons components.
> >
> > Our rule in Commons is that when you change a package name, you must
> change
> > the Maven artifact id.
> >
> > My suggestion is to do this in your POM:
> >
> >   <groupId>org.jdom</groupId>
> >   <artifactId>jdom2</artifactId>
> >   <version>2.0.2</version>
> >
> > Depending on your philosophy, you could also re-publish the Maven
> artifacts
> > for 2.0.1. But this is usually considered bad form because the POM needs
> to
> > change and you would then have 2 2.0.1 version with different pom.xml in
> > your sources jar.
> >
> > Gary
> >
>
>

-- 
E-Mail: garydgregory at gmail.com | ggregory at apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.jdom.org/pipermail/jdom-interest/attachments/20120518/2abf84ae/attachment.html>