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.
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.
Since dependencies are not the same, the second solution would mean to
have separate modules for each and every one of them (not to speak about
the need to find a way to share the same source trees between those
modules).
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.
Claude
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
