date:20170126

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Claude Brisson




On 26/01/2017 19:45, Michael Osipov wrote:

Am 2017-01-26 um 18:37 schrieb Claude Brisson:




Now my question is: do you or someone else think that the OSGi missing
meta-informations are a show stopper for the 2.0? Otherwise, my plan
is to open JIRA issues for all those remarks, try to release the RC6,
and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one
I'm not really sure about, since I'm not using any tool relying on
OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).


Velocity 2.0 took so much time, one month more or less doesn't really 
make a difference now.


It does. It's becoming harder and harder for me to find time working on 
it. Your and others help as a reviewer is very helpful, but it does 
still take several hours each time, and there will *always* be an extra 
space to fix somewhere. I am not against seeking a certain form of 
perfection in the code, but the process doesn't have to be coerced in a 
single release.


And once the engine is released, I still have to take care of the Tools. 
And then of several other tools and filters for the next release of the 
Tools.


That's why I would like to see some rhythm. And releasing can attract 
more people. And who said "release often release early"? Or, in the same 
vein, "when the product is almost ready, kill the engineer"? Well, I'm 
an engineer, but I do understand the motivation.


But there will at least be an RC7. So, I'll try to do something about 
this OSGi missing informations.




Of course, if we find any other serious bug, the question is not anymore
pertinent. And I think I found a problem that sits here since some 
time...


What is the problem?


Velocity "truthiness": https://issues.apache.org/jira/browse/VELOCITY-692

It should definitely be part of 2.0. I missed it because the issue was 
closed, we should have opened a 2.0 one to remember it.



  Claude



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





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

Velocity 2 press release announcement

2017-01-26 Thread Mike Kienenberger

It might be worthwhile to send a message to press@ to start the
process of creating a velocity 2 press release.

MyFaces Tobago is working through that process now, and while I am not
directly involved, it appears that Sally will prepare a draft press
release for you and someone from velocity would need to help her fill
in the details.

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Michael Osipov

Am 2017-01-26 um 17:54 schrieb Claude Brisson:

On 26/01/2017 14:11, Michael Osipov wrote:
[...]

* StringUtils#normalizePath() can likely be replaced with Common IO's
FilenameUtils#normalize()

If we take this route, then we'll shade the commons-io class.

Absolutely, they might be other spots where this class can be used.
Moreover, either using IOUtils#closeQuietly() or try-with-resources will
clean up a lot of boilerplace code.

* OSGi metadata are gone from Core, no Bundle-SymbolicName, no
Exports, everything is gone from MANIFEST.MF

This I don't understand at all. You said "gone", so you implied that
those meta informations *were* to be found somewhere before this RC? I
think we never made the effort to properly populate those informations.

JIRA release notes say:
[VELOCITY-694] Make Velocity OSGi-ready

I do not see any of the OSGi required metadata.

* There are several spots where collections are iterated with a for
loop with a counter and #get(i) or a literal (legacy code). This
should generally be avoided. One example has been commented on GitHub.

I agree. Hopefully, this reenginering has already been done in sensitive
code sections, and remaining ones should be harmless.

Are you sure? I found a few #get(i) in a few loaders, RuntimeMacro and
Template. In a high-concurrency webapp where templates and macros are
loaded very often, this can be an issue, but of course, I do not have
hard numbers for this.

* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:

Note: UNICODE_INPUT option is specified. Please make sure you create
the parser/lexer using a Reader with the correct character encoding.
Warning: Choice conflict in [...] construct at line 1325, column 21.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is:
Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in (...)* construct at line 2157, column 5.
Expansion nested within construct and expansion following
construct
have common prefixes, one of which is:
Consider using a lookahead of 2 or more for nested expansion.

Is this something one needs to take care of?

Not at all. Those two grammar constructs partially rely on the *order of
declaration* (and the '?' cardinality suffix inside a repetition
operator is enough to trigger the warning). javacc is just anxious about
that, and suggests adding lookahead instead.

OK, great. What about UNICODE_INPUT? Docs say we should set this if we
have Unicode files. We have set UTF-8. Can we ignore this message too#?

Thanks for all this remarks, Michael. They all are very constructive.

Very much welcome.

Now my question is: do you or someone else think that the OSGi missing
meta-informations are a show stopper for the 2.0? Otherwise, my plan is
to open JIRA issues for all those remarks, try to release the RC6, and
handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one I'm
not really sure about, since I'm not using any tool relying on OSGi
myself (or maybe I'm the Monsieur Jourdain of the OSGi).

I do not use OSGi myself, but this says pretty much everything:
https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.velocity.
I consider proper OSGi metadata as vital for Velocity. Unfortunately, I
do not know what to set with the Bundle Maven Plugin to have proper data
generated.

Michael

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Michael Osipov


Am 2017-01-26 um 18:37 schrieb Claude Brisson:




Now my question is: do you or someone else think that the OSGi missing
meta-informations are a show stopper for the 2.0? Otherwise, my plan
is to open JIRA issues for all those remarks, try to release the RC6,
and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one
I'm not really sure about, since I'm not using any tool relying on
OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).


Velocity 2.0 took so much time, one month more or less doesn't really 
make a difference now.




Of course, if we find any other serious bug, the question is not anymore
pertinent. And I think I found a problem that sits here since some time...


What is the problem?


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Claude Brisson





Now my question is: do you or someone else think that the OSGi missing 
meta-informations are a show stopper for the 2.0? Otherwise, my plan 
is to open JIRA issues for all those remarks, try to release the RC6, 
and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one 
I'm not really sure about, since I'm not using any tool relying on 
OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).





Of course, if we find any other serious bug, the question is not anymore 
pertinent. And I think I found a problem that sits here since some time...


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Claude Brisson


On 26/01/2017 14:11, Michael Osipov wrote:
[...]
* StringUtils#normalizePath() can likely be replaced with Common IO's 
FilenameUtils#normalize()

If we take this route, then we'll shade the commons-io class.


* StringUtils#nullTrim() can be replaced with Commons Lang's 
StringUtils#trim()
* StringUtils#trimStrings() can be disposed altogether because it 
iterates the list and it is iterated right after the call again. Use 
StringUtils#trim() during the real iteration directly


Right.

[...]

* OSGi metadata are gone from Core, no Bundle-SymbolicName, no 
Exports, everything is gone from MANIFEST.MF


This I don't understand at all. You said "gone", so you implied that 
those meta informations *were* to be found somewhere before this RC? I 
think we never made the effort to properly populate those informations.


* There are several spots where collections are iterated with a for 
loop with a counter and #get(i) or a literal (legacy code). This 
should generally be avoided. One example has been commented on GitHub.


I agree. Hopefully, this reenginering has already been done in sensitive 
code sections, and remaining ones should be harmless.



* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:
Note: UNICODE_INPUT option is specified. Please make sure you create 
the parser/lexer using a Reader with the correct character encoding.

Warning: Choice conflict in [...] construct at line 1325, column 21.
 Expansion nested within construct and expansion following 
construct

 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in (...)* construct at line 2157, column 5.
 Expansion nested within construct and expansion following 
construct

 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.


Is this something one needs to take care of?

Not at all. Those two grammar constructs partially rely on the *order of 
declaration* (and the '?' cardinality suffix inside a repetition 
operator is enough to trigger the warning). javacc is just anxious about 
that, and suggests adding lookahead instead.


Thanks for all this remarks, Michael. They all are very constructive.

Now my question is: do you or someone else think that the OSGi missing 
meta-informations are a show stopper for the 2.0? Otherwise, my plan is 
to open JIRA issues for all those remarks, try to release the RC6, and 
handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one I'm 
not really sure about, since I'm not using any tool relying on OSGi 
myself (or maybe I'm the Monsieur Jourdain of the OSGi).



   Claude



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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Greg Huber

Ahh java, now seems so many different ways of doing the same thing
Just importing a file, I also have standard utils.

The path is the tricky one now, without testing it.

value = FileUtils.readFileToString(new File(
getProject().resolveFile(value)
.getCanonicalPath()),
UTF_8);

Path thePath = FileSystems.getDefault().getPath(
getProject().resolveFile(value)
.getCanonicalPath());

value = new String(Files.readAllBytes(thePath),
StandardCharsets.UTF_8);



On 26 January 2017 at 15:48, Claude Brisson  wrote:

> Oh, and Michael Osipov suggested a much easier way:
>
> import java.nio.Files;
> import java.nio.charset.StandardCharsets;
> 
> String contents = new String(Files.readAllBytes(path),
> StandardCharsets.UTF_8);
>
>
>   Claude
>
> On 26/01/2017 15:42, Claude Brisson wrote:
>
>> Hi Greg.
>>
>> Just include the commons-io library [1], then do:
>>
>> import org.apache.commons.io.FileUtils;
>> 
>> String content = FiileUtils.readFileToString(new File(filename),
>> Charset.UTF_8);
>>
>> The charset parameter is optional but recommended. Adapt it to your
>> needs, of course.
>>
>> [1] https://mvnrepository.com/artifact/commons-io/commons-io/2.5
>>
>>
>>   Claude
>>
>> On 26/01/2017 14:52, Greg Huber wrote:
>>
>>> Hello,
>>>
>>> I use the taxen task, and now have a local copy as its no longer
>>> supported.
>>>
>>> What would be an equivalent to .fileContentsToString(..) as its now
>>> missing?
>>>
>>> org.apache.velocity.util.StringUtils
>>>
>>> value = StringUtils.fileContentsToString(
>>> getProject().resolveFile(value)
>>> .getCanonicalPath());
>>>
>>> Cheers Greg
>>>
>>>
>>>
>>> On 26 January 2017 at 03:39, Claude Brisson  wrote:
>>>
>>> A new test build of Velocity Engine 2.0 is available (RC6).

 No determination as to the quality ('alpha,' 'beta,' or 'GA') of
 Velocity
 Engine 2.0 has been made, and at this time it is simply a "test build".
 We
 welcome any comments you may have, and will take all feedback into
 account
 if a quality vote is called for this build.

 Release notes:

 * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
 ine/2.0/release-notes.html

 Distribution:

   * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
 ine/2.0/

 Maven 2 staging repository:

   * https://repository.apache.org/content/repositories/orgapache
 velocity-1016/

 A vote regarding the quality of this test build will be initiated within
 the next couple of days.

 Release Candidates changelog:
RC1: initial candidate
RC2: bugfixes
RC3: review SLF4J Logger names (instead of a single logger named
 "Velocity", have a hierarchy of loggers with a base of
 'org.apache.velocity')
RC4: minor fixes
RC5:
 * the default encoding is now UTF-8 (and not the platform default)
 * commons-collections is not any more a compilation dependency
 * commons-lang3 dependency is not any more shaded
 * the configuration API doesn't reference ExtProperties
 * the events API has been optimized and reviewed: all events do
 receive
 the current Context
 * there has been a few optimizations in ASTStringLiteral rendering
 RC6: mostly code cleaning and build process optimization ; assembly
 module
 has been dropped


 Regards,

Claude




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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Greg Huber

Hello,

I use the taxen task, and now have a local copy as its no longer supported.

What would be an equivalent to .fileContentsToString(..) as its now missing?

org.apache.velocity.util.StringUtils

value = StringUtils.fileContentsToString(
getProject().resolveFile(value)
.getCanonicalPath());

Cheers Greg



On 26 January 2017 at 03:39, Claude Brisson  wrote:

> A new test build of Velocity Engine 2.0 is available (RC6).
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of Velocity
> Engine 2.0 has been made, and at this time it is simply a "test build". We
> welcome any comments you may have, and will take all feedback into account
> if a quality vote is called for this build.
>
> Release notes:
>
> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> ine/2.0/release-notes.html
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  * https://repository.apache.org/content/repositories/orgapache
> velocity-1016/
>
> A vote regarding the quality of this test build will be initiated within
> the next couple of days.
>
> Release Candidates changelog:
>   RC1: initial candidate
>   RC2: bugfixes
>   RC3: review SLF4J Logger names (instead of a single logger named
> "Velocity", have a hierarchy of loggers with a base of
> 'org.apache.velocity')
>   RC4: minor fixes
>   RC5:
>* the default encoding is now UTF-8 (and not the platform default)
>* commons-collections is not any more a compilation dependency
>* commons-lang3 dependency is not any more shaded
>* the configuration API doesn't reference ExtProperties
>* the events API has been optimized and reviewed: all events do receive
> the current Context
>* there has been a few optimizations in ASTStringLiteral rendering
> RC6: mostly code cleaning and build process optimization ; assembly module
> has been dropped
>
>
> Regards,
>
>   Claude
>
>
>

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

2017-01-26 Thread Michael Osipov


Am 2017-01-26 um 04:39 schrieb Claude Brisson:

A new test build of Velocity Engine 2.0 is available (RC6).

No determination as to the quality ('alpha,' 'beta,' or 'GA') of
Velocity Engine 2.0 has been made, and at this time it is simply a "test
build". We welcome any comments you may have, and will take all feedback
into account if a quality vote is called for this build.

Release notes:

*
https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/release-notes.html


Distribution:

 * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/

Maven 2 staging repository:

 *
https://repository.apache.org/content/repositories/orgapachevelocity-1016/

A vote regarding the quality of this test build will be initiated within
the next couple of days.


Hi Claude,

first of all, great improvement. Just checked the diff and have a few 
comments:


* Left a bunch of comments on the commits on GitHub, have a look
* StringUtils#EOL is never used
* StringUtils#normalizePath() can likely be replaced with Common IO's 
FilenameUtils#normalize()
* StringUtils#nullTrim() can be replaced with Commons Lang's 
StringUtils#trim()
* StringUtils#trimStrings() can be disposed altogether because it 
iterates the list and it is iterated right after the call again. Use 
StringUtils#trim() during the real iteration directly
* OSGi metadata are gone from Core, no Bundle-SymbolicName, no Exports, 
everything is gone from MANIFEST.MF
* There are several spots where collections are iterated with a for loop 
with a counter and #get(i) or a literal (legacy code). This should 
generally be avoided. One example has been commented on GitHub.

* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:

Note: UNICODE_INPUT option is specified. Please make sure you create the 
parser/lexer using a Reader with the correct character encoding.
Warning: Choice conflict in [...] construct at line 1325, column 21.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.
Warning: Choice conflict in (...)* construct at line 2157, column 5.
 Expansion nested within construct and expansion following construct
 have common prefixes, one of which is: 
 Consider using a lookahead of 2 or more for nested expansion.


Is this something one needs to take care of?


Michael

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Velocity 2 press release announcement

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

9 matches

Site Navigation

Mail list logo

Footer information