Re: V2.x not usable next to V1.x

bear with me, I really am trying to get a working solution here... but I
am 'South African', so I may come across a little rough ;-)

Also, understand that I do not use maven/ivy/whatever. Getting maven
working at all without expert advice was a challenge. I was literally
begging for help....

http://markmail.org/message/wcn5woeer2abez6m

Also understand that it is highly unlikely that jdom will move to the full
maven-build type model. It is going to stay as an ant-based build. The
massive re-organization of the code would be a huge impact on the version
history would be a PITA for a start....

Currently the maven deploy is done using a maven 'bundle' approach. I do
not see this changing any time soon.

https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven

See more comments inline.....

Rolf


On Fri, 18 May 2012 14:19:13 -0400, Gary Gregory <[email protected]>
wrote:
> Hello All,
> 
> All right, let's see... let me point out again that this is not a Maven
> problem. This will happen no matter what dependency management system
you
> use. Maven happens to be the grand-daddy of them all in the Java world.

Let me fix that statement for you :)

>  let me point out again that this is not a Maven-only problem and that
other dependency management systems have the same problem.
>  'ant' is the grand-daddy of dependency management in the Java world,
and Maven is the 'whippersnapper' ;-)

hehe.


> 
> In my case I use Ant and Ivy. So all the Maven bashing is pointless
because
> this can happen outside of Maven as is in my case. Maven has pros and
cons
> for sure and outside the scope of this thread.
> 
> The bottom line is that JDOM is broken for use from dependency
management
> tools like Ivy and Maven. My guess is that it is also broken for Scala
SBT,
> Buildr, and Graddle. Tools that rely on artifact ids cannot use two
> different code bases/packages/jars if they have the same id.
> 
> More below.
> 
> On Fri, May 18, 2012 at 1:30 PM, Rolf Lear <[email protected]> wrote:
> 
>>
>> So, a general comment, and four questions....
>>
>> The inability of maven to accommodate the flexibility of 'real life'
>> development in an automated way is not the fault of JDOM. The very fact
>> that I have spent so much time already 'dealing' with maven indicates
>> that
>> it has something fundamentally wrong with its design/model. I get the
>> impression that Maven developers expect the world to conform to them,
>> rather than tolerating the heterogeneous we live in. It is "everyone
>> else's
>> fault" if things don't work the maven way.....
>>
> 
> I disagree but I do not want to spend more time attributing blame.
That's
> not going to help anyone today.

Perhaps, I *know* there are emotions involved,... but the problem is
really quite simple.... I'll get to it.

> 
> 
>>
>> 1. you say that the artifact does not need to be the same as the 'base
>> name' of the jar, yet everything i have read suggests it does need to
be
>> the same: http://maven.apache.org/maven-conventions.html Further, while
I
>> have no record of it, I recall that when I tried to upload maven
bundles
>> to
>> sonatype, the jar name has to be of the specific form
>> <artifact>-<version>-<subcomp>.jar, If your artifact is abc123 and the
>> version is 1.2.3 then it expects abc123-1.2.3.jar,
>> abc123-1.2.3-sources.jar, abc123-1.2.3-javadocs.jar, etc. When I get
>> home I
>> can try something different to double-check, but i am pretty
certain....
>> If
>> maven were actually 'easy' to work with, there should be an easy way
for
>> anyone to actually try that.... is there a way?
>>
> 
> You might be right in the end WRT jar names matching artifact id. I like
> you do not care to fight Maven more than I already do. What I do know is
> that Maven is overridable is all sorts of advanced and magical ways that
I
> do not fully grok. So it might be possible of course to end up with the
jar
> file name you want in the end.
> 
> FWIW, for all of the Apache Commons projects I've seen that required a
> package name change (Math 3.0, Lang 3.0, VFS 2.0), we've ended up with a
> jar file that matches the artifact id. That's never bothered anyone
enough
> to change the default I suppose.
> 

For what it's worth, JDOM *has* changed the jar file, from jdom-1.1.3.jar
to jdom-2.0.1.jar

I know, you meant that you expected jdom2.jar or something.... but *why*?
Because *maven* needs it? Because *ivy* needs it?

> 
>> 2. If it is possible to load jdom-2.0.2.jar in to the jdom2 artifact, I
>> will consider it... but what about people who are already pulling 2.0.0
>> and
>> 2.0.1 from the jdom artifact? How will they know to 'move' if their
>> dependencies are not going to move with the artifact....? If I can keep
>> the
>> jdom-2.0.x.jar, I would also consider deploying to *both* jdom2 and
jdom
>> artifacts....
>>
> 
> This is where I think JDOM2 made a big mistake.
> 
> JDOM 1 is not binary compatible with JDOM 2 because of the package name
> change.

It was incompatible for other reasons, so 'formalizing' it with a package
change made it very obvious ... ;-)

And this is where I think your logic step breaks down....

   java -cp .:jdom-1.1.3.jar:jdom-2.0.1.jar MyApp

is just fine.

What you are saying is that it is JDOM's fault that Maven cannot build a
class path..... ;-)

There is *no* problem with running both jdom 1.x and 2.x in the same
system. The problem is how to 'package'/'build'/'deliver' the jars.

So, I am an 'old fashioned' ant-build type person. I am very happy with
that, but I know it is not 'cool'.

On the other hand, I acknowledge there are other ways to do it. So, it
comes down to the fact that *JDOM* is fine, the JDOM 2.x jars have a
perfectly good name, but they are not being *exposed* correctly in
Maven/ivy/whatever.

So I messed up with the maven deploy, again, how to fix it? As I said
before, I am willing to consider fixing things, this is not a dead
issue.... (but I take offense when people say it is JDOM's fault that maven
cannot build a classpath.... Hell, ant can do it, so why then is maven
'better'!).


> 
> So I cannot just change my ivy.xml (or pom.xml) and say I want "2.0.1"
> instead of "1.1.1" and have it work.

or ivy

> 
> I must change all of my source files to use the new package. If I have
to
> do that, then surely, changing the artifact id from "jdom" to "jdom2"
makes
> sense and is not an added burden IMO.
> 

The decision to put JDOM 2.x in the jdom artifact is/was (at the time)
reasonable.... now I see that it's not necessarily so reasonable, but I am
stuck.... I am stuck with deciding what the *right* solution is...

I agree that when changing package names that changing the artifactID is
easy too... but changing the artifactID has implications for JDOM....

Technically there is nothing wrong with the way that JDOM is released, as
jdom-1.1.3.jar and jdom-2.0.1.jar. Technically they are both successfully
released to maven. Technically they should probably have had different
artifact ID's.... but, do I have to rename (the future) jdom-2.0.2.jar
jdom2-2.0.2.jar just to make maven (and ivy.... etc.) happy?

So, the fix for this problem appears to be putting future versions of jdom
2.x in to a separate artifact. If the fix is accomplished by changing the
artifact ID, then great... the way I see it is:

1. leave it the way it is and have psycho's on jdom-interest whining ;-)
2. put jdom-2.0.2.jar in the jdom artifact, as now, but also deploy
jdom2-2.0.2.jar to jdom2 artifact (double-release to maven)
3. put jdom-2.0.2.jar and future versions in jdom2 artifact (assuming I
can have a different jar 'base' name than artifact name).
4. put jdom2-2.0.2.jar and future versions in jdom2 artifact, and keep the
'standard' jdom-2.0.2.jar on jdom.org, but that *sux* to have different
jars on www.jdom.org and maven-central.
5. rename all of JDOM's future jars to jdom2-2.x.y.jar to accomodate the
maven 'problem' ( ;-) ) and then 'conform' to maven-mantra.


>>
>> 3. How do I 'notify' the 30k people a month using 1.1 that they should
>> upgrade/change their artifact to jdom2?
>>
> 
> The same way you tell them there is a new version. At Apache we use an
> announcement mailing list, some folks use Twitter, and so on.
> 
> In the end you cannot force people to upgrade, each developer has to
make a
> conscious decision to update a jar (which might drag in other jars with
it
> and so on.)

Agreed, I was just whining about no-one liking jdom 2.x ;-)

> 
> 
>> 4. Maven provides no way to 'test' something... (at least not with the
>> simple 'bundle' upload). How do I do a 'dry run'? I have already got
the
>> JDOM beta's in the jdom2 artifact because I needed to get some
'practice'
>> in.....
>>
> 
> This is how we do it for Apache Commons including dry runs:
> http://wiki.apache.org/commons/UsingNexus

That *requires* using 'mvn' to build JDOM.... which is not going to happen
(short/medium term).

> 
> Gary
> 

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]