2010/6/30 Nathan Bubna <[email protected]>: > On Wed, Jun 30, 2010 at 7:40 AM, Antonio Petrelli > <[email protected]> wrote: >> 2010/6/30 Nathan Bubna <[email protected]>: >>> So, if i wanted to use the servlet log, i would have to download and >>> use both a velocity-engine jar and a velocity-engine-servlet jar? >> >> Yes. Or declare a dependency to velocity-log-servlet (I would like to >> name it this way) and velocity-engine will come as a transitive >> dependency. > > we have plenty of non-Maven users. so, naming it that way is making > an assumption that i would not recommend making.
Ok velocity-engine-servlet, however see below. >> Absolutely yes, optional dependencies are far more confusing than small >> modules. >> Take a look at how Tiles 2.2.2 is now, little modules with few >> classes, like tiles-servlet-wildcard, just to be sure to include >> Spring only when needed. > > more confusing to Maven users, perhaps. but there are many who do not > use Maven, for whom i think the confusion would run the other way. Again, for non-Maven users, there will be an uberjar. >>> optional packages? so *can* Maven acknowledge that a dependency is >>> required for compilation but optional at runtime? i've been operating >>> under the (mis)conception that it could not. >> >> Yes it can, by adding <optional>true</optional>. >> It must not confused with <scope>provided</scope> that means that a >> package is needed when compiling, but it is "provided" by an external >> source, e.g. servlet.jar in a servlet container, so it must be >> present, but outside of the package itself. >> The "provided" scope is clearer with WARs: if the scope is "compile" >> or "runtime", the package is included in WEB-INF/lib, if it is >> provided, it is not (not sure about optional packages though). > > yeah, i knew about "provided", but that would probably only apply to > the servlet api dependency. it would not have been an appropriate > designation for our log4j dependency. it is the "optional" > designation that i was looking for. "optional" does not indicate, in a clear way, if your package will work or not. This usually means that you discover that you need an extra dependency only at runtime. This also means that you need a clear documentation about it, thus you will receive some emails about it that you will easily avoid using non optional dependencies. > >>> what sort of transitive dependency troubles does it cause? >> >> If your project has optional packages, they must be included >> explicitly in projects that depend on it if you want to use them. The >> same for "provided" packages. > > that sounds perfect. how is it a trouble to require that users > explicitly declare optional things they wish to use? Because it is not "required" to do, you must discover it from Velocity's pom. > that is no different than non-Maven users being > required to add a jar for optional things they wish to use. Uberjar, again. Anyway, if you like to see one package with everything inside and optional dependencies, I won't object much. I tried in any way to describe the usefulness of the small package approach and the uberjar to collect packages in one jar if needed. Do we need to vote about it? (I know I will lose, who cares). Antonio P.S. Velocity Tools will follow the same path of splitting in several subpackages (at least "general", "struts" and "pure servlet"), but in this case the classes are more than just one. I hope to be more convincing next time. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
