You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Antonio Petrelli <an...@gmail.com> on 2010/07/07 18:47:54 UTC
[Maven reorg] Velocity Engine reorg finished
Hi all
I would like to inform you that Maven reorganization of Velocity
Engine has finished. You can see the result here:
http://svn.eu.apache.org/repos/asf/velocity/sandbox/maven-reorg/engine/trunk/
I already posted the snapshots of Maven packages at the repository:
https://repository.apache.org/content/repositories/snapshots/
I would like to upload an assembly example ASAP, so you will see how
the distribution looks like.
There are still some points to do, that I do not consider as a "Maven
reorganization". These steps might be done once a promotion of the
sandboxed software has been vote. These steps are:
* Remove dependencies on Oro, Commons Collections and Commons Lang. If
some classes are needed, we can use the Shade plugin to rename classes
and avoid a direct dependency.
* The Excalibur dependency has not been removed.
* I would like to see a SLF4J Log chute.
Thoughts?
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/7/13 Claude Brisson <cl...@renegat.net>:
> Why are the src included, whereas the archive is suffixed -bin ?
Stupid me :-D Copied and pasted the code from the Tiles assembly, the
"-bin" suffix can be removed. Anyway we can consider having more than
one distribution.
> All the logging modules should maybe have a -log- in their name, like:
>
> velocity-engine-log-commons-logging
> velocity-engine-log-log4j
> velocity-engine-log-servlet
>
> Or, at least, we should rename velocity-engine-servlet to
> velocity-engine-servlet-logger to clarify what it is.
I prefer the latter scheme, since the name "velocity-engine-log-XXX"
implies the existence of "velocity-engine-log".
> Text files at root are to be reviewed: we now have six jars in the archive,
> along with a text file which is called WHY_TWO_JARS.txt, confusing for
> newcomers.
Obviously +1.
> Modules docs should at least state how to use them (like what config file to
> alter).
Yes and no. For example in Tiles all the *real* docs are in the parent
project. The module docs contain, essentially, only reports. However
it's a nice idea at least to have a pointer, in each module, to the
portion of the docs relative to the module itself.
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Claude Brisson <cl...@renegat.net>.
The binaries look ok.
Why are the src included, whereas the archive is suffixed -bin ?
All the logging modules should maybe have a -log- in their name, like:
velocity-engine-log-commons-logging
velocity-engine-log-log4j
velocity-engine-log-servlet
Or, at least, we should rename velocity-engine-servlet to
velocity-engine-servlet-logger to clarify what it is.
Text files at root are to be reviewed: we now have six jars in the
archive, along with a text file which is called WHY_TWO_JARS.txt,
confusing for newcomers.
Modules docs should at least state how to use them (like what config
file to alter).
Of course, anyone of us commiters can help on those points.
Claude
On 10/07/2010 13:53, Antonio Petrelli wrote:
> 2010/7/7 Antonio Petrelli<an...@gmail.com>:
>
>> I would like to upload an assembly example ASAP, so you will see how
>> the distribution looks like.
>>
> Here it is:
> http://people.apache.org/builds/velocity/2.0.0-SNAPSHOT/
> Let me know your thoughts.
>
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/7/7 Antonio Petrelli <an...@gmail.com>:
> I would like to upload an assembly example ASAP, so you will see how
> the distribution looks like.
Here it is:
http://people.apache.org/builds/velocity/2.0.0-SNAPSHOT/
Let me know your thoughts.
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Nathan Bubna <nb...@gmail.com>.
On Tue, Aug 31, 2010 at 12:27 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/8/31 Nathan Bubna <nb...@gmail.com>:
>>> - 1 -
>>> The test organization is strange: the .java test files are considered
>>> resources, parsed just to substitute two variables in one file, and
>>> then compiled. These variables are pointing to the template and target
>>> directory.
>>> The best thing to do is using to access resources from classpath and
>>> writing to temporary files. If file access is needed on read phase,
>>> they should be copied into a temporary file and then accessed from
>>> there.
>>> A second solution, easier but I don't like it too much, is to create a
>>> .properties file containing these variables and substitute them only
>>> in this file.
>>
>> Actually, i would prefer to see most of those old tests re-written to
>> be string-based, not file-based and ditch the substitution, if
>> possible. Though, i imagine we'll still need to do something like
>> that to test the FileResourceLoader, most VTL-centric tests should not
>> use external resources. For where we do need to load files, i don't
>> greatly care how it is done. All of these solutions seem acceptable
>> to me, let whoever does the work decide.
>
> This is outdated, sorry, I replaced everything with system properties
> (like you did in other Velocity subprojects) and they work like a
> charm.
>
>>> - 2 -
>>> Currently the parser code has been generated previously and then
>>> committed into the repository. Probably, the best approach is to
>>> generate it at build time, using the JavaCC Maven plugin.
>>
>> +1 that would be fantastic
>
> Sure, but *after* there is consensus about promoting from the sandbox
> to the main trunk.
agreed. no point in doing it otherwise!
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/8/31 Nathan Bubna <nb...@gmail.com>:
>> - 1 -
>> The test organization is strange: the .java test files are considered
>> resources, parsed just to substitute two variables in one file, and
>> then compiled. These variables are pointing to the template and target
>> directory.
>> The best thing to do is using to access resources from classpath and
>> writing to temporary files. If file access is needed on read phase,
>> they should be copied into a temporary file and then accessed from
>> there.
>> A second solution, easier but I don't like it too much, is to create a
>> .properties file containing these variables and substitute them only
>> in this file.
>
> Actually, i would prefer to see most of those old tests re-written to
> be string-based, not file-based and ditch the substitution, if
> possible. Though, i imagine we'll still need to do something like
> that to test the FileResourceLoader, most VTL-centric tests should not
> use external resources. For where we do need to load files, i don't
> greatly care how it is done. All of these solutions seem acceptable
> to me, let whoever does the work decide.
This is outdated, sorry, I replaced everything with system properties
(like you did in other Velocity subprojects) and they work like a
charm.
>> - 2 -
>> Currently the parser code has been generated previously and then
>> committed into the repository. Probably, the best approach is to
>> generate it at build time, using the JavaCC Maven plugin.
>
> +1 that would be fantastic
Sure, but *after* there is consensus about promoting from the sandbox
to the main trunk.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Nathan Bubna <nb...@gmail.com>.
On Thu, Jul 8, 2010 at 12:33 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/7/8 Nathan Bubna <nb...@gmail.com>:
>>> * The Excalibur dependency has not been removed.
>>
>> but it should be
>
> Yes, I forgot to tell it :-D
>
> Other things that I forgot:
>
> - 1 -
> The test organization is strange: the .java test files are considered
> resources, parsed just to substitute two variables in one file, and
> then compiled. These variables are pointing to the template and target
> directory.
> The best thing to do is using to access resources from classpath and
> writing to temporary files. If file access is needed on read phase,
> they should be copied into a temporary file and then accessed from
> there.
> A second solution, easier but I don't like it too much, is to create a
> .properties file containing these variables and substitute them only
> in this file.
Actually, i would prefer to see most of those old tests re-written to
be string-based, not file-based and ditch the substitution, if
possible. Though, i imagine we'll still need to do something like
that to test the FileResourceLoader, most VTL-centric tests should not
use external resources. For where we do need to load files, i don't
greatly care how it is done. All of these solutions seem acceptable
to me, let whoever does the work decide.
> - 2 -
> Currently the parser code has been generated previously and then
> committed into the repository. Probably, the best approach is to
> generate it at build time, using the JavaCC Maven plugin.
+1 that would be fantastic
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/7/8 Will Glass-Husain <wg...@gmail.com>:
> For patches to the 1.x line, we should continue to support JDK 1.3 I think
> even though it's so old. There's no reason to ditch it.
Absolutely, there's an increase in major version number for a reason :-D
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Will Glass-Husain <wg...@gmail.com>.
Got it. I missed this was Velocity 2.0. Sounds great then.
We should set an official targeted JDK.
For patches to the 1.x line, we should continue to support JDK 1.3 I think
even though it's so old. There's no reason to ditch it.
WILL
On Thu, Jul 8, 2010 at 8:00 AM, Antonio Petrelli <antonio.petrelli@gmail.com
> wrote:
> 2010/7/8 Will Glass-Husain <wg...@gmail.com>:
> > Regarding your comments on oro, etc. One key thing is we need to
> preserve
> > backwards compatibility, at least for the 1.x line. What this means is
> (a)
> > no changes to key interfaces, and (b) must remain run-compatible with JDK
> > 1.3. (though compiling requires JDK 1.4). Practically this means we
> cannot
> > use JDK 1.4 regular expression classes.
>
> Sorry? The 2.0 version number usually means that it is *incompatible*
> to Velocity 1.x.
> And, come one, Java 5 is at EOL since the last year:
> http://java.sun.com/products/archive/eol.policy.html
> And Java 1.3 isn't even mentioned. I think that, at least, a move to
> Java 5 is necessary for the sake of everyone.
> Otherwise, let's name it Velocity 1.8, not 2.0, it does not make any sense.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/7/8 Will Glass-Husain <wg...@gmail.com>:
> Regarding your comments on oro, etc. One key thing is we need to preserve
> backwards compatibility, at least for the 1.x line. What this means is (a)
> no changes to key interfaces, and (b) must remain run-compatible with JDK
> 1.3. (though compiling requires JDK 1.4). Practically this means we cannot
> use JDK 1.4 regular expression classes.
Sorry? The 2.0 version number usually means that it is *incompatible*
to Velocity 1.x.
And, come one, Java 5 is at EOL since the last year:
http://java.sun.com/products/archive/eol.policy.html
And Java 1.3 isn't even mentioned. I think that, at least, a move to
Java 5 is necessary for the sake of everyone.
Otherwise, let's name it Velocity 1.8, not 2.0, it does not make any sense.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Will Glass-Husain <wg...@gmail.com>.
Yes, the test file setup is kind of dumb. It needs a refactoring. Really,
we should be able to change this so all paths are relative
Regarding your comments on oro, etc. One key thing is we need to preserve
backwards compatibility, at least for the 1.x line. What this means is (a)
no changes to key interfaces, and (b) must remain run-compatible with JDK
1.3. (though compiling requires JDK 1.4). Practically this means we cannot
use JDK 1.4 regular expression classes.
WILL
On Thu, Jul 8, 2010 at 12:33 AM, Antonio Petrelli <
antonio.petrelli@gmail.com> wrote:
> 2010/7/8 Nathan Bubna <nb...@gmail.com>:
> >> * The Excalibur dependency has not been removed.
> >
> > but it should be
>
> Yes, I forgot to tell it :-D
>
> Other things that I forgot:
>
> - 1 -
> The test organization is strange: the .java test files are considered
> resources, parsed just to substitute two variables in one file, and
> then compiled. These variables are pointing to the template and target
> directory.
> The best thing to do is using to access resources from classpath and
> writing to temporary files. If file access is needed on read phase,
> they should be copied into a temporary file and then accessed from
> there.
> A second solution, easier but I don't like it too much, is to create a
> .properties file containing these variables and substitute them only
> in this file.
>
> - 2 -
> Currently the parser code has been generated previously and then
> committed into the repository. Probably, the best approach is to
> generate it at build time, using the JavaCC Maven plugin.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Antonio Petrelli <an...@gmail.com>.
2010/7/8 Nathan Bubna <nb...@gmail.com>:
>> * The Excalibur dependency has not been removed.
>
> but it should be
Yes, I forgot to tell it :-D
Other things that I forgot:
- 1 -
The test organization is strange: the .java test files are considered
resources, parsed just to substitute two variables in one file, and
then compiled. These variables are pointing to the template and target
directory.
The best thing to do is using to access resources from classpath and
writing to temporary files. If file access is needed on read phase,
they should be copied into a temporary file and then accessed from
there.
A second solution, easier but I don't like it too much, is to create a
.properties file containing these variables and substitute them only
in this file.
- 2 -
Currently the parser code has been generated previously and then
committed into the repository. Probably, the best approach is to
generate it at build time, using the JavaCC Maven plugin.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity Engine reorg finished
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Jul 7, 2010 at 9:47 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> Hi all
>
> I would like to inform you that Maven reorganization of Velocity
> Engine has finished. You can see the result here:
> http://svn.eu.apache.org/repos/asf/velocity/sandbox/maven-reorg/engine/trunk/
great! i'll see if i can find some time this weekend to look at it closely.
> I already posted the snapshots of Maven packages at the repository:
> https://repository.apache.org/content/repositories/snapshots/
> I would like to upload an assembly example ASAP, so you will see how
> the distribution looks like.
>
> There are still some points to do, that I do not consider as a "Maven
> reorganization". These steps might be done once a promotion of the
> sandboxed software has been vote.
reminder to any concerned readers: this is concerning Velocity 2.0.
we will not be moving to Maven in 1.x.
> These steps are:
> * Remove dependencies on Oro, Commons Collections and Commons Lang. If
> some classes are needed, we can use the Shade plugin to rename classes
> and avoid a direct dependency.
+1
> * The Excalibur dependency has not been removed.
but it should be
> * I would like to see a SLF4J Log chute.
sounds good.
> Thoughts?
>
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org