You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <do...@gmail.com> on 2009/08/06 07:12:14 UTC
Let's kill xwork (was Re: 2.1.8 release?)
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 different packages is really confusing for
developers of the framework and its apps with no apparent benefit.
Ideally, I'd like to bring xwork trunk into the core jar and be done
with the theoretically useful yet practically painful split. However,
that would break Struts 2 apps without tedious backwards-compatibility
code, but getting the code bases integrated is the first step. Maybe
at first, we keep two artifacts, but I think we should think about a
serious migration to just one. XWork itself will always be around,
but trying to put a framework at our core that is meant for ambiguous
theoretical users brings unnecessary complexity and problems to all
parties.
Can I start planning the funeral? :)
Don
On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com> wrote:
> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
> [snip]
>>
>> I was going to ask if anyone was using it outside struts, but that
>> doesn't prevent us from making it it's own artifact.
>>
> [snip]
>>
>> I don't think this would fix the problem, which is the duplicated
>> effort on the builds. A good compromise would be to keep it under its
>> own artifact under struts, just like core, that way we would need just
>> one release and it could still be used independently. I haven't cared
>> much before, but if it will make our releases easier/smoother, then I
>> am +1 for it.
>>
>
> being its own artifact makes more sense, it would make releasing the two much
> easier, on second thought I agree with this. My only real concern is that I
> can get to it w/o struts. The context I am working with now doesn't fit well
> with struts, and adding struts means I would have to do even more work getting
> a base configuration so that xwork can run actions. One example that sticks out
> in my mind is that when I run actions, each action execution gets its own
> thread and one of the results I built for this project launches from 1 to
> infinite more actions. Obviously it wouldn't make sense to chain to multiple
> actions in a web-app and since a view is rendered in struts, having actions
> run in a separate thread wouldn't work well in a web-app.
>
> -W
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Don Brown <do...@gmail.com>.
On Thu, Aug 6, 2009 at 4:22 PM, Musachy Barroso<mu...@gmail.com> 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 through an IP clearance step,
which I'd be happy to help with. The target version will just be the
Struts version - no need for a separate release cycle.
Don
>
> musachy
>
> On Wed, Aug 5, 2009 at 10:12 PM, Don Brown<do...@gmail.com> 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 seems all but dead, leaving us
>> with no advantages having the code hosted over there. Furthermore,
>> having critical code in different packages is really confusing for
>> developers of the framework and its apps with no apparent benefit.
>>
>> Ideally, I'd like to bring xwork trunk into the core jar and be done
>> with the theoretically useful yet practically painful split. However,
>> that would break Struts 2 apps without tedious backwards-compatibility
>> code, but getting the code bases integrated is the first step. Maybe
>> at first, we keep two artifacts, but I think we should think about a
>> serious migration to just one. XWork itself will always be around,
>> but trying to put a framework at our core that is meant for ambiguous
>> theoretical users brings unnecessary complexity and problems to all
>> parties.
>>
>> Can I start planning the funeral? :)
>>
>> Don
>>
>> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com> wrote:
>>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
>>> [snip]
>>>>
>>>> I was going to ask if anyone was using it outside struts, but that
>>>> doesn't prevent us from making it it's own artifact.
>>>>
>>> [snip]
>>>>
>>>> I don't think this would fix the problem, which is the duplicated
>>>> effort on the builds. A good compromise would be to keep it under its
>>>> own artifact under struts, just like core, that way we would need just
>>>> one release and it could still be used independently. I haven't cared
>>>> much before, but if it will make our releases easier/smoother, then I
>>>> am +1 for it.
>>>>
>>>
>>> being its own artifact makes more sense, it would make releasing the two much
>>> easier, on second thought I agree with this. My only real concern is that I
>>> can get to it w/o struts. The context I am working with now doesn't fit well
>>> with struts, and adding struts means I would have to do even more work getting
>>> a base configuration so that xwork can run actions. One example that sticks out
>>> in my mind is that when I run actions, each action execution gets its own
>>> thread and one of the results I built for this project launches from 1 to
>>> infinite more actions. Obviously it wouldn't make sense to chain to multiple
>>> actions in a web-app and since a view is rendered in struts, having actions
>>> run in a separate thread wouldn't work well in a web-app.
>>>
>>> -W
>>>
>>> --
>>> Wes Wannemacher
>>>
>>> Head Engineer, WanTii, Inc.
>>> Need Training? Struts, Spring, Maven, Tomcat...
>>> Ask me for a quote!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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<do...@gmail.com> 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 seems all but dead, leaving us
> with no advantages having the code hosted over there. Furthermore,
> having critical code in different packages is really confusing for
> developers of the framework and its apps with no apparent benefit.
>
> Ideally, I'd like to bring xwork trunk into the core jar and be done
> with the theoretically useful yet practically painful split. However,
> that would break Struts 2 apps without tedious backwards-compatibility
> code, but getting the code bases integrated is the first step. Maybe
> at first, we keep two artifacts, but I think we should think about a
> serious migration to just one. XWork itself will always be around,
> but trying to put a framework at our core that is meant for ambiguous
> theoretical users brings unnecessary complexity and problems to all
> parties.
>
> Can I start planning the funeral? :)
>
> Don
>
> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com> wrote:
>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
>> [snip]
>>>
>>> I was going to ask if anyone was using it outside struts, but that
>>> doesn't prevent us from making it it's own artifact.
>>>
>> [snip]
>>>
>>> I don't think this would fix the problem, which is the duplicated
>>> effort on the builds. A good compromise would be to keep it under its
>>> own artifact under struts, just like core, that way we would need just
>>> one release and it could still be used independently. I haven't cared
>>> much before, but if it will make our releases easier/smoother, then I
>>> am +1 for it.
>>>
>>
>> being its own artifact makes more sense, it would make releasing the two much
>> easier, on second thought I agree with this. My only real concern is that I
>> can get to it w/o struts. The context I am working with now doesn't fit well
>> with struts, and adding struts means I would have to do even more work getting
>> a base configuration so that xwork can run actions. One example that sticks out
>> in my mind is that when I run actions, each action execution gets its own
>> thread and one of the results I built for this project launches from 1 to
>> infinite more actions. Obviously it wouldn't make sense to chain to multiple
>> actions in a web-app and since a view is rendered in struts, having actions
>> run in a separate thread wouldn't work well in a web-app.
>>
>> -W
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
Just make XWork a subproject of Struts. Then everyone can be happy.
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 seems all but dead, leaving us
> with no advantages having the code hosted over there. Furthermore,
> having critical code in different packages is really confusing for
> developers of the framework and its apps with no apparent benefit.
>
> Ideally, I'd like to bring xwork trunk into the core jar and be done
> with the theoretically useful yet practically painful split. However,
> that would break Struts 2 apps without tedious backwards-compatibility
> code, but getting the code bases integrated is the first step. Maybe
> at first, we keep two artifacts, but I think we should think about a
> serious migration to just one. XWork itself will always be around,
> but trying to put a framework at our core that is meant for ambiguous
> theoretical users brings unnecessary complexity and problems to all
> parties.
>
> Can I start planning the funeral? :)
>
> Don
>
> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com>
> wrote:
>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
>> [snip]
>>>
>>> I was going to ask if anyone was using it outside struts, but that
>>> doesn't prevent us from making it it's own artifact.
>>>
>> [snip]
>>>
>>> I don't think this would fix the problem, which is the duplicated
>>> effort on the builds. A good compromise would be to keep it under
>>> its
>>> own artifact under struts, just like core, that way we would need
>>> just
>>> one release and it could still be used independently. I haven't
>>> cared
>>> much before, but if it will make our releases easier/smoother,
>>> then I
>>> am +1 for it.
>>>
>>
>> being its own artifact makes more sense, it would make releasing
>> the two much
>> easier, on second thought I agree with this. My only real concern
>> is that I
>> can get to it w/o struts. The context I am working with now doesn't
>> fit well
>> with struts, and adding struts means I would have to do even more
>> work getting
>> a base configuration so that xwork can run actions. One example
>> that sticks out
>> in my mind is that when I run actions, each action execution gets
>> its own
>> thread and one of the results I built for this project launches
>> from 1 to
>> infinite more actions. Obviously it wouldn't make sense to chain to
>> multiple
>> actions in a web-app and since a view is rendered in struts, having
>> actions
>> run in a separate thread wouldn't work well in a web-app.
>>
>> -W
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper<ma...@apache.org> 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 original problem (2
release cycles), keeping it as it own maven artifact should be a good
compromise in the meantime, one release cycle, and it is still
independent.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
>
> 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 are using
> it. For all you know, 20 people might have downloaded it the day after Wes
> fixed it. Sounds crazy? Perhaps, but so does assuming nobody is using it
> just because there's no noise on the list.
Besides, bug fixes (things in which these ninja users might be
interested) in xwork are very few on every release of xwork. We
usually need a new release because new things get added, like lets say
the classpath scanner, or the reloading class loader. Because we have
this "invisible" line, that divides struts from xwork, these things
get added to xwork, instead of struts. If we were to add these new
features to struts, then xwork releases would be needed very far
between them.
We can argue about the ninja users all we want, but there are 2 hard facts:
1. We depend on xwork and need it released to release struts 2
2. There is only one person that does xwork releases
When I see someone volunteering on #2, then I will believe that #1
doesn't need to be fixed. The only ways I see of fixing #1 is to bring
xwork in, as suggested, or to stop putting new code in xwork, which
will eventually grow quieter and quieter until it is abandoned, and
then, when we do have to fix an issue in it, we will have this
argument again.
Any volunteers for #2?
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Martin Cooper <ma...@apache.org>.
On Mon, Aug 10, 2009 at 12:30 PM, Musachy Barroso <mu...@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper<ma...@apache.org> 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 to tell people to download the entire Struts 2 release and then
> throw
> > most of it away?
> >
>
> I don't think anyone is using XWork by itself except Wes. Wes had to
> fix some stuff to make XWork work in stand alone mode, so if nobody
> has complained about it before, it means very few (if any) users are
> using it like this, so we should not get too worried about it.
We really have no idea how many people are using XWork standalone. None.
Every developer - including every one of us - uses loads of other packages
without getting involved in their communities or developer lists or
whatever. There's just no way to judge how many such people there are for
XWork.
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 are using
it. For all you know, 20 people might have downloaded it the day after Wes
fixed it. Sounds crazy? Perhaps, but so does assuming nobody is using it
just because there's no noise on the list.
--
Martin Cooper
>
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
RE: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: paulus.benedictus@gmail.com
> [mailto:paulus.benedictus@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.
I too am for separate jars with a single build event.
>
> Paul
>
> On Mon, Aug 10, 2009 at 2:30 PM, Musachy Barroso
> <mu...@gmail.com> wrote:
>
> > On Mon, Aug 10, 2009 at 12:21 PM, Martin
> Cooper<ma...@apache.org> 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 to tell people to download the entire Struts 2 release and
> > > then
> > throw
> > > most of it away?
> > >
> >
> > I don't think anyone is using XWork by itself except Wes.
> Wes had to
> > fix some stuff to make XWork work in stand alone mode, so if nobody
> > has complained about it before, it means very few (if any)
> users are
> > using it like this, so we should not get too worried about it.
> >
> > musachy
> > --
> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
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 <mu...@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper<ma...@apache.org> 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 to tell people to download the entire Struts 2 release and then
> throw
> > most of it away?
> >
>
> I don't think anyone is using XWork by itself except Wes. Wes had to
> fix some stuff to make XWork work in stand alone mode, so if nobody
> has complained about it before, it means very few (if any) users are
> using it like this, so we should not get too worried about it.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Mon, Aug 10, 2009 at 12:21 PM, Martin Cooper<ma...@apache.org> 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 to tell people to download the entire Struts 2 release and then throw
> most of it away?
>
I don't think anyone is using XWork by itself except Wes. Wes had to
fix some stuff to make XWork work in stand alone mode, so if nobody
has complained about it before, it means very few (if any) users are
using it like this, so we should not get too worried about it.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Martin Cooper <ma...@apache.org>.
On Mon, Aug 10, 2009 at 12:12 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper<ma...@apache.org> 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 not be identifiable as an independent entity, and almost
> > certainly will lose its identity as a separately usable library.
>
> I don't think this is true. Even if it's part of the Struts codebase
> and built together, it can still be a separate jar, usable by anyone
> with our without Struts (as long as the developers take care not to
> introduce any dependencies.)
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 to tell people to download the entire Struts 2 release and then throw
most of it away?
--
Martin Cooper
'Marketing' wise it will be a tougher sell to use it independently as
> it will be seen as "part of" Struts, but that's a different issue.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Wendy Smoak <ws...@gmail.com>.
On Mon, Aug 10, 2009 at 10:32 AM, Martin Cooper<ma...@apache.org> 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 not be identifiable as an independent entity, and almost
> certainly will lose its identity as a separately usable library.
I don't think this is true. Even if it's part of the Struts codebase
and built together, it can still be a separate jar, usable by anyone
with our without Struts (as long as the developers take care not to
introduce any dependencies.)
'Marketing' wise it will be a tougher sell to use it independently as
it will be seen as "part of" Struts, but that's a different issue.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 the web APIs. I'd vote for dropping it into core and slowly
rewriting it to be 100% web centric. This is also my feeling about
OGNL/MVEL or any expression language. The expression language for
struts should be written to handle all the crazy cases that come up
with the web, specifically type conversions.
-bp
On Aug 10, 2009, at 11:32 AM, Martin Cooper wrote:
> 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
> we are now, except for the location of the code base.
>
> 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 not be identifiable as an independent entity, and
> almost
> certainly will lose its identity as a separately usable library.
>
> Which are we trying to do? I am hearing advocates of both
> approaches, each
> with their own pros and cons...
>
> Also, are all of the existing XWork committers already Struts
> committers? If
> not, what do we plan to do about that?
>
> --
> Martin Cooper
>
>
> On Wed, Aug 5, 2009 at 10:12 PM, Don Brown <do...@gmail.com>
> 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 seems all but dead, leaving
>> us
>> with no advantages having the code hosted over there. Furthermore,
>> having critical code in different packages is really confusing for
>> developers of the framework and its apps with no apparent benefit.
>>
>> Ideally, I'd like to bring xwork trunk into the core jar and be done
>> with the theoretically useful yet practically painful split.
>> However,
>> that would break Struts 2 apps without tedious backwards-
>> compatibility
>> code, but getting the code bases integrated is the first step. Maybe
>> at first, we keep two artifacts, but I think we should think about a
>> serious migration to just one. XWork itself will always be around,
>> but trying to put a framework at our core that is meant for ambiguous
>> theoretical users brings unnecessary complexity and problems to all
>> parties.
>>
>> Can I start planning the funeral? :)
>>
>> Don
>>
>> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com>
>> wrote:
>>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
>>> [snip]
>>>>
>>>> I was going to ask if anyone was using it outside struts, but that
>>>> doesn't prevent us from making it it's own artifact.
>>>>
>>> [snip]
>>>>
>>>> I don't think this would fix the problem, which is the duplicated
>>>> effort on the builds. A good compromise would be to keep it under
>>>> its
>>>> own artifact under struts, just like core, that way we would need
>>>> just
>>>> one release and it could still be used independently. I haven't
>>>> cared
>>>> much before, but if it will make our releases easier/smoother,
>>>> then I
>>>> am +1 for it.
>>>>
>>>
>>> being its own artifact makes more sense, it would make releasing
>>> the two
>> much
>>> easier, on second thought I agree with this. My only real concern
>>> is that
>> I
>>> can get to it w/o struts. The context I am working with now
>>> doesn't fit
>> well
>>> with struts, and adding struts means I would have to do even more
>>> work
>> getting
>>> a base configuration so that xwork can run actions. One example that
>> sticks out
>>> in my mind is that when I run actions, each action execution gets
>>> its own
>>> thread and one of the results I built for this project launches
>>> from 1 to
>>> infinite more actions. Obviously it wouldn't make sense to chain to
>> multiple
>>> actions in a web-app and since a view is rendered in struts, having
>> actions
>>> run in a separate thread wouldn't work well in a web-app.
>>>
>>> -W
>>>
>>> --
>>> Wes Wannemacher
>>>
>>> Head Engineer, WanTii, Inc.
>>> Need Training? Struts, Spring, Maven, Tomcat...
>>> Ask me for a quote!
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Martin Cooper <ma...@apache.org>.
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
we are now, except for the location of the code base.
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 not be identifiable as an independent entity, and almost
certainly will lose its identity as a separately usable library.
Which are we trying to do? I am hearing advocates of both approaches, each
with their own pros and cons...
Also, are all of the existing XWork committers already Struts committers? If
not, what do we plan to do about that?
--
Martin Cooper
On Wed, Aug 5, 2009 at 10:12 PM, Don Brown <do...@gmail.com> 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 seems all but dead, leaving us
> with no advantages having the code hosted over there. Furthermore,
> having critical code in different packages is really confusing for
> developers of the framework and its apps with no apparent benefit.
>
> Ideally, I'd like to bring xwork trunk into the core jar and be done
> with the theoretically useful yet practically painful split. However,
> that would break Struts 2 apps without tedious backwards-compatibility
> code, but getting the code bases integrated is the first step. Maybe
> at first, we keep two artifacts, but I think we should think about a
> serious migration to just one. XWork itself will always be around,
> but trying to put a framework at our core that is meant for ambiguous
> theoretical users brings unnecessary complexity and problems to all
> parties.
>
> Can I start planning the funeral? :)
>
> Don
>
> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com> wrote:
> > On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
> > [snip]
> >>
> >> I was going to ask if anyone was using it outside struts, but that
> >> doesn't prevent us from making it it's own artifact.
> >>
> > [snip]
> >>
> >> I don't think this would fix the problem, which is the duplicated
> >> effort on the builds. A good compromise would be to keep it under its
> >> own artifact under struts, just like core, that way we would need just
> >> one release and it could still be used independently. I haven't cared
> >> much before, but if it will make our releases easier/smoother, then I
> >> am +1 for it.
> >>
> >
> > being its own artifact makes more sense, it would make releasing the two
> much
> > easier, on second thought I agree with this. My only real concern is that
> I
> > can get to it w/o struts. The context I am working with now doesn't fit
> well
> > with struts, and adding struts means I would have to do even more work
> getting
> > a base configuration so that xwork can run actions. One example that
> sticks out
> > in my mind is that when I run actions, each action execution gets its own
> > thread and one of the results I built for this project launches from 1 to
> > infinite more actions. Obviously it wouldn't make sense to chain to
> multiple
> > actions in a web-app and since a view is rendered in struts, having
> actions
> > run in a separate thread wouldn't work well in a web-app.
> >
> > -W
> >
> > --
> > Wes Wannemacher
> >
> > Head Engineer, WanTii, Inc.
> > Need Training? Struts, Spring, Maven, Tomcat...
> > Ask me for a quote!
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Thu, Aug 13, 2009 at 10:13 AM, Rainer Hermanns<he...@aixcept.de> 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?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rainer Hermanns <he...@aixcept.de>.
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 AM, Dale Newfield<da...@newfield.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Rainer Hermanns
aixcept
Willibrordstraße 82
52134 Herzogenrath - Germany
w: http://aixcept.de/
t: +49 - 2406 - 979 22 11
f: +49 - 2406 - 979 22 13
m: +49 - 170 - 343 29 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Thu, Aug 13, 2009 at 10:03 AM, Dale Newfield<da...@newfield.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
Thanks Rainer.
musachy
On Sun, Aug 16, 2009 at 4:04 AM, Rainer Hermanns<he...@aixcept.de> 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<da...@newfield.org> 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 with (mostly)
>>> non-matching
>>> version numbers
>>>
>>> Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
>>>
>>> Struts 2.2.x is proposed to depend upon a forked, internal jar named
>>> struts2-xwork that will get generated as another artifact within the
>>> struts2
>>> release, and thus will share version numbers with struts2.2 releases.
>>>
>>> Struts 3.x is proposed to not depend upon any xwork component, as the
>>> two
>>> codebases will be merged into one.
>>>
>>>
>>> Is there any dissent from this plan?
>>>
>>> -Dale
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Rainer Hermanns
> aixcept
> Willibrordstraße 82
> 52134 Herzogenrath - Germany
> w: http://aixcept.de/
> t: +49 - 2406 - 979 22 11
> f: +49 - 2406 - 979 22 13
> m: +49 - 170 - 343 29 12
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rainer Hermanns <he...@aixcept.de>.
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 convention.
>
> musachy
>
> On Sun, Aug 16, 2009 at 4:04 AM, Rainer Hermanns<he...@aixcept.de>
> 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<da...@newfield.org>
>>> 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 with (mostly)
>>>> non-matching
>>>> version numbers
>>>>
>>>> Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
>>>>
>>>> Struts 2.2.x is proposed to depend upon a forked, internal jar named
>>>> struts2-xwork that will get generated as another artifact within the
>>>> struts2
>>>> release, and thus will share version numbers with struts2.2 releases.
>>>>
>>>> Struts 3.x is proposed to not depend upon any xwork component, as the
>>>> two
>>>> codebases will be merged into one.
>>>>
>>>>
>>>> Is there any dissent from this plan?
>>>>
>>>> -Dale
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> --
>> Rainer Hermanns
>> aixcept
>> Willibrordstraße 82
>> 52134 Herzogenrath - Germany
>> w: http://aixcept.de/
>> t: +49 - 2406 - 979 22 11
>> f: +49 - 2406 - 979 22 13
>> m: +49 - 170 - 343 29 12
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Rainer Hermanns
aixcept
Willibrordstraße 82
52134 Herzogenrath - Germany
w: http://aixcept.de/
t: +49 - 2406 - 979 22 11
f: +49 - 2406 - 979 22 13
m: +49 - 170 - 343 29 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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<he...@aixcept.de> 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<da...@newfield.org> 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 with (mostly)
>>> non-matching
>>> version numbers
>>>
>>> Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
>>>
>>> Struts 2.2.x is proposed to depend upon a forked, internal jar named
>>> struts2-xwork that will get generated as another artifact within the
>>> struts2
>>> release, and thus will share version numbers with struts2.2 releases.
>>>
>>> Struts 3.x is proposed to not depend upon any xwork component, as the
>>> two
>>> codebases will be merged into one.
>>>
>>>
>>> Is there any dissent from this plan?
>>>
>>> -Dale
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> --
> Rainer Hermanns
> aixcept
> Willibrordstraße 82
> 52134 Herzogenrath - Germany
> w: http://aixcept.de/
> t: +49 - 2406 - 979 22 11
> f: +49 - 2406 - 979 22 13
> m: +49 - 170 - 343 29 12
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rainer Hermanns <he...@aixcept.de>.
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<da...@newfield.org> 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 with (mostly)
>> non-matching
>> version numbers
>>
>> Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
>>
>> Struts 2.2.x is proposed to depend upon a forked, internal jar named
>> struts2-xwork that will get generated as another artifact within the
>> struts2
>> release, and thus will share version numbers with struts2.2 releases.
>>
>> Struts 3.x is proposed to not depend upon any xwork component, as the
>> two
>> codebases will be merged into one.
>>
>>
>> Is there any dissent from this plan?
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
Rainer Hermanns
aixcept
Willibrordstraße 82
52134 Herzogenrath - Germany
w: http://aixcept.de/
t: +49 - 2406 - 979 22 11
f: +49 - 2406 - 979 22 13
m: +49 - 170 - 343 29 12
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
it looks better this time ;)
On Thu, Aug 13, 2009 at 11:04 PM, Dale Newfield<da...@newfield.org> 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 with (mostly) non-matching
> version numbers
>
> Struts 2.1.8 (assuming GA) will depend upon external xwork 2.1.5
>
> Struts 2.2.x is proposed to depend upon a forked, internal jar named
> struts2-xwork that will get generated as another artifact within the struts2
> release, and thus will share version numbers with struts2.2 releases.
>
> Struts 3.x is proposed to not depend upon any xwork component, as the two
> codebases will be merged into one.
>
>
> Is there any dissent from this plan?
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Dale Newfield <da...@newfield.org>.
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 external xwork 2.1.5
Struts 2.2.x is proposed to depend upon a forked, internal jar named
struts2-xwork that will get generated as another artifact within the
struts2 release, and thus will share version numbers with struts2.2
releases.
Struts 3.x is proposed to not depend upon any xwork component, as the
two codebases will be merged into one.
Is there any dissent from this plan?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rene Gielen <gi...@it-neering.net>.
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 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 <gi...@it-neering.net> 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,
>> providing an artifact on which struts2-core depends - could we get a
>> consensus on this?
>>
>> Dale Newfield schrieb:
>>> 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 struts2 and xwork.
>>>
>>> -Dale
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>> --
>> René Gielen
>> IT-Neering.net
>> Saarstrasse 100, 52062 Aachen, Germany
>> Tel: +49-(0)241-4010770
>> Fax: +49-(0)241-4010771
>> Cel: +49-(0)177-3194448
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
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 <gi...@it-neering.net> 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,
> providing an artifact on which struts2-core depends - could we get a
> consensus on this?
>
> Dale Newfield schrieb:
> > 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 struts2 and xwork.
> >
> > -Dale
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)177-3194448
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
yup I am ok with that.
On Thu, Aug 13, 2009 at 2:32 PM, Rene Gielen<gi...@it-neering.net> 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,
> providing an artifact on which struts2-core depends - could we get a
> consensus on this?
>
> Dale Newfield schrieb:
>> 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 struts2 and xwork.
>>
>> -Dale
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --
> René Gielen
> IT-Neering.net
> Saarstrasse 100, 52062 Aachen, Germany
> Tel: +49-(0)241-4010770
> Fax: +49-(0)241-4010771
> Cel: +49-(0)177-3194448
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Frans Thamura [mailto:frans@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 pendulum did
Please no, we have to many projects/customers where spring is not approved.
>
> so struts will have non web implementation
>
> will this happen?
>
>
> --
> Frans Thamura
> Meruvian.
> Center of Java and Enterprise OpenSource
>
> Meruvian bukan hanya membuat anak SMK menjadi bisa tapi
> SAKTI, malah saktinya SAKTI Mandraguna.
>
>
> Mobile: +62 855 7888 699
> Blog & Profile: http://frans.thamura.info
>
> We provide services to migrate your apps to Java (web), in
> amazing fast and reliable.
>
>
>
> On Fri, Aug 14, 2009 at 12:00 AM, Jason
> Pyeron<jp...@pdinc.us> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Musachy Barroso [mailto:musachy@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 major version could be another
> discussion.
> >
> >
> > (Assumption: waiting on release because patches made to
> trunk not yet included
> > into released jar....)
> >
> > Why can we use their trunk or snapshots?
> >
> > If we fork we are essentially loosing their QA process anyway...
> >
> > My .02$
> >
> >>
> >> musachy
> >>
> >> On Wed, Aug 12, 2009 at 9:27 PM, Brian
> >> Pontarelli<br...@pontarelli.com> 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.
> >> >
> >> > Sent from my iPhone
> >> >
> >> > On Aug 12, 2009, at 8:06 PM, Don Brown <mr...@twdata.org> wrote:
> >> >
> >> >> On Thu, Aug 13, 2009 at 12:01 PM, Paul
> >> Benedict<pb...@apache.org>
> >> >> 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 there is
> >> any desire
> >> >>> to keep com.opensymphony when this occurs.
> >> >>> So my thinking would be this would be an incompatible
> >> change. Did I
> >> >>> get it wrong?
> >> >>
> >> >> I think completely removing any trace of xwork is a
> good long term
> >> >> 3.0 goal, but for now, we would simply fork it, keeping
> >> the package
> >> >> structure and class names.
> >> >>
> >> >> Don
> >> >>
> >> >>>
> >> >>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak
> >> <ws...@gmail.com> wrote:
> >> >>>
> >> >>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul
> >> >>>> Benedict<pb...@apache.org>
> >> >>>> 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 be acceptable in the 2.x branch.
> >> >>>>
> >> >>>> IMO "Struts 3" would imply a major change in Struts
> itself, the
> >> >>>> possibility of backwards incompatible changes, etc.
> >> This isn't...
> >> >>>> community aspects aside, it's just moving some code
> from one svn
> >> >>>> repo to another. -Wendy
> >> >>>>
> >> >>>>
> >> -------------------------------------------------------------------
> >> >>>> -- To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org For
> >> >>>> additional commands, e-mail: dev-help@struts.apache.org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> >> additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> > additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> > --
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > - -
> > - Jason Pyeron PD Inc. http://www.pdinc.us -
> > - Principal Consultant 10 West 24th Street #100 -
> > - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> > - -
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > This message is copyright PD Inc, subject to license 20080407P00.
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Frans Thamura <fr...@meruvian.org>.
any idea to make xwork implementaiton in spring, like pendulum did
so struts will have non web implementation
will this happen?
--
Frans Thamura
Meruvian.
Center of Java and Enterprise OpenSource
Meruvian bukan hanya membuat anak SMK menjadi bisa tapi SAKTI, malah
saktinya SAKTI Mandraguna.
Mobile: +62 855 7888 699
Blog & Profile: http://frans.thamura.info
We provide services to migrate your apps to Java (web), in amazing
fast and reliable.
On Fri, Aug 14, 2009 at 12:00 AM, Jason Pyeron<jp...@pdinc.us> wrote:
>
>
>> -----Original Message-----
>> From: Musachy Barroso [mailto:musachy@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 major version could be
>> another discussion.
>
>
> (Assumption: waiting on release because patches made to trunk not yet included
> into released jar....)
>
> Why can we use their trunk or snapshots?
>
> If we fork we are essentially loosing their QA process anyway...
>
> My .02$
>
>>
>> musachy
>>
>> On Wed, Aug 12, 2009 at 9:27 PM, Brian
>> Pontarelli<br...@pontarelli.com> 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.
>> >
>> > Sent from my iPhone
>> >
>> > On Aug 12, 2009, at 8:06 PM, Don Brown <mr...@twdata.org> wrote:
>> >
>> >> On Thu, Aug 13, 2009 at 12:01 PM, Paul
>> Benedict<pb...@apache.org>
>> >> 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 there is
>> any desire
>> >>> to keep com.opensymphony when this occurs.
>> >>> So my thinking would be this would be an incompatible
>> change. Did I
>> >>> get it wrong?
>> >>
>> >> I think completely removing any trace of xwork is a good long term
>> >> 3.0 goal, but for now, we would simply fork it, keeping
>> the package
>> >> structure and class names.
>> >>
>> >> Don
>> >>
>> >>>
>> >>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak
>> <ws...@gmail.com> wrote:
>> >>>
>> >>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul
>> >>>> Benedict<pb...@apache.org>
>> >>>> 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 be acceptable in the 2.x branch.
>> >>>>
>> >>>> IMO "Struts 3" would imply a major change in Struts itself, the
>> >>>> possibility of backwards incompatible changes, etc.
>> This isn't...
>> >>>> community aspects aside, it's just moving some code from one svn
>> >>>> repo to another. -Wendy
>> >>>>
>> >>>>
>> -------------------------------------------------------------------
>> >>>> -- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> >>>> additional commands, e-mail: dev-help@struts.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> >> additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> > additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron PD Inc. http://www.pdinc.us -
> - Principal Consultant 10 West 24th Street #100 -
> - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rene Gielen <gi...@it-neering.net>.
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 this?
Dale Newfield schrieb:
> 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 struts2 and xwork.
>
> -Dale
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Dale Newfield <da...@newfield.org>.
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 struts2 and xwork.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Jason Pyeron <jp...@pdinc.us>.
> -----Original Message-----
> From: Musachy Barroso [mailto:musachy@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 major version could be
> another discussion.
(Assumption: waiting on release because patches made to trunk not yet included
into released jar....)
Why can we use their trunk or snapshots?
If we fork we are essentially loosing their QA process anyway...
My .02$
>
> musachy
>
> On Wed, Aug 12, 2009 at 9:27 PM, Brian
> Pontarelli<br...@pontarelli.com> 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.
> >
> > Sent from my iPhone
> >
> > On Aug 12, 2009, at 8:06 PM, Don Brown <mr...@twdata.org> wrote:
> >
> >> On Thu, Aug 13, 2009 at 12:01 PM, Paul
> Benedict<pb...@apache.org>
> >> 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 there is
> any desire
> >>> to keep com.opensymphony when this occurs.
> >>> So my thinking would be this would be an incompatible
> change. Did I
> >>> get it wrong?
> >>
> >> I think completely removing any trace of xwork is a good long term
> >> 3.0 goal, but for now, we would simply fork it, keeping
> the package
> >> structure and class names.
> >>
> >> Don
> >>
> >>>
> >>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak
> <ws...@gmail.com> wrote:
> >>>
> >>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul
> >>>> Benedict<pb...@apache.org>
> >>>> 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 be acceptable in the 2.x branch.
> >>>>
> >>>> IMO "Struts 3" would imply a major change in Struts itself, the
> >>>> possibility of backwards incompatible changes, etc.
> This isn't...
> >>>> community aspects aside, it's just moving some code from one svn
> >>>> repo to another. -Wendy
> >>>>
> >>>>
> -------------------------------------------------------------------
> >>>> -- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >>>> additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
>
>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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<br...@pontarelli.com> 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.
>
> Sent from my iPhone
>
> On Aug 12, 2009, at 8:06 PM, Don Brown <mr...@twdata.org> wrote:
>
>> On Thu, Aug 13, 2009 at 12:01 PM, Paul Benedict<pb...@apache.org>
>> 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 there is any desire to keep com.opensymphony when this
>>> occurs.
>>> So my thinking would be this would be an incompatible change. Did I get
>>> it
>>> wrong?
>>
>> I think completely removing any trace of xwork is a good long term 3.0
>> goal, but for now, we would simply fork it, keeping the package
>> structure and class names.
>>
>> Don
>>
>>>
>>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak <ws...@gmail.com> wrote:
>>>
>>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
>>>> 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 be acceptable in the 2.x branch.
>>>>
>>>> IMO "Struts 3" would imply a major change in Struts itself, the
>>>> possibility of backwards incompatible changes, etc. This isn't...
>>>> community aspects aside, it's just moving some code from one svn repo
>>>> to another. -Wendy
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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<br...@pontarelli.com> 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.
>
> Sent from my iPhone
>
> On Aug 12, 2009, at 8:06 PM, Don Brown <mr...@twdata.org> wrote:
>
>> On Thu, Aug 13, 2009 at 12:01 PM, Paul Benedict<pb...@apache.org>
>> 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 there is any desire to keep com.opensymphony when this
>>> occurs.
>>> So my thinking would be this would be an incompatible change. Did I get
>>> it
>>> wrong?
>>
>> I think completely removing any trace of xwork is a good long term 3.0
>> goal, but for now, we would simply fork it, keeping the package
>> structure and class names.
>>
>> Don
>>
>>>
>>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak <ws...@gmail.com> wrote:
>>>
>>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
>>>> 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 be acceptable in the 2.x branch.
>>>>
>>>> IMO "Struts 3" would imply a major change in Struts itself, the
>>>> possibility of backwards incompatible changes, etc. This isn't...
>>>> community aspects aside, it's just moving some code from one svn repo
>>>> to another. -Wendy
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <mr...@twdata.org> wrote:
> On Thu, Aug 13, 2009 at 12:01 PM, Paul
> Benedict<pb...@apache.org> 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 there is any desire to keep com.opensymphony when
>> this occurs.
>> So my thinking would be this would be an incompatible change. Did I
>> get it
>> wrong?
>
> I think completely removing any trace of xwork is a good long term 3.0
> goal, but for now, we would simply fork it, keeping the package
> structure and class names.
>
> Don
>
>>
>> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak <ws...@gmail.com>
>> wrote:
>>
>>> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
>>> 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 be acceptable in the 2.x branch.
>>>
>>> IMO "Struts 3" would imply a major change in Struts itself, the
>>> possibility of backwards incompatible changes, etc. This isn't...
>>> community aspects aside, it's just moving some code from one svn
>>> repo
>>> to another. -Wendy
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Don Brown <mr...@twdata.org>.
On Thu, Aug 13, 2009 at 12:01 PM, Paul Benedict<pb...@apache.org> 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 there is any desire to keep com.opensymphony when this occurs.
> So my thinking would be this would be an incompatible change. Did I get it
> wrong?
I think completely removing any trace of xwork is a good long term 3.0
goal, but for now, we would simply fork it, keeping the package
structure and class names.
Don
>
> On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak <ws...@gmail.com> wrote:
>
>> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
>> 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 be acceptable in the 2.x branch.
>>
>> IMO "Struts 3" would imply a major change in Struts itself, the
>> possibility of backwards incompatible changes, etc. This isn't...
>> community aspects aside, it's just moving some code from one svn repo
>> to another. -Wendy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
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.
So my thinking would be this would be an incompatible change. Did I get it
wrong?
On Wed, Aug 12, 2009 at 4:45 PM, Wendy Smoak <ws...@gmail.com> wrote:
> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
> 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 be acceptable in the 2.x branch.
>
> IMO "Struts 3" would imply a major change in Struts itself, the
> possibility of backwards incompatible changes, etc. This isn't...
> community aspects aside, it's just moving some code from one svn repo
> to another. -Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <ws...@gmail.com> wrote:
> On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org>
> 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 be acceptable in the 2.x branch.
>
> IMO "Struts 3" would imply a major change in Struts itself, the
> possibility of backwards incompatible changes, etc. This isn't...
> community aspects aside, it's just moving some code from one svn repo
> to another. -Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Wendy Smoak <ws...@gmail.com>.
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict<pb...@apache.org> 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 be acceptable in the 2.x branch.
IMO "Struts 3" would imply a major change in Struts itself, the
possibility of backwards incompatible changes, etc. This isn't...
community aspects aside, it's just moving some code from one svn repo
to another. -Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
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 9:37 PM, Musachy Barroso <mu...@gmail.com> wrote:
> On Tue, Aug 11, 2009 at 9:55 AM, Brian Pontarelli<br...@pontarelli.com>
> 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". :)
>
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Tue, Aug 11, 2009 at 9:55 AM, Brian Pontarelli<br...@pontarelli.com> 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 smell of napalm in the morning"
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Brian Pontarelli <br...@pontarelli.com>.
On Aug 10, 2009, at 11:52 PM, Don Brown wrote:
> On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedict<pb...@apache.org>
> wrote:
>> On Tue, Aug 11, 2009 at 12:22 AM, Don Brown
>> <do...@gmail.com> 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 do to cut the apron strings, then I can agree to that.
>> However, I
>> thought you guys were saying you actually want to make Apache *OWN*
>> XWork.
>> That's something completely different and am against. If the code
>> is copied
>> into Struts as fork, the whole XWork branding should wash away and
>> Struts
>> should have no more reference to "xwork" anywhere.
>
> Awesome - that is exactly what I'm saying. Kill it with fire! :)
Oh yeah! Burn baby burn!
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". :)
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Don Brown <mr...@twdata.org>.
On Tue, Aug 11, 2009 at 3:38 PM, Paul Benedict<pb...@apache.org> wrote:
> On Tue, Aug 11, 2009 at 12:22 AM, Don Brown <do...@gmail.com> 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 do to cut the apron strings, then I can agree to that. However, I
> thought you guys were saying you actually want to make Apache *OWN* XWork.
> That's something completely different and am against. If the code is copied
> into Struts as fork, the whole XWork branding should wash away and Struts
> should have no more reference to "xwork" anywhere.
Awesome - that is exactly what I'm saying. Kill it with fire! :)
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
On Tue, Aug 11, 2009 at 12:22 AM, Don Brown <do...@gmail.com> 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 do to cut the apron strings, then I can agree to that. However, I
thought you guys were saying you actually want to make Apache *OWN* XWork.
That's something completely different and am against. If the code is copied
into Struts as fork, the whole XWork branding should wash away and Struts
should have no more reference to "xwork" anywhere.
Paul
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Don Brown <do...@gmail.com>.
On Tue, Aug 11, 2009 at 3:15 PM, Martin Cooper<ma...@apache.org> 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 the time?
>
> It's often bothered me that we always seem to need to wait for an XWork
> release, not so much because of the wait, but because we seem to be so
> dependent on constant change in that library. What's up with that? That is
> what seems to be the real issue here.
This is exactly my point. XWork is such a core part of what Struts 2
is that it shouldn't be separate. Any non-trivial change to Struts 2
involves changes to XWork and I don't see that changing anytime soon.
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.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Martin Cooper <ma...@apache.org>.
On Mon, Aug 10, 2009 at 9:57 PM, Musachy Barroso <mu...@gmail.com> 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 until the other day. Why would we try to
> support something for which there is no use case? It would be like
> supporting supporting Struts on java 1.1 just for those users still
> using java 1.1.
>
> That's one side of it, the other is that we *need* to consolidate
> releases. There aren't many of us contributing, and there are less
> willing to build releases (for example, I have never volunteered to
> make an XWork release). Before, building Struts was a bottleneck
> because it was largely undocummented, that got partially fixed and now
> there is more people that are willing/able to release Struts. Now
> XWork is the bottleneck because we have to depend on one brave dude to
> have free time. If everything was under the Struts umbrella, anyone
> with time to do a release could run the whole thing.
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 the time?
It's often bothered me that we always seem to need to wait for an XWork
release, not so much because of the wait, but because we seem to be so
dependent on constant change in that library. What's up with that? That is
what seems to be the real issue here.
--
Martin Cooper
>
>
> musachy
>
> On Mon, Aug 10, 2009 at 9:33 PM, Paul Benedict<pb...@apache.org>
> wrote:
> > 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:30 PM, Musachy Barroso <mu...@gmail.com>
> wrote:
> >
> >> On Mon, Aug 10, 2009 at 5:22 PM, Don Brown<do...@gmail.com>
> 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. A subproject is a no-go for me, as it would be
> >> the same thing that we have now.
> >>
> >> musachy
> >> --
> >> "Hey you! Would you help me to carry the stone?" Pink Floyd
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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 which there is no use case? It would be like
supporting supporting Struts on java 1.1 just for those users still
using java 1.1.
That's one side of it, the other is that we *need* to consolidate
releases. There aren't many of us contributing, and there are less
willing to build releases (for example, I have never volunteered to
make an XWork release). Before, building Struts was a bottleneck
because it was largely undocummented, that got partially fixed and now
there is more people that are willing/able to release Struts. Now
XWork is the bottleneck because we have to depend on one brave dude to
have free time. If everything was under the Struts umbrella, anyone
with time to do a release could run the whole thing.
musachy
On Mon, Aug 10, 2009 at 9:33 PM, Paul Benedict<pb...@apache.org> wrote:
> 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:30 PM, Musachy Barroso <mu...@gmail.com> wrote:
>
>> On Mon, Aug 10, 2009 at 5:22 PM, Don Brown<do...@gmail.com> 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. A subproject is a no-go for me, as it would be
>> the same thing that we have now.
>>
>> musachy
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Paul Benedict <pb...@apache.org>.
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:30 PM, Musachy Barroso <mu...@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 5:22 PM, Don Brown<do...@gmail.com> 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. A subproject is a no-go for me, as it would be
> the same thing that we have now.
>
> musachy
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
On Mon, Aug 10, 2009 at 5:22 PM, Don Brown<do...@gmail.com> 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. A subproject is a no-go for me, as it would be
the same thing that we have now.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Don Brown <do...@gmail.com>.
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. This silly division, while noble at the start, has proven to
provide no value and heaps of confusion. If someone wants to use
xwork by itself, the code will always be at opensymphony, but from all
accounts, that only affects like three people.
Don
On Tue, Aug 11, 2009 at 10:12 AM, Musachy Barroso<mu...@gmail.com> wrote:
> 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-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Musachy Barroso <mu...@gmail.com>.
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-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Let's kill xwork (was Re: 2.1.8 release?)
Posted by Rene Gielen <rg...@apache.org>.
+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 activity seems all but dead, leaving us
> with no advantages having the code hosted over there. Furthermore,
> having critical code in different packages is really confusing for
> developers of the framework and its apps with no apparent benefit.
>
> Ideally, I'd like to bring xwork trunk into the core jar and be done
> with the theoretically useful yet practically painful split. However,
> that would break Struts 2 apps without tedious backwards-compatibility
> code, but getting the code bases integrated is the first step. Maybe
> at first, we keep two artifacts, but I think we should think about a
> serious migration to just one. XWork itself will always be around,
> but trying to put a framework at our core that is meant for ambiguous
> theoretical users brings unnecessary complexity and problems to all
> parties.
>
> Can I start planning the funeral? :)
>
> Don
>
> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<we...@wantii.com> wrote:
>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote:
>> [snip]
>>> I was going to ask if anyone was using it outside struts, but that
>>> doesn't prevent us from making it it's own artifact.
>>>
>> [snip]
>>> I don't think this would fix the problem, which is the duplicated
>>> effort on the builds. A good compromise would be to keep it under its
>>> own artifact under struts, just like core, that way we would need just
>>> one release and it could still be used independently. I haven't cared
>>> much before, but if it will make our releases easier/smoother, then I
>>> am +1 for it.
>>>
>> being its own artifact makes more sense, it would make releasing the two much
>> easier, on second thought I agree with this. My only real concern is that I
>> can get to it w/o struts. The context I am working with now doesn't fit well
>> with struts, and adding struts means I would have to do even more work getting
>> a base configuration so that xwork can run actions. One example that sticks out
>> in my mind is that when I run actions, each action execution gets its own
>> thread and one of the results I built for this project launches from 1 to
>> infinite more actions. Obviously it wouldn't make sense to chain to multiple
>> actions in a web-app and since a view is rendered in struts, having actions
>> run in a separate thread wouldn't work well in a web-app.
>>
>> -W
>>
>> --
>> Wes Wannemacher
>>
>> Head Engineer, WanTii, Inc.
>> Need Training? Struts, Spring, Maven, Tomcat...
>> Ask me for a quote!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org