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. > 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. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
