[jdom-interest] JDOM2 Update - maven
jdom at tuis.net
Thu Sep 15 03:13:28 PDT 2011
No problem about jumping in at all! It is probably worth recapping the
reasoning anyway, so here goes.
JDOM2 is where all the exciting and (relatively) 'sexy' changes are
going to happen. JDOM 1.1.2 on the other hand must follow on the
tradition that JDOM has had so far of reliability, predictability,
There are some bugs that need fixing in the 1.1.2 stream, and we expect
that code to be used for years to come. The people who use it will want
to have a 'no issues' drop in replacement for their 1.1.1 jar.
We do not want to 'destabilize' the 1.1.2 code in any way.
The current JDOM build process does some 'odd' things:
1. It uses ant filters to whole-sale copy the *.java files in to a
separate location, and there may be some changes made to that code in
the process (small changes, admittedly, and I don't know exactly where...)
2. It uses some tricks to make a custom manifest file in the .jar files
3. It needs to build the code to be compatible with Java 1.2 (I am
hoping Jason will chime in with exactly how we can (still) do that in
the best way possible.
These things are 'complicated' and would require us to be 'experts' in
*both* JDOM *and* Maven to 'convert' 1.1.2 to Maven and be confident in
the full compatibility of the result. At the moment I don't believe
there is a single person who is qualified to the required degree... (in
both toos) ;-)
In addition, we don't want to spend time 'fixing' or 'investigating'
issues in 1.1.2. We don't want to have to worry about it in any way. Our
focus should be on JDOM2.
The simplest thing is to just do what has always been done and is tried
and true.... but still keep maven users happy by having jdom-1.1.2.jar
in maven central.
Speaking of which I have had some feedback from sonatype.... I will
forward it to the list for 'the record'.
It seems like everything is 'on track' on the administration side.
On 15/09/2011 3:22 AM, Christian Migowski wrote:
> sorry for jumping in from the side, disregard this mail if the
> problems are actually settled, it is meant helpful:
> On Thu, Sep 15, 2011 at 6:39 AM, Rolf<jdom at tuis.net> wrote:
>> 1. we intend to use http://jdom.org/downloads/ as the 'official' release
>> location of jdom, and maven-central will be 'useful'
> I don't see how this could be affected by building the project with Maven.
>> 2. we intend to keep the existing ant build processes in their entirety for
>> 1.1.2. We do not want to be trying out a new compile and packaging process
>> for it, especially if the final build will likely be done with Java 1.4 or
>> even older (Maven requires 1.5 I believe) (Jason, what did you use to
>> compile 1.1.1?).
> Maven does not use 1.5 per default (try creating and running a new
> Maven project with a class containing generics)
>> 3. Maven typically 'hooks' in to the project at a very low level. It often
>> establishes the whole 'personality' of the project before any code is even
>> written. But we only want the 'sweetness' of maven central, not all the
>> 'joys' of dependency management.
> What exactly are the problems / big changes that come up when building
> JDOM with Maven? Maven can actually be brought to doing what you want,
> it is just harder then bending yourself ;) Default directories and
> names can be changed, multiple locations added, there is a lot
> possible, it just takes a lot of time to investigate. Since I've done
> this already for some of our projects I would love to help if this is
> wanted. The only thing that cannot be changed (I think) is having a
> local Maven repository populated with all the dependencies required
> for (building) Jdom - which means at one point in time you have to
> have internet access during a build so all of this can be downloaded.
> Thanks for such a great library, it made me recover hope for XML under Java,
> best regards,
>> So, I don't believe what we have at the moment will work, so I have been
>> researching what it is that we can actually do.... and, (at least for
>> 1.1.2), here's what I think we need, and 95% of it is administrative rather
>> than technical... so:
>> 1. leave the ant build (mostly) alone.
>> 2. Register on oss.sonatype.org (I have registered) which is a 'gateway'
>> service for 'feeding' OSS artifacts to maven central (it may have been
>> easier if we were an apache project... ) Go and read:
>> 3. 'reclaim' the org.jdom "Group ID".
>> 4. Create and register GPG signing keys as per sonatype.org instructions
>> 5. modify the ant build (slightly) to build the jars that conform to the
>> oss.sonatype.org requirements: need jdom-javadocs and jdom-sources jars.
>> 6. Consider doing something similar for jdom-contrib (but skil jdom-test)
>> 7. publish the jars on jdom.org
>> From this point on each maven 'release' will be a manual-ish process:
>> 8. Create a 'deploy-only' pom.xml as per the instructions at sonatype
>> 9. push the 'release' to the sonatype staging area using either option 7b or
>> 7c in the sonatype usage guide
>> 10. check on the oss.sonatype.org website, log in, and 'release' the
>> 11. Comment on the JIRA created by me today so that the 'maven-central' sync
>> is activated.
>> Form my perspective we can do steps 5, 6, and 7, at any time prior to
>> actually releasing in maven-central. (I only put them there because I think
>> there still need to be some fixes applied to 1.1.2, and I anticipate that
>> steps 1 through 4 will be done before we have all the fixes applied and are
>> 'ready' to release 1.1.2)
>> The rest of the process is just going to be an administrative process, with
>> the usual red tape to negotiate.
>> What it means in the short term is that, as far as I can tell, it is not the
>> 'right thing' to commit Brad's pom.xml files yet:
>> 1. we will only need one pom.xml for 1.1.2
>> 2. 90% of the content in Brad's poms are for building the code, which we
>> will use ant for anyway.
>> 3. 90% of what is required for sonatype.org deployment is not in Brad's poms
>> (and the stuff that's missing is more administrative in nature and I don't
>> know the right answers for them all....)
>> 4. Brad was right the first time, the actual building content is relatively
>> trivial to reproduce if we ever need it.
>> So, I apologize for sounding 'negative' about the maven process, but I am
>> not trying to be.... honestly!
>> Oh, one other option we have is to just simply push JDOM up on to
>> maven-central via a 'third-party' dependency, which is how I think JDOM 1.0
>> and earlier got on to maven-central before in the 'jdom' group ID, and how
>> jdom 1.1 made it in as part of the 'org.jdom' group ID. See
>> Thanks again
>> On 14/09/2011 5:53 PM, Rolf wrote:
>>> I have not head back from Sonatype about the 'org.jdom' group id.
>>> I will pull the dropbox copy, make sure it works for me, then push the
>>> changes up to github.
>>> As for the build process, yes, there are warnings. Most of them relate
>>> to using a null value to what has become a varargs method in the
>>> reflection API. It can be safely ignored, and is one of the things that
>>> will be fixed when the junit testing is done.
>>> There is another warning in the junit tests because I am directly
>>> referencing an internal com.sun.* package to pull in an alternate parser.
>>> Will get back to you later on where things are at.
>>> On 14/09/2011 5:37 PM, Brad Cox wrote:
>>>> Rolf and Jason, I made a quick first pass at the 4 poms for your updated
>>>> files. They're at the new dropbox address
>>>> I copied them from the .zip file, not git. Couldn't make it work and
>>>> only now see why. Should be clone, not pull.
>>>> Hopefully the zip files will do. I didn't change anything except adding
>>>> the 4 poms, so they should work if you need to move them elsewhere.
>>> To control your jdom-interest membership:
>> To control your jdom-interest membership:
More information about the jdom-interest