Hibernate might be a good model.
If jdom2 is upward compatible with jdom1 then you have no need to run 2
versions.
It means not changing the behaviour of existing methods except in ways
that all current users will like (remove a bug).
You add new methods to add functionality and you make sure that the
version 2 supports all the version 1 calls in exactly the same way as
version 1 did.
Then you tell people that want to use the old methods and the new
methods to simply change the version on the dependency in their POM and
start to use the new library.
That is what most people do.
Not doing this, will have an impact on the reputation of the product for
those interested in total cost of ownership and robustness of their
applications.
If you want to change the functions of existing methods or delete
methods (without warning for several years in advanced - "deprecated")
in ways that will break current, properly written, applications, then
you can do what Hibernate did.
Change the library name to hibernate3 and make the names of all of the
methods have a 3 in their name.
This way the developer would have a real problem if they tried to mix
the old with the new since that is what you need in the case of database
access rather than your situation where it appears that mixing jdom
functions between versions will not result in data corruption.
Ron
On 29/05/2012 10:26 AM, Rolf Lear wrote:
So, being inexperienced, my intention is to find some solution that:
1. makes it possible (even if playing exclusion games is needed) to use
both JDOM 1.x and 2.x in a maven project (currently it is not).
2. 'salvages' the current mess as simply as possible for the 'typical'
maven user.
3. is something I can describe on the jdom website and expect people to
understand how to get it right... ( I don't want to have to do 'maven
support' ;-)
The way I understand things is that once I deploy to a second artifact
(either deploy JDOM 2.x to 'jdom2' artifact, or alternately deploy JDOM 1.x
to 'jdom1' artifact), then users can 'exclude' any conflicting dependencies
from their 'required' third-party projects, and substitute them with the
ones from the 'alternate' artifact.
In my head it seems that creating a jdom1 artifact would be very stable (I
do not expect any more 1.x JDOM releases....), and then people can 'stick'
with the 'jdom' artifact, and if they run in to problems they can play the
'exclusion' game with the jdom 1.x dependencies, and replace them with the
jdom1 dependency.
This 'keeps it simple' for the typical user, but still makes it possible
for the 'conflicted' user to get their jars.... ? right?
But, would that be 'sensible'? Would a maven user 'follow' that logic?
I am not really in any position to have firm opinions on this. The only
preferences I have would be:
1. I want the official JDOM release (on www.jdom.org) to be identical to
the releases on maven - I don't want to have different jar names, etc. The
www.jdom.org release is the 'official' release, and maven is a 'mirror'.
2. I would prefer to continue calling it jdom-2.0.2.jar instead of
jdom2-2.0.2.jar - to keep consistency with what we have already done....
but this is a lower priority.
Thanks for the insights so far ....
Rolf
On Tue, 29 May 2012 15:00:54 +0100, Stephen Connolly
<[email protected]> wrote:
On 29 May 2012 14:53, Curtis Rueden<[email protected]> wrote:
Hi Rolf,
Unfortunately, there are already some 'third party' packages that
depend
on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have
two
different versions of the same jar .... right? ... which is perhaps
worse
than not having it at all ... ;-)
Since your goal is to allow JDOM 1.x and JDOM 2.x in the same JVM from
a
Maven project, publishing as org.jdom:jdom2:2.0.x seems like the way to
go.
You can continue publishing org.jdom:jdom:2.0.x as well; the
duplication
does not really cause any problems other than potential confusion.
Curtis,
the issue is transitive version resolution. If one of your
dependencies depends on org.jdom:jdom:1.x and the other depends on
org.jdom:jdom:2.x then you're going to end up with something broken as
maven will resolve only one version of org.jdom:jdom... so you will
end up having to play the exclusions game to stop that version being
pulled in and manually add a dependency to org.jdom:jdom2...
this is why one of the major feature adds I want to get into maven 4
is a provides scope.
As long
as you document why org.jdom:jdom2 exists, it seems fine to me.
-Curtis
On Mon, May 28, 2012 at 5:15 PM, Rolf Lear<[email protected]> wrote:
Unfortunately, there are already some 'third party' packages that
depend
on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have
two
different versions of the same jar .... right? ... which is perhaps
worse
than not having it at all ... ;-)
Rolf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler President Artifact Software Inc email:
[email protected] skype: ronaldmwheeler phone:
866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
