[jdom-interest] jdom 2.0 with generics

[Brad Cox]

Glad to hear there's interest. Actually I've already done the work if it can
be called that. There was nothing more to it than moving jdom-contrib,
jdom-src and jdom-test into a common parent (jdom), moving src/* to
src/main/java inside each, and writing four simple poms for each folder.
Didn't chase any corner cases but the simple pom was all I needed to feel
right at home.

Absolutely right about maven as cross-IDE representation. I sincerely
encourage using it. If I can help with the learning curve, just ask. Maven
is simpler than it seems at first.

Let me know if you want the changes.

On Mon, Aug 8, 2011 at 12:23 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> I've been switching over to maven for my cross-IDE projects recently, and
> in fact was just converting some of mine from native NetBeans projects to
> Maven projects -- which is the only cross-IDE project representation that
> I'm aware of.  (Maven projects are the easiest for everyone to consume,
> assuming that everyone is using different IDEs or the command line.)
>
> That said, I build jdom extremely rarely, so I have no case of my own.
>
> On Mon, Aug 8, 2011 at 7:12 AM, Rolf wrote:
>
>
>> Hi Paul.
>>
>> Couple of things.... I've found that git's 'mv' tracking is somewhat
>> problematic, it's not as easy to track an item's history than before the
>> move.... you have to specify --follow for the 'git log' request.
>>
>> Neither eclipse nor github appear to apply the --follow logic to the moved
>> files' history... It would be nicer if they did, since all the classes
>> have
>> moved once already (jdom -> jdom2).
>>
>> I acknowledge that the current system of dumping the supporting jars in
>> the repo is 'crude', but, it has some other advantages. Having everyone
>> using the same jar versions for the JDOM2 development would reduce the
>> number of 'head-scratching' problems. This is up for discussion, but it
>> seems that eliminating inconsistencies at this point in the development
>> would be useful.
>>
>> Finally, I am in the habit of using ant and eclipse (call me 'old
>> fashioned'), and I have the habit of throwing in an 'eclipse' target for
>> ant build.xml files. I have added this target to the jdom build file.
>>
>> Running 'ant eclipse' and refreshing your eclipse project (f5) will set
>> up/update your eclipse source folders, and library dependencies in a way
>> that makes it all 'just work'.
>>
>> I normally have a 'smarter' eclipse target that uses the ant classpath to
>> set up eclipse, but, in this case, I have it hard-coded at the moment. I
>> see that it's missing the xml-apis.jar file, so it needs an update anyway.
>> I'll make it dynamic based on the ant compile classpath instead.
>>
>> Obviously the demand for 'Mavenization' is growing... perhaps the most
>> important question is 'how important' is it? I have always worked in an
>> environment where build dependencies are more tightly controlled than what
>> maven would allow, and the dependency-loading nature of maven would be
>> 'wrong'.
>>
>> If you can make a convincing argument to 'Mavenize' then the actual commit
>> process would have to be very tightly coordinated, and it would interrupt
>> the actual JDOM2 coding as things stabilize. Further, it would also
>> benefit
>> from having the comprehensive unit testing in order to confirm that
>> nothing
>> has broken in 'the wash'.
>>
>> As for a full Maven re-structure, I am hesitant... and I think Jason will
>> have to weigh in with the final word on that. It's more far-reaching than
>> just JDOM2...
>>
>> Rolf
>>
>> On Mon, 8 Aug 2011 15:25:31 +0200, Paul Libbrecht <paul at hoplahup.net>
>> wrote:
>> > I think Brad's offer was to do it.
>> > It does involve an amount of move around but it brings a few advantages
>> > for people to take things up.
>> >
>> > Except for being able to transparently depend on jdom if it makes its
>> way
>> > into the maven repo (that's somewhat further), it allows to open in
>> Eclipse
>> > and IntelliJ IDEA directly, classpath and sourcepath all set.
>> >
>> > Brad, have you tried using the IntelliJ IDEA or Eclipse git checkout
>> > methods (IntelliJ had me locate a Git executable which I had to
>> download,
>> > about 3 minutes)? If using this rearranging there will then nicely keep
>> > history the same way an svn mv would do.
>> >
>> > paul
>> >
>> > Le 8 août 2011 à 14:52, jdom a écrit :
>> >
>> >>
>> >> Hi Brad
>> >>
>> >> In the short term it is unlikely that the JDOM repo will be converted
>> to
>> >> a
>> >> maven-style build. I simply do not use maven at all, and I do not know
>> >> the
>> >> maven 'paradigm'.
>> >>
>> >> I know that the possibility is there to produe the maven co-ordinates
>> for
>> >> the JDOM releases, but it woul dmake sense to first get something
>> usable
>> >> out of JDOM2 before we go publishing it as a maven resource.
>> >>
>> >> Bottom line is that, if it happens, it will be one of the last things
>> to
>> >> go through. Probably only after the alpha/beta/final stages of JDOM2
>> are
>> >> settled.
>> >>
>> >> Still, JDOM is all about 'Java manipulation of XML made easy', so, it
>> >> should be considered, and I've updated the wiki page
>> >> https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 to reflect that
>> Maven
>> >> artifacts should be a possible goal of JDOM2.
>> >>
>> >> Pleased to see the mounting excitement for JDOM2.
>> >>
>> >> 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/20110810/91c92df5/attachment.html>