struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <>
Subject Re: struts-faces won't compile
Date Fri, 12 Aug 2005 03:04:24 GMT
From: "Craig McClanahan" <>

>> +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".

Wendy Smoak

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message