Re: [parent]

2014-10-19 Thread Benedikt Ritter 
Yes, I think so. What are the changes compared to last apache parent?

2014-10-19 18:39 GMT+02:00 Gary Gregory :

> Should commons-parent update the the latest Apache POM?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VFS] CustomRamProviderTest failure

2014-10-19 Thread Schalk Cronjé 

Ah yes, I now remember where I've seen it :)

I think it should just be committed. It is time we get VFS-2.1 released.

On 19/10/2014 20:36, Bernd Eckenfels wrote:

Hello,

https://issues.apache.org/jira/browse/VFS-521

I think I did not yet commit it, cause I was hoping it gets fixed in
the JDK, but it does not look like:

https://bugs.openjdk.java.net/browse/JDK-8042377

Gruss
Bernd

Am Sun, 19 Oct 2014 19:35:39 -0600
schrieb Schalk Cronjé :


When building from the Git repo of VFS I get the below error. I am
sure this was a previous issue that has been fixed. Is the Git repo
in sync with the SVN repo?

 Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
 0.018 sec <<< FAILURE! - in
 org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
 
testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
 Time elapsed: 0.009 sec  <<< ERROR!
 java.lang.IllegalArgumentException: Self-suppression not permitted
  at java.lang.Throwable.addSuppressed(Throwable.java:1043)
  at
java.io.FilterOutputStream.close(FilterOutputStream.java:159) at
 
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
  at
 
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
  at
 
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at
 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:483)
  at
 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
  at
 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
  at
 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
  at
 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
  at
 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
  at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
  at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
  at
 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
  at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
  at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
  at
 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
  at
 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
  at
 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
  at
 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
  at
 org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
 Caused by: java.io.IOException: FileSystem capacity (10) exceeded.
  at
 
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
  at
 
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
  at
 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
  at
 java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
  at
 
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
  at
java.io.FilterOutputStream.close(FilterOutputStream.java:158) ... 28
more







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




--
Schalk W. Cronjé
@ysb33r


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

Re: [VFS] CustomRamProviderTest failure

2014-10-19 Thread Bernd Eckenfels 
Hello,

https://issues.apache.org/jira/browse/VFS-521

I think I did not yet commit it, cause I was hoping it gets fixed in
the JDK, but it does not look like:

https://bugs.openjdk.java.net/browse/JDK-8042377

Gruss
Bernd

Am Sun, 19 Oct 2014 19:35:39 -0600
schrieb Schalk Cronjé :

> When building from the Git repo of VFS I get the below error. I am
> sure this was a previous issue that has been fixed. Is the Git repo
> in sync with the SVN repo?
> 
> Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.018 sec <<< FAILURE! - in
> org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
> 
> testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
> Time elapsed: 0.009 sec  <<< ERROR!
> java.lang.IllegalArgumentException: Self-suppression not permitted
>  at java.lang.Throwable.addSuppressed(Throwable.java:1043)
>  at
> java.io.FilterOutputStream.close(FilterOutputStream.java:159) at
> 
> org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
>  at
> 
> org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
>  at
> 
> org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at
> 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke(Method.java:483)
>  at
> 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at
> 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at
> 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at
> 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>  at
> 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>  at
> 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>  at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
> 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at
> 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
> 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
>  at
> 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>  at
> 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
>  at
> 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
>  at
> 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
>  at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.io.IOException: FileSystem capacity (10) exceeded.
>  at
> 
> org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
>  at
> 
> org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
>  at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>  at
> java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>  at
> 
> org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
>  at
> java.io.FilterOutputStream.close(FilterOutputStream.java:158) ... 28
> more
> 
> 
> 
> 
> 


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

[VFS] CustomRamProviderTest failure

2014-10-19 Thread Schalk Cronjé 
When building from the Git repo of VFS I get the below error. I am sure 
this was a previous issue that has been fixed. Is the Git repo in sync 
with the SVN repo?


   Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
   0.018 sec <<< FAILURE! - in
   org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest
   testSmallFS(org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest)
   Time elapsed: 0.009 sec  <<< ERROR!
   java.lang.IllegalArgumentException: Self-suppression not permitted
at java.lang.Throwable.addSuppressed(Throwable.java:1043)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
at
   
org.apache.commons.vfs2.util.MonitorOutputStream.close(MonitorOutputStream.java:54)
at
   
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentOutputStream.close(DefaultFileContent.java:711)
at
   
org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testSmallFS(CustomRamProviderTest.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
   sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
   
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
   
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
   
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
   
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
   
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
   org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
   org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
   
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
   
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at
   org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
   
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
   
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
   
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
   org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
   Caused by: java.io.IOException: FileSystem capacity (10) exceeded.
at
   
org.apache.commons.vfs2.provider.ram.RamFileObject.resize(RamFileObject.java:277)
at
   
org.apache.commons.vfs2.provider.ram.RamFileOutputStream.write(RamFileOutputStream.java:68)
at
   java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at
   java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at
   
org.apache.commons.vfs2.util.MonitorOutputStream.flush(MonitorOutputStream.java:114)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
... 28 more





--
Schalk W. Cronjé
@ysb33r

[parent]

2014-10-19 Thread Gary Gregory 
Should commons-parent update the the latest Apache POM?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] New compare() methods in LANG-536 pull request match Java source - is this ok?

2014-10-19 Thread Duncan Jones 
On 19 October 2014 07:04, Duncan Jones  wrote:
> On 18 October 2014 06:25, Duncan Jones  wrote:
>> On 17 October 2014 23:41, James Sawle  wrote:
>>> How do you create new implementations of such basic functionality that is 
>>> so explicitly defined within the API? It is like suggesting that we write 
>>> 1+1 as 1+((1+1)-1) just to look different.
>>
>> I think sometimes it's about knowing you did it right. I will make a
>> clean room implementation when I apply the patch. It will certainly
>> look different anyway, since I'm not a personal fan of short if
>> statements.
>>
>>
>>> They should also be made public as they are still useful for Java 6 and 
>>> prior (and unfortunately there are many houses that still depend on them) 
>>> and they will continue to persist!
>>
>> I agree. There is benefit to having them in the current release. Lang
>> 4.0 is probably some way off and many poor souls will be trapped in
>> Java 6 (and hence Lang 3.x) for some time.
>
> So, I went ahead and added these as non-deprecated, publicly
> accessible methods. Happy to have that aspect discussed on the ML if
> anyone wants to change it.
>
> (These were clean room implementations just based on the Javadoc description).

FYI - my Jira access is borked (anyone else?) so I've not been able to
resolve LANG-536 yet. I'll do so when I'm next able to log in.

>
>>> Just an off point, even if we can not use the implementations in a Java 7 
>>> situation. As the code has been copyrighted for Java 7 plus, do we not have 
>>> right to use it for Java 6 or before.
>>
>> IANAL, but I'm pretty sure the fact that we need this code because we
>> have no access to Java 7 is not a reason for the licenses not to
>> apply.
>>
>> Duncan
>>
>>> Sent from my iPhone
>>>
 On 17 Oct 2014, at 23:25, sebb  wrote:

> On 17 October 2014 22:56, James Sawle  wrote:
> Whilst the changes are the same as the Java 7 implementations, these in 
> fact came from OpenJDK implement ions and match the expected behaviour as 
> defined by the Javadoc. Any effort to change these so that that have less 
> resemblance to the Oracle implementation will just cause detrimental side 
> effects to performance.

 AIUI the OpenJDK license is GPLv2, which is not compatible with ALv2

 I think we need to create a clean-room implementation of the methods.

 These can be compared for speed against the OpenJDK versions.

 If they are much slower, then some effort might have to be expended to
 speed them up (again without reference to the JDK version).  Given
 that they are only needed temporarily, a minor slow-down is probably
 OK.

> We are not attempting to replace or capitalise Oracle functionality, but 
> merely polyfill it to precious Java versions. I think that the methods 
> should be removed as of Lang4 or if Java 7 becomes supported in Lang3 to 
> support this point.

 Yes, they should probably be removed when no longer needed.
 If they can be excluded from the public API then that will be easy.

> Sent from my iPhone
>
>> On 17 Oct 2014, at 12:45, Duncan Jones  wrote:
>>
>> Hi,
>>
>> James has authored a fine patch for LANG-536 (see below), but it does
>> include some code that exactly matches Java 7 source. Specifically,
>> the various compare(primitive, primitive) methods that have been added
>> to BooleanUtils, NumberUtils and CharUtils are identical to the
>> methods provided in Java 7 and above.
>>
>> Should we make some kind of syntactic changes to these methods to
>> avoid being accused of plagiarism? For instance, we could replace the
>> short-form if statements with the longer form. Or could we argue this
>> is just the canonical form of the method?
>>
>> Kind regards,
>>
>> Duncan
>>
>>
>>
>>> On 17 October 2014 01:02, jamessawle  wrote:
>>> GitHub user jamessawle opened a pull request:
>>>
>>>   https://github.com/apache/commons-lang/pull/32
>>>
>>>   Lang-536
>>>
>>>   Added new isSorted methods to the ArrayUtils class, along with 
>>> generic implementations.
>>>
>>>   Some of the primitive methods have needed reverse-engineered Java 7 
>>> 'compare' methods from their wrappers, so these have been added to 
>>> their respective Utils classes.
>>>
>>> You can merge this pull request into a Git repository by running:
>>>
>>>   $ git pull https://github.com/jamessawle/commons-lang LANG-536
>>>
>>> Alternatively you can review and apply these changes as the patch at:
>>>
>>>   https://github.com/apache/commons-lang/pull/32.patch
>>>
>>> To close this pull request, make a commit to your master/trunk branch
>>> with (at least) the following in the commit message:
>>>
>>>   This closes #32
>>>
>>> 
>>> commit d5244ac66df9557ecb634a1478b4a7c29f2a1783

Re: svn commit: r1632886 - in /commons/proper/collections/trunk/src: changes/changes.xml main/java/org/apache/commons/collections4/keyvalue/MultiKey.java

2014-10-19 Thread Thomas Neidhart 
On 10/19/2014 12:10 PM, brit...@apache.org wrote:
> Author: britter
> Date: Sun Oct 19 10:10:45 2014
> New Revision: 1632886
> 
> URL: http://svn.apache.org/r1632886
> Log:
> COLLECTIONS-535: Clarify JavaDoc of MultiKey getKey() and size(). This closes 
> #4 from github. Thanks to Alexander Kjäll
> 
> Modified:
> commons/proper/collections/trunk/src/changes/changes.xml
> 
> commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/keyvalue/MultiKey.java
> 
> Modified: commons/proper/collections/trunk/src/changes/changes.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/changes/changes.xml?rev=1632886&r1=1632885&r2=1632886&view=diff
> ==
> --- commons/proper/collections/trunk/src/changes/changes.xml (original)
> +++ commons/proper/collections/trunk/src/changes/changes.xml Sun Oct 19 
> 10:10:45 2014
> @@ -22,6 +22,9 @@
>
>  
>
> + due-to="Alexander Kjäll">
> +  Clarify JavaDoc of MultiKey getKey() and size()
> +
>  
>Added methods "removeAll(...)" and "retainAll(...)" to 
> "CollectionUtils" that perform
>equality checks using the provided "Equator" object instead of 
> "Object#equals()".
> 
> Modified: 
> commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/keyvalue/MultiKey.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/keyvalue/MultiKey.java?rev=1632886&r1=1632885&r2=1632886&view=diff
> ==
> --- 
> commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/keyvalue/MultiKey.java
>  (original)
> +++ 
> commons/proper/collections/trunk/src/main/java/org/apache/commons/collections4/keyvalue/MultiKey.java
>  Sun Oct 19 10:10:45 2014
> @@ -182,7 +182,8 @@ public class MultiKey implements Seri
>  }
>  
>  /**
> - * Gets the key at the specified index.
> + * Gets the key at the specified index. 
> + * The index enumeration starts at 0.

This is the default in the java language and does not need explicit
mentioning imho.

>   * 
>   * The key should be immutable.
>   * If it is not then it must not be changed.
> @@ -197,7 +198,7 @@ public class MultiKey implements Seri
>  }
>  
>  /**
> - * Gets the size of the list of keys.
> + * Gets the size of the list of keys, this number is the number of 
> values this object was created with.

this comment just adds more confusion, and I fail to see how the
original comment needs more clarification as the description is pretty
clear to me.

>   *
>   * @return the size of the list of keys
>   * @since 3.1
> 
> 

Thomas

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

[GitHub] commons-collections pull request: clarified javadoc for getKey() a...

2014-10-19 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-collections/pull/4


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

2014-10-19 Thread Romain Manni-Bucau 
Phil summarized it right!

But we can stop this thread since maybe tomee will just need to take more
《ownership》 on its deps to tackle it...
Le 19 oct. 2014 06:19, "Henri Yandell"  a écrit :

> On Sat, Oct 18, 2014 at 2:44 PM, Phil Steitz 
> wrote:
>
> > On 10/18/14 2:03 PM, Paul Benedict wrote:
> > > You are not including duplicate artifacts, they are totally distinct.
> >
> > I think Romain's point is that classes that are not changed in the
> > different versions are duplicated.  It's interesting that from
> > Romain's standpoint, the single jar, mass package rename strategy we
> > have taken is "impractical," but what seems reasonable to him -
> > split changed APIs into new jars - seems impractical to us.  So
> > either he ends up repackaging (or distributing a larger
> > distribution), or we do.  This is probably not a popular view here,
> > but I think the moral of the story is we should try as much as
> > possible to avoid backward-incompatible change in already released
> > APIs - i.e., favor deprecate and replace.  That at least makes the
> > splitting possible.  From painful experience in [math], however, I
> > know this is sometimes not possible - i.e., there is such a thing as
> > broken APIs - bugs that can't be resolved without incompatible API
> > change.  And in other cases [pool], [dbcp], there really is no
> > "duplication" as the v2's are completely different implementations.
> >
>
> But if Roman's use case is to ship the smallest amount of code as possible,
> then he shouldn't be relying on dependencies being small. He should be
> using build-time strategies to pull only the classes, or the functions,
> that are needed.
>
> Not that I'm not +1 to splitting off the lang3.time package into its own
> jar, and then leaving it in maintenance only mode :)
>
> Hen
>