You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Mary Helm (JIRA)" <ji...@apache.org> on 2016/12/08 16:38:58 UTC
[jira] [Created] (VELOCITY-878) commons collections is required at
run time
Mary Helm created VELOCITY-878:
----------------------------------
Summary: commons collections is required at run time
Key: VELOCITY-878
URL: https://issues.apache.org/jira/browse/VELOCITY-878
Project: Velocity
Issue Type: Bug
Components: Engine
Affects Versions: 2.0
Reporter: Mary Helm
The Velocity upgrading page states that •commons-lang, commons-collections and commons-logging aren't needed any more at runtime.
However, commons collections is still required. Here is the error received when using the latese version (4.1) of commons-collections jar:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties
at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
...
...
Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.ExtendedProperties
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [jira] [Created] (VELOCITY-878) commons collections is required
at run time
Posted by Claude Brisson <cl...@renegat.net>.
I agree, we don't need to expose ExtProperties.
On 09/12/2016 17:07, Michael Osipov wrote:
> Am 2016-12-09 um 13:05 schrieb Claude Brisson:
>> This issue has revealed another problem: we still have deprecated
>> initialization methods taking an ExtendedProperties object. But I had
>> totally overlooked the fact that since we now use shading, the method
>> signatures will change anyway. Even if we avoid shading this one
>> specific class, we can't decently keep an undeclared dependency, even
>
> I'd even question wether ExtProperties is needed as public API at all.
> ExtendedProperties was written long time ago, while Properties still
> don't have many features, it satisfies many cases.
>
> Why not have the user provide Properties only and ExtPropeties will
> extend Properties, removing duplication, adding only necessary bits
> and be an implementation-specific detail (e.g., VelocityProperties).
>
> The user pretty much does not care how velocity internally works with
> properties.
>
> Does this make sense?
>
> Michael
>
>
> ---------------------------------------------------------------------
> 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: [jira] [Created] (VELOCITY-878) commons collections is required
at run time
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-12-09 um 13:05 schrieb Claude Brisson:
> This issue has revealed another problem: we still have deprecated
> initialization methods taking an ExtendedProperties object. But I had
> totally overlooked the fact that since we now use shading, the method
> signatures will change anyway. Even if we avoid shading this one
> specific class, we can't decently keep an undeclared dependency, even
I'd even question wether ExtProperties is needed as public API at all.
ExtendedProperties was written long time ago, while Properties still
don't have many features, it satisfies many cases.
Why not have the user provide Properties only and ExtPropeties will
extend Properties, removing duplication, adding only necessary bits and
be an implementation-specific detail (e.g., VelocityProperties).
The user pretty much does not care how velocity internally works with
properties.
Does this make sense?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [jira] [Created] (VELOCITY-878) commons collections is required
at run time
Posted by Claude Brisson <cl...@renegat.net>.
> Plus, getting rid of ExtendedProperties can allow us to upgrade our
> dependency to commons-collections v4.1.
>
hum.. to totally get rid of this dependency, in fact.
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [jira] [Created] (VELOCITY-878) commons collections is required
at run time
Posted by Claude Brisson <cl...@renegat.net>.
This issue has revealed another problem: we still have deprecated
initialization methods taking an ExtendedProperties object. But I had
totally overlooked the fact that since we now use shading, the method
signatures will change anyway. Even if we avoid shading this one
specific class, we can't decently keep an undeclared dependency, even
for backward compatibility.
To upgrade, frameworks using this setExtendedProperties method just have
to use it with our cloned class, o.a.v.util.ExtProperties.
Plus, getting rid of ExtendedProperties can allow us to upgrade our
dependency to commons-collections v4.1.
Claude
On 08/12/2016 19:10, Claude Brisson wrote:
> Our first 2.0 JIRA entry! Champagne!
>
>
> On 08/12/2016 17:38, Mary Helm (JIRA) wrote:
>> Mary Helm created VELOCITY-878:
>> ----------------------------------
>>
>> Summary: commons collections is required at run time
>> Key: VELOCITY-878
>> URL:
>> https://issues.apache.org/jira/browse/VELOCITY-878
>> Project: Velocity
>> Issue Type: Bug
>> Components: Engine
>> Affects Versions: 2.0
>> Reporter: Mary Helm
>>
>>
>> The Velocity upgrading page states that \u2022commons-lang,
>> commons-collections and commons-logging aren't needed any more at
>> runtime.
>> However, commons collections is still required. Here is the error
>> received when using the latese version (4.1) of commons-collections jar:
>> Exception in thread "main" java.lang.NoClassDefFoundError:
>> org/apache/commons/collections/ExtendedProperties
>> at
>> org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
>> at
>> org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
>> ...
>> ...
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.commons.collections.ExtendedProperties
>> at java.net.URLClassLoader.findClass(Unknown Source)
>> at java.lang.ClassLoader.loadClass(Unknown Source)
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>> ---------------------------------------------------------------------
>> 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: [jira] [Created] (VELOCITY-878) commons collections is required
at run time
Posted by Claude Brisson <cl...@renegat.net>.
Our first 2.0 JIRA entry! Champagne!
On 08/12/2016 17:38, Mary Helm (JIRA) wrote:
> Mary Helm created VELOCITY-878:
> ----------------------------------
>
> Summary: commons collections is required at run time
> Key: VELOCITY-878
> URL: https://issues.apache.org/jira/browse/VELOCITY-878
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 2.0
> Reporter: Mary Helm
>
>
> The Velocity upgrading page states that \u2022commons-lang, commons-collections and commons-logging aren't needed any more at runtime.
> However, commons collections is still required. Here is the error received when using the latese version (4.1) of commons-collections jar:
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/ExtendedProperties
> at org.apache.velocity.runtime.RuntimeInstance.<init>(RuntimeInstance.java:175)
> at org.apache.velocity.app.VelocityEngine.<init>(VelocityEngine.java:60)
> ...
> ...
> Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.ExtendedProperties
> at java.net.URLClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> ---------------------------------------------------------------------
> 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