You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ja...@wendysmoak.com> on 2005/08/09 03:47:47 UTC
struts-faces won't compile
Faces is using a formerly deprecated, and now removed, method in
RequestUtils. This breaks the Maven build, which works against
struts-core-1.3.0-dev.
Is this the correct fix?
Thanks,
Wendy
Index:
core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
===================================================================
---
core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
(revision 230657)
+++
core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
(working copy)
@@ -35,6 +35,7 @@
import org.apache.struts.config.ModuleConfig;
import org.apache.struts.faces.Constants;
import org.apache.struts.faces.component.FormComponent;
+import org.apache.struts.util.ModuleUtils;
import org.apache.struts.util.RequestUtils;
@@ -152,7 +153,7 @@
// Invoke the appropriate request processor for this request
try {
request.setAttribute(Constants.ACTION_EVENT_KEY, event);
- RequestUtils.selectModule(request, servletContext);
+ ModuleUtils.getInstance().selectModule(request,
servletContext);
ModuleConfig moduleConfig = (ModuleConfig)
request.getAttribute(Globals.MODULE_KEY);
if (log.isTraceEnabled()) {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-faces won't compile
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/11/05, Michael Rasmussen <ra...@gmail.com> wrote:
> Craig,
> I know this issue came up about a year ago that struts-faces
> wouldn't compile against the latest version of Struts (I think it was
> a validator issue). It makes sense to me that it should always work
> with the latest version of Struts. I think it would serve the project
> well to cut a *.0 release of struts-faces and give it a 1.1-1.2.x
> compatability...after that put it into maintenence mode. Then cut a
> new *.0 release that brings struts-faces up to date with struts
> core...
>
> I haven't been following faces too closely lately...has it gone to 1.x
> yet? If so, maybe this Struts dependency change to 1.2.x should
> denote a v 2.0?
>
> I totally understand that the target audience for struts-faces is the
> developer trying to migrate a struts app off of struts to jsf. I have
> a hard time (and sort of balked at struts-faces because of it)
> commiting to a path that may force me to run my app on struts 1.2.x
> and 1.3 in paralell if I decide later that JSF just won't get it done
> for me. Basically I just mean that I am forced to limit my options if
> I use struts-faces, and I thought the spirit of the library was to
> increase my options.
>
The Maven-generated build script has been getting tweaked lately, and
does indeed impose a Struts 1.2 dependency. I'll have to take a look
at that -- but there seem to have been some incompatible changes in
the underlying utility classes that is going to make supporting both
1.1 and 1.2 "interesting" -- let alone supporting 1.3 as well.
NB - the nightly builds are compiled against 1.2.6 at the moment.
http://cvs.apache.org/builds/struts/nightly/struts-faces/
> My $0.02
>
> Michael
>
Craig
> On 8/8/05, Craig McClanahan <cr...@gmail.com> wrote:
> > On 8/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > > From: "Craig McClanahan" <cr...@gmail.com>
> > >
> > > > Maybe the Maven mavens can figure out a way to share the build
> > > > infrastructure without sharing the dependency information?
> > >
> > > Not a problem... just change the dependency in project.xml. Looks like it
> > > needs at least 1.2.2 to compile. (It won't compile against Struts 1.1.
> > > Should it?)
> > >
> >
> > Given that Struts changed incompatibly, I'm ok with 1.2.x as a
> > restriction. But doesn't that mean we still need an independent
> > project.xml file instead of a shared one?
> >
> > > If it makes sense, we can remove the <extend>build/project.xml</extend> from
> > > project.xml, and that will make the build stand on its own. That
> > > seems more appropriate for Tiles than Struts-Faces, though.
> >
> > Yep ... but without disrupting all the subprojects that *do* want to
> > share dependencies. Maybe another opportunity to use SVN externals
> > creatively.
> >
> > >
> > > Thanks,
> > > Wendy
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > 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: struts-faces won't compile
Posted by Michael Rasmussen <ra...@gmail.com>.
Craig,
I know this issue came up about a year ago that struts-faces
wouldn't compile against the latest version of Struts (I think it was
a validator issue). It makes sense to me that it should always work
with the latest version of Struts. I think it would serve the project
well to cut a *.0 release of struts-faces and give it a 1.1-1.2.x
compatability...after that put it into maintenence mode. Then cut a
new *.0 release that brings struts-faces up to date with struts
core...
I haven't been following faces too closely lately...has it gone to 1.x
yet? If so, maybe this Struts dependency change to 1.2.x should
denote a v 2.0?
I totally understand that the target audience for struts-faces is the
developer trying to migrate a struts app off of struts to jsf. I have
a hard time (and sort of balked at struts-faces because of it)
commiting to a path that may force me to run my app on struts 1.2.x
and 1.3 in paralell if I decide later that JSF just won't get it done
for me. Basically I just mean that I am forced to limit my options if
I use struts-faces, and I thought the spirit of the library was to
increase my options.
My $0.02
Michael
On 8/8/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 8/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> > From: "Craig McClanahan" <cr...@gmail.com>
> >
> > > Maybe the Maven mavens can figure out a way to share the build
> > > infrastructure without sharing the dependency information?
> >
> > Not a problem... just change the dependency in project.xml. Looks like it
> > needs at least 1.2.2 to compile. (It won't compile against Struts 1.1.
> > Should it?)
> >
>
> Given that Struts changed incompatibly, I'm ok with 1.2.x as a
> restriction. But doesn't that mean we still need an independent
> project.xml file instead of a shared one?
>
> > If it makes sense, we can remove the <extend>build/project.xml</extend> from
> > project.xml, and that will make the build stand on its own. That
> > seems more appropriate for Tiles than Struts-Faces, though.
>
> Yep ... but without disrupting all the subprojects that *do* want to
> share dependencies. Maybe another opportunity to use SVN externals
> creatively.
>
> >
> > Thanks,
> > Wendy
>
> Craig
>
> ---------------------------------------------------------------------
> 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: struts-faces won't compile
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> From: "Craig McClanahan" <cr...@gmail.com>
>
> > Maybe the Maven mavens can figure out a way to share the build
> > infrastructure without sharing the dependency information?
>
> Not a problem... just change the dependency in project.xml. Looks like it
> needs at least 1.2.2 to compile. (It won't compile against Struts 1.1.
> Should it?)
>
Given that Struts changed incompatibly, I'm ok with 1.2.x as a
restriction. But doesn't that mean we still need an independent
project.xml file instead of a shared one?
> If it makes sense, we can remove the <extend>build/project.xml</extend> from
> project.xml, and that will make the build stand on its own. That
> seems more appropriate for Tiles than Struts-Faces, though.
Yep ... but without disrupting all the subprojects that *do* want to
share dependencies. Maybe another opportunity to use SVN externals
creatively.
>
> Thanks,
> Wendy
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-faces won't compile
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
> Maybe the Maven mavens can figure out a way to share the build
> infrastructure without sharing the dependency information?
Not a problem... just change the dependency in project.xml. Looks like it
needs at least 1.2.2 to compile. (It won't compile against Struts 1.1.
Should it?)
If it makes sense, we can remove the <extend>build/project.xml</extend> from
project.xml, and that will make the build stand on its own. That
seems more appropriate for Tiles than Struts-Faces, though.
Thanks,
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Common build file issues (was Re: struts-faces won't compile)
Posted by James Mitchell <jm...@apache.org>.
I also had the same thoughts during the initial timeframe when I was setting
up the Maven config.
I think we should stay away from getting too complex with config
inheritance.
I was thinking about this the other day, and what we might want do is move
to a completely independent maven configuration for all subprojects. We
will still share the build/ dir via svn:externals for common stuff like
license and CheckStyle config, but each subproject will be a complete
configuration itself (no <extends>).
By doing it this way, we can create a new project.xml and maven.xml in
current/ which is actually the "normal" way of doing it. This also puts the
subprojects in a position to go ahead and do releases independent of other
subprojects. We need to further discuss how we handle this with respect to
how Maven deals with dependencies. Specifically, someone will need to
maintain a chart of compatibility issues for all projects under Struts.
This will be the only way to keep "what version of core works with what
version of taglibs or el or foo" type questions from making this split even
worth the effort. As it is now, the same issue (sort of) applies across the
commons dependencies. Things can get very complicated, very fast.
In addition to the above, it will be easier for me to fix the problems with
the nightly build that come up every time anything is changed or released.
Currently the release targets are hardcoded in my cron script (because of
the way the files have to be named for the cleanup cron to work properly)
and I'd like to remove that inefficiency.
I'll be making some changes a little later today and more this week (as free
time allows).
With all hope, we can simplify this whole process and get it moved over to
our zone and stop relying on our personal machines and (my) sometimes flaky
network connection.
(Wendy, just got your other email, I'll look into doing that when things
settle down a bit)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "Wendy Smoak" <ja...@wendysmoak.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Sunday, August 14, 2005 8:27 AM
Subject: Common build file issues (was Re: struts-faces won't compile)
> Wendy wrote:
>> But there are things in the common build file that are *not*
>> common to all subprojects.
>
> We needs a way to make sure that core/taglib/el/apps/plugins are all using
> the same versions of their dependencies, without imposing those
> dependencies on 'standalone' subprojects.
>
> How about:
>
> /current/build/project.xml
> ... has the list of committers, reports, etc. Only things that are common
> to *all* sub-projects
>
> /current/build/project-core.xml
> ... <extend>project.xml</extend>
> ... has the list of dependencies for struts-core
>
> Then each subproject chooses which build file to extend.
>
> - core, taglib, el, struts-tiles, apps, plugins can all extend
> build/project-core.xml in order to keep their dependencies on [mostly]
> commons libraries in sync. Even if the subproject doesn't necessarily
> need
> one of the dependencies that struts-core does, you can't use these
> subprojects without core, so you end up needing that dependency anyway.
> Subprojects can add additional dependencies, but can't remove the ones
> they
> inherit from core.
>
> - Faces, Standalone Tiles, etc., can extend from the generic 'project.xml'
> to pick up the list of committers, reports, etc., but are responsible for
> their own dependencies.
>
> --
> 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: Common build file issues (was Re: struts-faces won't compile)
Posted by James Mitchell <jm...@apache.org>.
I also had the same thoughts during the initial timeframe when I was setting
up the Maven config.
I think we should stay away from getting too complex with config
inheritance.
I was thinking about this the other day, and what we might want do is move
to a completely independent maven configuration for all subprojects. We
will still share the build/ dir via svn:externals for common stuff like
license and CheckStyle config, but each subproject will be a complete
configuration itself (no <extends>).
By doing it this way, we can create a new project.xml and maven.xml in
current/ which is actually the "normal" way of doing it. This also puts the
subprojects in a position to go ahead and do releases independent of other
subprojects. We need to further discuss how we handle this with respect to
how Maven deals with dependencies. Specifically, someone will need to
maintain a chart of compatibility issues for all projects under Struts.
This will be the only way to keep "what version of core works with what
version of taglibs or el or foo" type questions from making this split even
worth the effort. As it is now, the same issue (sort of) applies across the
commons dependencies. Things can get very complicated, very fast.
In addition to the above, it will be easier for me to fix the problems with
the nightly build that come up every time anything is changed or released.
Currently the release targets are hardcoded in my cron script (because of
the way the files have to be named for the cleanup cron to work properly)
and I'd like to remove that inefficiency.
I'll be making some changes a little later today and more this week (as free
time allows).
With all hope, we can simplify this whole process and get it moved over to
our zone and stop relying on our personal machines and (my) sometimes flaky
network connection.
(Wendy, just got your other email, I'll look into doing that when things
settle down a bit)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "Wendy Smoak" <ja...@wendysmoak.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Sunday, August 14, 2005 8:27 AM
Subject: Common build file issues (was Re: struts-faces won't compile)
> Wendy wrote:
>> But there are things in the common build file that are *not*
>> common to all subprojects.
>
> We needs a way to make sure that core/taglib/el/apps/plugins are all using
> the same versions of their dependencies, without imposing those
> dependencies on 'standalone' subprojects.
>
> How about:
>
> /current/build/project.xml
> ... has the list of committers, reports, etc. Only things that are common
> to *all* sub-projects
>
> /current/build/project-core.xml
> ... <extend>project.xml</extend>
> ... has the list of dependencies for struts-core
>
> Then each subproject chooses which build file to extend.
>
> - core, taglib, el, struts-tiles, apps, plugins can all extend
> build/project-core.xml in order to keep their dependencies on [mostly]
> commons libraries in sync. Even if the subproject doesn't necessarily
> need
> one of the dependencies that struts-core does, you can't use these
> subprojects without core, so you end up needing that dependency anyway.
> Subprojects can add additional dependencies, but can't remove the ones
> they
> inherit from core.
>
> - Faces, Standalone Tiles, etc., can extend from the generic 'project.xml'
> to pick up the list of committers, reports, etc., but are responsible for
> their own dependencies.
>
> --
> 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
Common build file issues (was Re: struts-faces won't compile)
Posted by Wendy Smoak <ja...@wendysmoak.com>.
Wendy wrote:
> But there are things in the common build file that are *not*
> common to all subprojects.
We needs a way to make sure that core/taglib/el/apps/plugins are all using
the same versions of their dependencies, without imposing those
dependencies on 'standalone' subprojects.
How about:
/current/build/project.xml
... has the list of committers, reports, etc. Only things that are common
to *all* sub-projects
/current/build/project-core.xml
... <extend>project.xml</extend>
... has the list of dependencies for struts-core
Then each subproject chooses which build file to extend.
- core, taglib, el, struts-tiles, apps, plugins can all extend
build/project-core.xml in order to keep their dependencies on [mostly]
commons libraries in sync. Even if the subproject doesn't necessarily need
one of the dependencies that struts-core does, you can't use these
subprojects without core, so you end up needing that dependency anyway.
Subprojects can add additional dependencies, but can't remove the ones they
inherit from core.
- Faces, Standalone Tiles, etc., can extend from the generic 'project.xml'
to pick up the list of committers, reports, etc., but are responsible for
their own dependencies.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-faces won't compile
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
>> +import org.apache.struts.util.ModuleUtils;
>> -RequestUtils.selectModule(request, servletContext);
>> +ModuleUtils.getInstance().selectModule(request,servletContext);
> Conceptually that fix makes sense in that it solves the compilation
> problem ... but I don't believe that struts-faces should inherit a
> dependency on 1.3.x.
I don't see how switching from a deprecated method call to the replacement
causes a dependency on 1.3.x. That change still compiles under 1.2.2.
> Today it works (runtime) on 1.1 and 1.2, and it
> would be pretty pointless to throw away the vast majority of the
> potential target market.
Does it really still work on 1.1? It won't compile against 1.1 due to the
use of org.apache.struts.taglib.TagUtils and
org.apache.struts.util.ModuleUtils, which must not have existed then.
> I think Struts-Faces (if it's going to be built with Maven :-) needs
> its own set of dependencies, independent of whatever Struts Core is
> using.
It was inheriting from the Struts Common Build, not from Struts Core. The
incorrect dependency on struts-core-1.3.0-dev was actually *in* the
struts-faces build file and has been corrected to struts-1.2.2. (You said
you're using 1.2.6 for the Ant build, but that one isn't on ibiblio. Can we
agree on 1.2.7 by any chance?)
James, can you comment on how you'd like to see this handled? The website
builds just fine whether or not the <extend> tag is there (so I'm happy
either way). But there are things in the common build file that are *not*
common to all subprojects. Maven is smart enough to allow sub-projects to
override dependencies by specifying a different version number,
(servletapi-2.2 instead of servletapi-2.3, for example.) But by extending
the common build, Struts Faces picks up dependencies on antlr,
commons-chain, commons-digester, commons-fileupload and oro, none of which
it really needs. I don't see a way to override a dependency coming from the
common build with "nothing".
Thanks,
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts-faces won't compile
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
> Faces is using a formerly deprecated, and now removed, method in
> RequestUtils. This breaks the Maven build, which works against
> struts-core-1.3.0-dev.
>
> Is this the correct fix?
>
Conceptually that fix makes sense in that it solves the compilation
problem ... but I don't believe that struts-faces should inherit a
dependency on 1.3.x. Today it works (runtime) on 1.1 and 1.2, and it
would be pretty pointless to throw away the vast majority of the
potential target market.
I think Struts-Faces (if it's going to be built with Maven :-) needs
its own set of dependencies, independent of whatever Struts Core is
using. That may mean decoupling from the shared "build"
infrastructure that is so handy across Struts Core ... but this
problem is going to get faced by other subcomponents as soon as they
contemplate independent release cycles.
Maybe the Maven mavens can figure out a way to share the build
infrastructure without sharing the dependency information?
Craig
> Thanks,
> Wendy
>
> Index:
> core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
> ===================================================================
> ---
> core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
> (revision 230657)
> +++
> core-library/src/java/org/apache/struts/faces/application/ActionListenerImpl.java
> (working copy)
> @@ -35,6 +35,7 @@
> import org.apache.struts.config.ModuleConfig;
> import org.apache.struts.faces.Constants;
> import org.apache.struts.faces.component.FormComponent;
> +import org.apache.struts.util.ModuleUtils;
> import org.apache.struts.util.RequestUtils;
>
>
> @@ -152,7 +153,7 @@
> // Invoke the appropriate request processor for this request
> try {
> request.setAttribute(Constants.ACTION_EVENT_KEY, event);
> - RequestUtils.selectModule(request, servletContext);
> + ModuleUtils.getInstance().selectModule(request,
> servletContext);
> ModuleConfig moduleConfig = (ModuleConfig)
> request.getAttribute(Globals.MODULE_KEY);
> if (log.isTraceEnabled()) {
>
>
>
> ---------------------------------------------------------------------
> 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