> 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
