On Sat, 15 Jan 2005 15:22:12 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:
> In "apps" are we getting to a single artifact per project.xml? Yes!
Looking good!
> 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?
As Ted mentioned, the idea with xdocs was to use Maven to build the
docs. What's in there now is probably not very useful, since it's so
out of date.
However, since we're now driving towards Maven again, we'll want to
decide on whether we want to migrate the docs and keep them that way
this time. IMO, we should focus on getting the various builds into
shape first, so that we're sure we're going to stick with Maven this
time. Assuming we get to that point, we can think about divvying up
the docs across the projects and migrating them to xdocs. (I guess we
could do the divvying up sooner, but that would lead to a bunch of
other things we'd need to change. One thing at a time, IMO.)
> 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).
Yes, we should continue to generate the tlds and docs from common
sources, as long as that's possible. One thing I don't know right now
is if we'll be able to mark up the xdocs directly (i.e. if Maven will
get confused if we add some of the tags we need). If that's the case,
we might end up having to start with a common source file and generate
xdocs as well as tlds, and then feed the xdocs to Maven. That would be
messy but still workable, I would think.
> (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
When you say 'docs' here, I'm not sure what you mean. With each
subproject building its own docs, perhaps you mean 'site'? That would
be the glue that holds the remainder together. Although I recall Ted
suggesting that 'core' own the main site and the remaining subprojects
would link to that. (The problem with that, IMO, is that we still need
some way of referring to the subprojects from the main page, so I
believe we still need a 'site'. We just need to decide what's in
that.)
Also, I would expect 'el' to come before 'apps'. Shouldn't 'apps' be
last, so that it can take advantage of all the other subprojects?
> ...come to think of it, with the dependencies declared correctly in
> project.xml, maven will automatically figure it out for us, right?
Dunno. I haven't got that far in my Maven education yet. ;-)
> 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
Well, there are scads of other targets, too. ;-) We'll need to decide
what to keep and what to drop (if anything).
The nightly builds do 'ant clean dist', so we'll need a way to do
that. The Cactus targets get taken care of by Maven ('maven cactus'),
and we should be able to use 'maven dist' instead of 'ant release'
(with a bit of work).
> 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)
Hmm. The intent is to have the subprojects individually versioned and
released, so I'm not sure we need a 'global:release' target. It would
be convenient for developers to be able to build everything at once
now and then, but we won't need to package everything up into a single
drop.
--
Martin Cooper
> 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]
