On Sat, Mar 31, 2018 at 6:52 AM, Gary Gregory <garydgreg...@gmail.com> 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 release is 4.2. > FWIW, I'd like to see 4.2 release as soon as we release new versions our build plugin and parent POM. Gary Gary > > On Sat, Mar 31, 2018, 03:24 Claude Warren <cla...@xenei.com> wrote: > >> 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 on this in my mind I finally come down on >> the >> side of keeping the changes bumping the version number. We should not >> stop >> progress for fear of breaking some code (eggs and omelets) as long as we >> are clear and clean. Those that need new functionality but can't take all >> the changes a re free to recompile as they need; as we will do at my >> $dayjob. >> >> +1 bump the number and keep the functionality. >> +2 if we clearly document where it breaks from earlier version ;) >> >> Claude >> >> On Sat, Mar 31, 2018 at 2:08 AM, Dave Brosius <dbros...@baybroadband.net> >> wrote: >> >> > 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. >> >> Bridger itself is built with Maven. >> >> >> >> On Fri, Mar 30, 2018 at 12:20 PM, Paul King <paul.king.as...@gmail.com >> > >> >> wrote: >> >> >> >>> 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: >> >>> rootProject.configurations.tools.asPath, outputproperty: 'stdout') { >> >>> arg(value: >> >>> "${sourceSets.main.java.outputDir.canonicalPath}/org/codehau >> >>> s/groovy/runtime/DefaultGroovyMethods.class") >> >>> } >> >>> ant.echo('Bridger: ' + ant.properties.stdout) >> >>> } >> >>> } >> >>> >> >>> And in the relevant source file we have a small number of $$bridge >> >>> methods like this one: >> >>> >> >>> public static <T> List<T> withDefault$$bridge(List<T> self, Closure<T> >> >>> init) { >> >>> return withDefault(self, init); >> >>> } >> >>> >> >>> to match the original methods we are duplicating, e.g.: >> >>> >> >>> public static <T> ListWithDefault<T> withDefault(List<T> self, >> >>> Closure<T> init) { >> >>> // ... code here ... >> >>> } >> >>> >> >>> Cheers, Paul. >> >>> >> >>> On Fri, Mar 30, 2018 at 9:52 AM, Peter Burka <pe...@quux.net> wrote: >> >>> >> >>>> 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 <seb...@gmail.com> 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 <garydgreg...@gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>>> Yep, that's no good. I'll revert. >> >>>>>> >> >>>>>> Gary >> >>>>>> >> >>>>>> On Thu, Mar 29, 2018 at 10:16 AM, Paul King < >> >>>>>> paul.king.as...@gmail.com> >> >>>>>> 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 java.util.List; >> >>>>>>> >> >>>>>>> public class Lib { >> >>>>>>> List getMyList() { >> >>>>>>> return new ArrayList(); >> >>>>>>> } >> >>>>>>> } >> >>>>>>> >> >>>>>>> Now compile this user of the library: >> >>>>>>> >> >>>>>>> import java.util.List; >> >>>>>>> >> >>>>>>> public class Main { >> >>>>>>> public static void main(String[] args) { >> >>>>>>> doit(new Lib().getMyList()); >> >>>>>>> } >> >>>>>>> >> >>>>>>> private static void doit(List list) { >> >>>>>>> System.out.println("list is: " + list); >> >>>>>>> } >> >>>>>>> } >> >>>>>>> >> >>>>>>> >> >>>>>>> Ensure it all works: >> >>>>>>> >> >>>>>>> java -cp path_to_lib Main >> >>>>>>>> >> >>>>>>> Should output: >> >>>>>>> >> >>>>>>> List is: [] >> >>>>>>> >> >>>>>>> Now change the Lib class to return ArrayList instead of List and >> >>>>>>> recompile just the Lib class (i.e. importantly don't recompile >> Main). >> >>>>>>> >> >>>>>>> Now if you try: >> >>>>>>> >> >>>>>>> java -cp path_to_lib Main >> >>>>>>>> >> >>>>>>> you should see: >> >>>>>>> >> >>>>>>> Exception in thread "main" java.lang.NoSuchMethodError: >> >>>>>>> Lib.getMyList()Ljava/util/List; >> >>>>>>> at Main.main(Main.java:5) >> >>>>>>> >> >>>>>>> Cheers, Paul. >> >>>>>>> >> >>>>>>> On Fri, Mar 30, 2018 at 1:41 AM, Gary Gregory < >> >>>>>>> garydgreg...@gmail.com> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> Can you show how older code would not function. Aside from using >> >>>>>>>> >> >>>>>>> reflection. >> >>>>>>> >> >>>>>>>> Gary >> >>>>>>>> >> >>>>>>>> On Thu, Mar 29, 2018, 09:03 Claude Warren <cla...@xenei.com> >> 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:51 PM, Gary Gregory < >> >>>>>>>>> >> >>>>>>>> garydgreg...@gmail.com> >> >>>>> >> >>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> 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-maven-plugin:0.11.0:cmp-report report: Failed to >> generate >> >>>>>>>>>> >> >>>>>>>>> report: >> >>>>>>> >> >>>>>>>> Breaking the build because there is at least one incompatibility: >> >>>>>>>>>> org.apache.commons.collections4.IteratorUtils. >> >>>>>>>>>> >> >>>>>>>>> peekingIterator(java.util. >> >>>>>>> >> >>>>>>>> Iterator):METHOD_RETURN_TYPE_CHANGED,org.apache.commons. >> >>>>>>>>>> collections4.IteratorUtils.pushbackIterator(java.util. >> >>>>>>>>>> Iterator):METHOD_RETURN_TYPE_CHANGED >> >>>>>>>>>> -> [Help 1] >> >>>>>>>>>> >> >>>>>>>>>> This is caused by: >> >>>>>>>>>> >> >>>>>>>>>> - [COLLECTIONS-676] Modify IteratorUtils.pushbackIterator >> >>>>>>>>>> >> >>>>>>>>> signature to >> >>>>> >> >>>>>> return PushbackIterator. >> >>>>>>>>>> - [COLLECTIONS-675] Modify IteratorUtils.peekingIterator >> signature >> >>>>>>>>>> >> >>>>>>>>> to >> >>>>> >> >>>>>> return PeekingIterator. >> >>>>>>>>>> >> >>>>>>>>>> Which are reasonable changes IMO. >> >>>>>>>>>> >> >>>>>>>>>> Does anyone object to these changes and adding exceptions to >> allow >> >>>>>>>>>> >> >>>>>>>>> japicmp >> >>>>>>>>> >> >>>>>>>>>> to >> >>>>>>>>>> not fail the build? >> >>>>>>>>>> >> >>>>>>>>>> Thank you, >> >>>>>>>>>> Gary >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> I like: Like Like - The likeliest place on the web >> >>>>>>>>> <http://like-like.xenei.com> >> >>>>>>>>> LinkedIn: http://www.linkedin.com/in/claudewarren >> >>>>>>>>> >> >>>>>>>>> ------------------------------------------------------------ >> >>>>>>> --------- >> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>>>>> >> >>>>>>> >> >>>>>>> ------------------------------------------------------------ >> >>>>> --------- >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>>>> >> >>>>> >> >>>>> ------------------------------------------------------------ >> --------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> >> -- >> I like: Like Like - The likeliest place on the web >> <http://like-like.xenei.com> >> LinkedIn: http://www.linkedin.com/in/claudewarren >> >
