Oki, I'll prepare another xwork release during the week :)
cheers,
Rainer
> I am terrible sorry, but I messed up something on xwork trying to make
> convention work with jboss 5. I had to rollback my last change to
> UrlSet. We will have to re-build xwork as I don't have any way to hack
> it from
I am terrible sorry, but I messed up something on xwork trying to make
convention work with jboss 5. I had to rollback my last change to
UrlSet. We will have to re-build xwork as I don't have any way to hack
it from convention.
musachy
On Sun, Aug 16, 2009 at 4:04 AM, Rainer Hermanns wrote:
> Fin
Thanks Rainer.
musachy
On Sun, Aug 16, 2009 at 4:04 AM, Rainer Hermanns wrote:
> Finally done, xwork 2.1.5 is on its way to the mirrors...
> Let's get the S2.1 release out of the door...
>
> Cheers,
> Rainer
>
>
>> it looks better this time ;)
>>
>> On Thu, Aug 13, 2009 at 11:04 PM, Dale Newfield
Finally done, xwork 2.1.5 is on its way to the mirrors...
Let's get the S2.1 release out of the door...
Cheers,
Rainer
> it looks better this time ;)
>
> On Thu, Aug 13, 2009 at 11:04 PM, Dale Newfield wrote:
>> Clearly my attempt at clarification has failed (by 1 character!), as
>> it's
>> need
it looks better this time ;)
On Thu, Aug 13, 2009 at 11:04 PM, Dale Newfield wrote:
> Clearly my attempt at clarification has failed (by 1 character!), as it's
> needed much restating to be precise (and accurate :-). Let me try this
> again:
>
> Struts 2.{0,1} branch depends upon external xwork w
Clearly my attempt at clarification has failed (by 1 character!), as
it's needed much restating to be precise (and accurate :-). Let me try
this again:
Struts 2.{0,1} branch depends upon external xwork with (mostly)
non-matching version numbers
Struts 2.1.8 (assuming GA) will depend upon ex
Sorry to have been unclear here, I wanted to clarify that currently
Struts 2.1.8 is waiting on XW 2.1.5, not 2.1.8 as Dale mentioned.
As for the plan of an integrated module in Struts 2.2, it should of
course carry the Struts release version number.
Paul Benedict schrieb:
> I concur that it shoul
yup I am ok with that.
On Thu, Aug 13, 2009 at 2:32 PM, Rene Gielen wrote:
> Besides the wrong versioning (XW 2.1.5 vs. 2.1.8), that's a reasonable
> plan. To clarify the possible S2.2 plan as I understand (and prefer) it,
> it would be a struts2-xwork module within S2 build and release cycle,
> p
I concur that it should be a module within Struts and thus carry the version
number of the Struts release.
On Thu, Aug 13, 2009 at 4:32 PM, Rene Gielen wrote:
> Besides the wrong versioning (XW 2.1.5 vs. 2.1.8), that's a reasonable
> plan. To clarify the possible S2.2 plan as I understand (and p
Besides the wrong versioning (XW 2.1.5 vs. 2.1.8), that's a reasonable
plan. To clarify the possible S2.2 plan as I understand (and prefer) it,
it would be a struts2-xwork module within S2 build and release cycle,
providing an artifact on which struts2-core depends - could we get a
consensus on thi
My ideas for S3: Better REST support + MVEL. Still working on the second part.
musachy
On Wed, Aug 12, 2009 at 9:27 PM, Brian Pontarelli wrote:
> Why so hesitant to do another release? It has been a long time since 2.0. I
> think it is time for some major rework and releasing a new major version.
On Thu, Aug 13, 2009 at 10:13 AM, Rainer Hermanns wrote:
> Musachy, are you done with your changes?
I have been working off some S2 bugs, but I think I am done with any
changes that involve xwork. Any pending xwork tickets that need work?
musachy
--
"Hey you! Would you help me to carry the stone
Hi folks,
I really like he idea of bringing xwork into ASF.
I'll post my comments about this topic tomorrow,
was too busy to reply yet.
The long awaited xwork release will happen definitely
this weekend.
Musachy, are you done with your changes?
cheers,
Rainer
> On Thu, Aug 13, 2009 at 10:03 A
> -Original Message-
> From: Frans Thamura [mailto:fr...@meruvian.org]
> Sent: Thursday, August 13, 2009 13:00
> To: Struts Developers List
> Subject: Re: Let's kill xwork (was Re: 2.1.8 release?)
>
> any idea to make xwork implementaiton in spring, like p
On Thu, Aug 13, 2009 at 10:03 AM, Dale Newfield wrote:
> struts-2.1.8: still waiting on xwork-2.1.8
struts-2.1.8: waiting on xwork-2.1.5
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail:
Is this an accurate summary?
struts-2.1.8: still waiting on xwork-2.1.8
struts-2.2.x: assuming IP clearance process passes for xwork, fork it
and have it still be a separate jar, but within the struts2 package.
(Probably the only real change would be package names.)
struts-3.x: merge stru
ilto:musa...@gmail.com]
>> Sent: Thursday, August 13, 2009 12:45
>> To: Struts Developers List
>> Subject: Re: Let's kill xwork (was Re: 2.1.8 release?)
>>
>> Have we reached any kind of consensus about bringing xwork
>> in? If we are going to release a new
> -Original Message-
> From: Musachy Barroso [mailto:musa...@gmail.com]
> Sent: Thursday, August 13, 2009 12:45
> To: Struts Developers List
> Subject: Re: Let's kill xwork (was Re: 2.1.8 release?)
>
> Have we reached any kind of consensus about bringing xw
Have we reached any kind of consensus about bringing xwork in? If we
are going to release a new major version could be another discussion.
musachy
On Wed, Aug 12, 2009 at 9:27 PM, Brian Pontarelli wrote:
> Why so hesitant to do another release? It has been a long time since 2.0. I
> think it is t
Why so hesitant to do another release? It has been a long time since
2.0. I think it is time for some major rework and releasing a new
major version.
Sent from my iPhone
On Aug 12, 2009, at 8:06 PM, Don Brown wrote:
On Thu, Aug 13, 2009 at 12:01 PM, Paul
Benedict wrote:
Are you sure it's
Except the API changes. Remember that any API change that breaks
someone should be a major release. That's why people work so hard on
keeping old APIs around.
Sent from my iPhone
On Aug 12, 2009, at 3:45 PM, Wendy Smoak wrote:
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict
wrote:
I defin
On Thu, Aug 13, 2009 at 12:01 PM, Paul Benedict wrote:
> Are you sure it's not an incompatible change? I thought the discussion was
> the importing of XWork and getting rid of its branding. That means all of
> XWork's annotations and packages would be changed to org.apache.struts. I
> don't believe
Are you sure it's not an incompatible change? I thought the discussion was
the importing of XWork and getting rid of its branding. That means all of
XWork's annotations and packages would be changed to org.apache.struts. I
don't believe there is any desire to keep com.opensymphony when this occurs.
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict wrote:
> I definitely agree that Struts 3 would be a good candidate to do this XWork
> migration. It is not an appropriate candidate for 2.1, or 2.2. However, if
> you like to do a 2.5 (I dislike superficial jumps in versions though), then
> it might b
I definitely agree that Struts 3 would be a good candidate to do this XWork
migration. It is not an appropriate candidate for 2.1, or 2.2. However, if
you like to do a 2.5 (I dislike superficial jumps in versions though), then
it might be acceptable in the 2.x branch.
Paul
On Tue, Aug 11, 2009 at
On Tue, Aug 11, 2009 at 9:55 AM, Brian Pontarelli wrote:
> Maybe its time to branch Struts core, drop in xwork, refactor the heck out
> of it, and call it struts 3. Code name the release "Phoenix". :)
"Do you smell that? It's napalm, son. Nothing else on the world smells
like that . I love the sme
On Aug 10, 2009, at 11:52 PM, Don Brown wrote:
On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedict
wrote:
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown
wrote:
By forking XWork, we can a) bring core Struts 2 code into the
project
where it belongs and b) still leave it available for other users
>
> As for Wes having to fix some stuff to make it work, that's a question of
> how long it's been not working properly, and how many people have needed an
> update during that period. That nobody else happened to report an issue
> during that timeframe says nothing about how many people out there
On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedict wrote:
> On Tue, Aug 11, 2009 at 12:22 AM, Don Brown wrote:
>
>> By forking XWork, we can a) bring core Struts 2 code into the project
>> where it belongs and b) still leave it available for other users in
>> OpenSymphony.
>>
>>
> If you fork XWork, i
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown wrote:
> By forking XWork, we can a) bring core Struts 2 code into the project
> where it belongs and b) still leave it available for other users in
> OpenSymphony.
>
>
If you fork XWork, it obviously won't be XWork anymore. If that's what you
want to d
On Tue, Aug 11, 2009 at 3:15 PM, Martin Cooper wrote:
> OK, here's a question that's been on my mind for a while. Why is it that,
> for almost every S2 release, we need to make changes to something as core as
> XWork? Why isn't XWork stable enough by now that we don't have to be
> changing it all t
On Mon, Aug 10, 2009 at 9:57 PM, Musachy Barroso wrote:
> Although I agree in theory, looking at it from a practical point of
> view, that wouldn't make sense. Nobody seems to be interested in using
> XWork outside Struts(yes, yes except that dude), and the proof is that
> it didn't actually work
On Mon, Aug 10, 2009 at 12:30 PM, Musachy Barroso wrote:
> On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper wrote:
> > So, assuming the XWork-consuming developer is not using Maven (sorry,
> Wendy,
> > but that's still most of the world ;), are we planning on providing
> separate
> > download link
Although I agree in theory, looking at it from a practical point of
view, that wouldn't make sense. Nobody seems to be interested in using
XWork outside Struts(yes, yes except that dude), and the proof is that
it didn't actually work until the other day. Why would we try to
support something for wh
To say it has no value outside of Struts, I believe, downplays its ability
to be an independent framework / dependency injection container. I am not
for binding it to Struts. I would vote for being it's own independent Maven
module or vote for it to join Apache Commons.
On Mon, Aug 10, 2009 at 7:3
On Mon, Aug 10, 2009 at 5:22 PM, Don Brown wrote:
> Well, it shouldn't be in the struts2-core jar, but it should be in the
> main Struts project as something like struts2-xwork.jar. There is
> little value trying to bring it in as a new subproject with its own
> release cycle
That's what I meant.
Well, it shouldn't be in the struts2-core jar, but it should be in the
main Struts project as something like struts2-xwork.jar. There is
little value trying to bring it in as a new subproject with its own
release cycle.
I really don't understand the resistance to completely getting rid of
xwork.
I think we have a consensus on bringing XWork in, but we still have to
get to an agreement on where it will actually land (inside core vs its
own artifact), can we get the IP clearing process rolling?
musachy
-
To unsubscribe, e-
> -Original Message-
> From: paulus.benedic...@gmail.com
> [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict
> Sent: Monday, August 10, 2009 16:29
> To: Struts Developers List
> Subject: Re: Let's kill xwork (was Re: 2.1.8 release?)
>
&
If XWork can remain as an independent Maven project, that's good enough for
me. I don't care if it gets built only when Struts gets built. I just hope
we don't import Struts into XWork. So I am +1 with Musachy.
Paul
On Mon, Aug 10, 2009 at 2:30 PM, Musachy Barroso wrote:
> On Mon, Aug 10, 2009
On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper wrote:
> So, assuming the XWork-consuming developer is not using Maven (sorry, Wendy,
> but that's still most of the world ;), are we planning on providing separate
> download links on our web site for *pieces* of our releases, then? Or are we
> going
On Mon, Aug 10, 2009 at 12:12 PM, Wendy Smoak wrote:
> On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper wrote:
> > If we bring it here and embed it within the Struts 2 core, then it will
> > become part of the Struts 2 release, but will no longer be available as
> an
> > independent entity. This m
On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper wrote:
> If we bring it here and embed it within the Struts 2 core, then it will
> become part of the Struts 2 release, but will no longer be available as an
> independent entity. This means it probably will not be usable outside of
> Struts 2, will n
On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper wrote:
> Also, are all of the existing XWork committers already Struts committers? If
> not, what do we plan to do about that?
I haven't checked all the committers, but the active committers are. I
think that making xwork a subproject won't fix the o
Personally, I feel that struts top to bottom should be web centric and
not try to abstract out JEE. This makes life cumbersome and difficult
in many cases. Often this also leads to hacking interfaces or writing
tricky new semantics on top of more general interfaces in order to get
access to
If we bring XWork here and it becomes its own subproject, it will have its
own release cycle. This will allow people to use XWork independently of
Struts, but it means there is still a separate release cycle, independent of
the Struts 2 release cycle. Thus we're in pretty much the same situation as
+1 for moving XW over as a S2 subproject.
Not sure if I'd come dressed in black to that funeral ... :)
Don Brown schrieb:
> XWork was left at OpenSymphony, because at the time, there were a
> number of WebWork developers still around and we wanted to continue to
> work together. Today, WebWork ac
Just make XWork a subproject of Struts. Then everyone can be happy.
I'm all for this ;) (http://markmail.org/message/nykgr354ts4hlkif)
-bp
On Aug 5, 2009, at 11:12 PM, Don Brown wrote:
XWork was left at OpenSymphony, because at the time, there were a
number of WebWork developers still around and we wanted to continue to
work together. Today, WebWork activity
On Thu, Aug 6, 2009 at 4:22 PM, Musachy Barroso wrote:
> Sounds reasonable to me. Couple of question to fuel discussion:
>
> What would be the target version?
> Do we need to go through incubation, etc? (I have never known much
> about the ASF legal process)
The code would definitely have to go th
Sounds reasonable to me. Couple of question to fuel discussion:
What would be the target version?
Do we need to go through incubation, etc? (I have never known much
about the ASF legal process)
musachy
On Wed, Aug 5, 2009 at 10:12 PM, Don Brown wrote:
> XWork was left at OpenSymphony, because at
XWork was left at OpenSymphony, because at the time, there were a
number of WebWork developers still around and we wanted to continue to
work together. Today, WebWork activity seems all but dead, leaving us
with no advantages having the code hosted over there. Furthermore,
having critical code in
52 matches
Mail list logo
