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

Fri May 18 09:04:57 PDT 2012

To add fuel to this fire... I stopped using JDOM 1.x altogether when it
wasn't available on maven (awhile back) and started again only when JDOM
2.x became available on maven.

The "alternative" distro argument doesn't persuade; its just too much a
PITA to adjust to each and every developer's idiosyncratic objections to a
well-established model, regardless of its deficiencies. Its far easier to
adjust to the idiosyncacies of the many DOM alternatives that ARE available
on maven.

My main interest is SIMPLIFYING my life in this overly-complex world, and
maven is the only tool that does that for me. I'd go back to W3C DOM if
that were the only way to achieve it, as much as I detest working with that.

On Fri, May 18, 2012 at 11:24 AM, Gary Gregory <garydgregory at gmail.com>wrote:

> 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
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>

-- 
Cell: 703-594-1883
Blog: http://bradjcox.blogspot.com
Web: http://virtualschool.edu
Manassas VA 20111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.jdom.org/pipermail/jdom-interest/attachments/20120518/621e0ef3/attachment.html>