You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Brian Pontarelli <br...@pontarelli.com> on 2008/01/02 19:44:27 UTC
XWork project
What is the policy for Struts committers getting access to XWork? While
updating the convention plugin I had to change a few things in XWork and I
want to make sure that they get committed to trunk before I start using the
convention plugin on projects. I have a few bugs open, but it could take a
while to get those in. Since Struts and XWork as so tightly coupled and
still separate projects, would it make sense for all Struts committers to
also have access to XWork?
Also, as a separate topic, what are the future plans for all the external
dependencies for Struts core? One of the difficult things I've found is that
the two most major dependencies, OGNL and XWork, are not only confusing for
some of my employees since the need to import from packages other than
org.apache.struts2, but also not accessible to me for modification and
updates and such.
-bp
Re: XWork project
Posted by Musachy Barroso <mu...@gmail.com>.
I have asked about this before but I never got an answer. Just assign
a couple of patches to Rainer and bother him on #struts and he will
give you commit rights. (that's what I unintentionally did :) )
musachy
On Jan 2, 2008 1:44 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
> What is the policy for Struts committers getting access to XWork? While
> updating the convention plugin I had to change a few things in XWork and I
> want to make sure that they get committed to trunk before I start using the
> convention plugin on projects. I have a few bugs open, but it could take a
> while to get those in. Since Struts and XWork as so tightly coupled and
> still separate projects, would it make sense for all Struts committers to
> also have access to XWork?
>
> Also, as a separate topic, what are the future plans for all the external
> dependencies for Struts core? One of the difficult things I've found is that
> the two most major dependencies, OGNL and XWork, are not only confusing for
> some of my employees since the need to import from packages other than
> org.apache.struts2, but also not accessible to me for modification and
> updates and such.
>
> -bp
>
--
"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: XWork project
Posted by Brian Pontarelli <br...@pontarelli.com>.
Don Brown wrote:
> On Jan 3, 2008 5:44 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> What is the policy for Struts committers getting access to XWork? While
>> updating the convention plugin I had to change a few things in XWork and I
>> want to make sure that they get committed to trunk before I start using the
>> convention plugin on projects. I have a few bugs open, but it could take a
>> while to get those in. Since Struts and XWork as so tightly coupled and
>> still separate projects, would it make sense for all Struts committers to
>> also have access to XWork?
>>
>
> Yep, send me an email with your desired user name and your
> sha1-encoded password, and I'll add you.
>
Don, I wanted to see if you got my email with this information. I'm
afraid that it might be going to spam and figured I'd send out a message
to the mailing list instead. Let me know if you didn't get it and I'll
figure out some way to send it to you.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: XWork project
Posted by Don Brown <mr...@twdata.org>.
In a perfect world, we would have the theme system in core, then a
Freemarker theme plugin that implements it for Freemarker (same for
velocity). Still there are a couple other areas we use freemarker,
the debug screen comes to mind. That probably doesn't need something
as powerful as Freemarker, so perhaps we could get away with embedding
a version of StringTemplate or something.
Don
On 1/3/08, Chris Pratt <th...@gmail.com> wrote:
> On Jan 2, 2008 2:26 PM, Don Brown <do...@gmail.com> wrote:
> > At this point, our plan is to leave them where they are. I'd like to
> > get rid of OGNL through the JUEL plugin, and perhaps just include the
> > xwork code inside the Struts jar, dropping our dependency list down to
> > just Freemarker.
> >
>
> If we push the theme support into the plugins, wouldn't that move the
> Freemarker dependency to that plug-in, and out of the core?
>
> ---------------------------------------------------------------------
> 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: XWork project
Posted by Chris Pratt <th...@gmail.com>.
On Jan 2, 2008 2:26 PM, Don Brown <do...@gmail.com> wrote:
> At this point, our plan is to leave them where they are. I'd like to
> get rid of OGNL through the JUEL plugin, and perhaps just include the
> xwork code inside the Struts jar, dropping our dependency list down to
> just Freemarker.
>
If we push the theme support into the plugins, wouldn't that move the
Freemarker dependency to that plug-in, and out of the core?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: XWork project
Posted by Ted Husted <hu...@apache.org>.
Not every Struts committer works on Struts 2, and not every committer
working on Struts 2 wants to work on XWork too. It's a security
exception to give people accounts that they haven't requested and may
never use.
AFAIK, to date, anyone here who wanted access to XWork has gotten it
without any trouble. I don't think we need any formal agreements. (In
fact, I think some people like the fact that XWork is not as formal
than Struts.) We probably just need to remember to mention to new
committers that anyone who wants access to XWork should ping Rainer or
Don.
And, in any event, the venue for that discussion would be the XWork list. :)
-Ted.
On Jan 4, 2008 12:24 PM, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> If the codebases are to remain separate, I'd like to suggest that all
> Struts2 committers are added to XWork. The reason that I say that is the
> codebases are so coupled. If you look through comments in XWork, you
> start to see more references directly to Struts2. Struts2 won't function
> unless XWork is functioning and the XWork API is not changing.
> Therefore, it is sometimes very important to work in both codebases when
> doing development for Struts2 and bugs in XWork often halt development
> completely on Struts2 until they are resolved.
>
> -bp
>
>
>
> Ted Husted wrote:
> > The backstory is that we proposed bringing over WebWork as Struts 2,
> > we decided to leave XWork at OpenSymphony. One reason is that most of
> > us like the strong separation between XWork and Struts 2, so as to
> > keep HTTP from creeping back in the core API. Another reason is that
> > incubating a large codebase is painful, and there are so many other
> > ways we could spend our volunteer hours.
> >
> > As it stands, most or all of the active XWork committers are Struts 2
> > committers, and, in practice, Struts 2 committers tend to be welcomed
> > as XWork committers. So far, XWork hasn't had too much trouble keeping
> > up with the Struts 2 releases.
> >
> > If XWork did decide to join the ASF, it probably end up being another
> > top-level Apache project, and the overall workflow wouldn't be much
> > different. The net gain would be pretty much zero.
> >
> > Merging XWork and Struts 2 back into a monolithic codebase has been
> > discussed, and the suggestion seems like a non-starter.
> >
> > As for OGNL, the codebase is rumored to be dark and mysterious. As Don
> > mentioned, volunteer hours might be better spent making the expression
> > language pluggable, and then plugging in JUEL.
> >
> > I'm not 100% sure, but I believe if we ever made the tags into a
> > plugin, then FreeMarker would be a dependency of that plugin, rather
> > than the core. (A Good Thing, IMHO.)
> >
> > -Ted.
> >
> > On Jan 2, 2008 5:26 PM, Don Brown <do...@gmail.com> wrote:
> >
> >>> Also, as a separate topic, what are the future plans for all the external
> >>> dependencies for Struts core? One of the difficult things I've found is that
> >>> the two most major dependencies, OGNL and XWork, are not only confusing for
> >>> some of my employees since the need to import from packages other than
> >>> org.apache.struts2, but also not accessible to me for modification and
> >>> updates and such.
> >>>
> >> At this point, our plan is to leave them where they are. I'd like to
> >> get rid of OGNL through the JUEL plugin, and perhaps just include the
> >> xwork code inside the Struts jar, dropping our dependency list down to
> >> just Freemarker.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: XWork project
Posted by Brian Pontarelli <br...@pontarelli.com>.
If the codebases are to remain separate, I'd like to suggest that all
Struts2 committers are added to XWork. The reason that I say that is the
codebases are so coupled. If you look through comments in XWork, you
start to see more references directly to Struts2. Struts2 won't function
unless XWork is functioning and the XWork API is not changing.
Therefore, it is sometimes very important to work in both codebases when
doing development for Struts2 and bugs in XWork often halt development
completely on Struts2 until they are resolved.
-bp
Ted Husted wrote:
> The backstory is that we proposed bringing over WebWork as Struts 2,
> we decided to leave XWork at OpenSymphony. One reason is that most of
> us like the strong separation between XWork and Struts 2, so as to
> keep HTTP from creeping back in the core API. Another reason is that
> incubating a large codebase is painful, and there are so many other
> ways we could spend our volunteer hours.
>
> As it stands, most or all of the active XWork committers are Struts 2
> committers, and, in practice, Struts 2 committers tend to be welcomed
> as XWork committers. So far, XWork hasn't had too much trouble keeping
> up with the Struts 2 releases.
>
> If XWork did decide to join the ASF, it probably end up being another
> top-level Apache project, and the overall workflow wouldn't be much
> different. The net gain would be pretty much zero.
>
> Merging XWork and Struts 2 back into a monolithic codebase has been
> discussed, and the suggestion seems like a non-starter.
>
> As for OGNL, the codebase is rumored to be dark and mysterious. As Don
> mentioned, volunteer hours might be better spent making the expression
> language pluggable, and then plugging in JUEL.
>
> I'm not 100% sure, but I believe if we ever made the tags into a
> plugin, then FreeMarker would be a dependency of that plugin, rather
> than the core. (A Good Thing, IMHO.)
>
> -Ted.
>
> On Jan 2, 2008 5:26 PM, Don Brown <do...@gmail.com> wrote:
>
>>> Also, as a separate topic, what are the future plans for all the external
>>> dependencies for Struts core? One of the difficult things I've found is that
>>> the two most major dependencies, OGNL and XWork, are not only confusing for
>>> some of my employees since the need to import from packages other than
>>> org.apache.struts2, but also not accessible to me for modification and
>>> updates and such.
>>>
>> At this point, our plan is to leave them where they are. I'd like to
>> get rid of OGNL through the JUEL plugin, and perhaps just include the
>> xwork code inside the Struts jar, dropping our dependency list down to
>> just Freemarker.
>>
>
> ---------------------------------------------------------------------
> 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: XWork project
Posted by Ted Husted <hu...@apache.org>.
The backstory is that we proposed bringing over WebWork as Struts 2,
we decided to leave XWork at OpenSymphony. One reason is that most of
us like the strong separation between XWork and Struts 2, so as to
keep HTTP from creeping back in the core API. Another reason is that
incubating a large codebase is painful, and there are so many other
ways we could spend our volunteer hours.
As it stands, most or all of the active XWork committers are Struts 2
committers, and, in practice, Struts 2 committers tend to be welcomed
as XWork committers. So far, XWork hasn't had too much trouble keeping
up with the Struts 2 releases.
If XWork did decide to join the ASF, it probably end up being another
top-level Apache project, and the overall workflow wouldn't be much
different. The net gain would be pretty much zero.
Merging XWork and Struts 2 back into a monolithic codebase has been
discussed, and the suggestion seems like a non-starter.
As for OGNL, the codebase is rumored to be dark and mysterious. As Don
mentioned, volunteer hours might be better spent making the expression
language pluggable, and then plugging in JUEL.
I'm not 100% sure, but I believe if we ever made the tags into a
plugin, then FreeMarker would be a dependency of that plugin, rather
than the core. (A Good Thing, IMHO.)
-Ted.
On Jan 2, 2008 5:26 PM, Don Brown <do...@gmail.com> wrote:
> > Also, as a separate topic, what are the future plans for all the external
> > dependencies for Struts core? One of the difficult things I've found is that
> > the two most major dependencies, OGNL and XWork, are not only confusing for
> > some of my employees since the need to import from packages other than
> > org.apache.struts2, but also not accessible to me for modification and
> > updates and such.
>
> At this point, our plan is to leave them where they are. I'd like to
> get rid of OGNL through the JUEL plugin, and perhaps just include the
> xwork code inside the Struts jar, dropping our dependency list down to
> just Freemarker.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: XWork project
Posted by Don Brown <do...@gmail.com>.
On Jan 3, 2008 5:44 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
> What is the policy for Struts committers getting access to XWork? While
> updating the convention plugin I had to change a few things in XWork and I
> want to make sure that they get committed to trunk before I start using the
> convention plugin on projects. I have a few bugs open, but it could take a
> while to get those in. Since Struts and XWork as so tightly coupled and
> still separate projects, would it make sense for all Struts committers to
> also have access to XWork?
Yep, send me an email with your desired user name and your
sha1-encoded password, and I'll add you.
> Also, as a separate topic, what are the future plans for all the external
> dependencies for Struts core? One of the difficult things I've found is that
> the two most major dependencies, OGNL and XWork, are not only confusing for
> some of my employees since the need to import from packages other than
> org.apache.struts2, but also not accessible to me for modification and
> updates and such.
At this point, our plan is to leave them where they are. I'd like to
get rid of OGNL through the JUEL plugin, and perhaps just include the
xwork code inside the Struts jar, dropping our dependency list down to
just Freemarker.
Don
>
> -bp
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org