You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Mitchell <jm...@apache.org> on 2005/01/15 21:22:12 UTC
svn restructure
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 15 Jan 2005 20:47:52 -0600, Vic <vi...@friendvu.com> wrote:
> As far as site docs... that is a lot of work. One alternative is to use
> one of PHP CMS systems... it is easy and no work.
I'm obviously missing something. Are there PHP CMS systems that use
the same XML format that our docs are currently in? Assuming there are
not, then why is it a lot of work to do site docs as we have been
discussing, and no work to use a CMS that doesn't understand our
current doc format?
In any case, the infrastructure folks are very unlikely to OK a
non-static site system, because of the load it would put on our
servers, especially for a project as popular as Struts.
--
Martin Cooper
> I know, I know.
> (BasicPortal is Apache License, that is Struts and it works at several
> comercial.... even that is less work).
> Springframework.com uses something. Etc. etc.
> I use Drupal and am properly shamed.
>
> .V
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by James Mitchell <jm...@apache.org>.
I don't see that happening. I'd rather use a Maven or Forrest generated
site.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Vic" <vi...@friendvu.com>
To: <de...@struts.apache.org>
Sent: Saturday, January 15, 2005 9:47 PM
Subject: Re: svn restructure
> As far as site docs... that is a lot of work. One alternative is to use
> one of PHP CMS systems... it is easy and no work. I know, I know.
> (BasicPortal is Apache License, that is Struts and it works at several
> comercial.... even that is less work).
> Springframework.com uses something. Etc. etc.
> I use Drupal and am properly shamed.
>
> .V
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Vic <vi...@friendvu.com>.
As far as site docs... that is a lot of work. One alternative is to use
one of PHP CMS systems... it is easy and no work. I know, I know.
(BasicPortal is Apache License, that is Struts and it works at several
comercial.... even that is less work).
Springframework.com uses something. Etc. etc.
I use Drupal and am properly shamed.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Ted Husted <hu...@apache.org>.
On Sat, 15 Jan 2005 18:00:01 -0800, Martin Cooper wrote:
>�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.)
Yes, a thin "site" subproject might be a better idea. The site subproject could introduce and link to the other subprojects, like a portal page.
We could then just run core like any other subproject, with the same set of documents as the others.
One trick would be to use a blank page at /index.html to that redirects to the /site/index.html page.
The subprojects could then link back to /index.html or to ../site/index.html .
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 15 Jan 2005 15:22:12 -0500, James Mitchell <jm...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 15 Jan 2005 17:52:15 -0500, James Mitchell <jm...@apache.org> 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" <hu...@apache.org>
> To: "Struts Developers List" <de...@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: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by James Mitchell <jm...@apache.org>.
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" <hu...@apache.org>
To: "Struts Developers List" <de...@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: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn restructure
Posted by Ted Husted <hu...@apache.org>.
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.
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.
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.
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).
-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: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org