Actually - it all stemmed from me just wanting to exclude the SpringModule when using the tapx templating library for sending html emails!
Since that's a standalone app that just uses tapx & tap-ioc (no web component) it just got me thinking about using Tap-IOC for my other standalone, non Tapestry5 web based, projects (hence all the questons!). On Thu, 2011-01-06 at 15:23 -0800, Josh Canfield wrote: > > Again, it doesn't seem right to have to consider what are effectively > > runtime deployment configuration options when building an application into > > a jar. > > This is funny because I thought that is exactly what you are trying to > do. If you are going to exclude modules from a deployment but don't > want to do it from system properties, then you must be creating an app > module that uses your multi-module jar? If that's the case then you > can define your dependencies using the @SubModule annotation on your > deployed AppModule. If all of your included modules also define their > dependencies this way then you don't have to worry about extra's > getting loaded, just don't use the Manifest auto-loading. > > I prefer this method because it also documents your dependencies. > > If you are putting third party modules that use the auto-loading into > your classpath... then just don't do that. > > Josh > > > > On Thu, Jan 6, 2011 at 8:37 AM, Joel Halbert <j...@su3analytics.com> wrote: > > > >> > > - if you have lots of modules, which a client may want to selectively > >> > > enable, do not declare them in the manifest, but instead let the client > >> > > use the tapestry.modules sys property to selectively enabl > > > > But that's sort of my point - configuring IOC via a system property doesn't > > seem right, especially if all I wanted to do was disable 1 of many services. > > > > > > > >> > This looks like a huge JAR. Why not break it in smaller, more manageable > >> > ones? > > > > Again, it doesn't seem right to have to consider what are effectively > > runtime deployment configuration options when building an application into > > a jar. > > > > > > > > > > On Thu, 2011-01-06 at 14:15 -0200, Thiago H. de Paula Figueiredo wrote: > >> On Thu, 06 Jan 2011 14:09:02 -0200, Joel Halbert <j...@su3analytics.com> > >> wrote: > >> > >> > So if I understand correctly: > >> > > >> > - the only way to disable modules that are specified in the manifest is > >> > to remove the jar from the classpath > >> > >> Wrong. See > >> http://tapestry.1045711.n5.nabble.com/T5-disable-loading-specified-module-td2431110.html > >> > >> > - if you have lots of modules, which a client may want to selectively > >> > enable, do not declare them in the manifest, but instead let the client > >> > use the tapestry.modules sys property to selectively enable them > >> > >> This looks like a huge JAR. Why not break it in smaller, more manageable > >> ones? > >> You can also use @SubModule in a module class to include other modules > >> automatically without using system properties or context parameters. > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
