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.
>
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/32
---
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
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 t
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 rena
Le 18 oct. 2014 23:03, "Paul Benedict" a écrit :
>
> You are not including duplicate artifacts, they are totally distinct.
For maven yes, but code is the same. Said otherwise getting rid if all this
kind of duplicate would make a distrib like tomee significantly lighter
You are not including duplicate artifacts, they are totally distinct.
Romain Manni-Bucau wrote:
> Right but why should i have N times same binaries (cause broken apis are
> minor as it was said)?
Because you don't own the code that is using the library in two incompatible
versions?
> In tomee we even thought to repackage everything to
> avoid duplication
Your ch
GitHub user mbracher opened a pull request:
https://github.com/apache/commons-lang/pull/35
Avoid memory allocation when using date formating to StringBuffer.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mbracher/commons-lang
Right but why should i have N times same binaries (cause broken apis are
minor as it was said)? In tomee we even thought to repackage everything to
avoid duplication
Le 18 oct. 2014 20:54, "Paul Benedict" a écrit :
> I don't understand the point your making. Because the two libraries have
> their
I don't understand the point your making. Because the two libraries have
their code in completely separate packages, there will never be a conflict
at compile time or runtime.
Cheers,
Paul
On Sat, Oct 18, 2014 at 2:21 AM, Romain Manni-Bucau
wrote:
> Le 17 oct. 2014 23:09, "sebb" a écrit :
> >
TN,
Are you up for RM?
Gary
On Wed, Oct 15, 2014 at 10:46 AM, Gary Gregory
wrote:
> I'm done with my updates now... we can call it 1.3.4; or 1.4 to note the
> new APIs in the (util) MIME parser and updated deps.
>
> Any RMs out there?
>
> Gary
>
> On Wed, Oct 15, 2014 at 4:29 AM, Thomas Neidha
On Thu, Oct 16, 2014 at 3:57 PM, sebb wrote:
> On 14 October 2014 21:42, wrote:
> > Author: ggregory
> > Date: Tue Oct 14 20:42:57 2014
> > New Revision: 1631874
> >
> > URL: http://svn.apache.org/r1631874
> > Log:
> > Add maven-eclipse.xml and other Maven/Eclipse files to svn:ignore.
> >
> > A
Hi Murthy,
Le 18/10/2014 15:00, venkatesha murthy a écrit :
> Hi All
> (Not sure if this is already discussed;)
>
> The source repository link still points to svn. Perhaps this can point to
> latest git link and then may be another old repo link can be given to
> svn(for read only)
Thanks for th
Good Point. Would be nice if the jira issues could be generated
automatically... is anybody aware of such a service?
Send from my mobile device
> Am 17.10.2014 um 21:43 schrieb sebb :
>
> A related issue: when filing a JIRA from the pull request, please
> include more than just the PR URL.
>
>
Hi All
(Not sure if this is already discussed;)
The source repository link still points to svn. Perhaps this can point to
latest git link and then may be another old repo link can be given to
svn(for read only)
Next the Latest API Docs still takes us to 3.3 where as Last Published
version is 3.4-
Le 17 oct. 2014 23:09, "sebb" a écrit :
>
> On 17 October 2014 21:57, Paul Benedict wrote:
> > FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
> > breeze. I did a wholesale replacement of the package name and then fixed
> > any compiler problems due to API differences.
>
16 matches
Mail list logo
