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: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
