Re: jdom 2.0 with generics

Re "IntelliJ IDEA or Eclipse git checkout methods", no I haven't tried them
since mercurial does everything I need. Didn't want to tool up for jdom
unless there's clear interest...and a recipe to follow so I don't screw
something up.

Re: "move-around", that can probably be minimized by dispensing with maven's
src/main/java convention and just overriding that to use src in the pom.
Might be useful to start that way to eliminate any impact at all on ant
users.

As I see it: negatives... none at all. Even putting the three parts in a
common jdom parent isn't essential. The only delta is one new file, pom.xml,
in each folder. Can be ignored if not desired.

Positives: dependency management is all gain, no pain, compared to managing
that lib folder with ant. When you're ready, jdom can be auto-distributed to
maven repos where its automatically available to everyone. Being unable to
manage jdom as I do everything else was the main reason i gave up on it
earlier. The cross-IDE feature is really important too. I could go on.

All gain no pain.... what more could you want? ;)

On Wed, Aug 10, 2011 at 6:57 PM, Brad Cox <[email protected]> wrote:

> 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 <[email protected]>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 <[email protected]>
>>> 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/[email protected]
>>
>
>
>
> --
> Cell: 703-594-1883
> Blog: http://bradjcox.blogspot.com
> Web: http://virtualschool.edu
> Manassas VA 20111
>
>


-- 
Cell: 703-594-1883
Blog: http://bradjcox.blogspot.com
Web: http://virtualschool.edu
Manassas VA 20111

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]