On Mon, 17 Jan 2005 14:10:57 -0500, James Mitchell <[EMAIL PROTECTED]> wrote: > > 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?
I believe we decided that that would come out of a 'site' pseudo-subproject. I still think that's the right place for it. -- Martin Cooper > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > ----- Original Message ----- > From: "Martin Cooper" <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > > 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" <[EMAIL PROTECTED]> > >> 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: [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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
