What sort of comparison are you looking to do within the same code? Performance?
On Wed, Jun 5, 2019 at 10:54 AM Gilles Sadowski <gillese...@gmail.com> wrote: > Le mer. 5 juin 2019 à 16:22, sebb <seb...@gmail.com> a écrit : > > > > On Wed, 5 Jun 2019 at 15:06, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > > Le mer. 5 juin 2019 à 15:59, sebb <seb...@gmail.com> a écrit : > > > > > > > > On Wed, 5 Jun 2019 at 14:33, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > > > > > > Le mer. 5 juin 2019 à 15:18, sebb <seb...@gmail.com> a écrit : > > > > > > > > > > > > I'm not sure what problem this is trying to solve. > > > > > > > > > > > > How is it intended to use the facility? > > > > > > > > > > Ideally: > > > > > $ mvn -Pbetarelease [... other settings ...] > -Dbetasubversion=alpha1 > > > > > where the latter profile would take care of changing the > > > > > toplevel package name > > > > > o.a.c.somecomp > > > > > to > > > > > o.a.c.somecomp.alpha1 > > > > > > > > > > And, if the upcoming version is, say, "2.3", the generated > > > > > artefact(s) would be: > > > > > commons-somecomp-2.3-alpha1 > > > > > > > > That's not what I intended to ask. > > > > > > > > What problem does the ability to readily change the package name > actually solve? > > > > And how are the amended packages going to be used? > > > > > > Maybe, I don't understand the question. > > > The purpose is to be able to quickly produce several beta releases that > > > don't have to be compatible with other beta releases but that can > coexist > > > for the purpose of allowing users to compare the impact of the changes. > > > > I don't understand how the user can actually test the release unless > > they also produce code that is likewise shaded to invoke the > > appropriate version of the package. > > Of course, if they want to test "alpha1", they need to depend on it, > and modify their code accordingly. > > > Surely it would be easier to test the code if it used the standard > > package names, i.e. no need to change the user code? > > Yes, but that means that we cannot compare "alpha1" and "alpha2" in > the same code. > > > i.e. take their app, and run it against the relevant alpha- or > beta-release. > > Then the main concern is the possibility of JAR hell (e.g. when several > "alpha" are in the classpath). > > > This is already possible if the user has the ability to compile the > > component from source. > > I think that If we hope to get help from users, we should provide a JAR. > > Regards, > Gilles > > > > > > Gilles > > > > > > > > > > > > Regards, > > > > > Gilles > > > > > > > > > > > > > > > > > On Tue, 4 Jun 2019 at 17:35, Matt Sicker <boa...@gmail.com> > wrote: > > > > > > > > > > > > > > This sounds like a shade feature, yes. However, in order to > > > > > > > automatically extract the version extra data and detect a > version > > > > > > > keyword like "alpha" may require some additional code, though > maybe > > > > > > > the shade plugin already supports that. > > > > > > > > > > > > > > Alternatively, JUnit 5.x uses a tool called API Guardian for > marking > > > > > > > which APIs are stable or not: > > > > > > > https://github.com/apiguardian-team/apiguardian > > > > > > > > > > > > > > On Tue, 4 Jun 2019 at 05:53, Gilles Sadowski < > gillese...@gmail.com> wrote: > > > > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > > > Does someone see a practical way to automate package names > > > > > > > > and source files conversions so that each all alpha/beta > releases > > > > > > > > can be used together (e.g. to compare their behaviours). > > > > > > > > > > > > > > > > I mean, for release version "1.0-alpha1", the top-level > package > > > > > > > > name "o.a.c.compid" would be turned into > "o.a.c.compid.alpha1". > > > > > > > > > > > > > > > > This would also solve issues with compatibility checkers > (with the > > > > > > > > added bonus that JAR hell could never happen). > > > > > > > > > > > > > > > > Couldn't the "shade" plugin be put to use (so that all > artefacts have > > > > > > > > their top-level package transparently set to > "o.a.c.compid.alpha1" > > > > > > > > and all the tools operate on that)? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Gilles > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
