Hi Chris, You are correct and I agree with everything you say, no buts. You are even right in your assumption that I'm not aware of the @SubModule annotation. I don't recall seeing it mentioned anywhere, but will look it up in a minute.
To address your specific points (...of my inadequacy - ulp!) 1) However which way my Eclipse environment was set up (with disparate projects, maven plugins, etc...) the component module's manifest wasn't being picked up. (I suspect the compiled class folders were on the classpath and not the .jar itself - I never investigated.) As a dirty hack to get both modules loaded, I extended the module class. Wrong, I now know. 2) My thinking was thus; the only reason to enhance / add to an existing app's module would be for creating a test version of your app. I presumed that extending the module class was the only way to do that. I guess that, knowing T5 is still in alpha and not knowing the its code base, when something goes wrong and I've been bashing my head against it for some time, I'm not sure if I've done something really dumb (which has been the case) or if it's a problem yet to be addressed. If it helps redeem me any, I've been an avid follower of Tapestry since v3 and advocate it to all and sundry. And I am truely impressed with the clean design of T5. Regards, Steve. On Dec 9, 2007 5:04 PM, Chris Lewis <[EMAIL PROTECTED]> wrote: > This leaves me with two questions: > > My App Module class extended the > Component Module class. (Doh!) I now remember doing this to have the > Jetty Launcher in Eclipse pick up the component module configuration. > > 1) Why would you extend a module class so that it is effectively > included, when all you need to do is have it on the class path and the > the appropriate manifest entry (which I believe you said you had)? One > of the main bonuses of having component libs is to specifically avoid > this rigid coupling. However even if you wanted that, this is what > @SubModule is for. > > Except for maybe adding extra configuration for a test version of an > application I can't think why you'd want to extend the module class. > > 2) Again, extending the module class is (IMO) the Wrong Way(tm) of doing > this. I do this kind of testing/demoing for my component lib and have > such a test version of an app module. In the test version I simply use > @SubModule to 'include' the usual app module. > > Don't mistake my input as criticism - I just want to know if you were > aware of these seemingly emerging T5 best practices and had found > reasons to avoid them. If so, please share! > > sincerely, > chris > > > Steve Eynon wrote: > > Except for maybe adding extra configuration for a test version of an > > application I can't think why you'd want to extend the module class. > > That said, it's quite a constraint to impose for the module class > > doesn't *need* to be final. (And guaranteed someone, somewhere will > > want to at some point for some reason!) > > > > Maybe consider logging a warning message instead? That would then give > > more context to the "Service id has already been defined" error > > message. > > > > Steve. > > > > On Dec 8, 2007 5:26 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > >> Makes me wonder if Tapestry modules should be final? > >> > >> > >> On Dec 8, 2007 9:12 AM, Steve Eynon <[EMAIL PROTECTED]> wrote: > >> > >>> To clear this one up, I was in error. My App Module class extended the > >>> Component Module class. (Doh!) I now remember doing this to have the > >>> Jetty Launcher in Eclipse pick up the component module configuration. > >>> > >>> During my tour of the tapestry source I came across the > >>> "tapestry.modules" system parameter, so I can now have the component > >>> module picked up by both a stand-alone Jetty instance and the Eclipse > >>> Jetty Launcher. > >>> > >>> Cheers, > >>> > >>> Steve. > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
