struts-faces won't compile

NAVIGATION

CATEGORIES

Java

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » Java

struts-faces won't compile
9 answers - 936 bytes -
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:
(revision 230657)
(working copy)
@@ -35,6 +35,7 @@
import ;
import ;
import ;
+import ;
import ;
@@ -152,7 +153,7 @@
// Invoke the appropriate request processor for this request
try {
request.setAttribute(Constants.ACTIN_EVENT_KEY, event);
- RequestUtils.selectModule(request, servletContext);
+ ModuleUtils.getInstance().selectModule(request,
servletContext);
ModuleConfig moduleConfig = (ModuleConfig)
request.getAttribute(Globals.MDULE_KEY);
if (log.isTraceEnabled()) {
To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.1 | | 1989 bytes | |
8/8/05, Wendy Smoak <java (AT) wendysmoak (DOT) comwrote:
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:

(revision 230657)

(working copy)
@@ -35,6 +35,7 @@
import ;
import ;
import ;
+import ;
import ;

@@ -152,7 +153,7 @@
// Invoke the appropriate request processor for this request
try {
request.setAttribute(Constants.ACTIN_EVENT_KEY, event);
- RequestUtils.selectModule(request, servletContext);
+ ModuleUtils.getInstance().selectModule(request,
servletContext);
ModuleConfig moduleConfig = (ModuleConfig)
request.getAttribute(Globals.MDULE_KEY);
if (log.isTraceEnabled()) {

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.2 | | 773 bytes | |
From: "Craig McClanahan" <craigmcc (AT) gmail (DOT) 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</extendfrom
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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.3 | | 1200 bytes | |
8/8/05, Wendy Smoak <java (AT) wendysmoak (DOT) comwrote:
From: "Craig McClanahan" <craigmcc (AT) gmail (DOT) 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</extendfrom
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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.4 | | 2660 bytes | |
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
compatabilityafter 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 latelyhas 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

8/8/05, Craig McClanahan <craigmcc (AT) gmail (DOT) comwrote:
8/8/05, Wendy Smoak <java (AT) wendysmoak (DOT) comwrote:
From: "Craig McClanahan" <craigmcc (AT) gmail (DOT) 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</extendfrom
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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.5 | | 3233 bytes | |
8/11/05, Michael Rasmussen <razmaspaz (AT) gmail (DOT) comwrote:
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
compatabilityafter 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 latelyhas 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.

My $0.02

Michael

Craig

8/8/05, Craig McClanahan <craigmcc (AT) gmail (DOT) comwrote:
8/8/05, Wendy Smoak <java (AT) wendysmoak (DOT) comwrote:
From: "Craig McClanahan" <craigmcc (AT) gmail (DOT) 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</extendfrom
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 (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
>
>
>

To unsubscribe, e-mail: dev-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: dev-help (AT) struts (DOT) apache.org
No.6 | | 2116 bytes | |
From: "Craig McClanahan" <craigmcc (AT) gmail (DOT) com>

>+import ;
>-RequestUtils.selectModule(request, servletContext);
>+ModuleUtils.getInstance().selectModule(request,se rvletContext);

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 and
, 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 <extendtag 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,
No.7 | | 1341 bytes | |
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. 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.
No.8 | | 2064 bytes | |
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)
No.9 | | 2064 bytes | |
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)

Re: struts-faces won't compile

EMSDN.COM

Question 'struts-faces won't compile' on 'Java'

Java

struts-faces won't compile