Rainer Hermanns hermanns at aixcept.de writes:
both, XWork 2.0.1 and OGNL 2.6.10 were released and are available via
the maven repository at OpenSymphony.com.
I already updated the core/pom.xml for branch 2.0.X and trunk.
One note for others using the OGNL dependency: The groupId changed to
Nate,
only WW-1615[1] was resolved...
We already released version 2.6.11 cause there were some confusions
after the initial code migration of OGNL to the SVN repo at OpenSymphony.
For the next release, a lot more issues will be addressed.
hth,
Rainer
[1]
Two questions:
1, when will 2.0.6 be released?
2, is one *-all.zip will be released in the distribution?
On 2/14/07, Ted Husted [EMAIL PROTECTED] wrote:
So, tonight is last call on 2.0.6. Please try to take a look at the
TODO list, if you have a chance.
*
If everything is in working order, I'll tag the build circa 13:00 PST
today. The PMC will then decide whether to release the build.
The build will be like the others, and include an -all distribution.
On 2/15/07, Ted Husted [EMAIL PROTECTED] wrote:
As mentioned on another thread, Rainer is
Ted,
both, XWork 2.0.1 and OGNL 2.6.10 were released and are available via
the maven repository at OpenSymphony.com.
I already updated the core/pom.xml for branch 2.0.X and trunk.
One note for others using the OGNL dependency: The groupId changed to
opensymphony.
-Rainer
As mentioned on
As mentioned on another thread, Rainer is creating new releases of
OGNL and then XWork 2. Since he expects the new releases to be
available in the next 24 hours, we might as well wait and include the
new JARs in the Struts 2.0.6 release.
I'm tied up tomorrow and Saturday, but Sunday, 18-Feb,
I think the problem is that when the TLD is generated into the META-INF
folder, maven already copied the resources to the target folder, so the new
TLD doesn't make it into the jar file. We can change the output path to the
target/class/META-INF, but maven doesn't create the META-INF folder if it
Make sure you have the META-INF folder in src/main/resources -- because
resources are always processed.
Musachy Barroso wrote:
I think the problem is that when the TLD is generated into the META-INF
folder, maven already copied the resources to the target folder, so the new
TLD doesn't make it
On 2/15/07, Musachy Barroso [EMAIL PROTECTED] wrote:
I think the problem is that when the TLD is generated into the META-INF
folder, maven already copied the resources to the target folder, so the new
TLD doesn't make it into the jar file.
Sounds like the TLD is getting generated too late in
Sounds like the TLD is getting generated too late in the build
lifecycle, then. What phase is the plugin execution bound to?
compile
Shouldn't the plugin create the directory if it doesn't exist?
Should it create every subfolder on the specified path if they don't exist?
We could do
So, tonight is last call on 2.0.6. Please try to take a look at the
TODO list, if you have a chance.
*
https://issues.apache.org/struts/secure/IssueNavigator.jspa?mode=hiderequestId=10764
A fix for WW-1711 that didn't break the tests (or updated tests) would
be especially welcome!
-Ted.
On
I'd like to go ahead and tag the 2.0.6 release on Thursday between 1pm
and 3pm PST. If you have a chance to preview the build, please do so,
since we've removed the dependencies on the new API. Any of the other
simple changes on the Struts 2.0.6 list would be welcome as well,
otherwise we can
On 2/10/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 2/10/07, Tom Schneider [EMAIL PROTECTED] wrote:
Umm, it looks like the spring plugin jar isn't included. Someone on
#struts mentioned this and I confirmed it by downloading
struts-2.0.5-all.zip from the website and it's not in the lib
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
Yes, both the Spring Plugin and Codebehind Plugin are missing from the
assembly POM.
Do we just want to
(1) note this as a known issue,
(2) branch on 2.0.5 and issue a 2.0.5.1 version of the lib and all
distributions.
(3) issue 2.0.6 from the
On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I'm not familiar enough with this to comment. Does this mean we're
checking a generated file into svn?
My understanding is the annotations are generating the TLD. We checked
the TLD when we were having problems with the generation, but I don't
The TLD is always generated. It was removed at some point, but when we had
the problem with the annotations, it was added back until the problem would
be fixed, so it can be removed now.
musachy
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 2/11/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I'm working on cleaning up the build issues with 2.0.5, with the hope
of tagging and rolling 2.0.6.
The only question is whether we want to roll 2.0.6 immediately, or
wait a day or two to see what else comes in. I'd say if not today,
then by, say, Thursday.
I also added a Release Plan section
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
The TLD is always generated. It was removed at some point, but when we had
the problem with the annotations, it was added back until the problem would
be fixed, so it can be removed now.
There seems to be a timing problem with the TLD
I'm not sure what you mean. If I delete the TLD and do:
mvn compile
on core, it generates the TLD.
musachy
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
The TLD is always generated. It was removed at some point, but when we
had
the
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
I'm not sure what you mean. If I delete the TLD and do:
mvn compile
on core, it generates the TLD.
Try it from a clean checkout and look to see if the TLD is in the JAR.
Meanwhile, we seem to have two tags (doubleselect and
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
I'm not sure what you mean. If I delete the TLD and do:
mvn compile
on core, it generates the TLD.
Try it from a clean checkout and look to see if the TLD is in the JAR.
Clean
Inside the META-INF folder inside the core jar, there is a maven folder. I
don't remember that folder, is it supposed to be there?
musachy
On 2/11/07, Musachy Barroso [EMAIL PROTECTED] wrote:
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
On 2/11/07, Musachy Barroso [EMAIL PROTECTED]
If you want to remove those maven files, you need to update the POM to
include this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
archive
addMavenDescriptorfalse/addMavenDescriptor
Thanks Paul. My bad, I had never seen them before, Wendy told me about it.
There is a problem on DoubleListUIBean, the setter and the getter methods
for doubleListKey are annotated as tag attributes, leave the annotation on
the setter and remove the one on the getter, I think that will do.
From a clean Maven repository, and a clean checkout of the 2_0_x
branch, with no TLD present,
$ mvn clean install site -P all,alljars,pre-assembly
does not generate a core JAR with a TLD for me.
The Manifest.mf is under META-INF, along with the mysterious maven
folder, but the not TLD.
If I
It is in the -sources JAR, though, but that maven folder is not. Weird.
On 2/11/07, Ted Husted [EMAIL PROTECTED] wrote:
From a clean Maven repository, and a clean checkout of the 2_0_x
branch, with no TLD present,
$ mvn clean install site -P all,alljars,pre-assembly
does not generate a core
Umm, it looks like the spring plugin jar isn't included. Someone on
#struts mentioned this and I confirmed it by downloading
struts-2.0.5-all.zip from the website and it's not in the lib
directory. (All the other plugins are there) Am I crazy or is it
really missing?
Tom
Ted Husted wrote:
--- Tom Schneider [EMAIL PROTECTED] wrote:
Am I crazy or is it really missing?
It wasn't in mine; I copied it from showcase again.
Dave
Any questions? Get answers on any topic at www.Answers.yahoo.com.
On 2/10/07, Tom Schneider [EMAIL PROTECTED] wrote:
Umm, it looks like the spring plugin jar isn't included. Someone on
#struts mentioned this and I confirmed it by downloading
struts-2.0.5-all.zip from the website and it's not in the lib
directory. (All the other plugins are there) Am I crazy
-
From: Tom Schneider [EMAIL PROTECTED]
Date: Sat, 10 Feb 2007 22:37:08
To:Struts Developers List dev@struts.apache.org
Subject: Re: [VOTE] Struts 2.0.5 Quality
Umm, it looks like the spring plugin jar isn't included. Someone on
#struts mentioned this and I confirmed it by downloading
struts
[ ] Leave at test build
[ ] Alpha
[ X ] Beta
[ ] General Availability (GA)
cheers,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote:
On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote:
* http://httpd.apache.org/dev/guidelines.html
which also mentions that On some issues, this vote is only binding if
the voter has tested the action on their own system(s). I would
suggest
OK, after thee days, we have
GA - Binding
+1 Patrick Lightbody
Beta - Binding
+1 Rene Gielen
+1 Alexandru Popescu
+1 Ted Husted
+1 Rainer Hermanns
GA - Non Binding
+1 Matt Raible
+1 Philip Luppens
+1 David H. DeWolf
I've submitted the 2.0.5 release for mirroring, so we can update the
releases
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote:
which also mentions that On some issues, this vote is only binding if
the voter has tested the action on their own system(s). I would
suggest that in terms of a vote on a GA release, this means that the
voter is using the bits in production
I was hoping after 2.0.4 that the ognl race condition issue would have
been resolved. Jesse is ready to push the release out probably this
evening, but give it a couple of days. For me, 2.0.5 came a bit too
soon after 2.0.4. But overal, I think the framework itself is ready
for GA.
[ ] Leave
On 2/7/07, Rene Gielen [EMAIL PROTECTED] wrote:
Craig,
So feature freeze and branch 2.0.x now, only fix reported bugs from beta
tests and roll out the result as GA, while trunk moves on to 2.1.x,
fully open for new features and whatever? IMO this would be the perfect
way to go, you get a big +1
On 2/7/07, mraible [EMAIL PROTECTED] wrote:
I'm with Don here - IMO, Struts 2.0.1 was been usable for the general public
True. And if we had a stable release of XWork 2 in September, I
believe that we would have marked 2.0.1 GA.
and the subsequent releases are all a result of Apache politics
On 2/7/07, Philip Luppens [EMAIL PROTECTED] wrote:
On 2/7/07, Rene Gielen [EMAIL PROTECTED] wrote:
Craig,
So feature freeze and branch 2.0.x now, only fix reported bugs from beta
tests and roll out the result as GA, while trunk moves on to 2.1.x,
fully open for new features and whatever?
Rene Gielen wrote:
Craig,
So feature freeze and branch 2.0.x now, only fix reported bugs from beta
tests and roll out the result as GA, while trunk moves on to 2.1.x,
fully open for new features and whatever? IMO this would be the perfect
way to go, you get a big +1 from me on this :)
+1 As
Ted Husted wrote:
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[ X ] General Availability (GA)
+1 GA
Deployed and tested into our qa environment without any glitches.
Moving to production soon without any reservations.
On 2/5/07, Ted Husted [EMAIL PROTECTED] wrote:
[ ] Leave at test build
[ ] Alpha
[x] Beta
[ ] General Availability (GA)
We've had a lot of comments on the prior test builds, and so I do have
confidence in the bits. But, I'd still like to have a brief ten-day
beta period, to encourage wider
On 2/5/07, Ted Husted [EMAIL PROTECTED] wrote:
The Struts 2.0.5 test build is now available.
Release notes:
* http://struts.apache.org/2.x/docs/release-notes-205.html
Distribution:
* http://people.apache.org/builds/struts/2.0.5/
Maven 2 staging repository:
*
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote:
No, it implies no such thing. A binding +1 for GA is a statement that you
believe that the code is of a quality commensurate with a release to a
general audience. It is not an implication of personal support or anything
else. Further, a
On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote:
On 2/7/07, Martin Cooper [EMAIL PROTECTED] wrote:
No, it implies no such thing. A binding +1 for GA is a statement that
you
believe that the code is of a quality commensurate with a release to a
general audience. It is not an implication of
/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8821923
Sent from the Struts - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1 for GA - I'm using it in HostedQA now and it is working great.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=62617messageID=121464#121464
+0 for GA. I have some testing code that looks good, but no production
code that has been converted.
/Ian
Ted Husted wrote:
The Struts 2.0.5 test build is now available.
Release notes:
* http://struts.apache.org/2.x/docs/release-notes-205.html
Distribution:
*
Beta is also an option :)
On 2/6/07, Ian Roughley [EMAIL PROTECTED] wrote:
+0 for GA. I have some testing code that looks good, but no production
code that has been converted.
/Ian
-
To unsubscribe, e-mail: [EMAIL
I disagree; you shouldn't vote beta just because you haven't ran the
code in production. A beta vote should be reserved for the case where
you don't believe the quality is at the level of a GA release, and there
should be specific issues you can point to that you feel need to be
resolved
We might have to agree to disagree. I believe a beta vote is warranted
when someone believes the code is ready for testing outside of the
development group. Personally, I am not in favor of passing a set of
bits straight to GA without a beta cycle, especially when a release
series hasn't seen a
Well, two comments here. First, how many beta releases do we need
before it is time for a GA? I think we've been at beta quality since
2.0.1 and, yes, it has been helpful to weed out issues, but now with
several large applications running Struts 2 and no significant issues in
JIRA, I think
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote:
Well, two comments here. First, how many beta releases do we need
before it is time for a GA? I think we've been at beta quality since
2.0.1 and, yes, it has been helpful to weed out issues, but now with
several large applications running Struts 2
I'm going to do more testing this week, but I think (fear?) I have a
first opinion so far:
[ ] Leave at test build
[ ] Alpha
[ x] Beta
[ ] General Availability (GA)
Especially, I think we're not at GA level, because I have already two
concerns preventing me from seeing the required level
I fully agree with Ted's explanation of vote meanings so
[ ] Leave at test build
[ ] Alpha
[ x] Beta
[ ] General Availability (GA)
./alex
--
.w( the_mindstorm )p.
On 2/7/07, Ted Husted [EMAIL PROTECTED] wrote:
We might have to agree to disagree. I believe a beta vote is warranted
when
On 2/7/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote:
Well, two comments here. First, how many beta releases do we need
before it is time for a GA? I think we've been at beta quality since
2.0.1 and, yes, it has been helpful to weed out issues,
On 2/6/07, Rene Gielen [EMAIL PROTECTED] wrote:
But if we throw out a GA now,
we commit on a certain api stability which I doubt we can guarantee
in nearest future.
The new API is clearly marked experimental, and so I don't feel that
we would be committing to anything. Worse case, we could
On 2/6/07, Craig McClanahan [EMAIL PROTECTED] wrote:
Isn't a feature of the current release practice that you could vote a
particular x.y.z release as beta now, but later hold another vote to
upgrade it to GA status later (i.e. without requiring another release)?
Don's success with it is great
Alexandru Popescu wrote:
I see two clear stages:
- a product that is ready from developers point of view
- a product that gets its users acceptance
An OSS project can take the same approach or not, and this is up to
its management. However, I feel that a project that would like to be
widely
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote:
I would love it if we actually did this. Unfortunately, we don't do the
second step, which is to have a scheduled period that allows fixes to go
in if necessary. What we actually do is freeze the code in a test
build, and put that through an
On 2/6/07, Don Brown [EMAIL PROTECTED] wrote:
Alexandru Popescu wrote:
I see two clear stages:
- a product that is ready from developers point of view
- a product that gets its users acceptance
An OSS project can take the same approach or not, and this is up to
its management. However, I
: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-VOTE--Struts-2.0.5-Quality-tf3175941.html#a8840543
Sent from the Struts - Dev mailing list archive at Nabble.com
Craig,
So feature freeze and branch 2.0.x now, only fix reported bugs from beta
tests and roll out the result as GA, while trunk moves on to 2.1.x,
fully open for new features and whatever? IMO this would be the perfect
way to go, you get a big +1 from me on this :)
- Rene
Craig McClanahan
The Struts 2.0.5 test build is now available.
Release notes:
* http://struts.apache.org/2.x/docs/release-notes-205.html
Distribution:
* http://people.apache.org/builds/struts/2.0.5/
Maven 2 staging repository:
* http://people.apache.org/builds/struts/2.0.5/m2-staging-repository/
If you have
63 matches
Mail list logo
