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/02/17 20:27:20 UTC

Building Struts

With the move to svn and the shake up of the directory layout, we seem to be 
(more often than not) in a half-baked state.  I've been pushing hard trying 
to get most of the maven builds working.

So far, here's what works:  (this should work right now, unless I've 
forgotten to commit something)

$ cd path/to/your/local/struts/current/core
$ maven dist
$ cd ../taglib
$ maven dist
$ cd ../apps
$ maven dist
$ cd ../tiles
$ maven dist
$ cd ../el
$ maven dist
$ cd ../bsf
$ maven dist


Doing this yields several things:
 - newly built jars in your ${user.home}/.maven/repository/struts/jars
        struts-1.3.0-dev.jar
        struts-mailreader-dao-1.3.0-dev.jar
        struts-taglib-1.3.0-dev.jar
        struts-tiles-1.3.0-dev.jar

 - a full maven distribution in each subproject's target (or m-target) 
directories



My biggest complaint right now is with the way we are doing things and how 
much duplication we now have (and will have in the future) wrt maven and ant 
configuration.  Each subproject has it's own copy of project.properties, 
maven.xml, and 90% of each project.xml is repeated.  I've already wasted 
several hours trying to get these all in sync.  I am -1 for keeping each 
separate for the sake of seperation.

I prefer that we setup our maven project files to extend a single top 
project.xml under current/site/ (future), like it is done now in commons. 
This includes the CheckStyle config and license as well as other shared 
resources.



--
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: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 17 Feb 2005 16:36:31 -0500, Ted Husted <hu...@apache.org> wrote:
> On Thu, 17 Feb 2005 12:12:49 -0800, Martin Cooper wrote:
> > I am +1 on putting common build-related stuff in a common place,
> > but I am -1 on combining / confusing the notions of 'build' and
> > 'site'. IMO, we want:
> >
> > current/build: Shared build configuration, as you are describing.
> > current/site: All of the stuff for the root Struts web site, to
> > which subproject sites will "plug in" (when deployed).
> 
> Is there an advantage to having both /build and /site?

There are at least two that I can think of:

1) When someone is interested in building 'core', say, they need to
check out 'build' but they don't have to check out all of the root web
site docs, images and build system as well.

2) When we bundle the common build system in the subproject source
distros, as James was describing, we don't have to bundle the root web
site as well.

Of course, people could avoid (1) by checking out only a part of the
common subproject (if they knew to do that), and we could work around
(2) by extracting only the necessary files to bundle, but it would
just be simpler - and more transparent - if we have a 'build' place
for the build process and a 'site' place for the web site.

It would be very non-obvious to me to have to check out something
called 'site' to have to build some other subproject, and I would
expect lots of questions on the lists about that.

--
Martin Cooper


> Is there a reason why /site cannot play both roles?
> 
> The general use case would be that /site is the "integration" module, both in terms of subproject builds and subproject documentation/websites.
> 
> -T.
> 
> ---------------------------------------------------------------------
> 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: Building Struts

Posted by Ted Husted <hu...@apache.org>.
On Thu, 17 Feb 2005 12:12:49 -0800, Martin Cooper wrote:
>�I am +1 on putting common build-related stuff in a common place,
>�but I am -1 on combining / confusing the notions of 'build' and
>�'site'. IMO, we want:
>
>�current/build: Shared build configuration, as you are describing.
>�current/site: All of the stuff for the root Struts web site, to
>�which subproject sites will "plug in" (when deployed).

Is there an advantage to having both /build and /site?

Is there a reason why /site cannot play both roles?

The general use case would be that /site is the "integration" module, both in terms of subproject builds and subproject documentation/websites. 

-T.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 17 Feb 2005 14:27:20 -0500, James Mitchell <jm...@apache.org> wrote:
> With the move to svn and the shake up of the directory layout, we seem to be
> (more often than not) in a half-baked state.  I've been pushing hard trying
> to get most of the maven builds working.
> 
> So far, here's what works:  (this should work right now, unless I've
> forgotten to commit something)
> 
> $ cd path/to/your/local/struts/current/core
> $ maven dist
> $ cd ../taglib
> $ maven dist
> $ cd ../apps
> $ maven dist
> $ cd ../tiles
> $ maven dist
> $ cd ../el
> $ maven dist
> $ cd ../bsf
> $ maven dist
> 
> Doing this yields several things:
>  - newly built jars in your ${user.home}/.maven/repository/struts/jars
>         struts-1.3.0-dev.jar
>         struts-mailreader-dao-1.3.0-dev.jar
>         struts-taglib-1.3.0-dev.jar
>         struts-tiles-1.3.0-dev.jar
> 
>  - a full maven distribution in each subproject's target (or m-target)
> directories
> 
> My biggest complaint right now is with the way we are doing things and how
> much duplication we now have (and will have in the future) wrt maven and ant
> configuration.  Each subproject has it's own copy of project.properties,
> maven.xml, and 90% of each project.xml is repeated.  I've already wasted
> several hours trying to get these all in sync.  I am -1 for keeping each
> separate for the sake of seperation.
> 
> I prefer that we setup our maven project files to extend a single top
> project.xml under current/site/ (future), like it is done now in commons.
> This includes the CheckStyle config and license as well as other shared
> resources.

I am +1 on putting common build-related stuff in a common place, but I
am -1 on combining / confusing the notions of 'build' and 'site'. IMO,
we want:

current/build: Shared build configuration, as you are describing.
current/site: All of the stuff for the root Struts web site, to which
subproject sites will "plug in" (when deployed).

--
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: Building Struts

Posted by Ted Husted <hu...@apache.org>.
On Thu, 17 Feb 2005 20:07:14 -0800, Martin Cooper wrote:
>�struts-core-1.3.0-dev/
>� ��build/
>� ��core/
>� ������config/
>� ������src/
>� ������...
>
>�so introducing a 'core' directory that we would normally not have
>�in the distro. That's not necessarily a huge big deal, it just
>�seems a little odd. (But it does avoid the weirdness with mixing
>�levels in the distro, and it does let people build from the source
>�distro, and those are both Good Things. ;)

+1 for the "odd" layout. :)

-T.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 22 Feb 2005 09:49:52 +0100, Mark Lowe <me...@gmail.com> wrote:
> Sorry if this sound stupid, I cant find the url that svn requires to
> checkout shale et al.

http://struts.apache.org/acquiring.html#SourceCode

--
Martin Cooper


> I saw that someone mentioned flowscript unit
> testing, I'm working on a cocoon project and I'd like to see if
> there's a way of testing the flowscripts we have.
> 
> Mark
> 
> 
> On Mon, 21 Feb 2005 11:28:04 -0800, Don Brown <mr...@twdata.org> wrote:
> > Martin Cooper wrote:
> > <snip />
> > > OK, I've created a build subproject, with trunk / tags / branches,
> > > added it to 'current', and also added it to the following subprojects:
> > > apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
> > > flow, sandbox, shale. Certainly shale uses a separate build system,
> > > but should I go ahead and add it to flow and sandbox?
> >
> > Sure, flow's build was copied right from bsf.  Flow does have a custom
> > run-tests Ant task which uses a homegrown Javascript unit testing
> > framework.  It also has two other tasks for building the two example
> > applications.  I believe Maven can use Ant tasks, but I have no idea how.
> >
> > Thanks for the hard work.
> >
> > Don
> >
> > >
> > > I added a little README file that tries to explain what the deal is
> > > with this showing up in multiple places. With any luck, some people
> > > will actually read it. ;-)
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > >
> > >>--
> > >>James Mitchell
> > >>Software Engineer / Open Source Evangelist
> > >>EdgeTech, Inc.
> > >>678.910.8017
> > >>AIM: jmitchtx
> > >>
> > >>----- Original Message -----
> > >>From: "Martin Cooper" <mf...@gmail.com>
> > >>To: "Struts Developers List" <de...@struts.apache.org>
> > >>Sent: Sunday, February 20, 2005 3:13 AM
> > >>Subject: Re: Building Struts
> > >>
> > >>
> > >>>On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org>
> > >>>wrote:
> > >>>
> > >>>>That seems like quite a hack
> > >>>
> > >>>I'd be interested to hear why you feel this way. It's actually pretty
> > >>>much the exact scenario for which svn:externals were created, and, I
> > >>>think, somewhat more in line with the expected usage of that
> > >>>functionality that the whole 'current' thing is. ;-)
> > >>>
> > >>>--
> > >>>Martin Cooper
> > >>>
> > >>>
> > >>>
> > >>>>and going to be a bit awkward to the
> > >>>>unsuspecting user/developer.  But I honestly don't have a better option
> > >>>>right now.  I've already started the process of consolidating the various
> > >>>>common maven configuration stuff.  I'll be checking things in this
> > >>>>weekend
> > >>>>and next week.
> > >>>>
> > >>>>
> > >>>>--
> > >>>>James Mitchell
> > >>>>Software Engineer / Open Source Evangelist
> > >>>>EdgeTech, Inc.
> > >>>>678.910.8017
> > >>>>AIM: jmitchtx
> > >>>>
> > >>>>----- Original Message -----
> > >>>>From: "Martin Cooper" <mf...@gmail.com>
> > >>>>To: "Struts Developers List" <de...@struts.apache.org>
> > >>>>Sent: Saturday, February 19, 2005 1:03 PM
> > >>>>Subject: Re: Building Struts
> > >>>>
> > >>>>
> > >>>>>On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com>
> > >>>>>wrote:
> > >>>>>
> > >>>>>>I am not really familiar with svn:externals, but it sounds great.  I'm
> > >>>>>>not
> > >>>>>>100% sure that (2) is true, at least, if we're going to use maven dist
> > >>>>>>to
> > >>>>>>build distros.  But even if we have to do a little, it will be much
> > >>>>>>more
> > >>>>>>straightforward.
> > >>>>>
> > >>>>>Yes, you're right. We will need to tell Maven to include the build
> > >>>>>directory. But that should be pretty straightforward.
> > >>>>>
> > >>>>>If everyone's OK with this, I'll have a go at it tomorrow, if nobody
> > >>>>>beats me to it. (I'll be out all day today, starting about 5 minutes
> > >>>>>from now ;).
> > >>>>>
> > >>>>>--
> > >>>>>Martin Cooper
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>(for those who are interested:
> > >>>>>>Chapter 7. Advanced Topics: Externals Definitions
> > >>>>>>http://svnbook.red-bean.com/en/1.1/ch07s03.html
> > >>>>>>)
> > >>>>>>
> > >>>>>>
> > >>>>>>I'm +1 on this approach.  From the tail end of the page from the SVN
> > >>>>>>book,
> > >>>>>>it looks like we'll have to be conscious of some issues if we do any
> > >>>>>>future
> > >>>>>>repository re-orgs, but hopefully we won't have to.
> > >>>>>>
> > >>>>>>
> > >>>>>>Joe
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
> > >>>>>>By using svn:externals, we gain several things:
> > >>>>>>
> > >>>>>> 1) We get a "free" copy of 'build' along with each subproject,
> > >>>>>>meaning
> > >>>>>> that it doesn't have to be checked out separately to build one
> > >>>>>> subproject. Checking out 'core', for example, would be enough to
> > >>>>>>build
> > >>>>>> core.
> > >>>>>>
> > >>>>>> 2) The "free" copy means that we don't have to do anything special
> > >>>>>> when building the source distros, since the 'build' directory will
> > >>>>>> already be part of the checked out subproject when the distro is
> > >>>>>>being
> > >>>>>> created.
> > >>>>>>
> > >>>>>> 3) We don't have to mess with Maven properties to deal with two
> > >>>>>> different build scenarios (i.e. checked out vs. source distro).
> > >>>>>>
> > >>>>>> 4) It's really simple! :-)
> > >>>>>>
> > >>>>>> WDYT?
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>>
> > >>>>>>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
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>---------------------------------------------------------------------
> > >>>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
> >
> >
> 
> ---------------------------------------------------------------------
> 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: Building Struts

Posted by Don Brown <mr...@twdata.org>.
Regarding the flowscript unit tests, what I wrote was a small unit 
testing framework for testing the Java API extensions that I ported from 
Groovy to Javascript, and not flowscript per se.  You could probably 
adopt it or another more featured Javascript unit test framework to test 
flowscript, however, but it would take some work.

Don

Mark Lowe wrote:
> Sorry if this sound stupid, I cant find the url that svn requires to
> checkout shale et al. I saw that someone mentioned flowscript unit
> testing, I'm working on a cocoon project and I'd like to see if
> there's a way of testing the flowscripts we have.
> 
> Mark
> 
> 
> On Mon, 21 Feb 2005 11:28:04 -0800, Don Brown <mr...@twdata.org> wrote:
> 
>>Martin Cooper wrote:
>><snip />
>>
>>>OK, I've created a build subproject, with trunk / tags / branches,
>>>added it to 'current', and also added it to the following subprojects:
>>>apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
>>>flow, sandbox, shale. Certainly shale uses a separate build system,
>>>but should I go ahead and add it to flow and sandbox?
>>
>>Sure, flow's build was copied right from bsf.  Flow does have a custom
>>run-tests Ant task which uses a homegrown Javascript unit testing
>>framework.  It also has two other tasks for building the two example
>>applications.  I believe Maven can use Ant tasks, but I have no idea how.
>>
>>Thanks for the hard work.
>>
>>Don
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Mark Lowe <me...@gmail.com>.
Sorry if this sound stupid, I cant find the url that svn requires to
checkout shale et al. I saw that someone mentioned flowscript unit
testing, I'm working on a cocoon project and I'd like to see if
there's a way of testing the flowscripts we have.

Mark


On Mon, 21 Feb 2005 11:28:04 -0800, Don Brown <mr...@twdata.org> wrote:
> Martin Cooper wrote:
> <snip />
> > OK, I've created a build subproject, with trunk / tags / branches,
> > added it to 'current', and also added it to the following subprojects:
> > apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
> > flow, sandbox, shale. Certainly shale uses a separate build system,
> > but should I go ahead and add it to flow and sandbox?
> 
> Sure, flow's build was copied right from bsf.  Flow does have a custom
> run-tests Ant task which uses a homegrown Javascript unit testing
> framework.  It also has two other tasks for building the two example
> applications.  I believe Maven can use Ant tasks, but I have no idea how.
> 
> Thanks for the hard work.
> 
> Don
> 
> >
> > I added a little README file that tries to explain what the deal is
> > with this showing up in multiple places. With any luck, some people
> > will actually read it. ;-)
> >
> > --
> > Martin Cooper
> >
> >
> >
> >>--
> >>James Mitchell
> >>Software Engineer / Open Source Evangelist
> >>EdgeTech, Inc.
> >>678.910.8017
> >>AIM: jmitchtx
> >>
> >>----- Original Message -----
> >>From: "Martin Cooper" <mf...@gmail.com>
> >>To: "Struts Developers List" <de...@struts.apache.org>
> >>Sent: Sunday, February 20, 2005 3:13 AM
> >>Subject: Re: Building Struts
> >>
> >>
> >>>On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org>
> >>>wrote:
> >>>
> >>>>That seems like quite a hack
> >>>
> >>>I'd be interested to hear why you feel this way. It's actually pretty
> >>>much the exact scenario for which svn:externals were created, and, I
> >>>think, somewhat more in line with the expected usage of that
> >>>functionality that the whole 'current' thing is. ;-)
> >>>
> >>>--
> >>>Martin Cooper
> >>>
> >>>
> >>>
> >>>>and going to be a bit awkward to the
> >>>>unsuspecting user/developer.  But I honestly don't have a better option
> >>>>right now.  I've already started the process of consolidating the various
> >>>>common maven configuration stuff.  I'll be checking things in this
> >>>>weekend
> >>>>and next week.
> >>>>
> >>>>
> >>>>--
> >>>>James Mitchell
> >>>>Software Engineer / Open Source Evangelist
> >>>>EdgeTech, Inc.
> >>>>678.910.8017
> >>>>AIM: jmitchtx
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Martin Cooper" <mf...@gmail.com>
> >>>>To: "Struts Developers List" <de...@struts.apache.org>
> >>>>Sent: Saturday, February 19, 2005 1:03 PM
> >>>>Subject: Re: Building Struts
> >>>>
> >>>>
> >>>>>On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com>
> >>>>>wrote:
> >>>>>
> >>>>>>I am not really familiar with svn:externals, but it sounds great.  I'm
> >>>>>>not
> >>>>>>100% sure that (2) is true, at least, if we're going to use maven dist
> >>>>>>to
> >>>>>>build distros.  But even if we have to do a little, it will be much
> >>>>>>more
> >>>>>>straightforward.
> >>>>>
> >>>>>Yes, you're right. We will need to tell Maven to include the build
> >>>>>directory. But that should be pretty straightforward.
> >>>>>
> >>>>>If everyone's OK with this, I'll have a go at it tomorrow, if nobody
> >>>>>beats me to it. (I'll be out all day today, starting about 5 minutes
> >>>>>from now ;).
> >>>>>
> >>>>>--
> >>>>>Martin Cooper
> >>>>>
> >>>>>
> >>>>>
> >>>>>>(for those who are interested:
> >>>>>>Chapter 7. Advanced Topics: Externals Definitions
> >>>>>>http://svnbook.red-bean.com/en/1.1/ch07s03.html
> >>>>>>)
> >>>>>>
> >>>>>>
> >>>>>>I'm +1 on this approach.  From the tail end of the page from the SVN
> >>>>>>book,
> >>>>>>it looks like we'll have to be conscious of some issues if we do any
> >>>>>>future
> >>>>>>repository re-orgs, but hopefully we won't have to.
> >>>>>>
> >>>>>>
> >>>>>>Joe
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
> >>>>>>By using svn:externals, we gain several things:
> >>>>>>
> >>>>>> 1) We get a "free" copy of 'build' along with each subproject,
> >>>>>>meaning
> >>>>>> that it doesn't have to be checked out separately to build one
> >>>>>> subproject. Checking out 'core', for example, would be enough to
> >>>>>>build
> >>>>>> core.
> >>>>>>
> >>>>>> 2) The "free" copy means that we don't have to do anything special
> >>>>>> when building the source distros, since the 'build' directory will
> >>>>>> already be part of the checked out subproject when the distro is
> >>>>>>being
> >>>>>> created.
> >>>>>>
> >>>>>> 3) We don't have to mess with Maven properties to deal with two
> >>>>>> different build scenarios (i.e. checked out vs. source distro).
> >>>>>>
> >>>>>> 4) It's really simple! :-)
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>>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
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>---------------------------------------------------------------------
> >>>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
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
<snip />
> OK, I've created a build subproject, with trunk / tags / branches,
> added it to 'current', and also added it to the following subprojects:
> apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
> flow, sandbox, shale. Certainly shale uses a separate build system,
> but should I go ahead and add it to flow and sandbox?

Sure, flow's build was copied right from bsf.  Flow does have a custom 
run-tests Ant task which uses a homegrown Javascript unit testing 
framework.  It also has two other tasks for building the two example 
applications.  I believe Maven can use Ant tasks, but I have no idea how.

Thanks for the hard work.

Don

> 
> I added a little README file that tries to explain what the deal is
> with this showing up in multiple places. With any luck, some people
> will actually read it. ;-)
> 
> --
> Martin Cooper
> 
> 
> 
>>--
>>James Mitchell
>>Software Engineer / Open Source Evangelist
>>EdgeTech, Inc.
>>678.910.8017
>>AIM: jmitchtx
>>
>>----- Original Message -----
>>From: "Martin Cooper" <mf...@gmail.com>
>>To: "Struts Developers List" <de...@struts.apache.org>
>>Sent: Sunday, February 20, 2005 3:13 AM
>>Subject: Re: Building Struts
>>
>>
>>>On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org>
>>>wrote:
>>>
>>>>That seems like quite a hack
>>>
>>>I'd be interested to hear why you feel this way. It's actually pretty
>>>much the exact scenario for which svn:externals were created, and, I
>>>think, somewhat more in line with the expected usage of that
>>>functionality that the whole 'current' thing is. ;-)
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>>and going to be a bit awkward to the
>>>>unsuspecting user/developer.  But I honestly don't have a better option
>>>>right now.  I've already started the process of consolidating the various
>>>>common maven configuration stuff.  I'll be checking things in this
>>>>weekend
>>>>and next week.
>>>>
>>>>
>>>>--
>>>>James Mitchell
>>>>Software Engineer / Open Source Evangelist
>>>>EdgeTech, Inc.
>>>>678.910.8017
>>>>AIM: jmitchtx
>>>>
>>>>----- Original Message -----
>>>>From: "Martin Cooper" <mf...@gmail.com>
>>>>To: "Struts Developers List" <de...@struts.apache.org>
>>>>Sent: Saturday, February 19, 2005 1:03 PM
>>>>Subject: Re: Building Struts
>>>>
>>>>
>>>>>On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com>
>>>>>wrote:
>>>>>
>>>>>>I am not really familiar with svn:externals, but it sounds great.  I'm
>>>>>>not
>>>>>>100% sure that (2) is true, at least, if we're going to use maven dist
>>>>>>to
>>>>>>build distros.  But even if we have to do a little, it will be much
>>>>>>more
>>>>>>straightforward.
>>>>>
>>>>>Yes, you're right. We will need to tell Maven to include the build
>>>>>directory. But that should be pretty straightforward.
>>>>>
>>>>>If everyone's OK with this, I'll have a go at it tomorrow, if nobody
>>>>>beats me to it. (I'll be out all day today, starting about 5 minutes
>>>>>from now ;).
>>>>>
>>>>>--
>>>>>Martin Cooper
>>>>>
>>>>>
>>>>>
>>>>>>(for those who are interested:
>>>>>>Chapter 7. Advanced Topics: Externals Definitions
>>>>>>http://svnbook.red-bean.com/en/1.1/ch07s03.html
>>>>>>)
>>>>>>
>>>>>>
>>>>>>I'm +1 on this approach.  From the tail end of the page from the SVN
>>>>>>book,
>>>>>>it looks like we'll have to be conscious of some issues if we do any
>>>>>>future
>>>>>>repository re-orgs, but hopefully we won't have to.
>>>>>>
>>>>>>
>>>>>>Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
>>>>>>By using svn:externals, we gain several things:
>>>>>>
>>>>>> 1) We get a "free" copy of 'build' along with each subproject,
>>>>>>meaning
>>>>>> that it doesn't have to be checked out separately to build one
>>>>>> subproject. Checking out 'core', for example, would be enough to
>>>>>>build
>>>>>> core.
>>>>>>
>>>>>> 2) The "free" copy means that we don't have to do anything special
>>>>>> when building the source distros, since the 'build' directory will
>>>>>> already be part of the checked out subproject when the distro is
>>>>>>being
>>>>>> created.
>>>>>>
>>>>>> 3) We don't have to mess with Maven properties to deal with two
>>>>>> different build scenarios (i.e. checked out vs. source distro).
>>>>>>
>>>>>> 4) It's really simple! :-)
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>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
>>>>>
>>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>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: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 20 Feb 2005 23:26:00 -0500, James Mitchell <jm...@apache.org> wrote:
> Well, maybe not a 'hack' in the true sense of the word ;), but it will be
> weird having to commit and 'svn up' any change made in build/ to see it
> locally in the svn:external-ized build/ locations.  I know that won't have
> to happen very often once we are stable again, but it will cause a lot of
> confusion up front.
> 
> No matter how many times this gets discussed and reminded, someone will make
> a change to one of the build/ copies (not realizing it will affect them all)
> and effectively hose the entire build process till that change gets
> reverted. You can count on it.  Although that's not really enough to stop
> us from going ahead with it.
> 
> I am definitely -1 on having duplicate files and config stuff everywhere.
> Your suggestion is probably the best solution.
> 
> So, that said, let's move forward with it.  I've already made a lot of
> local changes that I'll have to fix, but it should be relatively painless.

OK, I've created a build subproject, with trunk / tags / branches,
added it to 'current', and also added it to the following subprojects:
apps, bsf, core, el, faces, taglib, tiles. I have *not* added it to:
flow, sandbox, shale. Certainly shale uses a separate build system,
but should I go ahead and add it to flow and sandbox?

I added a little README file that tries to explain what the deal is
with this showing up in multiple places. With any luck, some people
will actually read it. ;-)

--
Martin Cooper


> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> ----- Original Message -----
> From: "Martin Cooper" <mf...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Sunday, February 20, 2005 3:13 AM
> Subject: Re: Building Struts
> 
> > On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org>
> > wrote:
> >> That seems like quite a hack
> >
> > I'd be interested to hear why you feel this way. It's actually pretty
> > much the exact scenario for which svn:externals were created, and, I
> > think, somewhat more in line with the expected usage of that
> > functionality that the whole 'current' thing is. ;-)
> >
> > --
> > Martin Cooper
> >
> >
> >> and going to be a bit awkward to the
> >> unsuspecting user/developer.  But I honestly don't have a better option
> >> right now.  I've already started the process of consolidating the various
> >> common maven configuration stuff.  I'll be checking things in this
> >> weekend
> >> and next week.
> >>
> >>
> >> --
> >> James Mitchell
> >> Software Engineer / Open Source Evangelist
> >> EdgeTech, Inc.
> >> 678.910.8017
> >> AIM: jmitchtx
> >>
> >> ----- Original Message -----
> >> From: "Martin Cooper" <mf...@gmail.com>
> >> To: "Struts Developers List" <de...@struts.apache.org>
> >> Sent: Saturday, February 19, 2005 1:03 PM
> >> Subject: Re: Building Struts
> >>
> >> > On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com>
> >> > wrote:
> >> >>
> >> >> I am not really familiar with svn:externals, but it sounds great.  I'm
> >> >> not
> >> >> 100% sure that (2) is true, at least, if we're going to use maven dist
> >> >> to
> >> >> build distros.  But even if we have to do a little, it will be much
> >> >> more
> >> >> straightforward.
> >> >
> >> > Yes, you're right. We will need to tell Maven to include the build
> >> > directory. But that should be pretty straightforward.
> >> >
> >> > If everyone's OK with this, I'll have a go at it tomorrow, if nobody
> >> > beats me to it. (I'll be out all day today, starting about 5 minutes
> >> > from now ;).
> >> >
> >> > --
> >> > Martin Cooper
> >> >
> >> >
> >> >>
> >> >> (for those who are interested:
> >> >> Chapter 7. Advanced Topics: Externals Definitions
> >> >> http://svnbook.red-bean.com/en/1.1/ch07s03.html
> >> >> )
> >> >>
> >> >>
> >> >> I'm +1 on this approach.  From the tail end of the page from the SVN
> >> >> book,
> >> >> it looks like we'll have to be conscious of some issues if we do any
> >> >> future
> >> >> repository re-orgs, but hopefully we won't have to.
> >> >>
> >> >>
> >> >> Joe
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
> >> >> By using svn:externals, we gain several things:
> >> >>
> >> >>  1) We get a "free" copy of 'build' along with each subproject,
> >> >> meaning
> >> >>  that it doesn't have to be checked out separately to build one
> >> >>  subproject. Checking out 'core', for example, would be enough to
> >> >> build
> >> >>  core.
> >> >>
> >> >>  2) The "free" copy means that we don't have to do anything special
> >> >>  when building the source distros, since the 'build' directory will
> >> >>  already be part of the checked out subproject when the distro is
> >> >> being
> >> >>  created.
> >> >>
> >> >>  3) We don't have to mess with Maven properties to deal with two
> >> >>  different build scenarios (i.e. checked out vs. source distro).
> >> >>
> >> >>  4) It's really simple! :-)
> >> >>
> >> >>  WDYT?
> >> >>
> >> >>
> >> >>
> >> >>  --
> >> >>
> >> >> 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
> >> >
> >> >
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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: Building Struts

Posted by James Mitchell <jm...@apache.org>.
Well, maybe not a 'hack' in the true sense of the word ;), but it will be
weird having to commit and 'svn up' any change made in build/ to see it
locally in the svn:external-ized build/ locations.  I know that won't have
to happen very often once we are stable again, but it will cause a lot of
confusion up front.

No matter how many times this gets discussed and reminded, someone will make
a change to one of the build/ copies (not realizing it will affect them all)
and effectively hose the entire build process till that change gets
reverted. You can count on it.  Although that's not really enough to stop
us from going ahead with it.

I am definitely -1 on having duplicate files and config stuff everywhere.
Your suggestion is probably the best solution.

So, that said, let's move forward with it.  I've already made a lot of
local changes that I'll have to fix, but it should be relatively painless.



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message ----- 
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Sunday, February 20, 2005 3:13 AM
Subject: Re: Building Struts


> On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org>
> wrote:
>> That seems like quite a hack
>
> I'd be interested to hear why you feel this way. It's actually pretty
> much the exact scenario for which svn:externals were created, and, I
> think, somewhat more in line with the expected usage of that
> functionality that the whole 'current' thing is. ;-)
>
> --
> Martin Cooper
>
>
>> and going to be a bit awkward to the
>> unsuspecting user/developer.  But I honestly don't have a better option
>> right now.  I've already started the process of consolidating the various
>> common maven configuration stuff.  I'll be checking things in this
>> weekend
>> and next week.
>>
>>
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> EdgeTech, Inc.
>> 678.910.8017
>> AIM: jmitchtx
>>
>> ----- Original Message -----
>> From: "Martin Cooper" <mf...@gmail.com>
>> To: "Struts Developers List" <de...@struts.apache.org>
>> Sent: Saturday, February 19, 2005 1:03 PM
>> Subject: Re: Building Struts
>>
>> > On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com>
>> > wrote:
>> >>
>> >> I am not really familiar with svn:externals, but it sounds great.  I'm
>> >> not
>> >> 100% sure that (2) is true, at least, if we're going to use maven dist
>> >> to
>> >> build distros.  But even if we have to do a little, it will be much
>> >> more
>> >> straightforward.
>> >
>> > Yes, you're right. We will need to tell Maven to include the build
>> > directory. But that should be pretty straightforward.
>> >
>> > If everyone's OK with this, I'll have a go at it tomorrow, if nobody
>> > beats me to it. (I'll be out all day today, starting about 5 minutes
>> > from now ;).
>> >
>> > --
>> > Martin Cooper
>> >
>> >
>> >>
>> >> (for those who are interested:
>> >> Chapter 7. Advanced Topics: Externals Definitions
>> >> http://svnbook.red-bean.com/en/1.1/ch07s03.html
>> >> )
>> >>
>> >>
>> >> I'm +1 on this approach.  From the tail end of the page from the SVN
>> >> book,
>> >> it looks like we'll have to be conscious of some issues if we do any
>> >> future
>> >> repository re-orgs, but hopefully we won't have to.
>> >>
>> >>
>> >> Joe
>> >>
>> >>
>> >>
>> >>
>> >> At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
>> >> By using svn:externals, we gain several things:
>> >>
>> >>  1) We get a "free" copy of 'build' along with each subproject,
>> >> meaning
>> >>  that it doesn't have to be checked out separately to build one
>> >>  subproject. Checking out 'core', for example, would be enough to
>> >> build
>> >>  core.
>> >>
>> >>  2) The "free" copy means that we don't have to do anything special
>> >>  when building the source distros, since the 'build' directory will
>> >>  already be part of the checked out subproject when the distro is
>> >> being
>> >>  created.
>> >>
>> >>  3) We don't have to mess with Maven properties to deal with two
>> >>  different build scenarios (i.e. checked out vs. source distro).
>> >>
>> >>  4) It's really simple! :-)
>> >>
>> >>  WDYT?
>> >>
>> >>
>> >>
>> >>  --
>> >>
>> >> 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
>> >
>> >
>>
>>
>
> ---------------------------------------------------------------------
> 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: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 19 Feb 2005 15:04:34 -0500, James Mitchell <jm...@apache.org> wrote:
> That seems like quite a hack

I'd be interested to hear why you feel this way. It's actually pretty
much the exact scenario for which svn:externals were created, and, I
think, somewhat more in line with the expected usage of that
functionality that the whole 'current' thing is. ;-)

--
Martin Cooper


> and going to be a bit awkward to the
> unsuspecting user/developer.  But I honestly don't have a better option
> right now.  I've already started the process of consolidating the various
> common maven configuration stuff.  I'll be checking things in this weekend
> and next week.
> 
> 
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> ----- Original Message -----
> From: "Martin Cooper" <mf...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Saturday, February 19, 2005 1:03 PM
> Subject: Re: Building Struts
> 
> > On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >>
> >> I am not really familiar with svn:externals, but it sounds great.  I'm
> >> not
> >> 100% sure that (2) is true, at least, if we're going to use maven dist to
> >> build distros.  But even if we have to do a little, it will be much more
> >> straightforward.
> >
> > Yes, you're right. We will need to tell Maven to include the build
> > directory. But that should be pretty straightforward.
> >
> > If everyone's OK with this, I'll have a go at it tomorrow, if nobody
> > beats me to it. (I'll be out all day today, starting about 5 minutes
> > from now ;).
> >
> > --
> > Martin Cooper
> >
> >
> >>
> >> (for those who are interested:
> >> Chapter 7. Advanced Topics: Externals Definitions
> >> http://svnbook.red-bean.com/en/1.1/ch07s03.html
> >> )
> >>
> >>
> >> I'm +1 on this approach.  From the tail end of the page from the SVN
> >> book,
> >> it looks like we'll have to be conscious of some issues if we do any
> >> future
> >> repository re-orgs, but hopefully we won't have to.
> >>
> >>
> >> Joe
> >>
> >>
> >>
> >>
> >> At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
> >> By using svn:externals, we gain several things:
> >>
> >>  1) We get a "free" copy of 'build' along with each subproject, meaning
> >>  that it doesn't have to be checked out separately to build one
> >>  subproject. Checking out 'core', for example, would be enough to build
> >>  core.
> >>
> >>  2) The "free" copy means that we don't have to do anything special
> >>  when building the source distros, since the 'build' directory will
> >>  already be part of the checked out subproject when the distro is being
> >>  created.
> >>
> >>  3) We don't have to mess with Maven properties to deal with two
> >>  different build scenarios (i.e. checked out vs. source distro).
> >>
> >>  4) It's really simple! :-)
> >>
> >>  WDYT?
> >>
> >>
> >>
> >>  --
> >>
> >> 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
> >
> >
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by James Mitchell <jm...@apache.org>.
That seems like quite a hack and going to be a bit awkward to the 
unsuspecting user/developer.  But I honestly don't have a better option 
right now.  I've already started the process of consolidating the various 
common maven configuration stuff.  I'll be checking things in this weekend 
and next week.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message ----- 
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Saturday, February 19, 2005 1:03 PM
Subject: Re: Building Struts


> On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>>
>> I am not really familiar with svn:externals, but it sounds great.  I'm 
>> not
>> 100% sure that (2) is true, at least, if we're going to use maven dist to
>> build distros.  But even if we have to do a little, it will be much more
>> straightforward.
>
> Yes, you're right. We will need to tell Maven to include the build
> directory. But that should be pretty straightforward.
>
> If everyone's OK with this, I'll have a go at it tomorrow, if nobody
> beats me to it. (I'll be out all day today, starting about 5 minutes
> from now ;).
>
> --
> Martin Cooper
>
>
>>
>> (for those who are interested:
>> Chapter 7. Advanced Topics: Externals Definitions
>> http://svnbook.red-bean.com/en/1.1/ch07s03.html
>> )
>>
>>
>> I'm +1 on this approach.  From the tail end of the page from the SVN 
>> book,
>> it looks like we'll have to be conscious of some issues if we do any 
>> future
>> repository re-orgs, but hopefully we won't have to.
>>
>>
>> Joe
>>
>>
>>
>>
>> At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
>> By using svn:externals, we gain several things:
>>
>>  1) We get a "free" copy of 'build' along with each subproject, meaning
>>  that it doesn't have to be checked out separately to build one
>>  subproject. Checking out 'core', for example, would be enough to build
>>  core.
>>
>>  2) The "free" copy means that we don't have to do anything special
>>  when building the source distros, since the 'build' directory will
>>  already be part of the checked out subproject when the distro is being
>>  created.
>>
>>  3) We don't have to mess with Maven properties to deal with two
>>  different build scenarios (i.e. checked out vs. source distro).
>>
>>  4) It's really simple! :-)
>>
>>  WDYT?
>>
>>
>>
>>  -- 
>>
>> 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
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 19 Feb 2005 10:25:02 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>  
> I am not really familiar with svn:externals, but it sounds great.  I'm not
> 100% sure that (2) is true, at least, if we're going to use maven dist to
> build distros.  But even if we have to do a little, it will be much more
> straightforward. 

Yes, you're right. We will need to tell Maven to include the build
directory. But that should be pretty straightforward.

If everyone's OK with this, I'll have a go at it tomorrow, if nobody
beats me to it. (I'll be out all day today, starting about 5 minutes
from now ;).

--
Martin Cooper


>  
> (for those who are interested: 
> Chapter 7. Advanced Topics: Externals Definitions 
> http://svnbook.red-bean.com/en/1.1/ch07s03.html 
> ) 
> 
>  
> I'm +1 on this approach.  From the tail end of the page from the SVN book,
> it looks like we'll have to be conscious of some issues if we do any future
> repository re-orgs, but hopefully we won't have to. 
> 
>  
> Joe 
> 
>  
> 
>  
> At 7:43 AM -0800 2/19/05, Martin Cooper wrote: 
> By using svn:externals, we gain several things:
>  
>  1) We get a "free" copy of 'build' along with each subproject, meaning
>  that it doesn't have to be checked out separately to build one
>  subproject. Checking out 'core', for example, would be enough to build
>  core.
>  
>  2) The "free" copy means that we don't have to do anything special
>  when building the source distros, since the 'build' directory will
>  already be part of the checked out subproject when the distro is being
>  created.
>  
>  3) We don't have to mess with Maven properties to deal with two
>  different build scenarios (i.e. checked out vs. source distro).
>  
>  4) It's really simple! :-)
>  
>  WDYT? 
> 
>  
> 
>  -- 
>  
> 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: Building Struts

Posted by Joe Germuska <Jo...@Germuska.com>.
I am not really familiar with svn:externals, but it sounds great. 
I'm not 100% sure that (2) is true, at least, if we're going to use 
maven dist to build distros.  But even if we have to do a little, it 
will be much more straightforward.

(for those who are interested:
Chapter 7. Advanced Topics: Externals Definitions
http://svnbook.red-bean.com/en/1.1/ch07s03.html
)

I'm +1 on this approach.  From the tail end of the page from the SVN 
book, it looks like we'll have to be conscious of some issues if we 
do any future repository re-orgs, but hopefully we won't have to.

Joe


At 7:43 AM -0800 2/19/05, Martin Cooper wrote:
>By using svn:externals, we gain several things:
>
>1) We get a "free" copy of 'build' along with each subproject, meaning
>that it doesn't have to be checked out separately to build one
>subproject. Checking out 'core', for example, would be enough to build
>core.
>
>2) The "free" copy means that we don't have to do anything special
>when building the source distros, since the 'build' directory will
>already be part of the checked out subproject when the distro is being
>created.
>
>3) We don't have to mess with Maven properties to deal with two
>different build scenarios (i.e. checked out vs. source distro).
>
>4) It's really simple! :-)
>
>WDYT?


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

Re: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 18 Feb 2005 09:46:07 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 7:04 AM -0500 2/18/05, James Mitchell wrote:
> >
> >Ok, what about this:
> >
> >apps
> >bsf
> >struts-build/
> >  site/
> >  build/
> >core
> >el
> >faces
> >flow
> >sandbox
> >shale
> >site
> >taglib
> >tiles
> >
> >That would allow us to simply copy the nested build/ during the
> >source build of any specific subproject, and still allow the
> >relative references from struts-build/build/ to work (same for
> >site/).
> 
> I hope I'm not being obtuse, but I don't understand how this gets us
> what we want any more automatically than anything else, and I really
> don't like the way it "looks."
> 
> It is possible to use property expressions in POM files; maybe we could use:
> <extend>${struts.shared.pom.path}</extend>
> 
> I could imagine that maybe this is one place where the expressions
> can't be used since inheritance can also be used to resolve property
> values -- it will take just trying it to find out.
> 
> But, if it works, we could define the standard value in
> "project.properties" for each project:
> struts.shared.pom.path=../build/project.xml
> 
> Then as part of making the dist we could use maven.xml to copy the
> build directory into the dist as"./build" and copy in a
> "build.properties" file (which has priority over
> "project.properties") which specified the path to the distribution
> self-contained build-support files?
> 
> If the initial property-for-extend-path works, I think this would all
> come together, but it'll take some playing around.  I may have time
> to try it on Saturday, but if not, I'll be offline Sunday and Monday.
> If anyone else wants to give it a go, say so on the list.

This just gave me an even better idea (IMHO, at least ;). We do what I
had suggested before:

current/
    build/
    site/
    core/
    apps/
    ...

and then we use svn:externals to add 'build' to each of the
subprojects that need it. So when I check out 'core', I would see:

core/
    build/
    conf/
    src/
    ...

By using svn:externals, we gain several things:

1) We get a "free" copy of 'build' along with each subproject, meaning
that it doesn't have to be checked out separately to build one
subproject. Checking out 'core', for example, would be enough to build
core.

2) The "free" copy means that we don't have to do anything special
when building the source distros, since the 'build' directory will
already be part of the checked out subproject when the distro is being
created.

3) We don't have to mess with Maven properties to deal with two
different build scenarios (i.e. checked out vs. source distro).

4) It's really simple! :-)

WDYT?

--
Martin Cooper


> 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
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:04 AM -0500 2/18/05, James Mitchell wrote:
>
>Ok, what about this:
>
>apps
>bsf
>struts-build/
>  site/
>  build/
>core
>el
>faces
>flow
>sandbox
>shale
>site
>taglib
>tiles
>
>That would allow us to simply copy the nested build/ during the 
>source build of any specific subproject, and still allow the 
>relative references from struts-build/build/ to work (same for 
>site/).

I hope I'm not being obtuse, but I don't understand how this gets us 
what we want any more automatically than anything else, and I really 
don't like the way it "looks."

It is possible to use property expressions in POM files; maybe we could use:
<extend>${struts.shared.pom.path}</extend>

I could imagine that maybe this is one place where the expressions 
can't be used since inheritance can also be used to resolve property 
values -- it will take just trying it to find out.

But, if it works, we could define the standard value in 
"project.properties" for each project:
struts.shared.pom.path=../build/project.xml

Then as part of making the dist we could use maven.xml to copy the 
build directory into the dist as"./build" and copy in a 
"build.properties" file (which has priority over 
"project.properties") which specified the path to the distribution 
self-contained build-support files?

If the initial property-for-extend-path works, I think this would all 
come together, but it'll take some playing around.  I may have time 
to try it on Saturday, but if not, I'll be offline Sunday and Monday. 
If anyone else wants to give it a go, say so on the list.

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: Building Struts

Posted by James Mitchell <jm...@apache.org>.
Ok, what about this:

apps
bsf
struts-build/
  site/
  build/
core
el
faces
flow
sandbox
shale
site
taglib
tiles

That would allow us to simply copy the nested build/ during the source build 
of any specific subproject, and still allow the relative references from 
struts-build/build/ to work (same for site/).


> struts-core-1.3.0-dev/
>    build/
>    core/
>        config/
>        src/



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message ----- 
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, February 17, 2005 11:07 PM
Subject: Re: Building Struts


> On Thu, 17 Feb 2005 22:20:39 -0500, James Mitchell <jm...@apache.org> 
> wrote:
>> Right, sorry.
>>
>> If we don't want to include the build/ folder as a peer, then we can just
>> warn the user to go and fetch the src for that one as well (if not 
>> found).
>
> What I meant was that normally the subproject-level directory would
> not be a subdirectory of the distribution, so when you unzip the
> distro, you'd see something like this:
>
> struts-core-1.3.0-dev/
>    config/
>    src/
>    ...
>
> But if we include the build "subproject" in the distro, and have the
> structure above, we'd end up with this:
>
> struts-core-1.3.0-dev/
>    build/
>    config/
>    src/
>    ...
>
> which is "wrong" from a peer directory level, and wouldn't work
> without adjustment to the build files in one place or another. We'd
> have to include the original subproject directory in the distro as
> well to make this work. So that would mean:
>
> struts-core-1.3.0-dev/
>    build/
>    core/
>        config/
>        src/
>        ...
>
> so introducing a 'core' directory that we would normally not have in
> the distro. That's not necessarily a huge big deal, it just seems a
> little odd. (But it does avoid the weirdness with mixing levels in the
> distro, and it does let people build from the source distro, and those
> are both Good Things. ;)
>
> --
> Martin Cooper
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 17 Feb 2005 22:20:39 -0500, James Mitchell <jm...@apache.org> wrote:
> Right, sorry.
> 
> If we don't want to include the build/ folder as a peer, then we can just
> warn the user to go and fetch the src for that one as well (if not found).

What I meant was that normally the subproject-level directory would
not be a subdirectory of the distribution, so when you unzip the
distro, you'd see something like this:

struts-core-1.3.0-dev/
    config/
    src/
    ...

But if we include the build "subproject" in the distro, and have the
structure above, we'd end up with this:

struts-core-1.3.0-dev/
    build/
    config/
    src/
    ...

which is "wrong" from a peer directory level, and wouldn't work
without adjustment to the build files in one place or another. We'd
have to include the original subproject directory in the distro as
well to make this work. So that would mean:

struts-core-1.3.0-dev/
    build/
    core/
        config/
        src/
        ...

so introducing a 'core' directory that we would normally not have in
the distro. That's not necessarily a huge big deal, it just seems a
little odd. (But it does avoid the weirdness with mixing levels in the
distro, and it does let people build from the source distro, and those
are both Good Things. ;)

--
Martin Cooper


> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> ----- Original Message -----
> From: "Martin Cooper" <mf...@gmail.com>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Thursday, February 17, 2005 4:09 PM
> Subject: Re: Building Struts
> 
> > On Thu, 17 Feb 2005 15:48:13 -0500, James Mitchell <jm...@apache.org>
> > wrote:
> >> No, because the site/ directory would be included in the source
> >> distribution.
> >
> > You mean the build/ directory. ;-)
> >
> > This could be tricky, though, since in this case it would be inside of
> > the subproject directory rather than a peer of it, no?
> >
> > --
> > Martin Cooper
> >
> >
> >> --
> >> James Mitchell
> >> Software Engineer / Open Source Evangelist
> >> EdgeTech, Inc.
> >> 678.910.8017
> >> AIM: jmitchtx
> >>
> >> ----- Original Message -----
> >> From: "Joe Germuska" <Jo...@Germuska.com>
> >> To: "James Mitchell" <jm...@apache.org>; "Struts Developers List"
> >> <de...@struts.apache.org>
> >> Sent: Thursday, February 17, 2005 3:30 PM
> >> Subject: Re: Building Struts
> >>
> >> > At 3:09 PM -0500 2/17/05, James Mitchell wrote:
> >> >>>I think this is reasonable, but I'm not totally thrilled about the
> >> >>>fact
> >> >>>that you then cannot build the distributions with Maven.
> >> >>
> >> >>Sure we can, we just use the reactor and set the check style props to a
> >> >>relative path (say ../site/conf/qa/CheckStyle and
> >> >>../site/LICENSE.CheckStyle)
> >> >
> >> > I don't understand.  If I've just downloaded
> >> > struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go
> >> > into that directory and type"maven jar", what would happen? Wouldn't it
> >> > immediately fail when it tried to read the POM file because the
> >> > dependencies couldn't be found?
> >> >
> >> > 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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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: Building Struts

Posted by James Mitchell <jm...@apache.org>.
Right, sorry.

If we don't want to include the build/ folder as a peer, then we can just 
warn the user to go and fetch the src for that one as well (if not found).



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message ----- 
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, February 17, 2005 4:09 PM
Subject: Re: Building Struts


> On Thu, 17 Feb 2005 15:48:13 -0500, James Mitchell <jm...@apache.org> 
> wrote:
>> No, because the site/ directory would be included in the source
>> distribution.
>
> You mean the build/ directory. ;-)
>
> This could be tricky, though, since in this case it would be inside of
> the subproject directory rather than a peer of it, no?
>
> --
> Martin Cooper
>
>
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> EdgeTech, Inc.
>> 678.910.8017
>> AIM: jmitchtx
>>
>> ----- Original Message -----
>> From: "Joe Germuska" <Jo...@Germuska.com>
>> To: "James Mitchell" <jm...@apache.org>; "Struts Developers List"
>> <de...@struts.apache.org>
>> Sent: Thursday, February 17, 2005 3:30 PM
>> Subject: Re: Building Struts
>>
>> > At 3:09 PM -0500 2/17/05, James Mitchell wrote:
>> >>>I think this is reasonable, but I'm not totally thrilled about the 
>> >>>fact
>> >>>that you then cannot build the distributions with Maven.
>> >>
>> >>Sure we can, we just use the reactor and set the check style props to a
>> >>relative path (say ../site/conf/qa/CheckStyle and
>> >>../site/LICENSE.CheckStyle)
>> >
>> > I don't understand.  If I've just downloaded
>> > struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go
>> > into that directory and type"maven jar", what would happen? Wouldn't it
>> > immediately fail when it tried to read the POM file because the
>> > dependencies couldn't be found?
>> >
>> > 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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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: Building Struts

Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 17 Feb 2005 15:48:13 -0500, James Mitchell <jm...@apache.org> wrote:
> No, because the site/ directory would be included in the source
> distribution.

You mean the build/ directory. ;-)

This could be tricky, though, since in this case it would be inside of
the subproject directory rather than a peer of it, no?

--
Martin Cooper


> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> ----- Original Message -----
> From: "Joe Germuska" <Jo...@Germuska.com>
> To: "James Mitchell" <jm...@apache.org>; "Struts Developers List"
> <de...@struts.apache.org>
> Sent: Thursday, February 17, 2005 3:30 PM
> Subject: Re: Building Struts
> 
> > At 3:09 PM -0500 2/17/05, James Mitchell wrote:
> >>>I think this is reasonable, but I'm not totally thrilled about the fact
> >>>that you then cannot build the distributions with Maven.
> >>
> >>Sure we can, we just use the reactor and set the check style props to a
> >>relative path (say ../site/conf/qa/CheckStyle and
> >>../site/LICENSE.CheckStyle)
> >
> > I don't understand.  If I've just downloaded
> > struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go
> > into that directory and type"maven jar", what would happen? Wouldn't it
> > immediately fail when it tried to read the POM file because the
> > dependencies couldn't be found?
> >
> > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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: Building Struts

Posted by James Mitchell <jm...@apache.org>.
No, because the site/ directory would be included in the source 
distribution.



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

----- Original Message ----- 
From: "Joe Germuska" <Jo...@Germuska.com>
To: "James Mitchell" <jm...@apache.org>; "Struts Developers List" 
<de...@struts.apache.org>
Sent: Thursday, February 17, 2005 3:30 PM
Subject: Re: Building Struts


> At 3:09 PM -0500 2/17/05, James Mitchell wrote:
>>>I think this is reasonable, but I'm not totally thrilled about the fact 
>>>that you then cannot build the distributions with Maven.
>>
>>Sure we can, we just use the reactor and set the check style props to a 
>>relative path (say ../site/conf/qa/CheckStyle and 
>>../site/LICENSE.CheckStyle)
>
> I don't understand.  If I've just downloaded 
> struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and go 
> into that directory and type"maven jar", what would happen? Wouldn't it 
> immediately fail when it tried to read the POM file because the 
> dependencies couldn't be found?
>
> 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
>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: Building Struts

Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:09 PM -0500 2/17/05, James Mitchell wrote:
>>I think this is reasonable, but I'm not totally thrilled about the 
>>fact that you then cannot build the distributions with Maven.
>
>Sure we can, we just use the reactor and set the check style props 
>to a relative path (say ../site/conf/qa/CheckStyle and 
>../site/LICENSE.CheckStyle)

I don't understand.  If I've just downloaded 
struts-core-src-1.3.0-dev.tar.gz (or whatever), and I unpack it and 
go into that directory and type"maven jar", what would happen? 
Wouldn't it immediately fail when it tried to read the POM file 
because the dependencies couldn't be found?

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: Building Struts

Posted by James Mitchell <jm...@apache.org>.
> I think this is reasonable, but I'm not totally thrilled about the fact 
> that you then cannot build the distributions with Maven.

Sure we can, we just use the reactor and set the check style props to a 
relative path (say ../site/conf/qa/CheckStyle and 
../site/LICENSE.CheckStyle)

> Also, I don't use "current", although maybe I should, but I think it would 
> then be annoying that the relative paths to the shared files only works in 
> one of two possible SVN states.

No problem there either, we just run through a set of known paths and set 
the appropriate prop to match.
We would test for ../core, then ../../core/trunk, then svn.core.path, if 
still not found, then fail.

>
> I don't mean to say that it's better to have copies all over the place, 
> but these are things that have frustrated me about our options.
>
> Joe
>


The more I use Maven, the more I likes.  There are definitely some quirks, 
but I feel comfortable with it.

--
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: Building Struts

Posted by Joe Germuska <Jo...@Germuska.com>.
>My biggest complaint right now is with the way we are doing things 
>and how much duplication we now have (and will have in the future) 
>wrt maven and ant configuration.  Each subproject has it's own copy 
>of project.properties, maven.xml, and 90% of each project.xml is 
>repeated.  I've already wasted several hours trying to get these all 
>in sync.  I am -1 for keeping each separate for the sake of 
>seperation.
>
>I prefer that we setup our maven project files to extend a single 
>top project.xml under current/site/ (future), like it is done now in 
>commons. This includes the CheckStyle config and license as well as 
>other shared resources.

I think this is reasonable, but I'm not totally thrilled about the 
fact that you then cannot build the distributions with Maven.  Also, 
I don't use "current", although maybe I should, but I think it would 
then be annoying that the relative paths to the shared files only 
works in one of two possible SVN states.

I don't mean to say that it's better to have copies all over the 
place, but these are things that have frustrated me about our options.

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