On Sat, 15 Jan 2005 17:52:15 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > 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.
If we get the Maven builds right, we'll be able to generate the Ant builds anyway, right? > > 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 Are you talking about the same issue I was describing in my previous message? This definitely needs some more thought. > > > 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. Yup, all the taglibs docs should be moved to that subproject. (BTW, shouldn't the subproject name be plural??) > 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> Dream on ... or scratch the itch. ;-) ;-) > > > 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), Just FYI, the Maven build for 'core' is generating the tlds right now. ;-) > 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. Can you expand on this? What went missing, and how were we using it? -- Martin Cooper > 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" <dev@struts.apache.org> > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
