On Sat, Mar 31, 2018 at 6:52 AM, Gary Gregory
wrote:
> These two changes will happen when we go to version 5, the next major
> version, which will also change the package name and maven artifact ID.
> There are no other BC breaking changes ATM, so I took them out of master
> since the next releas
These two changes will happen when we go to version 5, the next major
version, which will also change the package name and maven artifact ID.
There are no other BC breaking changes ATM, so I took them out of master
since the next release is 4.2.
Gary
On Sat, Mar 31, 2018, 03:24 Claude Warren wro
I have been of 2 minds on this. On one side I think we move forward, bump
the number.
on the other side is the part of me from my $dayjob that has to deal with
new versions and security alerts and make it all run on Java 6 (I'll not
bore you with the details here).
Having flopped back and forth
i'm not sure i follow, don't we already have breaking changes for which
we've decided to change bump the version?
On 03/29/2018 11:00 PM, Paul King wrote:
Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Brid
Just to clarify, when I said "It's built with gradle and uses Ant", I
mean our build is gradle based and our call of Bridger uses Ant.
Bridger itself is built with Maven.
On Fri, Mar 30, 2018 at 12:20 PM, Paul King wrote:
> In the Groovy build we do this using Bridger
> (https://github.com/dmlloy
In the Groovy build we do this using Bridger
(https://github.com/dmlloyd/bridger). It's built with gradle (and uses
Ant). They have a Maven plugin but I haven't used it.
In our build we have this:
compileJava {
doLast {
ant.java(classname:'org.jboss.bridger.Bridger', classpath:
rootPr
This could be solved if it were possible to force javac to generate bridge
methods. There's an extension which would allow that here:
https://github.com/infradna/bridge-method-injector, but I suspect it would
complicate the build process quite a bit.
On Thu, Mar 29, 2018 at 4:48 PM sebb wrote:
>
The return type is part of the method signature that Java uses to find
resolve references.
Even changing from void to non-void will cause binary incompatibility.
(Source-wise, that's fine)
On 29 March 2018 at 18:20, Gary Gregory wrote:
> Yep, that's no good. I'll revert.
>
> Gary
>
> On Thu, Mar
Yep, that's no good. I'll revert.
Gary
On Thu, Mar 29, 2018 at 10:16 AM, Paul King
wrote:
> I haven't looked into the IteratorUtils class at all but it's easy to
> show binary incompatibility when changing the return type.
> Compile this "library" class:
>
> import java.util.ArrayList;
> import
I haven't looked into the IteratorUtils class at all but it's easy to
show binary incompatibility when changing the return type.
Compile this "library" class:
import java.util.ArrayList;
import java.util.List;
public class Lib {
List getMyList() {
return new ArrayList();
}
}
Now
Can you show how older code would not function. Aside from using reflection.
Gary
On Thu, Mar 29, 2018, 09:03 Claude Warren wrote:
> if we are using semantic numbering would this not cause a major revision
> change as older code will no longer function?
>
> Claude
>
> On Thu, Mar 29, 2018 at 3:
if we are using semantic numbering would this not cause a major revision
change as older code will no longer function?
Claude
On Thu, Mar 29, 2018 at 3:51 PM, Gary Gregory
wrote:
> Hi All:
>
> Updating Commons Collections' commons-parent from version 43 to 45 causes
> the build to fail due to t
Hi All:
Updating Commons Collections' commons-parent from version 43 to 45 causes
the build to fail due to the use of japicmp which reports:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
project commons-collections4: Error generating
japicmp-
13 matches
Mail list logo
