You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Turner <tu...@blackbear.com> on 2003/05/28 19:38:10 UTC
Status check?
Ok folks, things have been mighty quiet lately here. So I'm going to
summerize where I think things are right now:
1) Struts core is basically ready to go, and the dependency on the
latest version of DBCP has been removed
2) What we're waiting on is the final release of FileUpload, which
Martin is working on.
Can we get a status check on FileUpload? It would be mighty nice to get
RC2 out before JavaOne.
James Turner
Director of Software Development
Benefit Systems, Inc.
turner@blackbear.com
Track Chair, Strategic Open Source
2003 Fall COMDEX
Author:
MySQL & JSP Web Applications
Struts Kick Start
JavaServer Faces Kick Start
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> I have been building the releases using J2SE 1.4 for some time now, and I
> would recommend sticking with that. Going with 1.4 ensures we get the
> benefits of the latest compiler improvements. The compatibility issue is
> with the JVM rather than the compiler - we want to be able to run on J2SE
> 1.2, but we don't need to build the releases with that.
Works for me. I'll just confirm that we still build under 1.2-1.4, as
alleged by the installation page.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
"Ted Husted" <hu...@apache.org> wrote in message
news:3EE0BDA1.7060309@apache.org...
> Our installation page says our dependency is J2SE 1.2 or later.
>
> Does that mean I should compile the binary distribution under the latest
> J2SE 1.2, or should I use the latest J2SE 1.4?
I have been building the releases using J2SE 1.4 for some time now, and I
would recommend sticking with that. Going with 1.4 ensures we get the
benefits of the latest compiler improvements. The compatibility issue is
with the JVM rather than the compiler - we want to be able to run on J2SE
1.2, but we don't need to build the releases with that.
--
Martin Cooper
>
> I'm installing 1.2 now, to at least be sure it still builds (as I
> remember, the nightlies are building on Craig's machine under 1.4).
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Our installation page says our dependency is J2SE 1.2 or later.
Does that mean I should compile the binary distribution under the latest
J2SE 1.2, or should I use the latest J2SE 1.4?
I'm installing 1.2 now, to at least be sure it still builds (as I
remember, the nightlies are building on Craig's machine under 1.4).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 4 Jun 2003, Ted Husted wrote:
> Date: Wed, 04 Jun 2003 14:25:15 -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: Status check?
>
>
> Martin Cooper wrote:
> > OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
> > updated the web site, but it's there.
> >
> > The Tomcat build did indeed break, and interested parties can see the
> > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
> > for their support.
>
> Excellent. I'm blocking out Friday morning to work on releasing
> struts-legacy and then RC2. I assume it's OK with everyone if we just
> update the RC1 plan and work from that.
>
>From a planning perspective, this sounds fine.
On a release date, is anyone going to believe any date we publish in the
plan, no matter what it is? :-)
I do think we should say something like "two weeks after RC2, barring any
major bugs" so that we can encourage people to actually try RC2 in that
time frame.
> -Ted.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Status check?
Posted by James Turner <tu...@blackbear.com>.
Good for me. Since the intent is for RC2 to go final after testing and
a FileUpload Final, do we want to set a date for Struts 1.1 final?
Think we can have RC2 live before we head off for SF? It would be a
nice trophy to bring to JavaOne, especially with a target release date
for Final.
James
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Wednesday, June 04, 2003 2:25 PM
> To: Struts Developers List
> Subject: Re: Status check?
>
>
>
> Martin Cooper wrote:
> > OK, FileUpload 1.0 RC1 is out. I haven't done the
> announcement yet, or
> > updated the web site, but it's there.
> >
> > The Tomcat build did indeed break, and interested parties
> can see the
> > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and
> > Joe for their support.
>
> Excellent. I'm blocking out Friday morning to work on releasing
> struts-legacy and then RC2. I assume it's OK with everyone if we just
> update the RC1 plan and work from that.
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
> updated the web site, but it's there.
>
> The Tomcat build did indeed break, and interested parties can see the
> resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
> for their support.
Excellent. I'm blocking out Friday morning to work on releasing
struts-legacy and then RC2. I assume it's OK with everyone if we just
update the RC1 plan and work from that.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 31 May 2003, Martin Cooper wrote:
>
> "Ted Husted" <hu...@apache.org> wrote in message
> news:3F0075A9.4020205@apache.org...
> > Martin Cooper wrote:
> > > Now, about the Struts 1.1 RC2 release. The problem is the staging
> > > needed to get FileUpload out the door. It's currently at Beta 1, and
> > > the code base in CVS has some methods that have been deprecated since
> > > Beta 1. The deprecated methods need to be removed before 1.0 Final,
> > > which means that we need a Beta 2 to publicise the deprecations. Then
> > > they can be removed in an RC1, shortly to be followed (hopefully) by
> > > 1.0 Final.
> >
> > So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2
> > this weekend, I can then cut RC2 with that, if you like.
>
> The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).)
> So it's just a matter of what release this will be, and what to do about the
> deprecated methods. Then I can send out the vote.
OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
updated the web site, but it's there.
The Tomcat build did indeed break, and interested parties can see the
resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
for their support.
--
Martin Cooper
>
> >
> > I'm going to release the struts-generic package first thing in the
> > morning, and move the nightly build dependencies over to that, so we can
> > then just plug in the latest FileUpload.
> >
> > IMHO, you might consider taking FileUpload straight to RC1. It's
> > unreleased software and API changes are to be expected. If this were FU
> > 2.0, and you were removing something that was in FU 1.0's established
> > API, it would be different. But greater latitude as to API changes
> > should be given to unreleased, pre-1.0 packages.
>
> So you're suggesting that I rip out the deprecated methods now, go for RC1,
> and damn the torpedoes that the API is incompatible between Beta 1 and RC1,
> and there was no warning (other than nightly builds)? You really think
> that's OK?
>
> Gump builds for Tomcat and Turbine will start failing as soon as I remove
> the deprecated methods. Tapestry won't be affected, since Mr. Tapestry
> doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts
> already has the necessary changes.
>
> --
> Martin Cooper
>
>
> >
> > If you were to go to FileUpload RC1, then perhaps Struts and FileUpload
> > can then go to final together.
> >
> > -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> So you're suggesting that I rip out the deprecated methods now, go for RC1,
> and damn the torpedoes that the API is incompatible between Beta 1 and RC1,
> and there was no warning (other than nightly builds)? You really think
> that's OK?
>
> Gump builds for Tomcat and Turbine will start failing as soon as I remove
> the deprecated methods. Tapestry won't be affected, since Mr. Tapestry
> doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts
> already has the necessary changes.
The question is what's best for the community. From what you say, these
methods are already doomed. It's just a matter of whether they fix the
dependency now or a fortnight from now. (Or just stick with whatever JAR
they are already using.)
Yes, Gump may break. That's why we have Gump. =:) Sam did not create
Gump to chain us, but to free us to make changes. When Gump breaks
people get the heads-up that they need to make changes themselves.
(Before they *voluntarily* elect to use the new version.)
And, I agree with David. We've been taking backward compatibility
between betas way too seriously. In the case of Struts, our betas have
languished so long that it did become prudent for us to take that into
account. They became de-facto releases. But I don't agree that as a rule
we have to maintain full backward compatibility between betas *and*
between final releases. Otherwise, why even have betas?
When the software is released, you have established an API contract. But
a beta is not a contract, it is a *proposed* contract, and subject to
change until we "sign on the dotted line" and cut a final release.
Personally, I don't think anyone will be astonished that things change
in an unreleased product between betas. If they are, then maybe they
should step up to bat and give you a hand with what is supposed to be a
community-supported product.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Max Cooper <ma...@maxcooper.com>.
I have been struggling with this for another project, too. Ideally, it would
be great to have a "continuous integration" build that would also deploy and
test the app(s) in a bunch of containers automatically. You'd still have to
install and configure some deployment details, of course, but it would be
nice to have a machine with a bunch of containers on it that would run and
test builds in all of them automatically. I imagine the same system could be
used to deploy to a developer's favorite container or containers for local
testing on a much smaller scale.
Are there any projects out there intended to make it easier to test the same
app(s) in a variety of containers?
-Max
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Friday, June 06, 2003 3:39 PM
Subject: Re: Status check?
> Martin Cooper wrote:
> > For the main Struts release, the most time-consuming part is just
testing
> > that everything works with all the supported containers (including all
the
> > web apps).
>
> So, I take it we would be satisfied with testing our sample applications
> against the binary distribution (rather than against all the
> permutations of Java 1.2, 1.3, 1.4, and Servlet 2.2 and 2.3).
>
> And then for Cactus, I take it we would run TC 3.3 against Servlet 2.2,
> and TC 4.x against Servlet 2.3, as that would be the expected use.
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> For the main Struts release, the most time-consuming part is just testing
> that everything works with all the supported containers (including all the
> web apps).
So, I take it we would be satisfied with testing our sample applications
against the binary distribution (rather than against all the
permutations of Java 1.2, 1.3, 1.4, and Servlet 2.2 and 2.3).
And then for Cactus, I take it we would run TC 3.3 against Servlet 2.2,
and TC 4.x against Servlet 2.3, as that would be the expected use.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Martin Cooper wrote:
> > http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
> >
> > I added the section on PGP 8.0 Freeware, since that's what I use, but you
> > can also use GPG, which I think is installed on daedalus. The MD5 tool is
> > definitely installed on daedalus, since that's where I create the digests
> > for Struts releases.
> >
> > If you're still having trouble, you could put the zip and tar.gz bundles
> > in your home directory on cvs and give me access, and I can create the
> > sigs and upload them, if you want.
>
> OK, I admittedly haven't even tried signing these, but I still need to
> pack. =:) I uploaded struts-legacy to my home directory on
> cvs.apache.org. Could you could sign these for me, Martin?
>
> There aren't any lib files, since this distribution is nothing but lib :)
Did you mean by this that the struts-legacy-1.0-lib.* files are empty? I
just noticed that they are, which is why I'm asking. If that's supposed to
be the case, then we don't need to have them in the distribution. ;-)
--
Martin Cooper
>
> (Really loving that release target!)
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o.
> I've created the .asc signature files, and the .md5 digest files, but only
> for the .tar.gz and .zip files, since we don't usually release the .tar
> files. (They're only needed to produce the .tar.gz files.)
OK, got 'em. Thanks!
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Martin Cooper wrote:
> > You'll find everything ready to go at ~martinc/struts-legacy on
> > cvs.a.o. I've created the .asc signature files, and the .md5 digest
> > files, but only for the .tar.gz and .zip files, since we don't usually
> > release the .tar files. (They're only needed to produce the .tar.gz
> > files.)
>
> OK, I've made the changes regarding the DBPC/Pool dependencies, and play
> tested the new build in an application that exercises the datasource,
> along with the Tiles and the Validator -- all systems nominal!
>
> I can do the stock Tomcat testing in the morning, and, should everything
> pass, we can tag this puppy and ship it!
>
> (If anyone wants to be the Release Test Manager, jump in now! There's a
> working candidate at http://cvs.apache.org/~husted/ - This is a preview
> only - it is *not* the final RC! but it's what we want to test.)
>
> Assuming the rest is done, Martin, old friend, will you be around
> tomorrow at mid-day to sign the Struts jar for me?
If you mean mid-day EDT, yes, I should be around then. By mid-day PDT,
though, I'll be out at a lunch appointment. So the earlier you're ready,
the better. ;-)
--
Martin Cooper
>
> (I promise to get setup to do signing for next time.)
>
> -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: Status check?
Posted by Vic Cekvenich <vi...@baseBeans.com>.
SNIP:
Ted Husted wrote:
There's a
> working candidate at http://cvs.apache.org/~husted/ - This is a preview
> only - it is *not* the final RC! but it's what we want to test.)
I downloaded and it apears to work with a sample app of mine, just FYI.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Vic Cekvenich wrote:
> I downloaded and it apears to work with a sample app of mine, just
> FYI.
Phil Steitz wrote:
> Ted,
>
> Don't know if this is useful, but I did the following successfully:
>
> 1. Hack build.xml to remove "compile.library" depends for tomcat, junit
> test targets.
>
> 2. Replace contents of <my local cvs co>/target/library with
> jararta-struts-1.1-rc2-lib
>
> 3. execute test.tomcat.all and test.junit targets using the hacked
> build.xml. All tests ran clean and no compile targets were executed.
>
> I do not have tc 3 installed, so only the 40 and 41 tc tests ran,
> hitting tc 4.04 and 4.1.24 resp. I ran once using (Sun Linux) JDK
> 1.4.1_01 and once using JDK 1.3.1_03.
Thanks, guys. More eyes always help. =:)
I'll have some (liquid) java and run through the standard suite now, and
then we can ship this puppy!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Phil Steitz <ph...@steitz.com>.
Ted Husted wrote:
> Martin Cooper wrote:
> > You'll find everything ready to go at ~martinc/struts-legacy on
> > cvs.a.o. I've created the .asc signature files, and the .md5 digest
> > files, but only for the .tar.gz and .zip files, since we don't usually
> > release the .tar files. (They're only needed to produce the .tar.gz
> > files.)
>
> OK, I've made the changes regarding the DBPC/Pool dependencies, and play
> tested the new build in an application that exercises the datasource,
> along with the Tiles and the Validator -- all systems nominal!
>
> I can do the stock Tomcat testing in the morning, and, should everything
> pass, we can tag this puppy and ship it!
>
> (If anyone wants to be the Release Test Manager, jump in now! There's a
> working candidate at http://cvs.apache.org/~husted/ - This is a preview
> only - it is *not* the final RC! but it's what we want to test.)
>
> Assuming the rest is done, Martin, old friend, will you be around
> tomorrow at mid-day to sign the Struts jar for me?
>
> (I promise to get setup to do signing for next time.)
>
> -Ted.
>
>
Ted,
Don't know if this is useful, but I did the following successfully:
1. Hack build.xml to remove "compile.library" depends for tomcat, junit
test targets.
2. Replace contents of <my local cvs co>/target/library with
jararta-struts-1.1-rc2-lib
3. execute test.tomcat.all and test.junit targets using the hacked
build.xml. All tests ran clean and no compile targets were executed.
I do not have tc 3 installed, so only the 40 and 41 tc tests ran,
hitting tc 4.04 and 4.1.24 resp. I ran once using (Sun Linux) JDK
1.4.1_01 and once using JDK 1.3.1_03.
hth,
Phil
>
>
>
>
> ---------------------------------------------------------------------
> 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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> You'll find everything ready to go at ~martinc/struts-legacy on
> cvs.a.o. I've created the .asc signature files, and the .md5 digest
> files, but only for the .tar.gz and .zip files, since we don't usually
> release the .tar files. (They're only needed to produce the .tar.gz
> files.)
OK, I've made the changes regarding the DBPC/Pool dependencies, and play
tested the new build in an application that exercises the datasource,
along with the Tiles and the Validator -- all systems nominal!
I can do the stock Tomcat testing in the morning, and, should everything
pass, we can tag this puppy and ship it!
(If anyone wants to be the Release Test Manager, jump in now! There's a
working candidate at http://cvs.apache.org/~husted/ - This is a preview
only - it is *not* the final RC! but it's what we want to test.)
Assuming the rest is done, Martin, old friend, will you be around
tomorrow at mid-day to sign the Struts jar for me?
(I promise to get setup to do signing for next time.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Martin Cooper wrote:
> > http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
> >
> > I added the section on PGP 8.0 Freeware, since that's what I use, but you
> > can also use GPG, which I think is installed on daedalus. The MD5 tool is
> > definitely installed on daedalus, since that's where I create the digests
> > for Struts releases.
> >
> > If you're still having trouble, you could put the zip and tar.gz bundles
> > in your home directory on cvs and give me access, and I can create the
> > sigs and upload them, if you want.
>
> OK, I admittedly haven't even tried signing these, but I still need to
> pack. =:) I uploaded struts-legacy to my home directory on
> cvs.apache.org. Could you could sign these for me, Martin?
You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o.
I've created the .asc signature files, and the .md5 digest files, but only
for the .tar.gz and .zip files, since we don't usually release the .tar
files. (They're only needed to produce the .tar.gz files.)
--
Martin Cooper
>
> There aren't any lib files, since this distribution is nothing but lib :)
>
> (Really loving that release target!)
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
>
> I added the section on PGP 8.0 Freeware, since that's what I use, but you
> can also use GPG, which I think is installed on daedalus. The MD5 tool is
> definitely installed on daedalus, since that's where I create the digests
> for Struts releases.
>
> If you're still having trouble, you could put the zip and tar.gz bundles
> in your home directory on cvs and give me access, and I can create the
> sigs and upload them, if you want.
OK, I admittedly haven't even tried signing these, but I still need to
pack. =:) I uploaded struts-legacy to my home directory on
cvs.apache.org. Could you could sign these for me, Martin?
There aren't any lib files, since this distribution is nothing but lib :)
(Really loving that release target!)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> If you're still having trouble, you could put the zip and tar.gz bundles
> in your home directory on cvs and give me access, and I can create the
> sigs and upload them, if you want.
I might do that. It's turning into a tough week, and I still have a lot
do before catching a plane on Monday, which isn't always the best time
to try something new =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Tue, 3 Jun 2003, Ted Husted wrote:
> If anyone had a mind to, it would be really great to have the Struts
> News and Resources pages updated this week, before the next RC. There's
> been a bunch of stuff announced on the list lately. (If not, I'll try to
> do it before we go to final release.)
>
> I'm still getting my head around the release procedures [never signed a
> JAR before, except with a marker =:)], but do hope to have it sorted out
> by Friday or Saturday.
You shouldn't have to sign any jars - we haven't done that for Struts
before. The only things I sign for the releases are the zip and tar.gz
bundles. There's a page on the Wiki that might help you with that:
http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases
I added the section on PGP 8.0 Freeware, since that's what I use, but you
can also use GPG, which I think is installed on daedalus. The MD5 tool is
definitely installed on daedalus, since that's where I create the digests
for Struts releases.
If you're still having trouble, you could put the zip and tar.gz bundles
in your home directory on cvs and give me access, and I can create the
sigs and upload them, if you want.
--
Martin Cooper
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
If anyone had a mind to, it would be really great to have the Struts
News and Resources pages updated this week, before the next RC. There's
been a bunch of stuff announced on the list lately. (If not, I'll try to
do it before we go to final release.)
I'm still getting my head around the release procedures [never signed a
JAR before, except with a marker =:)], but do hope to have it sorted out
by Friday or Saturday.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> I'll take care of tagging our dependencies once RC2 is out.
Hey, if setting CVS tags is something you like to do, more power to you,
brother =:)
But don't forget to tag ORO too, not to mention the jdbc2_0-stdext.jar
and Servlet JAR =:) We also have external dependencies on them, just as
we have *external* dependencies on the Commons JARs.
But, for the record, I'm planning on building the distribution from that
same possibly erroneous document that you will later use to set the
tags. So if the document is wrong, everything else will be wrong too.
If compiling our distribution from JARs distributed by another CVS is
not acceptable to the team, and I totally misunderstand the point of
sending these packages to the Commons in the first place, then please
let me know now, and I'll pass the baton.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
"Ted Husted" <hu...@apache.org> wrote in message
news:3EE0C61B.8080808@apache.org...
> Martin Cooper wrote:
> > The tagging for the main Struts release will actually be a bit more
> > painful for RC2 since you can't just blanket-tag the Commons packages -
> > they'll have to be tagged individually to match the specific versions
> > we're bundling.
>
> I can understand why we tagged the Commons packages when we were
> building betas against the nightly builds, but now that we are basing
> our RCs on Final Releases or other Release Candidates, tagging the
> Commons CVS seems futile and dangerous. Don't they already have tags for
> the versions upon which we have declared our dependency? And, I'd have
> to be sure I had the release version checked-out (some of which are
> months old now) rather than the current trunk.
I disagree that it is either futile or dangerous.
It is useful because you can, at some point in time, just do a CVS checkout
using the appropriate Struts tag and get everything you need to build that
version of Struts. That way, you don't have to refer to a (possibly
erroneous) document to look up which versions you need to get.
It isn't dangerous, because you can simply ask CVS to tag the code for a
specific version of a Commons component with the relevant Struts tag. It
could be dangerous if it was done off a local code base rather than tagging
CVS against CVS itself, but that's not necessary.
I'll take care of tagging our dependencies once RC2 is out.
--
Martin Cooper
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> The tagging for the main Struts release will actually be a bit more
> painful for RC2 since you can't just blanket-tag the Commons packages -
> they'll have to be tagged individually to match the specific versions
> we're bundling.
I can understand why we tagged the Commons packages when we were
building betas against the nightly builds, but now that we are basing
our RCs on Final Releases or other Release Candidates, tagging the
Commons CVS seems futile and dangerous. Don't they already have tags for
the versions upon which we have declared our dependency? And, I'd have
to be sure I had the release version checked-out (some of which are
months old now) rather than the current trunk.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> Incidentally, I noticed that the installation page still references DBCP
> and Pool, and the build file is still including those jars in the build.
> We obviously need to fix those before the release. Let me know if you'd
> like me to take care of either of those.
I'm trying to run my integration tests again before releasing the final
version of Struts-Legacy JAR. But, the Struts 1.1 RC1 version of my
isn't connecting to my database right now, and I don't know why.
I'm going to bring the Struts 1.02 version back up, to make sure that
works, and then change my local CVS to use RC2 with Struts-Legacy, and
plug that into the Struts 1.1 version of the same app, then see if that
tests OK. If it does (which it did before), we can release Struts-Legacy
and then RC2.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Martin Cooper wrote:
> > I'm actually in the middle of adding that now. ;-) I remember you asked me
> > a while ago to make sure we list the explicit versions we use.
> >
> > The "What's Included" section seems like the logical place. My only
> > concern is that, because of the length of the "RC/Beta Fixes" section,
> > it's quite far down the page. But I don't know where else I would put
> > it...
>
> It would be best to carry the explicit list on the installation page
>
> installation.html
>
> as we always have, and then add a cross-reference from the Release
> Notes, to remind people where to find it. =;)
The list on the installation page refers to what you need if you want to
build Struts from source, rather than what is bundled with Struts itself.
They're similar, but not identical, since in the former, we refer to
"version 123 or later", whereas in the latter, we need to specify an exact
version. I'd actually prefer to put the list in the "What's Included" and
then change the installation page to say that you need to build against
what's included with Struts, or a later version, and have the link point
the other way.
Since I'm already done adding the list to the release notes, I'll go ahead
and check that in, but feel free to move it if you'd prefer.
Incidentally, I noticed that the installation page still references DBCP
and Pool, and the build file is still including those jars in the build.
We obviously need to fix those before the release. Let me know if you'd
like me to take care of either of those.
--
Martin Cooper
>
> We might also mention that the packages are also cited in the
> build.properties.sample file.
>
> But, we should avoid keeping the actual list in a third place =:)
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> I'm actually in the middle of adding that now. ;-) I remember you asked me
> a while ago to make sure we list the explicit versions we use.
>
> The "What's Included" section seems like the logical place. My only
> concern is that, because of the length of the "RC/Beta Fixes" section,
> it's quite far down the page. But I don't know where else I would put
> it...
It would be best to carry the explicit list on the installation page
installation.html
as we always have, and then add a cross-reference from the Release
Notes, to remind people where to find it. =;)
We might also mention that the packages are also cited in the
build.properties.sample file.
But, we should avoid keeping the actual list in a third place =:)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 7 Jun 2003, Craig R. McClanahan wrote:
>
>
> On Sat, 7 Jun 2003, Ted Husted wrote:
>
> > Date: Sat, 07 Jun 2003 14:25:23 -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: Status check?
> >
> > Yes, go ahead, Martin.
> >
> > I made a couple of very minor changes to my local copy, but nothing that
> > won't reconcile after you chedck in yours.
> >
>
> A very popular FAQ after each release has been "what version of the
> commons libraries was included". Can we be explicit about this, perhaps
> in the "what's included" section?
I'm actually in the middle of adding that now. ;-) I remember you asked me
a while ago to make sure we list the explicit versions we use.
The "What's Included" section seems like the logical place. My only
concern is that, because of the length of the "RC/Beta Fixes" section,
it's quite far down the page. But I don't know where else I would put
it...
--
Martin Cooper
>
> By the way, I uploaded the new Struts-Faces integration library stuff (and
> copied over the old one for legacy purposes) to a new directory:
>
> http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
>
> I left a web server redirect in place so to that the old URL comes here.
>
> > Martin Cooper wrote:
> > > I'm doing a cleanup pass over the release notes right now, fixing some
> > > things and cleaning up the text in some places. Is it OK for me to go
> > > ahead and check that in when I'm done, Ted?
>
> One more status note ... it doesn't look like I'm going to be able to
> resurrect my nightly build process (for Commons packages and Struts)
> before getting on a plane tomorrow for JavaOne, so nightly builds will
> probably not be available until I can get back and clean that up.
>
> I hate disk hardware problems :-(.
>
> 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: Status check - [ANN]
Posted by Ted Husted <hu...@apache.org>.
The News and Resources pages are woefully behind the times right now. It
would be great if someone were able to go through the User list looking
for product announcements and other news since the last update, and
patch these puppies up. =;)
It seems like lotsa cool stuff has been coming out, and a good way to
keep it coming out is by providing positive feed back through News and
Resource pages.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> The nightly directories get any file older than five days cleaned out --
> and, because I'm not able to deal with getting them published in the time
> I'm at JavaOne, that means a "somewhere else or nothing" policy is
> important.
Understood and agreed. Making the s-f distruibution available to the
community is more important that observing the letter of our procecures.
(Apache was made for developers, not developers for Apache.)
> That being said, we definitely need to figure out a strategy for stuff not
> in Struts core but having "releases" by whatever definition is
> appropriate.
+1. All the optional components, the original struts-tags, struts-el,
tiles, validator, struts-faces, should all have their own release
cycles. We need to emphasize the fact that Strut is (and always has
been) pluggable, and everyone's favorite flavor of the day will work
just fine. The only thing that really needs to be in the struts-core is
the Action package and its direct dependencies.
For Struts-faces, I think if you just call for a [VOTE] when you get
back, we can just release it as a milestone, like anything else. So long
as it's a positive vote, and we get the minimum three binding +1s, we
could just leave them there.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Date: Sat, 07 Jun 2003 16:55:07 -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: Status check?
>
> Craig R. McClanahan wrote:
> > By the way, I uploaded the new Struts-Faces integration library stuff (and
> > copied over the old one for legacy purposes) to a new directory:
> >
> > http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
> >
> > I left a web server redirect in place so to that the old URL comes here.
>
> Is this a temporary location related to the hard drive problems?
>
> Posting these at
>
> http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/
>
> seemed cool, but we don't want to keep things under release unless
> there's been an actual vote, n'est pas?
The nightly directories get any file older than five days cleaned out --
and, because I'm not able to deal with getting them published in the time
I'm at JavaOne, that means a "somewhere else or nothing" policy is
important.
That being said, we definitely need to figure out a strategy for stuff not
in Struts core but having "releases" by whatever definition is
appropriate.
>
> -Ted.
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> By the way, I uploaded the new Struts-Faces integration library stuff (and
> copied over the old one for legacy purposes) to a new directory:
>
> http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
>
> I left a web server redirect in place so to that the old URL comes here.
Is this a temporary location related to the hard drive problems?
Posting these at
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/
seemed cool, but we don't want to keep things under release unless
there's been an actual vote, n'est pas?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 7 Jun 2003, Ted Husted wrote:
> Date: Sat, 07 Jun 2003 14:25:23 -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: Status check?
>
> Yes, go ahead, Martin.
>
> I made a couple of very minor changes to my local copy, but nothing that
> won't reconcile after you chedck in yours.
>
A very popular FAQ after each release has been "what version of the
commons libraries was included". Can we be explicit about this, perhaps
in the "what's included" section?
By the way, I uploaded the new Struts-Faces integration library stuff (and
copied over the old one for legacy purposes) to a new directory:
http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
I left a web server redirect in place so to that the old URL comes here.
> Martin Cooper wrote:
> > I'm doing a cleanup pass over the release notes right now, fixing some
> > things and cleaning up the text in some places. Is it OK for me to go
> > ahead and check that in when I'm done, Ted?
One more status note ... it doesn't look like I'm going to be able to
resurrect my nightly build process (for Commons packages and Struts)
before getting on a plane tomorrow for JavaOne, so nightly builds will
probably not be available until I can get back and clean that up.
I hate disk hardware problems :-(.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Yes, go ahead, Martin.
I made a couple of very minor changes to my local copy, but nothing that
won't reconcile after you chedck in yours.
Martin Cooper wrote:
> I'm doing a cleanup pass over the release notes right now, fixing some
> things and cleaning up the text in some places. Is it OK for me to go
> ahead and check that in when I'm done, Ted?
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
I'm doing a cleanup pass over the release notes right now, fixing some
things and cleaning up the text in some places. Is it OK for me to go
ahead and check that in when I'm done, Ted?
--
Martin Cooper
On Sat, 7 Jun 2003, Ted Husted wrote:
> OK, the release-notes are updated. ]My, we have been busy little
> beavers:-)]. There were a good number of refactoring and fixes, but no
> new major changes aside from those stated. (Though, I'll need to add the
> new deprecations to the "What's Different" list.
>
> If there's anything else we've done recently that should be added to the
> "What's New" and "What's Different" sections, please let me know.
>
> I need to run some errands. If anyone is around and is up for starting
> on some of the Tomcat tests for me, that would be great. We need to run
> the Cactus tests and playtest the examples apps for the supported
> containers. Otherwise, I'll get to it this afternoon.
>
> -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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Ted Husted wrote:
> OK, the release-notes are updated.
The page is not linked, but I uploaded it already.
http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc2.html
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
OK, the release-notes are updated. ]My, we have been busy little
beavers:-)]. There were a good number of refactoring and fixes, but no
new major changes aside from those stated. (Though, I'll need to add the
new deprecations to the "What's Different" list.
If there's anything else we've done recently that should be added to the
"What's New" and "What's Different" sections, please let me know.
I need to run some errands. If anyone is around and is up for starting
on some of the Tomcat tests for me, that would be great. We need to run
the Cactus tests and playtest the examples apps for the supported
containers. Otherwise, I'll get to it this afternoon.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Ted Husted wrote:
> BUILD FAILED
> file:C:/projects/Apache/jakarta/jakarta-struts/build.xml:308:
> java.lang.IllegalM
> onitorStateException: current thread not owner
>
> Total time: 3 seconds
>
> Any thoughts?
>
> J2SE 1.3 compiles fine, and of course 1.4 is good, and I thought I had
> 1.2 working too, but now it doesn't like me anymore =:(
>
> -Ted.
OK, for the purposes of this release candidate, I am going to take it on
faith that given a proper JAXP installation, that Struts will compile
under J2SE 1.2.
If someone does know how, *starting from scratch*, you can download the
latest J2SE 1.2 and add JAXP support from resources *now available*,
please provide a patch to the installation page.
If it turns out you-can't-get-there-from-here anymore (because the Sun
JAXP RI is no longer available as bundled release), we'll just have to
move our dependency to J2SE 1.3. Time marches on.
I'm running the Tomcat tests now and updating the release notes. Film at 11.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Ted Husted wrote:
> Just sorting out what I need to do to retrofit 1.2/1.3 with JAXP these
> days, so I can confirm we still compile with the old guard =:0)
I downloaded the latest Web Services pack (I had an older version), and
at first the JAXP from that distribution seemed to work, but now for
J2SE 1.2 I'm getting
init:
[echo] --------- jakarta-struts 1.1-rc2 ---------
[echo] java.class.path =
C:\Javasoft\jdk1.2.2\lib\tools.jar;C:\opt\Ant\jaka
rta-ant-1.5.1\lib\xsltc.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\xml-apis.jar;C:\opt
\Ant\jakarta-ant-1.5.1\lib\xercesImpl.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\xalan
.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\src.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\s
ax.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\optional.jar;C:\opt\Ant\jakarta-ant-1.5.
1\lib\junit.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\junit-src.jar;C:\opt\Ant\jakart
a-ant-1.5.1\lib\jaxp-api.jar;C:\opt\Ant\jakarta-ant-1.5.1\lib\dom.jar;C:\opt\Ant
\jakarta-ant-1.5.1\lib\ant.jar;.
[echo] java.home = C:\Javasoft\jdk1.2.2\jre
[echo] user.home = C:\Documents and Settings\ted
prepare.library:
compile.library:
[style] Transforming into
C:\projects\Apache\jakarta\jakarta-struts\target\l
ibrary
[style] Processing
C:\projects\Apache\jakarta\jakarta-struts\doc\userGuide\s
truts-bean.xml to
C:\projects\Apache\jakarta\jakarta-struts\target\library\strut
s-bean.tld
[style] Loading stylesheet
C:\projects\Apache\jakarta\jakarta-struts\doc\sty
lesheets\tld.xsl
A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
occurred
in :
'org/apache/xalan/processor/StylesheetHandler.init
(Lorg/apache/xalan/processo
r/TransformerFactoryImpl;)V': Interpreting method.
Please report this error in detail to
http://java.sun.com/cgi-bin/bugreport.cg
i
A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
occurred
in :
'org/apache/xalan/templates/OutputProperties.getDefaultMethodProperties
(Ljava
/lang/String;)Ljava/util/Properties;': Interpreting method.
Please report this error in detail to
http://java.sun.com/cgi-bin/bugreport.cg
i
A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
occurred
in :
'org/apache/xalan/transformer/TransformerImpl.setErrorListener
(Ljavax/xml/tra
nsform/ErrorListener;)V': Interpreting method.
Please report this error in detail to
http://java.sun.com/cgi-bin/bugreport.cg
i
[style] Failed to process
C:\projects\Apache\jakarta\jakarta-struts\doc\user
Guide\struts-bean.xml
BUILD FAILED
file:C:/projects/Apache/jakarta/jakarta-struts/build.xml:308:
java.lang.IllegalM
onitorStateException: current thread not owner
Total time: 3 seconds
Any thoughts?
J2SE 1.3 compiles fine, and of course 1.4 is good, and I thought I had
1.2 working too, but now it doesn't like me anymore =:(
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> As far as building and packaging go, you might want to take a look at the
> 'release' target I added to the main Struts build file. That really helps
> with putting the binary and source uploads together.
Very nice work here, Martin. This target certainly simplifies things!
Just sorting out what I need to do to retrofit 1.2/1.3 with JAXP these
days, so I can confirm we still compile with the old guard =:0)
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Sun, 1 Jun 2003, Ted Husted wrote:
> Martin,
>
> I'm trying to release the struts-legacy package with our
> GenericDataSource implementation. I'm working from the Commons
> instructions (but substituting jakarta-struts where appropriate).
>
> http://jakarta.apache.org/commons/releases.html
The instructions here are more up to date and more comprehensive:
http://jakarta.apache.org/commons/releases/
I proposed switching the link to that not too long ago, but Robert wanted
to do some cleanup first. IMHO, they're still better, though.
>
> At step 5, it looks like I should log into cvs.apache.org first, tag the
> live files there, and create the binary distribution on that machine, as
> is done with the source distribution at step 9.
When you tag something in CVS, you're tagging the repository rather than
the files per se. So yes, you need to be connected to cvs.apache.org.
Basically, you need to make sure what you have on your local disk is what
you want to tag, and then run the CVS 'tag' command. That will tag the
repository. The reason your local files need to be up to date is because
the version tagged in the repo is whatever you have locally. You can also
use 'cvs rtag' if you want to tag the repo regardless of what you have,
but I think most people, myself included, stick with 'cvs tag'.
The binary and source distributions come from your local machine. You
won't be able to build them on cvs.a.o or www.a.o, since they don't have
the JDK available.
As far as building and packaging go, you might want to take a look at the
'release' target I added to the main Struts build file. That really helps
with putting the binary and source uploads together.
For the main Struts release, the most time-consuming part is just testing
that everything works with all the supported containers (including all the
web apps). I don't know how much you'll need to do for the legacy stuff.
Another time-consuming step is signing everything and creating digests.
The tagging for the main Struts release will actually be a bit more
painful for RC2 since you can't just blanket-tag the Commons packages -
they'll have to be tagged individually to match the specific versions
we're bundling.
Hope this helps.
--
Martin Cooper
>
> Is that correct?
>
> Otherwise, do I check the files in (again) between #8 and #9, so the tag
> propagates.
>
> I've haven't had to set CVS tags myself before, and so I'm a bit nervous
> about that part.
>
> -Ted.
>
>
>
> --
> Ted Hustled,
> Struts in Action <http://husted.com/struts/book.html>
>
>
>
> ---------------------------------------------------------------------
> 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: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin,
I'm trying to release the struts-legacy package with our
GenericDataSource implementation. I'm working from the Commons
instructions (but substituting jakarta-struts where appropriate).
http://jakarta.apache.org/commons/releases.html
At step 5, it looks like I should log into cvs.apache.org first, tag the
live files there, and create the binary distribution on that machine, as
is done with the source distribution at step 9.
Is that correct?
Otherwise, do I check the files in (again) between #8 and #9, so the tag
propagates.
I've haven't had to set CVS tags myself before, and so I'm a bit nervous
about that part.
-Ted.
--
Ted Hustled,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
"Ted Husted" <hu...@apache.org> wrote in message
news:3F0075A9.4020205@apache.org...
> Martin Cooper wrote:
> > Now, about the Struts 1.1 RC2 release. The problem is the staging
> > needed to get FileUpload out the door. It's currently at Beta 1, and
> > the code base in CVS has some methods that have been deprecated since
> > Beta 1. The deprecated methods need to be removed before 1.0 Final,
> > which means that we need a Beta 2 to publicise the deprecations. Then
> > they can be removed in an RC1, shortly to be followed (hopefully) by
> > 1.0 Final.
>
> So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2
> this weekend, I can then cut RC2 with that, if you like.
The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).)
So it's just a matter of what release this will be, and what to do about the
deprecated methods. Then I can send out the vote.
>
> I'm going to release the struts-generic package first thing in the
> morning, and move the nightly build dependencies over to that, so we can
> then just plug in the latest FileUpload.
>
> IMHO, you might consider taking FileUpload straight to RC1. It's
> unreleased software and API changes are to be expected. If this were FU
> 2.0, and you were removing something that was in FU 1.0's established
> API, it would be different. But greater latitude as to API changes
> should be given to unreleased, pre-1.0 packages.
So you're suggesting that I rip out the deprecated methods now, go for RC1,
and damn the torpedoes that the API is incompatible between Beta 1 and RC1,
and there was no warning (other than nightly builds)? You really think
that's OK?
Gump builds for Tomcat and Turbine will start failing as soon as I remove
the deprecated methods. Tapestry won't be affected, since Mr. Tapestry
doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts
already has the necessary changes.
--
Martin Cooper
>
> If you were to go to FileUpload RC1, then perhaps Struts and FileUpload
> can then go to final together.
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check? - Houston we have a problem
Posted by Ted Husted <hu...@apache.org>.
So, I tried it under Tomcat 3.3.1 (no a), with the same result. =:(
I had compiled the release under servlet 2.3, but I redid it under
servlet 2.2 with the same result.
I don't use cookies much, and off-hand I don't know if it's a problem
with the test, Tomcat, or Jasper. The other cats are happy, though. And
everything else for TC3 is nominal
I suspect that the comparison test would pass, but that Jasper is
running out of resources. If there's a way to reconfigure TC3 so this
one will run, let me know.
I'm also seeing some Servlet Exceptions in the tiles example for TC3
that don't appear for the TC4s. For example,
http://localhost:8080/tiles-documentation/tutorial/extendedDefinitionTag.jsp
throws
[ServletException in:/common/menuViewSrc.jsp]
TOMCAT/JSP/common/menuViewSrc.jsp'
but only in TC3.
So, pending advice from the other committers, the release seems to be
stalled, since our exercise-taglib tests and some of our
tiles-documentation pages do not seem to run successfully against one of
our "supported" containers.
Tiles is an optional component, so I could live with there being TC3
issues for that (if we document them). But I'm not sure what to think
about the cookies error.
-T.
Ted Husted wrote:
> I'm still play-testing the web apps against all three, but here's an
> early warning:
>
> Running the exercise app under Tomcat 3.3.1a
>
> The logic-compare test kills container - nothing in log to indicate why.
> This is a big test, so it may be rendering problem. (TC41 is OK)
>
> Same result under NN and IE for Windows XP. The Tomcat test memory usage
> is under 50%.
>
> Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),
>
> http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp
>
> Error: 500
> Location: /struts-exercise-taglib/bean-cookie.jsp
> Internal Servlet Error:
>
> org.apache.jasper.JasperException: Class
> org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of
> class org.apache.tomcat.facade.CookieFacade with modifiers "public"
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430)
>
> at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> at
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
> at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
> at org.apache.tomcat.core.Handler.service(Handler.java:235)
> at
> org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
>
> at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
> at
> org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
>
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
>
> at java.lang.Thread.run(Thread.java:536)
> Root cause:
> java.lang.IllegalAccessException: Class
> org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of
> class org.apache.tomcat.facade.CookieFacade with modifiers "public"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
> at java.lang.reflect.Method.invoke(Method.java:317)
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428)
>
> at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java)
> at
> org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
> at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
> at org.apache.tomcat.core.Handler.service(Handler.java:235)
> at
> org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
>
> at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
> at
> org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
>
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
>
> at java.lang.Thread.run(Thread.java:536)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check? - Houston we have a problem
Posted by Ted Husted <hu...@apache.org>.
I'm still play-testing the web apps against all three, but here's an
early warning:
Running the exercise app under Tomcat 3.3.1a
The logic-compare test kills container - nothing in log to indicate why.
This is a big test, so it may be rendering problem. (TC41 is OK)
Same result under NN and IE for Windows XP. The Tomcat test memory usage
is under 50%.
Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal),
http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp
Error: 500
Location: /struts-exercise-taglib/bean-cookie.jsp
Internal Servlet Error:
org.apache.jasper.JasperException: Class
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
at
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:430)
at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)
Root cause:
java.lang.IllegalAccessException: Class
org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of
class org.apache.tomcat.facade.CookieFacade with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57)
at java.lang.reflect.Method.invoke(Method.java:317)
at
org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty(JspRuntimeLibrary.java:428)
at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at
org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Ted Husted <hu...@apache.org>.
Martin Cooper wrote:
> Now, about the Struts 1.1 RC2 release. The problem is the staging
> needed to get FileUpload out the door. It's currently at Beta 1, and
> the code base in CVS has some methods that have been deprecated since
> Beta 1. The deprecated methods need to be removed before 1.0 Final,
> which means that we need a Beta 2 to publicise the deprecations. Then
> they can be removed in an RC1, shortly to be followed (hopefully) by
> 1.0 Final.
So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2
this weekend, I can then cut RC2 with that, if you like.
I'm going to release the struts-generic package first thing in the
morning, and move the nightly build dependencies over to that, so we can
then just plug in the latest FileUpload.
IMHO, you might consider taking FileUpload straight to RC1. It's
unreleased software and API changes are to be expected. If this were FU
2.0, and you were removing something that was in FU 1.0's established
API, it would be different. But greater latitude as to API changes
should be given to unreleased, pre-1.0 packages.
If you were to go to FileUpload RC1, then perhaps Struts and FileUpload
can then go to final together.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Mark Lowe <ma...@talk21.com>.
how easy it to become a commiter? I've got some time, I'll take a look
at all the notes , cvs logs and bugzilla for fileUpload, and see if i
can help.
cheers mark
On Thursday, May 29, 2003, at 07:18 Europe/London, Martin Cooper wrote:
>
>
> On Wed, 28 May 2003, James Turner wrote:
>
>> Ok folks, things have been mighty quiet lately here. So I'm going to
>> summerize where I think things are right now:
>>
>> 1) Struts core is basically ready to go, and the dependency on the
>> latest version of DBCP has been removed
>>
>> 2) What we're waiting on is the final release of FileUpload, which
>> Martin is working on.
>>
>> Can we get a status check on FileUpload? It would be mighty nice to
>> get
>> RC2 out before JavaOne.
>
> First, the FileUpload status. I have had some e-mail exchanges off-list
> with the reporters of the two outstanding bugs. A partial solution
> exists
> for one of them, and, when completed, should actually solve both of
> them.
>
> Unfortunately, those solutions won't work for Struts users, since they
> involve passing new information to FileUpload, which Struts obviously
> doesn't do right now. However, that could potentially be deferred to a
> Struts 1.2 release, as long as we promise ourselves that we'll be
> better
> about getting releases out more frequently.
>
> My problem right now with getting this finished up is that I am really
> swamped at my "day job". With the hours I'm having to devote to that at
> the moment, there aren't many left for anything else. (Somebody told me
> last weekend was a holiday weekend. What weekend? ;)
>
> I promise I'll try to find some time this coming weekend to get a fix
> in
> that will hopefully resolve both issues.
>
> Now, about the Struts 1.1 RC2 release. The problem is the staging
> needed
> to get FileUpload out the door. It's currently at Beta 1, and the code
> base in CVS has some methods that have been deprecated since Beta 1.
> The
> deprecated methods need to be removed before 1.0 Final, which means
> that
> we need a Beta 2 to publicise the deprecations. Then they can be
> removed
> in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>
> Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I
> just
> don't see how that can happen, given the steps that FileUpload has to
> go
> through before a final release.
>
> I almost felt like finishing up the following paragraph with "Sorry,
> folks". But I decided to rant instead. |->
>
> <rant>
> For a long time now, not one other "committer" to FileUpload has put in
> any effort to finish it up and/or get it released. This is despite the
> fact that FileUpload is used by Tomcat, Turbine and Tapestry, as well
> as
> by Struts. I feel like I'm running a one-man show, which is exactly
> what
> Jakarta (and Apache) projects are not supposed to be.
>
> Running such a one-man show makes me feel guilty when I don't have the
> time to put in to help get Struts 1.1 RC2 out the door. It makes me
> feel
> like it's my fault. But it shouldn't be up to just me.
> </rant>
>
> (Can you tell that I'm really stressed out right now? ;)
>
> Important note: The above rant should *not* be read as a complaint that
> other Struts developers are not getting involved with FileUpload. I
> don't
> expect you guys to do that at all.
>
> Rant over. Now back to my "day job". (A "day job" at 11pm? What's wrong
> with this picture?)
>
> --
> Martin Cooper
>
>
>>
>> James Turner
>> Director of Software Development
>> Benefit Systems, Inc.
>> turner@blackbear.com
>>
>> Track Chair, Strategic Open Source
>> 2003 Fall COMDEX
>>
>> Author:
>> MySQL & JSP Web Applications
>> Struts Kick Start
>> JavaServer Faces Kick Start
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Posted by James Turner <tu...@blackbear.com>.
Is that a +1 for the vote?
James
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, May 29, 2003 7:19 PM
> To: Struts Developers List
> Subject: Re: VOTE (enough already!): Release Struts RC2 with
> FileUpload Beta 2
>
>
> I have enough karma to make the release, if Martin is busy,
> and that's
> what everyone wants to do. I've put the pieces in place to remove the
> DBCP dependency, but need to actually release that as well.
>
> Hopefully, there will be a final release of FileUpload early
> in June, so
> we can pop that in and go to final.
>
> The underlying problem has nothing to do with the Apache process. We
> simply tried to release too many things at once. If we had done
> step-wise releases (tag improvements/ nested/ modules/
> validator/ tiles/
> jstl/ etc), we wouldn't be in this jam. By rights, we should be at
> something like Struts 1.8 by now.
>
> As soon as Struts 1.1 is out the door, I'd like to remove the
> deprecations and release Struts 1.2. It's gotten so that it's hard to
> see the forest for the trees anymore.
>
> We should then try to relase whenever a useful feature is
> added, so as
> to put it in the hands of people as soon as possible.
>
> -Ted.
>
>
>
> James Turner wrote:
> >>From: Martin Cooper [mailto:martinc@apache.org]
> >
> >
> > First off, big thanks to Martin for adopting FileUpload and getting
> > this puppy back in shape.
> >
> >
> >>Now, about the Struts 1.1 RC2 release. The problem is the
> >>staging needed to get FileUpload out the door. It's currently
> >>at Beta 1, and the code base in CVS has some methods that
> >>have been deprecated since Beta 1. The deprecated methods
> >>need to be removed before 1.0 Final, which means that we need
> >>a Beta 2 to publicise the deprecations. Then they can be
> >>removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
> >>
> >>Much as I would like to see Struts 1.1 RC2 happen before
> >>JavaOne, I just don't see how that can happen, given the
> >>steps that FileUpload has to go through before a final release.
> >
> >
> > Does this strike anyone but me as an example of the victory
> of process
> > over sanity?
> >
> > Why does a deprecation/removal of some methods require a
> new beta? If
> > your code depends on the deprecated methods, you can stick with
> > whatever you're using now until you can fix your code, and then use
> > the release. If you don't, you can evaluate the RC, and an
> entire step
> > can be saved.
> >
> > The entire Struts 1.1 release has been a Kafka-esq
> adventure in strict
> > adherence to a set of rules that, IMHO, has done nothing but add
> > months of delay to an already terminally late release.
> It's hard to
> > believe there's something that makes the JCP look speedy,
> but consider
> > that in the time we've been struggling to get 1.1 out the door, JSF
> > has gone almost completely from proposal to EA.
> >
> > Open source is supposed to be speedy and responsive, instead we're
> > starting to make Microsoft look like a speed demon. The
> Apache rules
> > serve a good purpose, to prevent shoddy releases. But at
> this point,
> > we've got a major release hanging fire on (frankly) some relatively
> > obscure supporting packages which aren't even used by the
> majority of
> > the user community.
> >
> > If I were benevolent dictator for a day, I'd do a 1.1 RC2
> now with the
> > FileUpload Beta 2. But, since we live in an enlightened
> society, I'm
> > putting it up for a vote.
> >
> > As we've been reminded recently, this type of voice is
> non-veto-able,
> > lazy majority
> >
> > SO:
> >
> > +1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
> > releases it.
> >
> > 0 - Eh
> >
> > -1 - I prefer to delay Struts RC2 until FileUpload is in final
> > release.
> >
> > The 72 hour voting cutoff is 3AM Eastern June 1
> >
> > James
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Ted Husted,
> Struts in Action <http://husted.com/struts/book.html>
>
>
>
> ---------------------------------------------------------------------
> 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: VOTE (enough already!): Release Struts RC2 with FileUpload Beta
2
Posted by Ted Husted <hu...@apache.org>.
I have enough karma to make the release, if Martin is busy, and that's
what everyone wants to do. I've put the pieces in place to remove the
DBCP dependency, but need to actually release that as well.
Hopefully, there will be a final release of FileUpload early in June, so
we can pop that in and go to final.
The underlying problem has nothing to do with the Apache process. We
simply tried to release too many things at once. If we had done
step-wise releases (tag improvements/ nested/ modules/ validator/ tiles/
jstl/ etc), we wouldn't be in this jam. By rights, we should be at
something like Struts 1.8 by now.
As soon as Struts 1.1 is out the door, I'd like to remove the
deprecations and release Struts 1.2. It's gotten so that it's hard to
see the forest for the trees anymore.
We should then try to relase whenever a useful feature is added, so as
to put it in the hands of people as soon as possible.
-Ted.
James Turner wrote:
>>From: Martin Cooper [mailto:martinc@apache.org]
>
>
> First off, big thanks to Martin for adopting FileUpload and getting this
> puppy back in shape.
>
>
>>Now, about the Struts 1.1 RC2 release. The problem is the
>>staging needed to get FileUpload out the door. It's currently
>>at Beta 1, and the code base in CVS has some methods that
>>have been deprecated since Beta 1. The deprecated methods
>>need to be removed before 1.0 Final, which means that we need
>>a Beta 2 to publicise the deprecations. Then they can be
>>removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>>
>>Much as I would like to see Struts 1.1 RC2 happen before
>>JavaOne, I just don't see how that can happen, given the
>>steps that FileUpload has to go through before a final release.
>
>
> Does this strike anyone but me as an example of the victory of process
> over sanity?
>
> Why does a deprecation/removal of some methods require a new beta? If
> your code depends on the deprecated methods, you can stick with whatever
> you're using now until you can fix your code, and then use the release.
> If you don't, you can evaluate the RC, and an entire step can be saved.
>
> The entire Struts 1.1 release has been a Kafka-esq adventure in strict
> adherence to a set of rules that, IMHO, has done nothing but add months
> of delay to an already terminally late release. It's hard to believe
> there's something that makes the JCP look speedy, but consider that in
> the time we've been struggling to get 1.1 out the door, JSF has gone
> almost completely from proposal to EA.
>
> Open source is supposed to be speedy and responsive, instead we're
> starting to make Microsoft look like a speed demon. The Apache rules
> serve a good purpose, to prevent shoddy releases. But at this point,
> we've got a major release hanging fire on (frankly) some relatively
> obscure supporting packages which aren't even used by the majority of
> the user community.
>
> If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the
> FileUpload Beta 2. But, since we live in an enlightened society, I'm
> putting it up for a vote.
>
> As we've been reminded recently, this type of voice is non-veto-able,
> lazy majority
>
> SO:
>
> +1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
> releases it.
>
> 0 - Eh
>
> -1 - I prefer to delay Struts RC2 until FileUpload is in final release.
>
> The 72 hour voting cutoff is 3AM Eastern June 1
>
> James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta
2
Posted by Ted Husted <hu...@apache.org>.
James Turner wrote:
> The 72 hour voting cutoff is 3AM Eastern June 1
Just for the record, the 72-hour convention is how long we should wait
before taking action. It doesn't mean that people couldn't continue to
vote after 3 AM on June 1, if we haven't already cut the release.
Of course, this is also a majority vote so there would have to be more
(binding) -1s than +1s for it to make a difference.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Posted by James Holmes <ja...@jamesholmes.com>.
+1. Let's do it!
-James
----- Original Message -----
From: "James Turner" <tu...@blackbear.com>
To: "'Struts Developers List'" <st...@jakarta.apache.org>
Sent: Thursday, May 29, 2003 3:05 AM
Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
> From: Martin Cooper [mailto:martinc@apache.org]
First off, big thanks to Martin for adopting FileUpload and getting this
puppy back in shape.
> Now, about the Struts 1.1 RC2 release. The problem is the
> staging needed to get FileUpload out the door. It's currently
> at Beta 1, and the code base in CVS has some methods that
> have been deprecated since Beta 1. The deprecated methods
> need to be removed before 1.0 Final, which means that we need
> a Beta 2 to publicise the deprecations. Then they can be
> removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>
> Much as I would like to see Struts 1.1 RC2 happen before
> JavaOne, I just don't see how that can happen, given the
> steps that FileUpload has to go through before a final release.
Does this strike anyone but me as an example of the victory of process
over sanity?
Why does a deprecation/removal of some methods require a new beta? If
your code depends on the deprecated methods, you can stick with whatever
you're using now until you can fix your code, and then use the release.
If you don't, you can evaluate the RC, and an entire step can be saved.
The entire Struts 1.1 release has been a Kafka-esq adventure in strict
adherence to a set of rules that, IMHO, has done nothing but add months
of delay to an already terminally late release. It's hard to believe
there's something that makes the JCP look speedy, but consider that in
the time we've been struggling to get 1.1 out the door, JSF has gone
almost completely from proposal to EA.
Open source is supposed to be speedy and responsive, instead we're
starting to make Microsoft look like a speed demon. The Apache rules
serve a good purpose, to prevent shoddy releases. But at this point,
we've got a major release hanging fire on (frankly) some relatively
obscure supporting packages which aren't even used by the majority of
the user community.
If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the
FileUpload Beta 2. But, since we live in an enlightened society, I'm
putting it up for a vote.
As we've been reminded recently, this type of voice is non-veto-able,
lazy majority
SO:
+1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
releases it.
0 - Eh
-1 - I prefer to delay Struts RC2 until FileUpload is in final release.
The 72 hour voting cutoff is 3AM Eastern June 1
James
---------------------------------------------------------------------
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: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
+1 from a non-committer (but sometimes contributor) as well. Release
it! Then if someone complains of a bug, it'll get fixed and another
release can come out.
On Thursday, May 29, 2003, at 03:15 AM, Andrew Hill wrote:
> I aint no committer/contributor but if I get 2 cents worth (about 1.15
> US
> cents) its:
>
> +1
>
> Do it! Do it now!
>
> -----Original Message-----
> From: James Turner [mailto:turner@blackbear.com]
> Sent: Thursday, 29 May 2003 15:06
> To: 'Struts Developers List'
> Subject: VOTE (enough already!): Release Struts RC2 with FileUpload
> Beta
> 2
>
>
>> From: Martin Cooper [mailto:martinc@apache.org]
>
> First off, big thanks to Martin for adopting FileUpload and getting
> this
> puppy back in shape.
>
>> Now, about the Struts 1.1 RC2 release. The problem is the
>> staging needed to get FileUpload out the door. It's currently
>> at Beta 1, and the code base in CVS has some methods that
>> have been deprecated since Beta 1. The deprecated methods
>> need to be removed before 1.0 Final, which means that we need
>> a Beta 2 to publicise the deprecations. Then they can be
>> removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>>
>> Much as I would like to see Struts 1.1 RC2 happen before
>> JavaOne, I just don't see how that can happen, given the
>> steps that FileUpload has to go through before a final release.
>
> Does this strike anyone but me as an example of the victory of process
> over sanity?
>
> Why does a deprecation/removal of some methods require a new beta? If
> your code depends on the deprecated methods, you can stick with
> whatever
> you're using now until you can fix your code, and then use the release.
> If you don't, you can evaluate the RC, and an entire step can be saved.
>
> The entire Struts 1.1 release has been a Kafka-esq adventure in strict
> adherence to a set of rules that, IMHO, has done nothing but add months
> of delay to an already terminally late release. It's hard to believe
> there's something that makes the JCP look speedy, but consider that in
> the time we've been struggling to get 1.1 out the door, JSF has gone
> almost completely from proposal to EA.
>
> Open source is supposed to be speedy and responsive, instead we're
> starting to make Microsoft look like a speed demon. The Apache rules
> serve a good purpose, to prevent shoddy releases. But at this point,
> we've got a major release hanging fire on (frankly) some relatively
> obscure supporting packages which aren't even used by the majority of
> the user community.
>
> If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the
> FileUpload Beta 2. But, since we live in an enlightened society, I'm
> putting it up for a vote.
>
> As we've been reminded recently, this type of voice is non-veto-able,
> lazy majority
>
> SO:
>
> +1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
> releases it.
>
> 0 - Eh
>
> -1 - I prefer to delay Struts RC2 until FileUpload is in final release.
>
> The 72 hour voting cutoff is 3AM Eastern June 1
>
> James
>
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Posted by Andrew Hill <an...@gridnode.com>.
I aint no committer/contributor but if I get 2 cents worth (about 1.15 US
cents) its:
+1
Do it! Do it now!
-----Original Message-----
From: James Turner [mailto:turner@blackbear.com]
Sent: Thursday, 29 May 2003 15:06
To: 'Struts Developers List'
Subject: VOTE (enough already!): Release Struts RC2 with FileUpload Beta
2
> From: Martin Cooper [mailto:martinc@apache.org]
First off, big thanks to Martin for adopting FileUpload and getting this
puppy back in shape.
> Now, about the Struts 1.1 RC2 release. The problem is the
> staging needed to get FileUpload out the door. It's currently
> at Beta 1, and the code base in CVS has some methods that
> have been deprecated since Beta 1. The deprecated methods
> need to be removed before 1.0 Final, which means that we need
> a Beta 2 to publicise the deprecations. Then they can be
> removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>
> Much as I would like to see Struts 1.1 RC2 happen before
> JavaOne, I just don't see how that can happen, given the
> steps that FileUpload has to go through before a final release.
Does this strike anyone but me as an example of the victory of process
over sanity?
Why does a deprecation/removal of some methods require a new beta? If
your code depends on the deprecated methods, you can stick with whatever
you're using now until you can fix your code, and then use the release.
If you don't, you can evaluate the RC, and an entire step can be saved.
The entire Struts 1.1 release has been a Kafka-esq adventure in strict
adherence to a set of rules that, IMHO, has done nothing but add months
of delay to an already terminally late release. It's hard to believe
there's something that makes the JCP look speedy, but consider that in
the time we've been struggling to get 1.1 out the door, JSF has gone
almost completely from proposal to EA.
Open source is supposed to be speedy and responsive, instead we're
starting to make Microsoft look like a speed demon. The Apache rules
serve a good purpose, to prevent shoddy releases. But at this point,
we've got a major release hanging fire on (frankly) some relatively
obscure supporting packages which aren't even used by the majority of
the user community.
If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the
FileUpload Beta 2. But, since we live in an enlightened society, I'm
putting it up for a vote.
As we've been reminded recently, this type of voice is non-veto-able,
lazy majority
SO:
+1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
releases it.
0 - Eh
-1 - I prefer to delay Struts RC2 until FileUpload is in final release.
The 72 hour voting cutoff is 3AM Eastern June 1
James
---------------------------------------------------------------------
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
VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Posted by James Turner <tu...@blackbear.com>.
> From: Martin Cooper [mailto:martinc@apache.org]
First off, big thanks to Martin for adopting FileUpload and getting this
puppy back in shape.
> Now, about the Struts 1.1 RC2 release. The problem is the
> staging needed to get FileUpload out the door. It's currently
> at Beta 1, and the code base in CVS has some methods that
> have been deprecated since Beta 1. The deprecated methods
> need to be removed before 1.0 Final, which means that we need
> a Beta 2 to publicise the deprecations. Then they can be
> removed in an RC1, shortly to be followed (hopefully) by 1.0 Final.
>
> Much as I would like to see Struts 1.1 RC2 happen before
> JavaOne, I just don't see how that can happen, given the
> steps that FileUpload has to go through before a final release.
Does this strike anyone but me as an example of the victory of process
over sanity?
Why does a deprecation/removal of some methods require a new beta? If
your code depends on the deprecated methods, you can stick with whatever
you're using now until you can fix your code, and then use the release.
If you don't, you can evaluate the RC, and an entire step can be saved.
The entire Struts 1.1 release has been a Kafka-esq adventure in strict
adherence to a set of rules that, IMHO, has done nothing but add months
of delay to an already terminally late release. It's hard to believe
there's something that makes the JCP look speedy, but consider that in
the time we've been struggling to get 1.1 out the door, JSF has gone
almost completely from proposal to EA.
Open source is supposed to be speedy and responsive, instead we're
starting to make Microsoft look like a speed demon. The Apache rules
serve a good purpose, to prevent shoddy releases. But at this point,
we've got a major release hanging fire on (frankly) some relatively
obscure supporting packages which aren't even used by the majority of
the user community.
If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the
FileUpload Beta 2. But, since we live in an enlightened society, I'm
putting it up for a vote.
As we've been reminded recently, this type of voice is non-veto-able,
lazy majority
SO:
+1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin
releases it.
0 - Eh
-1 - I prefer to delay Struts RC2 until FileUpload is in final release.
The 72 hour voting cutoff is 3AM Eastern June 1
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Status check?
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 28 May 2003, James Turner wrote:
> Ok folks, things have been mighty quiet lately here. So I'm going to
> summerize where I think things are right now:
>
> 1) Struts core is basically ready to go, and the dependency on the
> latest version of DBCP has been removed
>
> 2) What we're waiting on is the final release of FileUpload, which
> Martin is working on.
>
> Can we get a status check on FileUpload? It would be mighty nice to get
> RC2 out before JavaOne.
First, the FileUpload status. I have had some e-mail exchanges off-list
with the reporters of the two outstanding bugs. A partial solution exists
for one of them, and, when completed, should actually solve both of them.
Unfortunately, those solutions won't work for Struts users, since they
involve passing new information to FileUpload, which Struts obviously
doesn't do right now. However, that could potentially be deferred to a
Struts 1.2 release, as long as we promise ourselves that we'll be better
about getting releases out more frequently.
My problem right now with getting this finished up is that I am really
swamped at my "day job". With the hours I'm having to devote to that at
the moment, there aren't many left for anything else. (Somebody told me
last weekend was a holiday weekend. What weekend? ;)
I promise I'll try to find some time this coming weekend to get a fix in
that will hopefully resolve both issues.
Now, about the Struts 1.1 RC2 release. The problem is the staging needed
to get FileUpload out the door. It's currently at Beta 1, and the code
base in CVS has some methods that have been deprecated since Beta 1. The
deprecated methods need to be removed before 1.0 Final, which means that
we need a Beta 2 to publicise the deprecations. Then they can be removed
in an RC1, shortly to be followed (hopefully) by 1.0 Final.
Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just
don't see how that can happen, given the steps that FileUpload has to go
through before a final release.
I almost felt like finishing up the following paragraph with "Sorry,
folks". But I decided to rant instead. |->
<rant>
For a long time now, not one other "committer" to FileUpload has put in
any effort to finish it up and/or get it released. This is despite the
fact that FileUpload is used by Tomcat, Turbine and Tapestry, as well as
by Struts. I feel like I'm running a one-man show, which is exactly what
Jakarta (and Apache) projects are not supposed to be.
Running such a one-man show makes me feel guilty when I don't have the
time to put in to help get Struts 1.1 RC2 out the door. It makes me feel
like it's my fault. But it shouldn't be up to just me.
</rant>
(Can you tell that I'm really stressed out right now? ;)
Important note: The above rant should *not* be read as a complaint that
other Struts developers are not getting involved with FileUpload. I don't
expect you guys to do that at all.
Rant over. Now back to my "day job". (A "day job" at 11pm? What's wrong
with this picture?)
--
Martin Cooper
>
> James Turner
> Director of Software Development
> Benefit Systems, Inc.
> turner@blackbear.com
>
> Track Chair, Strategic Open Source
> 2003 Fall COMDEX
>
> Author:
> MySQL & JSP Web Applications
> Struts Kick Start
> JavaServer Faces Kick Start
>
>
>
> ---------------------------------------------------------------------
> 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