[jdom-interest] JDOM2 Update - maven
chrismfwrd at gmail.com
Thu Sep 15 00:22:33 PDT 2011
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,
> 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