Re: Common build file issues (was Re: struts-faces won't compile)
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 ). 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: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Wendy Smoak" <[EMAIL PROTECTED]> To: "Struts Developers List" 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 ... project.xml ... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common build file issues (was Re: struts-faces won't compile)
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 ). 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: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Wendy Smoak" <[EMAIL PROTECTED]> To: "Struts Developers List" 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 ... project.xml ... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 ... project.xml ... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
From: "Craig McClanahan" <[EMAIL PROTECTED]> +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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
On 8/11/05, Michael Rasmussen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > On 8/8/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > From: "Craig McClanahan" <[EMAIL PROTECTED]> > > > > > > > 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 build/project.xml > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
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 <[EMAIL PROTECTED]> wrote: > On 8/8/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > From: "Craig McClanahan" <[EMAIL PROTECTED]> > > > > > 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 build/project.xml 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
On 8/8/05, Wendy Smoak <[EMAIL PROTECTED]> wrote: > From: "Craig McClanahan" <[EMAIL PROTECTED]> > > > 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 build/project.xml 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
From: "Craig McClanahan" <[EMAIL PROTECTED]> 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 build/project.xml 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
On 8/8/05, Wendy Smoak <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]