On Sun, 9 Jun 2019 at 14:20, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hi. > > Le dim. 9 juin 2019 à 14:06, James Carman <ja...@carmanconsulting.com> a > écrit : > > > > On Sun, Jun 9, 2019 at 7:36 AM sebb <seb...@gmail.com> wrote: > > > > > > > > Huh? > > > That can still cause jar issues, *precisely because* only one jar will > > > reach the Java classpath. > > > > > > Suppose there is jar1 with API-V1. > > > This is depended on by app1 and app2. > > > > > > Then jar2 is produced with API-V2 (not BC-compatible with API-V1) > > > Update app2 to use jar2. > > > > > > Assuming jar2 is a later version than jar1, the classpath will no > > > longer contain jar1. > > > However jar1 contains objects needed by app1. > > > > > > > My "jar hell" I usually think of is when two different jars are on the > > classpath at the same time and they expose the same class name. > > You're talking about the transitive dependency "jar hell" which > > definitely can happen. Sorry for my confusion. > > > > So, in order to get two different jars on the classpath at the same > > time (which I thought was what the original request was about in order > > to compare APIs), you'd need to change the maven coordinates to allow > > them to co-exist. When you do that, you'll need to change the package > > names in order to avoid collisions. > > > > If folks are publishing jars for others to consume with alpha/beta > > dependencies (which may very well change), I'd think that's really not > > a good idea and we should document our alpha/beta releases as such > > (although that's a pretty standard understanding). > > Sure, it's not good to depend on "beta"; but it's still better than > no code at all. With such releases, developers can start to > migrate away from obsolete CM codes, knowing that if all is > well, adapting to the final release will only be matter of a trivial > update of the "import" statements.
Or just recommend that developers download the current CM branch/tag and compile+test against that. This means no need to change the import statements. Which BTW might have to be done multiple times if there are several alphas/betas. And if errors are found in the user code, they may have to update multiple versions. This all seems a lot of work. I question whether releasing source-incompatible code is likely to encourage more alpha/beta testers compared with requiring users to compile the code from source. > > The other option > > is to just keep with SNAPSHOTs and tell folks to point to our snapshot > > repository. > > This is a step worse than "beta", as the artefacts can change > without notice. That is always the case with SNAPSHOTs. > Regards, > Gilles > > --------------------------------------------------------------------- > 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
