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] https://issues.apache.org/struts/browse/W
Rainer Hermanns 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
> ope
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 cr
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.
*
https://issues.apache.org/struts/se
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 anoth
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 th
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
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
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
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, woul
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=hide&requestId=10764
A fix for WW-1711 that didn't break the tests (or updated tests) would
be especially welcome!
-Ted.
On 2
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 push
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
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 b
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.
regar
If you want to remove those maven files, you need to update the POM to
include this:
org.apache.maven.plugins
maven-jar-plugin
>>> false
Paul
Musachy Barroso wrote:
Inside the META-INF folder inside the core jar, the
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 PROTECT
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
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
optiontransfe
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
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 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
22 matches
Mail list logo
