Le dim. 9 juin 2019 à 15:46, sebb <seb...@gmail.com> a écrit : > > 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 scenario which I'm trying to address is: * a "supervising" org collects dependencies (only it can change the POM), * a developer provides a library (that depends on the new features of the "beta" release) to that org, as part of a larger software, * the org will only accept an official release (i.e. not a snapshot, not an ad-hoc JAR compiled by the developer, and not to do additional work, such as download the source and make an ad-hoc JAR). So, the aim is two-fold: 1. *not* a lot work of the org (just change the POM in some appropriate branch), 2. all the adaptation work is for the developer (and anyone who later decides to use the new features). > > > 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. And the reason why it is a no-no for the above scenario. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
