You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <mf...@gmail.com> on 2004/12/24 23:43:31 UTC
Where should the build system live?
The new build system will consist of a few shared build files, and a
per-subproject build.xml file. This leads to the obvious question of
where the shared build files should live. There are basically two
options, as I see it:
1) In a 'build' subproject. This is the cleaner option, and the one I
prefer. It does mean that an additional subproject has be to checked
out, but that would be true for all but one subproject in any case,
and an independent 'build' subproject is pretty much guaranteed to be
a lot smaller than any other subproject.
2) In 'core'. The only advantage I see to putting the build system in
'core' is that a single checkout would be enough to build 'core'
itself. However, to build any other subproject, 'core' would need to
be checked out as well. The main disadvantage I see to this option is
that if another subproject comes along that we need to build before
'core', it would be icky to have that subproject depend on 'core' when
'core' depends on it. (This might sound like an unlikely scenario, but
I actually believe that's exactly what would happen if we bring
StrutsTestCase into the fold, since we'd need to build that before
'core' could be built and tested.)
So what do people think? My preference, as I said, is (1).
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Where should the build system live?
Posted by Vic <vi...@friendvu.com>.
Don Brown wrote:
> perhaps another neutral mock library should be used,
jMock. It lets you extend a class, then write tests in it.
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a coomunity
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Where should the build system live?
Posted by Deryl Seale <de...@acm.org>.
> Hmm..this raises an interesting issue. When you mention build
> dependencies, do you really mean build one project then another in the
> same process, or just that one project would depend on a jar from
> another? In the case of StrutsTestCase, 1) I don't like Core being
> dependent on a subproject, so perhaps another neutral mock library
> should be used, and 2) even if the Core build depended on
> StrutsTestCase, it would be the latter and use a jar.
>
> As for the build organization, I lean towards 1, but I don't really
> feel strongly one way or another.
StrutsTestCase could easily be split into the mock servlet classes, and
the testing framework itself. The latter could be included in the core
package, and since the testing framework would depend on the core
package, I think the dependencies would be satisfied.
-d.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Where should the build system live?
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 25 Dec 2004 00:42:13 -0800, Don Brown <mr...@twdata.org> wrote:
> Martin Cooper wrote:
> > The new build system will consist of a few shared build files, and a
> > per-subproject build.xml file. This leads to the obvious question of
> > where the shared build files should live. There are basically two
> > options, as I see it:
> >
> > 1) In a 'build' subproject. This is the cleaner option, and the one I
> > prefer. It does mean that an additional subproject has be to checked
> > out, but that would be true for all but one subproject in any case,
> > and an independent 'build' subproject is pretty much guaranteed to be
> > a lot smaller than any other subproject.
> >
> > 2) In 'core'. The only advantage I see to putting the build system in
> > 'core' is that a single checkout would be enough to build 'core'
> > itself. However, to build any other subproject, 'core' would need to
> > be checked out as well. The main disadvantage I see to this option is
> > that if another subproject comes along that we need to build before
> > 'core', it would be icky to have that subproject depend on 'core' when
> > 'core' depends on it. (This might sound like an unlikely scenario, but
> > I actually believe that's exactly what would happen if we bring
> > StrutsTestCase into the fold, since we'd need to build that before
> > 'core' could be built and tested.)
>
> Hmm..this raises an interesting issue. When you mention build
> dependencies, do you really mean build one project then another in the
> same process, or just that one project would depend on a jar from
> another?
Originally, I had been thinking of just the latter. However, James
Mitchell's message requesting that we call him crazy ;-) got me
thinking about the possibility of handling the former as well. We at
least need some scheme for avoiding the need to build everything
independently, as James's message demonstrates.
--
Martin Cooper
> In the case of StrutsTestCase, 1) I don't like Core being
> dependent on a subproject, so perhaps another neutral mock library
> should be used, and 2) even if the Core build depended on
> StrutsTestCase, it would be the latter and use a jar.
>
> As for the build organization, I lean towards 1, but I don't really feel
> strongly one way or another.
>
> Don
>
> >
> > So what do people think? My preference, as I said, is (1).
> >
> > --
> > Martin Cooper
> >
> > ---------------------------------------------------------------------
> > 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: Where should the build system live?
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
> The new build system will consist of a few shared build files, and a
> per-subproject build.xml file. This leads to the obvious question of
> where the shared build files should live. There are basically two
> options, as I see it:
>
> 1) In a 'build' subproject. This is the cleaner option, and the one I
> prefer. It does mean that an additional subproject has be to checked
> out, but that would be true for all but one subproject in any case,
> and an independent 'build' subproject is pretty much guaranteed to be
> a lot smaller than any other subproject.
>
> 2) In 'core'. The only advantage I see to putting the build system in
> 'core' is that a single checkout would be enough to build 'core'
> itself. However, to build any other subproject, 'core' would need to
> be checked out as well. The main disadvantage I see to this option is
> that if another subproject comes along that we need to build before
> 'core', it would be icky to have that subproject depend on 'core' when
> 'core' depends on it. (This might sound like an unlikely scenario, but
> I actually believe that's exactly what would happen if we bring
> StrutsTestCase into the fold, since we'd need to build that before
> 'core' could be built and tested.)
Hmm..this raises an interesting issue. When you mention build
dependencies, do you really mean build one project then another in the
same process, or just that one project would depend on a jar from
another? In the case of StrutsTestCase, 1) I don't like Core being
dependent on a subproject, so perhaps another neutral mock library
should be used, and 2) even if the Core build depended on
StrutsTestCase, it would be the latter and use a jar.
As for the build organization, I lean towards 1, but I don't really feel
strongly one way or another.
Don
>
> So what do people think? My preference, as I said, is (1).
>
> --
> Martin Cooper
>
> ---------------------------------------------------------------------
> 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: Where should the build system live?
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
> I'm fine with (1).
>
> As to things like Struts TestCase, if we decide to adopt it, then I'd suggest that it be part of the Core itself.
>
> Once you start using something like this, it becomes integral to development. The benefit of bringing in Struts TestCase, rather than just snagging it from SourceForge, is to keep it synched with any changes to the Core. If TestCase is a separate subproject, then we start to miss the point.
>
> Although we've talked about TestCase as a subproject, I think it would be a better fit as a package in the Core.
I agree, that would make things a _lot_ easier.
Don
>
> -Ted.
>
> On Fri, 24 Dec 2004 14:43:31 -0800, Martin Cooper wrote:
>
>> The new build system will consist of a few shared build files, and
>> a per-subproject build.xml file. This leads to the obvious question
>> of where the shared build files should live. There are basically
>> two options, as I see it:
>>
>> 1) In a 'build' subproject. This is the cleaner option, and the one
>> I prefer. It does mean that an additional subproject has be to
>> checked out, but that would be true for all but one subproject in
>> any case, and an independent 'build' subproject is pretty much
>> guaranteed to be a lot smaller than any other subproject.
>>
>> 2) In 'core'. The only advantage I see to putting the build system
>> in 'core' is that a single checkout would be enough to build 'core'
>> itself. However, to build any other subproject, 'core' would need
>> to be checked out as well. The main disadvantage I see to this
>> option is that if another subproject comes along that we need to
>> build before 'core', it would be icky to have that subproject
>> depend on 'core' when 'core' depends on it. (This might sound like
>> an unlikely scenario, but I actually believe that's exactly what
>> would happen if we bring StrutsTestCase into the fold, since we'd
>> need to build that before 'core' could be built and tested.)
>>
>> So what do people think? My preference, as I said, is (1).
>>
>> --
>> Martin Cooper
>>
>> --------------------------------------------------------------------
>> - 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: Where should the build system live?
Posted by Ted Husted <hu...@apache.org>.
I'm fine with (1).
As to things like Struts TestCase, if we decide to adopt it, then I'd suggest that it be part of the Core itself.
Once you start using something like this, it becomes integral to development. The benefit of bringing in Struts TestCase, rather than just snagging it from SourceForge, is to keep it synched with any changes to the Core. If TestCase is a separate subproject, then we start to miss the point.
Although we've talked about TestCase as a subproject, I think it would be a better fit as a package in the Core.
-Ted.
On Fri, 24 Dec 2004 14:43:31 -0800, Martin Cooper wrote:
>�The new build system will consist of a few shared build files, and
>�a per-subproject build.xml file. This leads to the obvious question
>�of where the shared build files should live. There are basically
>�two options, as I see it:
>
>�1) In a 'build' subproject. This is the cleaner option, and the one
>�I prefer. It does mean that an additional subproject has be to
>�checked out, but that would be true for all but one subproject in
>�any case, and an independent 'build' subproject is pretty much
>�guaranteed to be a lot smaller than any other subproject.
>
>�2) In 'core'. The only advantage I see to putting the build system
>�in 'core' is that a single checkout would be enough to build 'core'
>�itself. However, to build any other subproject, 'core' would need
>�to be checked out as well. The main disadvantage I see to this
>�option is that if another subproject comes along that we need to
>�build before 'core', it would be icky to have that subproject
>�depend on 'core' when 'core' depends on it. (This might sound like
>�an unlikely scenario, but I actually believe that's exactly what
>�would happen if we bring StrutsTestCase into the fold, since we'd
>�need to build that before 'core' could be built and tested.)
>
>�So what do people think? My preference, as I said, is (1).
>
>�--
>�Martin Cooper
>
>�--------------------------------------------------------------------
>�- 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