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

Fri May 18 11:06:44 PDT 2012

The maven dox are clear about its adherence to "convention over
configuration", which is the very thing I found compelling after my own
bout of grumbling over its noncompliance with *my* conventions
(src/main/java indeed when src should be enough, sez' I). That said, it
provide way to override almost anything, although that's usually painful
enough that its best avoided.

Think of it this way. For the problems I work on, JDOM is a very small tree
in a very large forest of jars that must work together. I need it to fit
 in to that forest and "just work" without having to think about your
reasons for wanting (or needing) your own set of conventions. Regardless of
its (many) flaws, maven projects generally more or less deliver on that
promise. Outlier conventions create problems for me and I avoid packages
that create problems.

On Fri, May 18, 2012 at 1:30 PM, Rolf Lear <jdom at tuis.net> 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.....
>
> 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
> >>
>
> _______________________________________________
> 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/205a4f17/attachment.html>