See intermixed and below for more questions...
The xdocs folder was an early attempt to migrate to Maven. It did actually work, we just weren't ready to finish the migration, and the experimental xdocs have not been maintained.
My ultimate goal (this year) is to get Struts and all of the subprojects to be singing to the same tune and to the same beat. My choice of tools is Maven, but the Ant scripts will be fully compatible.
Building the tld and reference documentation from the same source is a clever idea (though it does confuse everyone at first), and I imagine we want to retain it.
I'm wondering about this. I'd like to see the same thing implemented with maven. I don't know how much more it will buy us by doing:
xdoc -> tld/doco/and the foo report versus doc -> tld/doco
Conceptually, the dev*.xml files are like JavaDocs. They are the source for the TLDs, with embedded comments. These could be moved to the taglib subproject, along with the Java source.
Yes, that is just the coolest thing!!
<dreaming> Now all we need is an xdoc browser for Eclipse with full tag completion. It would let you preview your changes without having to fire off ant or maven....wow...I might actually pay for something like that. </dreaming>
The website for the taglib subproject could then link to the Developers
Guide (embedded in the JavaDoc) and the "TagDoc" (generated from the dev*.xml files).
It's on my todo list.
I've got apps building (though they won't work without the .tld), but I've come across one strange problem. I remember mentioning it before and asking about what we should do. The tile-documentation source are importing classes that were removed during digester 1.5 -> 1.6. They were moved to examples or samples or something like that (I remember reading about it in the release notes), so tiles-documentation won't compile unless I downgrade the dependency to 1.5.
So, should I:
a) ask commons-digester people to (+1 I have to do the same sort of thing
publish the sample.jar, so we for commons-resources db impls)
can pick it up?
b) copy the java source here (-0 bad idea, but may be best solution
if a does not happen)c) refactor the source to not use (-0 i'd hate to lose good documentation)
those classes
d) let David Geary worry about it ;) (+1 he's a bright guy!!!)
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[email protected]>
Sent: Saturday, January 15, 2005 3:45 PM
Subject: Re: svn restructure
-Ted.
On Sat, 15 Jan 2005 15:22:12 -0500, James Mitchell wrote:
In "apps" are we getting to a single artifact per project.xml? Yes!
So, what's the deal with docs? There's struts/trunk/doc and struts/trunk/xdoc.
If I recall correctly, xdoc was a failed attempt to move us over to a different documentation builder. Is that not correct?
Do we want to continue to build the tld and documentation from the same xml? (I am sure the answer is yes, but I need to know for sure). So, that said, what would be our best strategy? Given the new restructuring of apps, we can now build the apps against any version of struts, simply by changing the project.xml (locally).
(from here down, when I say "install", I mean how Maven compiles, JARs, and sticks that jar under your local .maven/repository/struts/jars)
From a global perspective, what should a full build do? (and in what
order?)
- core - bsf - taglib - docs - apps - el
...come to think of it, with the dependencies declared correctly in project.xml, maven will automatically figure it out for us, right?
Given the decision on a new global script, what kinds of targets do we want to setup?
before: ant dist - did a full distribution ant test.tomcat.x.y - ran the full test suite under jakarta- tomcat-x.y ant release - the "do it all" target that got us
Now that the project is fractured into smaller pieces, we are closer to a continuous integration strategy.
So, those of use that want to use Maven...I'm thinking.... - core:dist (builds a struts-core-x.y.z) - core:install (this installs the new jar) - taglib:dist (simply builds a distribution for this project) - taglib:install (same as core...sort of) - and so on - and so forth
and from core/trunk:
maven global:release(would build a complete distribution of all the latest components or artifacts)
Your thoughts?
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
-------------------------------------------------------------------- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
