In the case where we have a public beta, I wonder if we should make it
a practice to hold any subsequent quality vote on user@ rather than
[EMAIL PROTECTED] We could post a note to the initial quality vote, to be sure
everyone is in the loop, but holding the vote on user@ would give
other people
Ted,
I am releasing OGNL 2.6.10 now...
If everything goes well, I'll follow up with XWork 2.0.1 as well...
Perhaps you want to wait for these releases?
-Rainer
In the case where we have a public beta, I wonder if we should make it
a practice to hold any subsequent quality vote on user@ rather
On 2/15/07, Ted Husted [EMAIL PROTECTED] wrote:
In the case where we have a public beta, I wonder if we should make it
a practice to hold any subsequent quality vote on user@
Is purpose of this is to get more user feedback on the voting? Or is it so
users see what's going on since the beta
Do you have an ETA? If we are talking about tomorrow or Saturday, I'd
be inclined to wait. Otherwise, I'd be inclined to do 2.0.6 now and
2.0.7 later, with the new OGNL and XWork.
-Ted.
On 2/15/07, Rainer Hermanns [EMAIL PROTECTED] wrote:
Ted,
I am releasing OGNL 2.6.10 now...
If everything
Both. If the post-beta vote happens on user@, we are more likely to
get feedback, and we would be encouraging people to try the beta, so
that they can get in on the fun of the vote :)
On 2/15/07, Greg Reddin [EMAIL PROTECTED] wrote:
Is purpose of this is to get more user feedback on the voting?
Within the next 24 hours...
-Rainer
Do you have an ETA? If we are talking about tomorrow or Saturday, I'd
be inclined to wait. Otherwise, I'd be inclined to do 2.0.6 now and
2.0.7 later, with the new OGNL and XWork.
-Ted.
On 2/15/07, Rainer Hermanns [EMAIL PROTECTED] wrote:
Ted,
I am
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
I can't assign to myself tickets I didn't report, or change the status of
the ones that I did report. karma?
regards
musachy
--
Hey you! Would you help me to carry the stone? Pink Floyd
You should have now.
Niall
On 2/16/07, Musachy Barroso [EMAIL PROTECTED] wrote:
I can't assign to myself tickets I didn't report, or change the status of
the ones that I did report. karma?
regards
musachy
-
To unsubscribe,
13 matches
Mail list logo
