tools-2.1-dev and engine-2.x

[Claude Brisson <cl...@renegat.net>]

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'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.


  Claude


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: tools-2.1-dev and engine-2.x

[Antonio Petrelli <an...@gmail.com>]

2011/4/13 Claude Brisson <cl...@renegat.net>

> On 2011-04-13 11:57, Antonio Petrelli wrote:
>
>> Hi Claude
>>
>> 2011/4/13 Claude Brisson<cl...@renegat.net>
>>
>>  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

Re: [OT] tools-2.1-dev and engine-2.x

[Nathan Bubna <nb...@gmail.com>]

I have no active plans to release 2.0.x.

On Tue, Jan 31, 2012 at 9:56 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nathan,
>
> On 1/31/12 12:39 PM, Nathan Bubna wrote:
>> Do you want a new 2.0 release?  I can't recall offhand if there is/was
>> a particular need or demand for one.
>
> No, but I was going to make some changes that I need fixing :)
>
> So, the question is whether to commit to trunk and back-port to 2.0.x,
> or not bother back-porting because 2.0.x is essentially done.
>
> Thanks,
> -chris
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: [OT] tools-2.1-dev and engine-2.x

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

On 1/31/12 12:39 PM, Nathan Bubna wrote:
> Do you want a new 2.0 release?  I can't recall offhand if there is/was
> a particular need or demand for one.

No, but I was going to make some changes that I need fixing :)

So, the question is whether to commit to trunk and back-port to 2.0.x,
or not bother back-porting because 2.0.x is essentially done.

Thanks,
-chris

Re: [OT] tools-2.1-dev and engine-2.x

[Nathan Bubna <nb...@gmail.com>]

Do you want a new 2.0 release?  I can't recall offhand if there is/was
a particular need or demand for one.

On Tue, Jan 31, 2012 at 9:26 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nathan,
>
> On 4/13/11 12:03 PM, Nathan Bubna wrote:
>> On Wed, Apr 13, 2011 at 4:19 AM, Claude Brisson <cl...@renegat.net> wrote:
>>> On 2011-04-13 11:57, Antonio Petrelli wrote:
>>>>
>>>> Hi Claude
>>>>
>>>> 2011/4/13 Claude Brisson<cl...@renegat.net>
>> ...
>>>
>>> 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.  At this point, tools is evolving slowly, and what time i do
>> have to develop velocity will be largely spent on engine 2.  I think
>> it is fine to release fixes to Tools in the 2.0.x branch and have 2.1
>> be where we drop support for both Tools 1 config and Engine 1.
>
> Can you confirm that your expectation is that Tools 2.0.x will have at
> least one more release? I was getting ready to make a few changes and I
> want to make sure that I commit to the right place. If 2.0.x is
> essentially dead, then I'll only commit to trunk and leave 2.0.x alone.
>
> Thanks,
> -chris
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: [OT] tools-2.1-dev and engine-2.x

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

On 4/13/11 12:03 PM, Nathan Bubna wrote:
> On Wed, Apr 13, 2011 at 4:19 AM, Claude Brisson <cl...@renegat.net> wrote:
>> On 2011-04-13 11:57, Antonio Petrelli wrote:
>>>
>>> Hi Claude
>>>
>>> 2011/4/13 Claude Brisson<cl...@renegat.net>
> ...
>>
>> 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.  At this point, tools is evolving slowly, and what time i do
> have to develop velocity will be largely spent on engine 2.  I think
> it is fine to release fixes to Tools in the 2.0.x branch and have 2.1
> be where we drop support for both Tools 1 config and Engine 1.

Can you confirm that your expectation is that Tools 2.0.x will have at
least one more release? I was getting ready to make a few changes and I
want to make sure that I commit to the right place. If 2.0.x is
essentially dead, then I'll only commit to trunk and leave 2.0.x alone.

Thanks,
-chris

Re: tools-2.1-dev and engine-2.x

[Nathan Bubna <nb...@gmail.com>]

On Wed, Apr 13, 2011 at 4:19 AM, Claude Brisson <cl...@renegat.net> wrote:
> On 2011-04-13 11:57, Antonio Petrelli wrote:
>>
>> Hi Claude
>>
>> 2011/4/13 Claude Brisson<cl...@renegat.net>
...
>
> 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.  At this point, tools is evolving slowly, and what time i do
have to develop velocity will be largely spent on engine 2.  I think
it is fine to release fixes to Tools in the 2.0.x branch and have 2.1
be where we drop support for both Tools 1 config and Engine 1.

It is great that we have worked so hard in the past for backward
compatibility.  But with Engine 2, i think we need to start letting go
of that at the API level (VTL from 1.x era should still work, though).
  So, i don't think it is really sustainable to burden Tools 2.1 with
the task of staying compatible with both the API of Engine 1 and
Engine 2.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: tools-2.1-dev and engine-2.x

[Claude Brisson <cl...@renegat.net>]

On 2011-04-13 11:57, Antonio Petrelli wrote:
> Hi Claude
>
> 2011/4/13 Claude Brisson<cl...@renegat.net>
>
>> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: tools-2.1-dev and engine-2.x

[Antonio Petrelli <an...@gmail.com>]

Hi Claude

2011/4/13 Claude Brisson <cl...@renegat.net>

> 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?


> 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.

Antonio