You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Steve Raeburn <sr...@apache.org> on 2003/07/21 07:21:16 UTC
Nightly build is generating empty binary distribution file
I've noticed that the nightly build is not generating the binary
distribution. There is an archive created but it's only 45 bytes.
<http://cvs.apache.org/builds/jakarta-struts/nightly/>
As the gump build is working it looks like a configuration problem is
preventing the files being copied/archived. Could this be to due to the
build version number change from 1.1 to 1.2?
I couldn't find any documentation on configuring the nightly build process
so I can't confirm or fix the problem. Can someone please take a look and/or
point me in the direction of some info on the nightly build config?
Thanks
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Tiles w/o JSP (was: Re: Building struts-legacy (was: ...)
Posted by Nathan Bubna <na...@esha.com>.
Ted Husted said:
> Craig R. McClanahan wrote:
> > Splitting Tiles and Validator is a little tougher if we go for the
> > previously popular idea of melding all the custom request processor
> > subclasses into a single one (since we don't have multiple inheritance and
> > don't have a decomposition solution yet - which is at least partly my
> > fault).
>
> Unless someone can show me how Tiles can be used without JSP, I would be
> tend to be -1 on integrating Tiles with the inner core, or making any
> other product changes that imply a specific presentation technology.
Ted, i'd love to hear your thoughts on this:
http://nagoya.apache.org/wiki/apachewiki.cgi?TilesTool
it's been offered as a contribution to the Velocity-Tools project. i'm
inclined to take it, but since i've never used Tiles (yet), i'm soliciting
other's opinions/evaluations. i am a little concerned that some of the Tiles
classes use things in the org.apache.struts.taglib.tiles package (e.g.
ComponentConstants). once the struts taglibs are separated from the core, i
don't want to keep a dependency on them.
...
> I'd be very much in favor of integrating something like Tiles as part
> of the request processor, so long as it is accessible to non-JSP
> technologies. But I'm not sure if we have that now.
agreed.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Splitting Tiles and Validator is a little tougher if we go for the
> previously popular idea of melding all the custom request processor
> subclasses into a single one (since we don't have multiple inheritance and
> don't have a decomposition solution yet - which is at least partly my
> fault).
Unless someone can show me how Tiles can be used without JSP, I would be
tend to be -1 on integrating Tiles with the inner core, or making any
other product changes that imply a specific presentation technology.
I am a great advocate of using Tiles on JSP projects, and the first
thing I do when using another presentation technology is reinvent Tiles.
I'd be very much in favor of integrating something like Tiles as part
of the request processor, so long as it is accessible to non-JSP
technologies. But I'm not sure if we have that now.
-Ted.
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 21 Jul 2003, Ted Husted wrote:
> Date: Mon, 21 Jul 2003 16:50:34 -0400
> From: Ted Husted <hu...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Building struts-legacy (was: Re: Nightly build is generating
> empty binary distribution file)
>
> Craig R. McClanahan wrote:
> > It wouldn't bother me to break the overall build for a while in order to
> > get this sorted out -- IMHO it's pretty broken already :-). But we might
> > also want to do a 1.2.0 first. Comments?
>
> I'd agree that we should do a 1.2.0 first to get the first round of
> patches and removed deprecations out-there.
>
> As Martin and David pointed out, with the idea of a default DataSource
> stricken from the 1.2.0 release, Struts-Legacy does not need to be part
> of the core Struts build. (Another good reason to do 1.2.0 and the fuss
> with the build.) It should be handled like the Commons packages.
>
> As part of the 1.2.0 release, we can also give notice that the taglibs
> will be moved from the core Struts JAR in a subsequent release, and then
> start monkeying with the build file for the next milestone.
>
> If it's practicable, I'd also suggest we consider putting Tiles and the
> Validator into an struts-optional JAR. So there would be
> struts-core.jar, struts-taglib.jar, and struts-optional.jar on the next
> milestone after 1.2.0. (Or just the two if optional is problematic now.)
Splitting Tiles and Validator is a little tougher if we go for the
previously popular idea of melding all the custom request processor
subclasses into a single one (since we don't have multiple inheritance and
don't have a decomposition solution yet - which is at least partly my
fault).
>
> -Ted.
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> It wouldn't bother me to break the overall build for a while in order to
> get this sorted out -- IMHO it's pretty broken already :-). But we might
> also want to do a 1.2.0 first. Comments?
I'd agree that we should do a 1.2.0 first to get the first round of
patches and removed deprecations out-there.
As Martin and David pointed out, with the idea of a default DataSource
stricken from the 1.2.0 release, Struts-Legacy does not need to be part
of the core Struts build. (Another good reason to do 1.2.0 and the fuss
with the build.) It should be handled like the Commons packages.
As part of the 1.2.0 release, we can also give notice that the taglibs
will be moved from the core Struts JAR in a subsequent release, and then
start monkeying with the build file for the next milestone.
If it's practicable, I'd also suggest we consider putting Tiles and the
Validator into an struts-optional JAR. So there would be
struts-core.jar, struts-taglib.jar, and struts-optional.jar on the next
milestone after 1.2.0. (Or just the two if optional is problematic now.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by Martin Cooper <ma...@apache.org>.
"David Graham" <gr...@yahoo.com> wrote in message
news:20030723170600.21229.qmail@web20707.mail.yahoo.com...
> --- Martin Cooper <ma...@apache.org> wrote:
> >
> > "Steve Peterson" <st...@zpfe.com> wrote in message
> > news:5.2.0.9.0.20030722073711.038b8be0@wheresmymailserver.com...
> > > While you are talking about updating the build, another small item for
> > the
> > > todo list would be to sync the version number assignment up with the
> > > now-project-standard a.b.c style release numbering. I have personally
> > seen
> > > some (small) confusion related to release 1.1.0 being stored in
> > > jakarta-struts-1.1.zip.
> >
> > The problem here, I think, is that we should not be referring to it as
> > 1.1.0
> > at all. The decision we made, unless I'm mistaken, is that we would
> > start to
> > use the 3-part numbering *after* Struts 1.1, not *with* Struts 1.1. So
> > there
> > is no 1.1.0 release.
>
> I'm a bit confused by this. Didn't we already have a 3 part numbering
> system with 1.0.1 and 1.0.2? 1.1.1 would be a bugfix release only;
> however, we decided to not do that and roll up any bug fixes +
> enhancements into 1.2.0.
We had three-part numbering, yes, but only for bug fix releases. But we had
1.0 and 1.1 for the regular releases, not 1.0.0 and 1.1.0. Going forward
from now, the plan is to always have three parts to the release number, even
for non-bug-fix-only releases, in a similar manner to Tomcat.
--
Martin Cooper
>
> David
>
> >
> > --
> > Martin Cooper
> >
> >
> > >
> > > S
> > >
> > > At 08:14 AM 7/22/2003 -0400, Ted Husted wrote:
> > > >Craig R. McClanahan wrote:
> > > >>Do we really want to wait that long? CAN we wait that long?
> > > >
> > > >How long is a piece of String. =:0)
> > > >
> > > >We can do a 1.2 release candidate this month, and then figure on
> > doing
> > 1.3
> > > >by the end of August.
> > > >
> > > >As long as week keep 1.x.x in evolutionary mode, I don't think we
> > need to
> > > >worry too much about maintaining branch for 1.#.x versus 1.#.x. In
> > > >practice, the 1.1 branch has been out-there for over a year, and it
> > seems
> > > >unlikely that any serious problems could be cured with a trivial
> > > >point-release fix. We just have to be careful to keep the HEAD
> > > >release-ready and whiteboard anything radical before merging it in.
> > > >
> > > >I have family coming in this week and can't volunteer to roll 1.2
> > myself
> > > >this weekend. But if no one beats me to it, I'd like to roll a 1.2
> > release
> > > >candidate the first weekend in August.
> > > >
> > > >-Ted.
> > > >
> > > >
> > > >
> > > >
> > > >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by David Graham <gr...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> wrote:
>
> "Steve Peterson" <st...@zpfe.com> wrote in message
> news:5.2.0.9.0.20030722073711.038b8be0@wheresmymailserver.com...
> > While you are talking about updating the build, another small item for
> the
> > todo list would be to sync the version number assignment up with the
> > now-project-standard a.b.c style release numbering. I have personally
> seen
> > some (small) confusion related to release 1.1.0 being stored in
> > jakarta-struts-1.1.zip.
>
> The problem here, I think, is that we should not be referring to it as
> 1.1.0
> at all. The decision we made, unless I'm mistaken, is that we would
> start to
> use the 3-part numbering *after* Struts 1.1, not *with* Struts 1.1. So
> there
> is no 1.1.0 release.
I'm a bit confused by this. Didn't we already have a 3 part numbering
system with 1.0.1 and 1.0.2? 1.1.1 would be a bugfix release only;
however, we decided to not do that and roll up any bug fixes +
enhancements into 1.2.0.
David
>
> --
> Martin Cooper
>
>
> >
> > S
> >
> > At 08:14 AM 7/22/2003 -0400, Ted Husted wrote:
> > >Craig R. McClanahan wrote:
> > >>Do we really want to wait that long? CAN we wait that long?
> > >
> > >How long is a piece of String. =:0)
> > >
> > >We can do a 1.2 release candidate this month, and then figure on
> doing
> 1.3
> > >by the end of August.
> > >
> > >As long as week keep 1.x.x in evolutionary mode, I don't think we
> need to
> > >worry too much about maintaining branch for 1.#.x versus 1.#.x. In
> > >practice, the 1.1 branch has been out-there for over a year, and it
> seems
> > >unlikely that any serious problems could be cured with a trivial
> > >point-release fix. We just have to be careful to keep the HEAD
> > >release-ready and whiteboard anything radical before merging it in.
> > >
> > >I have family coming in this week and can't volunteer to roll 1.2
> myself
> > >this weekend. But if no one beats me to it, I'd like to roll a 1.2
> release
> > >candidate the first weekend in August.
> > >
> > >-Ted.
> > >
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by Martin Cooper <ma...@apache.org>.
"Steve Peterson" <st...@zpfe.com> wrote in message
news:5.2.0.9.0.20030722073711.038b8be0@wheresmymailserver.com...
> While you are talking about updating the build, another small item for the
> todo list would be to sync the version number assignment up with the
> now-project-standard a.b.c style release numbering. I have personally
seen
> some (small) confusion related to release 1.1.0 being stored in
> jakarta-struts-1.1.zip.
The problem here, I think, is that we should not be referring to it as 1.1.0
at all. The decision we made, unless I'm mistaken, is that we would start to
use the 3-part numbering *after* Struts 1.1, not *with* Struts 1.1. So there
is no 1.1.0 release.
--
Martin Cooper
>
> S
>
> At 08:14 AM 7/22/2003 -0400, Ted Husted wrote:
> >Craig R. McClanahan wrote:
> >>Do we really want to wait that long? CAN we wait that long?
> >
> >How long is a piece of String. =:0)
> >
> >We can do a 1.2 release candidate this month, and then figure on doing
1.3
> >by the end of August.
> >
> >As long as week keep 1.x.x in evolutionary mode, I don't think we need to
> >worry too much about maintaining branch for 1.#.x versus 1.#.x. In
> >practice, the 1.1 branch has been out-there for over a year, and it seems
> >unlikely that any serious problems could be cured with a trivial
> >point-release fix. We just have to be careful to keep the HEAD
> >release-ready and whiteboard anything radical before merging it in.
> >
> >I have family coming in this week and can't volunteer to roll 1.2 myself
> >this weekend. But if no one beats me to it, I'd like to roll a 1.2
release
> >candidate the first weekend in August.
> >
> >-Ted.
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is
generating empty binary distribution file)
Posted by Steve Peterson <st...@zpfe.com>.
While you are talking about updating the build, another small item for the
todo list would be to sync the version number assignment up with the
now-project-standard a.b.c style release numbering. I have personally seen
some (small) confusion related to release 1.1.0 being stored in
jakarta-struts-1.1.zip.
S
At 08:14 AM 7/22/2003 -0400, Ted Husted wrote:
>Craig R. McClanahan wrote:
>>Do we really want to wait that long? CAN we wait that long?
>
>How long is a piece of String. =:0)
>
>We can do a 1.2 release candidate this month, and then figure on doing 1.3
>by the end of August.
>
>As long as week keep 1.x.x in evolutionary mode, I don't think we need to
>worry too much about maintaining branch for 1.#.x versus 1.#.x. In
>practice, the 1.1 branch has been out-there for over a year, and it seems
>unlikely that any serious problems could be cured with a trivial
>point-release fix. We just have to be careful to keep the HEAD
>release-ready and whiteboard anything radical before merging it in.
>
>I have family coming in this week and can't volunteer to roll 1.2 myself
>this weekend. But if no one beats me to it, I'd like to roll a 1.2 release
>candidate the first weekend in August.
>
>-Ted.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Do we really want to wait that long? CAN we wait that long?
How long is a piece of String. =:0)
We can do a 1.2 release candidate this month, and then figure on doing
1.3 by the end of August.
As long as week keep 1.x.x in evolutionary mode, I don't think we need
to worry too much about maintaining branch for 1.#.x versus 1.#.x. In
practice, the 1.1 branch has been out-there for over a year, and it
seems unlikely that any serious problems could be cured with a trivial
point-release fix. We just have to be careful to keep the HEAD
release-ready and whiteboard anything radical before merging it in.
I have family coming in this week and can't volunteer to roll 1.2 myself
this weekend. But if no one beats me to it, I'd like to roll a 1.2
release candidate the first weekend in August.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 21 Jul 2003, Martin Cooper wrote:
> > Decoupling this would probably be nice, but I don't think we're done if we
> > just fix that. I never thought I'd see a build environment more complex
> > than the one for Tomcat 4.1, but I think we've grown ourselves one :-(.
>
> I agree that we're not done by just decoupling legacy from the rest.
> However, that's what I would recommend for 1.2 and the 1.1 branch.
>
I think we need to live with the current world on the 1.1 branch, and
focus only on fixing the really nasty bugs (if any). For 1.2, decoupling
the build interdependencies make lots of sense.
> Beyond that, we've also talked about moving to a Maven based build. If we're
> going to make changes on the scale you suggest below, then I would far
> rather do that as part of a migration to Maven than do it independently,
> assuming we do decide to move to Maven. Otherwise, we run the risk of making
> life difficult for ourselves under Maven, and I, for one, don't relish the
> prospect of reorganising the code base more than once. ;-)
>
I'm +0 on using Maven (assuming someone will take the time to become our
build script expert), although I sorta wish they'd do a 1.0 final release
before we switched :-).
However, I don't think switching to Maven will do anything to detangle the
current mess of spaghetti -- that takes a more fundamental refactoring
that is almost independent of the build technology.
> While we're at it, this would also be a good time to reorganise the docs. If
> we move to Maven, then we should be able to take advantage of its
> site:generate and site:deploy targets, which would be very nice.
>
That's ok, although I'm sure not a fan of learning yet another templating
language when XSLT has served us quite well.
> Hmm. I'm beginning to think that perhaps 1.3 should be just an internal
> reorg release...
Do we really want to wait that long? CAN we wait that long?
>
> --
> Martin Cooper
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by Martin Cooper <ma...@apache.org>.
"Craig R. McClanahan" <cr...@apache.org> wrote in message
news:20030721121545.V97514@icarus.apache.org...
>
>
> On Mon, 21 Jul 2003, Martin Cooper wrote:
>
> >
> > Given that we have struts-legacy on its own release cycle, I think we
need
> > to decouple the struts-legacy build from the main Struts build. They
were
> > coupled shortly before the 1.1 final release, and that was a big pain
when I
> > was creating the release. I should be able to do 'ant clean dist' at the
top
> > level and point to an existing struts-legacy release, but I can't do
that
> > the way the builds are coupled right now.
> >
> > I could have just gone in and undone the coupling that was done (and I
still
> > could ;), but I'd like to understand why they are so tightly coupled
before
> > I do that. It seems not only unnecessary, but also highly undesirable,
> > especially when struts-legacy is independently released.
> >
>
> Decoupling this would probably be nice, but I don't think we're done if we
> just fix that. I never thought I'd see a build environment more complex
> than the one for Tomcat 4.1, but I think we've grown ourselves one :-(.
I agree that we're not done by just decoupling legacy from the rest.
However, that's what I would recommend for 1.2 and the 1.1 branch.
Beyond that, we've also talked about moving to a Maven based build. If we're
going to make changes on the scale you suggest below, then I would far
rather do that as part of a migration to Maven than do it independently,
assuming we do decide to move to Maven. Otherwise, we run the risk of making
life difficult for ourselves under Maven, and I, for one, don't relish the
prospect of reorganising the code base more than once. ;-)
While we're at it, this would also be a good time to reorganise the docs. If
we move to Maven, then we should be able to take advantage of its
site:generate and site:deploy targets, which would be very nice.
Hmm. I'm beginning to think that perhaps 1.3 should be just an internal
reorg release...
--
Martin Cooper
>
> Isn't it time to start splitting chunks of this into inddependently
> buildable subdirectories, and then create a top-level build.xml that only
> does the appropriate things in the appropriate order? An example might be
> to create a "core" subdirectory for the things we think would go into
> struts-core.jar (informally, it's probably what we have now minus the tag
> libraries but that's a detail). The directory structure might look like:
>
> core/
> build.xml Build for this chunk
> src/java/ Java sources
> dist/ Output directory for "dist" of this
> target/ Output directory for "main" of this
>
> and we can start splitting things up one chunk at a time. The most
> important concern is to minimize cross dependencies between the builds for
> each subdirectory. The next consideration is that they should all default
> up to a developer's own "build.properties" in the top-level directory,
> instead of having a "build.properties" for each subdirectory.
>
> From this line of thinking, packaging releases becomes a function of
> grabbing the "dist" output from the relevant top-level directories like
> "core/dist". We could also dispense with "contrib" as an artificial
> distinction, and just have all the individual components at the top level,
> then decide what goes into a standard Struts release in each release plan.
>
> It wouldn't bother me to break the overall build for a while in order to
> get this sorted out -- IMHO it's pretty broken already :-). But we might
> also want to do a 1.2.0 first. Comments?
>
> > --
> > Martin Cooper
>
> Craig
>
> (jdk.version=1.4 solved one problem, but I'm still struggling to tweak all
> the individual build.properties files to work in my environment)
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating
empty binary distribution file)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 21 Jul 2003, Martin Cooper wrote:
>
> Given that we have struts-legacy on its own release cycle, I think we need
> to decouple the struts-legacy build from the main Struts build. They were
> coupled shortly before the 1.1 final release, and that was a big pain when I
> was creating the release. I should be able to do 'ant clean dist' at the top
> level and point to an existing struts-legacy release, but I can't do that
> the way the builds are coupled right now.
>
> I could have just gone in and undone the coupling that was done (and I still
> could ;), but I'd like to understand why they are so tightly coupled before
> I do that. It seems not only unnecessary, but also highly undesirable,
> especially when struts-legacy is independently released.
>
Decoupling this would probably be nice, but I don't think we're done if we
just fix that. I never thought I'd see a build environment more complex
than the one for Tomcat 4.1, but I think we've grown ourselves one :-(.
Isn't it time to start splitting chunks of this into inddependently
buildable subdirectories, and then create a top-level build.xml that only
does the appropriate things in the appropriate order? An example might be
to create a "core" subdirectory for the things we think would go into
struts-core.jar (informally, it's probably what we have now minus the tag
libraries but that's a detail). The directory structure might look like:
core/
build.xml Build for this chunk
src/java/ Java sources
dist/ Output directory for "dist" of this
target/ Output directory for "main" of this
and we can start splitting things up one chunk at a time. The most
important concern is to minimize cross dependencies between the builds for
each subdirectory. The next consideration is that they should all default
up to a developer's own "build.properties" in the top-level directory,
instead of having a "build.properties" for each subdirectory.
>From this line of thinking, packaging releases becomes a function of
grabbing the "dist" output from the relevant top-level directories like
"core/dist". We could also dispense with "contrib" as an artificial
distinction, and just have all the individual components at the top level,
then decide what goes into a standard Struts release in each release plan.
It wouldn't bother me to break the overall build for a while in order to
get this sorted out -- IMHO it's pretty broken already :-). But we might
also want to do a 1.2.0 first. Comments?
> --
> Martin Cooper
Craig
(jdk.version=1.4 solved one problem, but I'm still struggling to tweak all
the individual build.properties files to work in my environment)
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by David Graham <gr...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> wrote:
>
> "Craig R. McClanahan" <cr...@apache.org> wrote in message
> news:20030720222156.D87771@icarus.apache.org...
> >
> >
> > On Sun, 20 Jul 2003, Steve Raeburn wrote:
> >
> > > Date: Sun, 20 Jul 2003 22:21:16 -0700
> > > From: Steve Raeburn <sr...@apache.org>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> > > sraeburn@apache.org
> > > To: Struts Developers List <st...@jakarta.apache.org>
> > > Subject: Nightly build is generating empty binary distribution file
> > >
> > > I've noticed that the nightly build is not generating the binary
> > > distribution. There is an archive created but it's only 45 bytes.
> > > <http://cvs.apache.org/builds/jakarta-struts/nightly/>
> > >
> > > As the gump build is working it looks like a configuration problem
> is
> > > preventing the files being copied/archived. Could this be to due to
> the
> > > build version number change from 1.1 to 1.2?
> > >
> > > I couldn't find any documentation on configuring the nightly build
> process
> > > so I can't confirm or fix the problem. Can someone please take a
> look
> and/or
> > > point me in the direction of some info on the nightly build config?
> > >
> >
> > It's running on my personal desktop (which recently went through a
> hard
> > disk failure and replacement). Unfortunately, I've only got JDK 1.4.2
> > installed right now, and compiling struts-legacy requires 1.3 or
> before to
> > compile :-(.
>
> Given that we have struts-legacy on its own release cycle, I think we
> need
> to decouple the struts-legacy build from the main Struts build. They
> were
> coupled shortly before the 1.1 final release, and that was a big pain
> when I
> was creating the release. I should be able to do 'ant clean dist' at the
> top
> level and point to an existing struts-legacy release, but I can't do
> that
> the way the builds are coupled right now.
>
> I could have just gone in and undone the coupling that was done (and I
> still
> could ;), but I'd like to understand why they are so tightly coupled
> before
> I do that. It seems not only unnecessary, but also highly undesirable,
> especially when struts-legacy is independently released.
Not only that, but struts-legacy was only provided for backwards
compatibility with 1.0.2. Now that 1.1 is out we should remove
struts-legacy and get out of the DataSource implementation business
altogether. I believe that was the original plan anyways.
David
>
> --
> Martin Cooper
>
>
> >
> > > Thanks
> > >
> > > Steve
> > >
> >
> > Craig
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Posted by Martin Cooper <ma...@apache.org>.
"Craig R. McClanahan" <cr...@apache.org> wrote in message
news:20030720222156.D87771@icarus.apache.org...
>
>
> On Sun, 20 Jul 2003, Steve Raeburn wrote:
>
> > Date: Sun, 20 Jul 2003 22:21:16 -0700
> > From: Steve Raeburn <sr...@apache.org>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> > sraeburn@apache.org
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Nightly build is generating empty binary distribution file
> >
> > I've noticed that the nightly build is not generating the binary
> > distribution. There is an archive created but it's only 45 bytes.
> > <http://cvs.apache.org/builds/jakarta-struts/nightly/>
> >
> > As the gump build is working it looks like a configuration problem is
> > preventing the files being copied/archived. Could this be to due to the
> > build version number change from 1.1 to 1.2?
> >
> > I couldn't find any documentation on configuring the nightly build
process
> > so I can't confirm or fix the problem. Can someone please take a look
and/or
> > point me in the direction of some info on the nightly build config?
> >
>
> It's running on my personal desktop (which recently went through a hard
> disk failure and replacement). Unfortunately, I've only got JDK 1.4.2
> installed right now, and compiling struts-legacy requires 1.3 or before to
> compile :-(.
Given that we have struts-legacy on its own release cycle, I think we need
to decouple the struts-legacy build from the main Struts build. They were
coupled shortly before the 1.1 final release, and that was a big pain when I
was creating the release. I should be able to do 'ant clean dist' at the top
level and point to an existing struts-legacy release, but I can't do that
the way the builds are coupled right now.
I could have just gone in and undone the coupling that was done (and I still
could ;), but I'd like to understand why they are so tightly coupled before
I do that. It seems not only unnecessary, but also highly undesirable,
especially when struts-legacy is independently released.
--
Martin Cooper
>
> > Thanks
> >
> > Steve
> >
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Nightly build is generating empty binary distribution file
Posted by Rob Leland <rl...@apache.org>.
Craig R. McClanahan wrote:
>On Sun, 20 Jul 2003, Steve Raeburn wrote:
>
>
>
>>Date: Sun, 20 Jul 2003 22:21:16 -0700
>>From: Steve Raeburn <sr...@apache.org>
>>Reply-To: Struts Developers List <st...@jakarta.apache.org>,
>> sraeburn@apache.org
>>To: Struts Developers List <st...@jakarta.apache.org>
>>Subject: Nightly build is generating empty binary distribution file
>>
>>I've noticed that the nightly build is not generating the binary
>>distribution. There is an archive created but it's only 45 bytes.
>><http://cvs.apache.org/builds/jakarta-struts/nightly/>
>>
>>As the gump build is working it looks like a configuration problem is
>>preventing the files being copied/archived. Could this be to due to the
>>build version number change from 1.1 to 1.2?
>>
>>I couldn't find any documentation on configuring the nightly build process
>>so I can't confirm or fix the problem. Can someone please take a look and/or
>>point me in the direction of some info on the nightly build config?
>>
>>
>>
>
>It's running on my personal desktop (which recently went through a hard
>disk failure and replacement). Unfortunately, I've only got JDK 1.4.2
>installed right now, and compiling struts-legacy requires 1.3 or before to
>compile :-(.
>
In the top level build.properties file set
jdk.version=1.4
and you'll be able to build.
-Rob
>
>
>
>>Thanks
>>
>>Steve
>>
>>
>>
>
>Craig
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
>
>
--
Rob Leland
RE: Nightly build is generating empty binary distribution file
Posted by Steve Raeburn <sr...@apache.org>.
Ok. Would it be worthwhile stopping the upload of the empty archive file and
placing a README file in the nightly directory explaining that "normal
service will be resumed shortly"?
Steve
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: July 20, 2003 10:24 PM
> To: Struts Developers List; sraeburn@apache.org
> Subject: Re: Nightly build is generating empty binary distribution file
>
>
>
>
> On Sun, 20 Jul 2003, Steve Raeburn wrote:
>
> > Date: Sun, 20 Jul 2003 22:21:16 -0700
> > From: Steve Raeburn <sr...@apache.org>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> > sraeburn@apache.org
> > To: Struts Developers List <st...@jakarta.apache.org>
> > Subject: Nightly build is generating empty binary distribution file
> >
> > I've noticed that the nightly build is not generating the binary
> > distribution. There is an archive created but it's only 45 bytes.
> > <http://cvs.apache.org/builds/jakarta-struts/nightly/>
> >
> > As the gump build is working it looks like a configuration problem is
> > preventing the files being copied/archived. Could this be to due to the
> > build version number change from 1.1 to 1.2?
> >
> > I couldn't find any documentation on configuring the nightly
> build process
> > so I can't confirm or fix the problem. Can someone please take
> a look and/or
> > point me in the direction of some info on the nightly build config?
> >
>
> It's running on my personal desktop (which recently went through a hard
> disk failure and replacement). Unfortunately, I've only got JDK 1.4.2
> installed right now, and compiling struts-legacy requires 1.3 or before to
> compile :-(.
>
> > Thanks
> >
> > Steve
> >
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Nightly build is generating empty binary distribution file
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 20 Jul 2003, Steve Raeburn wrote:
> Date: Sun, 20 Jul 2003 22:21:16 -0700
> From: Steve Raeburn <sr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> sraeburn@apache.org
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Nightly build is generating empty binary distribution file
>
> I've noticed that the nightly build is not generating the binary
> distribution. There is an archive created but it's only 45 bytes.
> <http://cvs.apache.org/builds/jakarta-struts/nightly/>
>
> As the gump build is working it looks like a configuration problem is
> preventing the files being copied/archived. Could this be to due to the
> build version number change from 1.1 to 1.2?
>
> I couldn't find any documentation on configuring the nightly build process
> so I can't confirm or fix the problem. Can someone please take a look and/or
> point me in the direction of some info on the nightly build config?
>
It's running on my personal desktop (which recently went through a hard
disk failure and replacement). Unfortunately, I've only got JDK 1.4.2
installed right now, and compiling struts-legacy requires 1.3 or before to
compile :-(.
> Thanks
>
> Steve
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org