2011/4/13 Claude Brisson <[email protected]> > On 2011-04-13 11:57, Antonio Petrelli wrote: > >> Hi Claude >> >> 2011/4/13 Claude Brisson<[email protected]> >> >> My last commit allows the use of tools-2.1-dev with engine-2.x (providing >>> one has done "mvn install" in his local engine-2.0.0-SNAPSHOT directory). >>> >>> It's only a temporary solution for us developers, since for now it >>> requires >>> a manual replacement of three pom.xml by their respective alternate >>> pom.xml.engine2, and produces binaries which cannot be deployed since >>> they >>> have the same name as the ones depending upon engine-1.6, whereas they >>> would >>> need some kind of -engine2 suffix. >>> >>> I noticed you removed the velocity-tools-view-engine2 module. If it was >> not >> clear, its purpose was to support Engine 2, in particular for some >> problems >> with its API changes. Wasn't it enough from your POV? Where did you find >> problems? >> >> > It wasn't enough. There were two types of problems involving changes in > API: > > 1. The new ResourceLoader interface removed some "throw Exception" clauses. > You tried to circumvent this by duplicating the WebappResourceLoader in an > engine2 package in a dedicated module, but it's more easily solved by using > the trick consisting in catching Exceptions and throwing back > RuntimeExceptions in the client code, it avoids code duplication and > artefactual packages. Plus, your method needed a new velocity.properties > file, and the marshalling of its pathname in the configuration would have > led to more difficulties, like also having a specific > engine2.VelocityViewServlet class. > > 2. In the Log interface, some methods like "debug(Object message)" evolved > into "debug(Object message, Object... args)", and this problem wasn't > addressed: when you compile client code calling "debug(foo)" with > engine-1.6, it will not run with engine-2.x (because the Java runtime linker > still searches for the old pattern). In terms of dependencies, it means that > all tools modules must be compiled with engine-2.x.
Ok. > > I'm not at all expert with Maven so I don't know yet how we can manage to >>> have modules but producing different archive names depending on a >>> property >>> or a profile. >>> >>> >>> No, it's better not complicate things. Either we remove Engine 1.x >> support >> completely, and release Tools 2.1 when Engine 2.0 is ready, or support >> both >> of them through separate modules. >> Profiles are not ideal to create different artifacts. >> >> > Then I'd vote for the first solution: have tools-2.1 require engine-2.x > once it's released. After all, we can backport important changes to > tools-2.0.x. > I agree. > Just as a side node, I wonder why it's not possible in Maven to use > profiles to create different flavours of the binaries for one single > artifact, with a parametrized suffix that would distinguish their deployed > versions. There is surely a good reason I'm not aware of. > I did not mean that it is not possible, but it is not advisable. Profiles are designed to add certain extra functionality at build time, not to build extra artifacts. For example, add RAT plugin only when "release" profile is activated (RAT plugin checks presence of license headers in all source files). You can build extra artifacts even without profiles, simply configure Maven Jar plugin to do it, with extra *executions*. Flavouring builds might mean several things. For example, a typical use of "flavouring" is providing retrotranslated jars (compatible to Java 1.4), which involves the use of the retrotranslator plugin that creates a new artifact with a different classifier. But this is a corner and well known case. IMHO it's better to solve compatibility problems through modules and code patterns, such as "adapter" and "factory". Antonio
