struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Mitchell" <jmitch...@apache.org>
Subject Re: Adjustments to Struts Nightly Builds
Date Mon, 17 Jan 2005 19:10:57 GMT
> For these reasons, I think the uber-build, if we have one,
> should be kept very simple.

Would the uber-build also generate the global 'site' that glues all the 
other docs together?



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

----- Original Message ----- 
From: "Martin Cooper" <mfncooper@gmail.com>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Monday, January 17, 2005 2:05 PM
Subject: Re: Adjustments to Struts Nightly Builds


> On Mon, 17 Jan 2005 06:21:16 -0500, James Mitchell <jmitchell@apache.org> 
> wrote:
>> I was a bit disappointed last night while testing the Maven command
>> to generate an Ant build.xml.
>>
>> There were no hard coded paths (as you've experienced), but the
>> particular plugin that generates the build.xml is not as mature
>> (wrt multiproject builds) as I had assumed.
>>
>> No worries, I will put together a build that does (from current/apps)
>> everything that "maven apps:build-all" does from the same location.
>>
>> Note that maven target "apps:build-all" will probably change
>> shortly.  It will probably end up as "dist" to align with our
>> Ant build.  In core, build.xml will simply call apps/build.xml
>> with the same arguments, and apps/build.xml will (partly) take
>> over the job that build-webapps.xml used to have.
>
> We don't want 'core' building stuff in 'apps'. The 'core' subproject
> should not know about any other subprojects. As we discussed on
> another thread, any uber-build stuff we have should live in a 'build'
> pseudo-subproject, so that it's not part of any individual subproject.
>
> However, note that such an uber-build would serve only two purposes:
> (1) to make the nightly builds slightly simpler; (2) for the
> convenience of developers wanting to build everything. Since the
> subprojects will be independently released, we will not need an
> uber-build to handle the release process. For these reasons, I think
> the uber-build, if we have one, should be kept very simple.
>
> --
> Martin Cooper
>
>
>> Current/apps is progressing quite nicely right now.  I'm still
>> consolidating a few sets of duplicate code (partly due to my own
>> svn-newbie-ness and partly due to us actually _having_ duplicate
>> code out there).
>>
>> I've also moved the tiles stuff to tiles.
>>
>> There's still a lot of work to do to get us back to a clean distribution,
>> but I'm enjoying it so far.  I've got a lot on my todo list.
>>
>> Stay tuned for more...
>>
>> --
>> James Mitchell
>> Software Engineer / Open Source Evangelist
>> EdgeTech, Inc.
>> 678.910.8017
>> AIM: jmitchtx
>>
>> ----- Original Message -----
>> From: "Craig McClanahan" <craigmcc@gmail.com>
>> To: "Struts Developers List" <dev@struts.apache.org>
>> Sent: Monday, January 17, 2005 1:28 AM
>> Subject: Adjustments to Struts Nightly Builds
>>
>> > I've adjusted the scripts for the Struts nightly builds to use
>> > Martin's new "current" pseudo-project (thanks Martin!), to minimize
>> > problems in the face of all the restructuring that is currently going
>> > on.  As a side effect of this change, the source distribution for
>> > Struts will now contain all the sources in "current", instead of just
>> > the "core/trunk" part we used to get.  This seems to make more sense
>> > now that it's necessary to cross over all these subprojects in order
>> > to get a nightly binary.  However, the source distro is now
>> > substantially bigger (22mb versus 7.6mb).
>> >
>> > I'm also assuming that running "ant clean dist" in the "core" trunk is
>> > still the right command to build the nightly binary releases.  Let me
>> > know if you'd prefer something different.
>> >
>> > Craig
>> >
>> > ---------------------------------------------------------------------
>> > 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


Mime
View raw message