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

[Rolf Lear]

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.....

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?

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....

3. How do I 'notify' the 30k people a month using 1.1 that they should
upgrade/change their artifact to jdom2?

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.....

Frankly, I would rather be spending my time building 'fun' things than
untangling this mess....

Rolf

On Fri, 18 May 2012 11:24:11 -0400, 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
>>