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/11 12:35:25 UTC
svn repository
Who is going to finish moving the directory structure?
Right now, I can't load core as an Eclipse project because some of the
example apps rely on tiles, which relies on core. Creating a circular
reference as far as project dependencies goes.
I remember someone mentioning moving all the apps to an 'apps/trunk' base.
Is that still going to happen?
--
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 repository
Posted by Joe Germuska <Jo...@Germuska.com>.
>1. Why does commons-chain have a sample application called "mailreader"?
> This looks to be the same mailreader as the one in Struts.
Probably because it was an easy way to demonstrate a chain app!
>2. core doesn't compile with "ant dist" or "maven dist" due to half baked
> file structure changes. Specifically, the sample apps refer to TagUtils,
> which they can't find. How does the nightly run anyway?
It's just one offending class:
src/test/org/apache/struts/util/TestRequestUtils.java
which actually tests methods which were moved to TagUtils and have
been removed from RequestUtils. It could probably be deleted or 'svn
move'd to the taglibs side and adjusted to test the methods in their
new class and repository location...
>[The plan (yes, I'm volunteering) ]
>So, unless someone says something, my plans are as follows:
Looks great.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn repository
Posted by James Mitchell <jm...@apache.org>.
<snip/>
>>Where did 'conf' or 'config' go? We currently have 'conf/share',
>>'src/conf', etc., but I don't see where those land in your structures.
>
> I was assuming most of those things landed in src/resources.
> Personally, I'd be more comfortable with putting the things that get
> bound into the jar in src/resources under their final classpath.
> This works more automatically with maven, and I think it's clearer.
>
> That is, move
> conf/share/chain-config.xml
> to
> src/resources/org/apache/struts/chain/chain-config.xml
Yes, I like that idea too.
>
> I missed it too. I'm nervous that "modules" is too reminiscent of
> Struts modules specifically, especially since it's a relatively
> uncommon word otherwise. What's wrong with examples, besides that
> there's also an "example"? Should those two be merged? I have to
> admit that I haven't spent a lot of time with the example webapps
> (until this week!) and don't want to get in the way of anything
> you're motivated to do...
Ya, I thought of 'modules' since the app demonstrates how to use
modules by repackaging 3 previously separate examples. I'll leave
it alone for now (keep it as 'examples') since that's what most of
us are used to.
>>No, that's fine. If you have an itch to put a Maven build system
>>together, more power to you. I was actually taking tips from Maven for
>>the Ant build system anyway. ;-)
>
> On the topic, I think that one of the biggest perceived limitations
> of Maven for Struts right now is that it doesn't "do everything that
> the Ant build does."
Yes, I have made that exact statement on a number of occasions. Yet,
the more I work with Maven, the more I like it. There are still things
that aggravate the hell out of me, but I'm dealing with it. One day
I can say I'm a Maven maven, but not today :P
> While this is true, it's likely to become less
> so if we move the webapps and the Struts site into their own areas of
> the SVN repository. If "core" is really just about creating a
> struts.jar, I think we'll find that we can get Maven doing everything
> it needs to do much more readily.
>
> Joe
>
--
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 repository
Posted by James Mitchell <jm...@apache.org>.
Ok, I'm laying out a detailed plan for this effort. I will publish it to
the wiki and ask for comments before I actually start this. With any luck,
(giving people enough time to respond) I can finish this restructure effort
before the end of next week.
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
----- Original Message -----
From: "Craig McClanahan" <cr...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Wednesday, January 12, 2005 9:18 PM
Subject: Re: svn repository
> Your approach definitely makes sense ... and memorializes a great
> acronym to boot .
>
> Don't get the MADs mad at you :-)
>
> Craig
>
>
> On Wed, 12 Jan 2005 19:43:37 -0500, James Mitchell <jm...@apache.org>
> wrote:
>> >
>> > Note that this particular separation (of the model APIs and DAO) has
>> > been done already ... core/trunk/struts-examples/mailreader. We'd
>> > only need to make all the incantations of mailreader use this common
>> > code base to reduce some of the duplication.
>>
>> Yes, I noticed that a few weeks ago. I don't intend to change that,
>> in fact, I plan to build on it....see below.
>>
>> >
>> > However, you're going to end up with different implementations no
>> > matter what ... they exist to illustrate different technological
>> > approaches to building the same app, to facilitate comparisons.
>>
>> I am applying a strategy that builds the variations of mailreader
>> apps by repeating a process that, for each mailreader app:
>>
>> a) copies the "common" or "standard" base file structure and files
>> to a target dir
>> b) copies **/*.* over top of that
>> c) generates any docs/javadocs/etc and wars the artifact
>> (would also run the full test suite....yes I'm volunteering ;)
>>
>> This process would repeat for each "one-off mailreader"....like so:
>>
>> -- default --
>> apps/trunk/mailreader/standard
>> apps/trunk/mailreader/el
>> apps/trunk/mailreader/shale
>> apps/trunk/mailreader/jericho
>> apps/trunk/mailreader/resources (impl using commons-resources)
>> apps/trunk/mailreader/chain (probably don't need this any more)
>> apps/trunk/mailreader/tiles (this is not the tiles doc app)
>>
>> -- optional --
>> apps/trunk/mailreader/j2ee (mostly xdoclet generated ejb 3.0
>> against HSSQLDB)
>> apps/trunk/mailreader/spring
>> apps/trunk/mailreader/resources-hibernate (HSSQLDB with Hibernate)
>> apps/trunk/mailreader/spring-hibernate (it's a beautiful thing)
>> apps/trunk/mailreader/resources-jdbc (HSSQLDB with JDBC)
>>
>> There's a main project.xml in apps/trunk/
>> Each mailreader app project.xml extends that and overrides only what it
>> needs to for that specific app. More or less why Maven was invented in
>> the first place (from what I've read).
>>
>> This way we don't have to have full blown webapp structures that
>> duplicate 95% of the code. Only the files that are actually different
>> than the "standard" will exist in these "one off"'s....what do we call
>> these anyway? "Mailreader app demo"? (MAD)
>>
>> So, in the end, if you were to add some new button or page to
>> the standard app, they would all inherit it. And if something changes
>> that breaks any one of the "MAD"s (LOL), the extensive test coverage
>> would catch that....yes I'm volunteering again ;)
>>
>> Does that make sense the way I explained it?
>>
>> >
>> > Craig
>> >
>>
>> --
>> 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 repository
Posted by Craig McClanahan <cr...@gmail.com>.
Your approach definitely makes sense ... and memorializes a great
acronym to boot .
Don't get the MADs mad at you :-)
Craig
On Wed, 12 Jan 2005 19:43:37 -0500, James Mitchell <jm...@apache.org> wrote:
> >
> > Note that this particular separation (of the model APIs and DAO) has
> > been done already ... core/trunk/struts-examples/mailreader. We'd
> > only need to make all the incantations of mailreader use this common
> > code base to reduce some of the duplication.
>
> Yes, I noticed that a few weeks ago. I don't intend to change that,
> in fact, I plan to build on it....see below.
>
> >
> > However, you're going to end up with different implementations no
> > matter what ... they exist to illustrate different technological
> > approaches to building the same app, to facilitate comparisons.
>
> I am applying a strategy that builds the variations of mailreader
> apps by repeating a process that, for each mailreader app:
>
> a) copies the "common" or "standard" base file structure and files
> to a target dir
> b) copies **/*.* over top of that
> c) generates any docs/javadocs/etc and wars the artifact
> (would also run the full test suite....yes I'm volunteering ;)
>
> This process would repeat for each "one-off mailreader"....like so:
>
> -- default --
> apps/trunk/mailreader/standard
> apps/trunk/mailreader/el
> apps/trunk/mailreader/shale
> apps/trunk/mailreader/jericho
> apps/trunk/mailreader/resources (impl using commons-resources)
> apps/trunk/mailreader/chain (probably don't need this any more)
> apps/trunk/mailreader/tiles (this is not the tiles doc app)
>
> -- optional --
> apps/trunk/mailreader/j2ee (mostly xdoclet generated ejb 3.0
> against HSSQLDB)
> apps/trunk/mailreader/spring
> apps/trunk/mailreader/resources-hibernate (HSSQLDB with Hibernate)
> apps/trunk/mailreader/spring-hibernate (it's a beautiful thing)
> apps/trunk/mailreader/resources-jdbc (HSSQLDB with JDBC)
>
> There's a main project.xml in apps/trunk/
> Each mailreader app project.xml extends that and overrides only what it
> needs to for that specific app. More or less why Maven was invented in
> the first place (from what I've read).
>
> This way we don't have to have full blown webapp structures that
> duplicate 95% of the code. Only the files that are actually different
> than the "standard" will exist in these "one off"'s....what do we call
> these anyway? "Mailreader app demo"? (MAD)
>
> So, in the end, if you were to add some new button or page to
> the standard app, they would all inherit it. And if something changes
> that breaks any one of the "MAD"s (LOL), the extensive test coverage
> would catch that....yes I'm volunteering again ;)
>
> Does that make sense the way I explained it?
>
> >
> > Craig
> >
>
> --
> 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 repository
Posted by James Mitchell <jm...@apache.org>.
>
> Note that this particular separation (of the model APIs and DAO) has
> been done already ... core/trunk/struts-examples/mailreader. We'd
> only need to make all the incantations of mailreader use this common
> code base to reduce some of the duplication.
Yes, I noticed that a few weeks ago. I don't intend to change that,
in fact, I plan to build on it....see below.
>
> However, you're going to end up with different implementations no
> matter what ... they exist to illustrate different technological
> approaches to building the same app, to facilitate comparisons.
I am applying a strategy that builds the variations of mailreader
apps by repeating a process that, for each mailreader app:
a) copies the "common" or "standard" base file structure and files
to a target dir
b) copies **/*.* over top of that
c) generates any docs/javadocs/etc and wars the artifact
(would also run the full test suite....yes I'm volunteering ;)
This process would repeat for each "one-off mailreader"....like so:
-- default --
apps/trunk/mailreader/standard
apps/trunk/mailreader/el
apps/trunk/mailreader/shale
apps/trunk/mailreader/jericho
apps/trunk/mailreader/resources (impl using commons-resources)
apps/trunk/mailreader/chain (probably don't need this any more)
apps/trunk/mailreader/tiles (this is not the tiles doc app)
-- optional --
apps/trunk/mailreader/j2ee (mostly xdoclet generated ejb 3.0
against HSSQLDB)
apps/trunk/mailreader/spring
apps/trunk/mailreader/resources-hibernate (HSSQLDB with Hibernate)
apps/trunk/mailreader/spring-hibernate (it's a beautiful thing)
apps/trunk/mailreader/resources-jdbc (HSSQLDB with JDBC)
There's a main project.xml in apps/trunk/
Each mailreader app project.xml extends that and overrides only what it
needs to for that specific app. More or less why Maven was invented in
the first place (from what I've read).
This way we don't have to have full blown webapp structures that
duplicate 95% of the code. Only the files that are actually different
than the "standard" will exist in these "one off"'s....what do we call
these anyway? "Mailreader app demo"? (MAD)
So, in the end, if you were to add some new button or page to
the standard app, they would all inherit it. And if something changes
that breaks any one of the "MAD"s (LOL), the extensive test coverage
would catch that....yes I'm volunteering again ;)
Does that make sense the way I explained it?
>
> Craig
>
--
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 repository
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 12 Jan 2005 08:30:09 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> > > I'd like to get them all consolidated (at least as much as can be done)
> >> providing a single mailreader.jar for the variations.
> >
> >Do you mean one jar of the bits common to all flavours, and then
> >separate apps for each variation? If so, I think this would be a good
> >approach. If you mean combine the various mailreader apps into one, I
> >think that would muddy the waters, and wouldn't work as well as
> >examples of how to do things.
>
> I've seen talk before about bundling the "business app" part of
> Mailreader into its own jar, which I think is what you meant in your
> first sentence, Martin. I think this is a good idea, because I think
> beginning struts users sometimes don't have a good sense of how to
> arrange for good separation of Struts from a more generalized
> framework. In so far as we can demonstrate this a little bit, that
> would be a good thing.
Note that this particular separation (of the model APIs and DAO) has
been done already ... core/trunk/struts-examples/mailreader. We'd
only need to make all the incantations of mailreader use this common
code base to reduce some of the duplication.
However, you're going to end up with different implementations no
matter what ... they exist to illustrate different technological
approaches to building the same app, to facilitate comparisons.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn repository
Posted by Joe Germuska <Jo...@Germuska.com>.
> > I'd like to get them all consolidated (at least as much as can be done)
>> providing a single mailreader.jar for the variations.
>
>Do you mean one jar of the bits common to all flavours, and then
>separate apps for each variation? If so, I think this would be a good
>approach. If you mean combine the various mailreader apps into one, I
>think that would muddy the waters, and wouldn't work as well as
>examples of how to do things.
I've seen talk before about bundling the "business app" part of
Mailreader into its own jar, which I think is what you meant in your
first sentence, Martin. I think this is a good idea, because I think
beginning struts users sometimes don't have a good sense of how to
arrange for good separation of Struts from a more generalized
framework. In so far as we can demonstrate this a little bit, that
would be a good thing.
> > >
>> > We need to come up with one standard structure - we seem to have quite
>> > a few at the moment. The sources go in different places, the config
>> > files go in different places, etc. Not easy to follow at all.
>>
>> Yes, that's exactly what I intend to clean up. Please don't hesitate
>> if something looks odd, or if you prefer a diffent name.
>
>Where did 'conf' or 'config' go? We currently have 'conf/share',
>'src/conf', etc., but I don't see where those land in your structures.
I was assuming most of those things landed in src/resources.
Personally, I'd be more comfortable with putting the things that get
bound into the jar in src/resources under their final classpath.
This works more automatically with maven, and I think it's clearer.
That is, move
conf/share/chain-config.xml
to
src/resources/org/apache/struts/chain/chain-config.xml
For things which are conventionally put in WEB-INF, we'd need to
agree to a location. I think it might be nice to be more clear about
that, perhaps with conf/webinf or src/webinf but I don't feel too
strongly about it.
> > Not sure how many people caught my rename for 'examples' :D
>
>I admit that I missed it until you mentioned it just now. It could
>certainly use a new name, but I'm not sure about 'modules'.
I missed it too. I'm nervous that "modules" is too reminiscent of
Struts modules specifically, especially since it's a relatively
uncommon word otherwise. What's wrong with examples, besides that
there's also an "example"? Should those two be merged? I have to
admit that I haven't spent a lot of time with the example webapps
(until this week!) and don't want to get in the way of anything
you're motivated to do...
>No, that's fine. If you have an itch to put a Maven build system
>together, more power to you. I was actually taking tips from Maven for
>the Ant build system anyway. ;-)
On the topic, I think that one of the biggest perceived limitations
of Maven for Struts right now is that it doesn't "do everything that
the Ant build does." While this is true, it's likely to become less
so if we move the webapps and the Struts site into their own areas of
the SVN repository. If "core" is really just about creating a
struts.jar, I think we'll find that we can get Maven doing everything
it needs to do much more readily.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: svn repository
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 11 Jan 2005 21:09:48 -0500, James Mitchell <jm...@apache.org> wrote:
> <snip/>
>
> >> ' '
> >> ' [-] test
> >> ' ' (really need to get this back in order
> >> ' ' or figure out a new strategy..more on
> >> ' ' this later)
> >
> > Is this all taglibs tests right now? If so, perhaps it should live
> > under 'taglibs' instead of 'apps', since it isn't a "real"
> > application. If not, um, I dunno. This seems an odd place for tests.
>
> Yes, good point, I agree
>
> >
> > You missed one. We also have 'struts-examples' directly under
> > 'core/trunk', which has 'mailreader' in it. Just to complicate things,
> > this also has a different source structure.
>
> Yes, I've done some diffs on the various mailreader apps that
> seem to litter the landscape ;)
>
> I'd like to get them all consolidated (at least as much as can be done)
> providing a single mailreader.jar for the variations.
Do you mean one jar of the bits common to all flavours, and then
separate apps for each variation? If so, I think this would be a good
approach. If you mean combine the various mailreader apps into one, I
think that would muddy the waters, and wouldn't work as well as
examples of how to do things.
> >
> > We need to come up with one standard structure - we seem to have quite
> > a few at the moment. The sources go in different places, the config
> > files go in different places, etc. Not easy to follow at all.
>
> Yes, that's exactly what I intend to clean up. Please don't hesitate
> if something looks odd, or if you prefer a diffent name.
Where did 'conf' or 'config' go? We currently have 'conf/share',
'src/conf', etc., but I don't see where those land in your structures.
> Not sure how many people caught my rename for 'examples' :D
I admit that I missed it until you mentioned it just now. It could
certainly use a new name, but I'm not sure about 'modules'. I don't
hate it, though, and can't think of anything better right now. With
SVN, renames are easy enough, so we could go with this for now and
change it if someone comes up with a better name.
>
> >
> >> - merge the mailreader sample app (and tests) from commons-chain
> >> to struts "apps" (as indicated above)
> >
> > Need to check the relationship between this mailreader and the one
> > under struts-examples.
>
> will do.
>
> >
> >> I would like all the apps/trunk/foo to be mavenized, and each project.xml
> >> creates a single .war file suitable for deployment. Each project
> >> would/should inherit from a parent project.xml under apps/trunk that can
> >> build the entire set of apps. So you can build any app you like, or just
> >> build them all. The build.xml file will be generated by maven (hopefully
> >> the path issues will be resolved).
> >
> > Do you plan to do Maven builds for the other subprojects as well, or
> > just for the 'apps' subproject? Should I take the Ant build system off
> > my to-do list?
>
> I hope you don't feel that I'm ripping the rug from under your feet. That
> is
> certainly not my intent.
No, that's fine. If you have an itch to put a Maven build system
together, more power to you. I was actually taking tips from Maven for
the Ant build system anyway. ;-)
> I was just hoping to get a consistent structure
> and build for the "apps" for now. The repository seem to be in shambles at
> the moment.
Yah, it is. ;-(
> As complicated as the build xml files (all 3 of them) seem to be to
> some people, I know them pretty well, and it just makes my head hurt
> looking at where we are now and what needs to happen to get a clean
> "ant dist" and "ant release".
I was hoping to do this incrementally. It'll be messy in the short
term, but should get us up and running more quickly. Once we have a
standard directory structure in place, as you're suggesting and as I
was planning, it will be much easier to put a consistent build system
in place across the board.
--
Martin Cooper
> I figured I would take my chances on the "apps" and generate the ant stuff.
> Instead of the other way around (back into a project.xml by hand)
>
> Well, I'll wait to hear more on this before I actually pull out the axe and
> 10 lb sledge ;)
>
> >
> > --
> > Martin Cooper
> >
>
> --
> 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 repository
Posted by James Mitchell <jm...@apache.org>.
<snip/>
>> ' '
>> ' [-] test
>> ' ' (really need to get this back in order
>> ' ' or figure out a new strategy..more on
>> ' ' this later)
>
> Is this all taglibs tests right now? If so, perhaps it should live
> under 'taglibs' instead of 'apps', since it isn't a "real"
> application. If not, um, I dunno. This seems an odd place for tests.
Yes, good point, I agree
>
> You missed one. We also have 'struts-examples' directly under
> 'core/trunk', which has 'mailreader' in it. Just to complicate things,
> this also has a different source structure.
Yes, I've done some diffs on the various mailreader apps that
seem to litter the landscape ;)
I'd like to get them all consolidated (at least as much as can be done)
providing a single mailreader.jar for the variations.
>
> We need to come up with one standard structure - we seem to have quite
> a few at the moment. The sources go in different places, the config
> files go in different places, etc. Not easy to follow at all.
Yes, that's exactly what I intend to clean up. Please don't hesitate
if something looks odd, or if you prefer a diffent name. Not sure how
many people caught my rename for 'examples' :D
>
>> - merge the mailreader sample app (and tests) from commons-chain
>> to struts "apps" (as indicated above)
>
> Need to check the relationship between this mailreader and the one
> under struts-examples.
will do.
>
>> I would like all the apps/trunk/foo to be mavenized, and each project.xml
>> creates a single .war file suitable for deployment. Each project
>> would/should inherit from a parent project.xml under apps/trunk that can
>> build the entire set of apps. So you can build any app you like, or just
>> build them all. The build.xml file will be generated by maven (hopefully
>> the path issues will be resolved).
>
> Do you plan to do Maven builds for the other subprojects as well, or
> just for the 'apps' subproject? Should I take the Ant build system off
> my to-do list?
I hope you don't feel that I'm ripping the rug from under your feet. That
is
certainly not my intent. I was just hoping to get a consistent structure
and build for the "apps" for now. The repository seem to be in shambles at
the moment.
As complicated as the build xml files (all 3 of them) seem to be to
some people, I know them pretty well, and it just makes my head hurt
looking at where we are now and what needs to happen to get a clean
"ant dist" and "ant release".
I figured I would take my chances on the "apps" and generate the ant stuff.
Instead of the other way around (back into a project.xml by hand)
Well, I'll wait to hear more on this before I actually pull out the axe and
10 lb sledge ;)
>
> --
> Martin Cooper
>
--
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 repository
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 11 Jan 2005 13:58:32 -0500, James Mitchell <jm...@apache.org> wrote:
> Actually, I had bigger things in mind....well, sort of ;)
>
> See intermixed.
>
>
> ----- Original Message -----
> From: "Martin Cooper" <mf...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Tuesday, January 11, 2005 12:19 PM
> Subject: Re: svn repository
>
> > On Tue, 11 Jan 2005 06:35:25 -0500, James Mitchell <jm...@apache.org>
> > wrote:
> >> Who is going to finish moving the directory structure?
> >
> > Whoever pitches in? ;-)
> >
> >> Right now, I can't load core as an Eclipse project because some of the
> >> example apps rely on tiles, which relies on core. Creating a circular
> >> reference as far as project dependencies goes.
> >
> > It should be easy enough to exclude the examples in your Eclipse
> > project for now.
>
> Yes, but that's actually what I am after.
>
> >
> >> I remember someone mentioning moving all the apps to an 'apps/trunk'
> >> base.
> >> Is that still going to happen?
> >
> > I had hoped to pull out the examples a couple of weekends ago, but the
> > time didn't materialise as I had expected. It would be easy enough to
> > pull them all out into an 'apps' subproject, but it's not quite as
> > easy to get them all building again.
> >
> > However, if folks are OK with temporary breakage, I can pull them out
> > tonight and leave them broken until the weekend, when I'll hopefully
> > have time to make them build again. This sort of follows Ted's
> > suggestion, from some time ago, to focus on getting Core into shape
> > first and then clean up behind us after that.
>
>
> Well, before you do that I have a few more questions....and a plan.
>
> 1. Why does commons-chain have a sample application called "mailreader"?
> This looks to be the same mailreader as the one in Struts.
I believe Joe's answer hits the nail on the head.
> 2. core doesn't compile with "ant dist" or "maven dist" due to half baked
> file structure changes. Specifically, the sample apps refer to TagUtils,
> which they can't find. How does the nightly run anyway?
It's failing at the moment. Phooey. I made local changes to get it
running, but it seems I omitted to actually commit those changes. I'll
try to fix that tonight.
> 3. What is the status of tiles? I though David Geary was extracting
> it from core and we would simply provide an integration library.
I think we're in limbo at the moment. I believe the current thinking
is that David G will bring his Struts-independence changes into the
fold, and Tiles will live as a subproject for a while, potentially
graduating to a TLP when it's "ready".
> Also, tiles/trunk seems to be a copy of core/trunk, is this correct?
> The tiles stuff seem to be under tiles/trunk.old
Dunno. That's a question for Don, I think, since he did the Tiles &
Taglibs extractions.
> [The plan (yes, I'm volunteering) ]
> So, unless someone says something, my plans are as follows:
> - move all the sample apps to a new "apps" subproject as follows:
> [-] trunk
> ' [-] blank
> ' ' [-] src
> ' ' [+] java (nothing in here right now)
> ' ' [+] resources
> ' ' [+] test
> ' ' [+] webapp
> ' '
> ' [-] example (mailreader)
> ' ' (needs to be merged with latest
> ' ' from several places)
> ' ' [-] src
> ' ' [+] java
> ' ' [+] resources
> ' ' [+] test
> ' ' [+] webapp
> ' '
> ' [-] examples
> ' ' (exercise, upload, validator)
> ' ' (i feel this should be renamed to 'modules')
> ' ' [-] src
> ' ' [+] java
> ' ' [+] resources
> ' ' [+] test
> ' ' [+] webapp
> ' '
> ' [-] test
> ' ' (really need to get this back in order
> ' ' or figure out a new strategy..more on
> ' ' this later)
Is this all taglibs tests right now? If so, perhaps it should live
under 'taglibs' instead of 'apps', since it isn't a "real"
application. If not, um, I dunno. This seems an odd place for tests.
> ' ' [-] src
> ' ' [+] java
> ' ' [+] resources
> ' ' [+] test
> ' ' [+] webapp
> ' '
> ' [-] tile-documentation
> ' ' (this should probably go to tiles/trunk)
Yup.
> ' ' [-] src
> ' ' [+] java
> ' ' [+] resources
> ' ' [+] test
> ' ' [+] webapp
You missed one. We also have 'struts-examples' directly under
'core/trunk', which has 'mailreader' in it. Just to complicate things,
this also has a different source structure.
We need to come up with one standard structure - we seem to have quite
a few at the moment. The sources go in different places, the config
files go in different places, etc. Not easy to follow at all.
> - merge the mailreader sample app (and tests) from commons-chain
> to struts "apps" (as indicated above)
Need to check the relationship between this mailreader and the one
under struts-examples.
> I would like all the apps/trunk/foo to be mavenized, and each project.xml
> creates a single .war file suitable for deployment. Each project
> would/should inherit from a parent project.xml under apps/trunk that can
> build the entire set of apps. So you can build any app you like, or just
> build them all. The build.xml file will be generated by maven (hopefully
> the path issues will be resolved).
Do you plan to do Maven builds for the other subprojects as well, or
just for the 'apps' subproject? Should I take the Ant build system off
my to-do list?
--
Martin Cooper
> So long as the version dependencies for each app point to published JARs,
> this should work fine. For those that have some new stuff, may require the
> developer do a 'maven install' from core/trunk of course (for dev builds).
> And as we move along with the different subprojects, each can keep up with
> the latest.
>
> >
> > --
> > Martin Cooper
> >
> >
>
> --
> 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 repository
Posted by James Mitchell <jm...@apache.org>.
Actually, I had bigger things in mind....well, sort of ;)
See intermixed.
----- Original Message -----
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Tuesday, January 11, 2005 12:19 PM
Subject: Re: svn repository
> On Tue, 11 Jan 2005 06:35:25 -0500, James Mitchell <jm...@apache.org>
> wrote:
>> Who is going to finish moving the directory structure?
>
> Whoever pitches in? ;-)
>
>> Right now, I can't load core as an Eclipse project because some of the
>> example apps rely on tiles, which relies on core. Creating a circular
>> reference as far as project dependencies goes.
>
> It should be easy enough to exclude the examples in your Eclipse
> project for now.
Yes, but that's actually what I am after.
>
>> I remember someone mentioning moving all the apps to an 'apps/trunk'
>> base.
>> Is that still going to happen?
>
> I had hoped to pull out the examples a couple of weekends ago, but the
> time didn't materialise as I had expected. It would be easy enough to
> pull them all out into an 'apps' subproject, but it's not quite as
> easy to get them all building again.
>
> However, if folks are OK with temporary breakage, I can pull them out
> tonight and leave them broken until the weekend, when I'll hopefully
> have time to make them build again. This sort of follows Ted's
> suggestion, from some time ago, to focus on getting Core into shape
> first and then clean up behind us after that.
Well, before you do that I have a few more questions....and a plan.
1. Why does commons-chain have a sample application called "mailreader"?
This looks to be the same mailreader as the one in Struts.
2. core doesn't compile with "ant dist" or "maven dist" due to half baked
file structure changes. Specifically, the sample apps refer to TagUtils,
which they can't find. How does the nightly run anyway?
3. What is the status of tiles? I though David Geary was extracting
it from core and we would simply provide an integration library.
Also, tiles/trunk seems to be a copy of core/trunk, is this correct?
The tiles stuff seem to be under tiles/trunk.old
[The plan (yes, I'm volunteering) ]
So, unless someone says something, my plans are as follows:
- move all the sample apps to a new "apps" subproject as follows:
[-] trunk
' [-] blank
' ' [-] src
' ' [+] java (nothing in here right now)
' ' [+] resources
' ' [+] test
' ' [+] webapp
' '
' [-] example (mailreader)
' ' (needs to be merged with latest
' ' from several places)
' ' [-] src
' ' [+] java
' ' [+] resources
' ' [+] test
' ' [+] webapp
' '
' [-] examples
' ' (exercise, upload, validator)
' ' (i feel this should be renamed to 'modules')
' ' [-] src
' ' [+] java
' ' [+] resources
' ' [+] test
' ' [+] webapp
' '
' [-] test
' ' (really need to get this back in order
' ' or figure out a new strategy..more on
' ' this later)
' ' [-] src
' ' [+] java
' ' [+] resources
' ' [+] test
' ' [+] webapp
' '
' [-] tile-documentation
' ' (this should probably go to tiles/trunk)
' ' [-] src
' ' [+] java
' ' [+] resources
' ' [+] test
' ' [+] webapp
- merge the mailreader sample app (and tests) from commons-chain
to struts "apps" (as indicated above)
I would like all the apps/trunk/foo to be mavenized, and each project.xml
creates a single .war file suitable for deployment. Each project
would/should inherit from a parent project.xml under apps/trunk that can
build the entire set of apps. So you can build any app you like, or just
build them all. The build.xml file will be generated by maven (hopefully
the path issues will be resolved).
So long as the version dependencies for each app point to published JARs,
this should work fine. For those that have some new stuff, may require the
developer do a 'maven install' from core/trunk of course (for dev builds).
And as we move along with the different subprojects, each can keep up with
the latest.
>
> --
> Martin Cooper
>
>
--
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 repository
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 11 Jan 2005 06:35:25 -0500, James Mitchell <jm...@apache.org> wrote:
> Who is going to finish moving the directory structure?
Whoever pitches in? ;-)
> Right now, I can't load core as an Eclipse project because some of the
> example apps rely on tiles, which relies on core. Creating a circular
> reference as far as project dependencies goes.
It should be easy enough to exclude the examples in your Eclipse
project for now.
> I remember someone mentioning moving all the apps to an 'apps/trunk' base.
> Is that still going to happen?
I had hoped to pull out the examples a couple of weekends ago, but the
time didn't materialise as I had expected. It would be easy enough to
pull them all out into an 'apps' subproject, but it's not quite as
easy to get them all building again.
However, if folks are OK with temporary breakage, I can pull them out
tonight and leave them broken until the weekend, when I'll hopefully
have time to make them build again. This sort of follows Ted's
suggestion, from some time ago, to focus on getting Core into shape
first and then clean up behind us after that.
--
Martin Cooper
>
> --
> 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