Thanks for the testing :) I added the dependency to rest-showcase to make build again. I also added a note to the 2.1.1 release notes.
musachy On Fri, Jun 6, 2008 at 10:24 AM, Jeromy Evans <[EMAIL PROTECTED]> wrote: > Hi Musachy, > > Just letting you know I just moved a large rest-plugin app from an old > 2.1.3-snapshot to the current head to try things out...and it still works > :-) > > Here's what I had to do: - added codebehind as a direct dependency for the > application (for now) as it was removed as a dependency from rest-plugin > - removed direct use of > struts.configuration.classpath.disableActionScanning=true, which still has > an effect. > > I'll move this app over to a Rest+Convention later. > > I don't share the view that plugins must not have dependencies on other > plugins. I have plugins that provide Controllers so a run-time dependency > on the rest plugin is mandatory as the rest plugin provides fundamental > behaviour. Some of those Controllers use @Result annotations so an explicit > dependency on CodeBehind (or Convention later) also now exists. It doesn't > sit comfortably with me that the pom has to reference both dependencies > explicitly when the actual requirement is for the rest-plugin and its > transitive dependencies (such as struts-core and codebehind/convention). I > also am certain I will need to publish S2 plugins that depend on these > plugins (and others) later. > > regards, > Jeromy Evans > > PS. rest howcase on trunk can't build as it uses @Results and now needs an > explicit dependency on CodeBehind/Convention added to its pom. > > Musachy Barroso wrote: >> >> I created a proposal page on the wiki for this: >> >> >> http://cwiki.apache.org/confluence/display/S2WIKI/Convention%2CCodebehind+and+REST+2.3 >> >> I also opened a ticket for fixing the depenency between >> REST->Codebehind, which I don't see why it should exists: >> >> https://issues.apache.org/struts/browse/WW-2667 >> >> After taking care of that issue, and if we get to agree on the new >> "unknown-handler-stack" (nobody has said anything pro/against yet), we >> are done with the blocking concerns. (I think) >> >> musachy >> >> On Wed, Jun 4, 2008 at 9:25 AM, Musachy Barroso <[EMAIL PROTECTED]> wrote: >> >>> >>> Here is yet another idea, this one assumes that multiple >>> UnknowHandler(s) can be stacked (which I am prototyping). If we modify >>> ControllerClasspathPackageProvider, so it delegates to an instance of >>> ClasspathPackageProvider instead of extending it, and using reflection >>> for the delegation of those few methods, we could have a nice setup: >>> >>> 1. Applications using Codebehind >>> No changes to Codebehind were done, they will continue to work >>> >>> 2.Applications using Codebehind + REST >>> REST ControllerClasspathPackageProvider will find Codebehind's >>> ClasspathPackageProvider in the classpath, and delegate to it using >>> reflection. These applications will continue to work without any >>> modification. >>> >>> 3. Applications using REST + Convention >>> REST ControllerClasspathPackageProvider won't find Codebehind's >>> ClasspathPackageProvider in the classpath so it won't do anything. >>> REST will work on top of Convention (this works fine). >>> >>> Plugins will be standalone, like they are now, and backward >>> compatibility will be kept. As a side effect, REST could be used with >>> XML configuration without Codebehind being in the classpath. I know >>> reflection is not a very elegant solution, but it would be temporary >>> until Codebehind is phased out, a few versions later. >>> >>> musachy >>> >>> >> >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.6/1481 - Release >> Date: 3/06/2008 7:31 PM >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
