Repository navigation
Version 2.x Maven Central Identification #3170
Description
The intent of 2.x is to live side-by-side with 1.x. The package name (io.reactivex vs rx) is insufficient though, as the Maven Central artifactId needs to also be different otherwise both can't be imported. So instead of rxjava should it just be rxjava2 like this?
compile 'io.reactivex:rxjava2:2.x.y'
compile 'io.reactivex:rxjava:1.x.y'
Activity
benjchristensen commentedon Aug 21, 2015
@rspieldenner Rob, I can't figure out what I need to change in the Gradle properties to change the name from
rxjavatorxjava2other than changing "project.name" which also changes everything else.If I change
project.nameI end up with this:Is that what it should be? Or can it be this somehow with just 'rxjava' in the filename?
benjchristensen commentedon Aug 21, 2015
Seems that the artifactId is most commonly or always also the prefix for the filename. That suggests something like rxjava2 as above. Changing the complete name would also have the side-benefit of allowing two separate projects with different names in an IDE at the same time: rxjava and rxjava2.
However, I winder about the name rxjava2. If we need to make a 3.x but want to retain the same package names we would be stuck with the artifactId rxjava2 with version 3.x.
Is there a better name to represent this next version of rxjava?
io.reactivex – rxjava2 – rxjava2-2.0.0.jar
io.reactivex – rxjava2 – rxjava2-3.0.0.jar
io.reactivex – rxjava – rxjava-2.0.0.jar (I really wish this could work)
rspieldenner commentedon Aug 21, 2015
Why wouldn't this "io.reactivex – rxjava – rxjava-2.0.0.jar" work?
On Thu, Aug 20, 2015 at 9:33 PM, Ben Christensen notifications@github.com
wrote:
akarnokd commentedon Aug 21, 2015
A separate project makes things much easier; no need to switch back-and-forth between two branches. We could call it
rsjavabut I can see the confusion due to the one letter change. Having justrxjava-2.0.0is also attractive. How about copying the current 1.x to a new project RxJava1 and have the 2.0 start in a cleared out RxJava project?A separate project has also the benefit of not being intermixed with issues and PRs targeting the two versions.
rspieldenner commentedon Aug 21, 2015
I think changing the group and artifact name are some of the worst things
you can do. When you do that the 2 versions would no longer participate in
conflict resolution. So a gradle/maven/sbt etc. resolve could pull in 2
different versions of rxjava if you do anything besides moving to
io.reactivex:rxjava:2.x.x
On Fri, Aug 21, 2015 at 1:27 AM, David Karnok notifications@github.com
wrote:
JakeWharton commentedon Aug 21, 2015
That's the point of the change. They are able to operate next to each other.
On Fri, Aug 21, 2015, 10:04 AM Rob Spieldenner notifications@github.com
wrote:
benjchristensen commentedon Aug 21, 2015
@rspieldenner As @JakeWharton said, that's the point. Otherwise as soon as v2 comes out it will break every application and basically be unusable without herculean efforts to upgrade everything from v1 to v2 - and that could only be possible if and once v2 accounts for every piece of functionality v1 had (not necessary a good thing to force upon v2).
RxJava is not a library that hides well, as it is intended to be exposed in the public APIs, and be used for composing libraries and systems together. Thus, a breaking change would mean coordinating all systems and libraries to all upgrade at the same time.
For example, at Netflix we would need to upgrade Hystrix for the entire company at the same time. Not going to happen. I consider this an even harder upgrade than Guava (which typically take many months of effort to upgrade) since Guava generally is not part of our public APIs, just internal implementation details.
An application could have the following dependencies:
io.reactivex:rxjava:rxjava-1.0.14
io.reactivex:rxjava:rxjava2-2.0.0
They would then use different types like this:
rx.Observable (from rxjava-1)
io.reactivex.Observable (from rxjava-2) (or whatever we call the package and class names)
benjchristensen commentedon Aug 21, 2015
@akarnokd I'm not a fan of splitting the projects. We split the community, lose the collaboration between 1.x and 2.x issues (which will be very common), will end up cross-posting things a lot, and would complicate the branding. The branding includes the Github URL, contributors, forks and stars. Those statistics (as superficial as it sounds) are meaningful. They represent the community around the project. Community, branding and marketing are honestly a massive part of a project like this. The code itself honestly is the easiest part.
jkschneider commentedon Aug 21, 2015
@benjchristensen There is one alternative since you are also changing source package names which is to retain the same Maven coordinate but also provide a shim library that bridges 2.x functionality to the old package names. Effectively, anybody needing both 2.x and 1.x to coexist would just add an additional dependency on the shim. This is a little more in-your-face and encourages upgrades. Think of the SLF4J Log4J shim as a not-entirely-similar case.
benjchristensen commentedon Aug 21, 2015
@jkschneider can you give me an example of how that would work? That sounds intriguing.
benjchristensen commentedon Aug 21, 2015
I think I may understand. Is it as follows?
We could double publish RxJava v1 like this:
Then we publish v2 as:
So if someone gets upgraded to v2 and it breaks their world, and they need both to live together, they would have dependencies like:
So, instead of us changing artifactIds for new versions, we actually add one for the old version?
jkschneider commentedon Aug 21, 2015
@benjchristensen That's right -- the main benefit is a natural bias toward upgrading, especially for first order dependents. Depending on how easy it is to bridge new concepts to old, it may also provide an easy way for you to deliver bugfixes to older uses of the API without working on two distinct core branches of rxjava itself.
Perhaps call it something like
io.reactivex:rxjava-compat:2.x.yand have the compat library's version track the version of rxjava itself. After all, the compat shim and rxjava will be feature coupled.zsxwing commentedon Aug 22, 2015
@jkschneider I think it's possible that someone uses both a library A that depends on io.reactivex:rxjava:1.x.y, and a library B that depends on io.reactivex:rxjava:2.x.y. Then the user needs to fix the dependency tree manually, since maven/gradle only selects one version of
io.reactivex:rxjava.6 remaining items
zsxwing commentedon Aug 28, 2015
@benjchristensen 👍 for your proposal. This is just a tradeoff. Thanks for explaining why you made this choice.
JakeWharton commentedon Dec 12, 2015
As RxJava 2 has yet to be released, I would like to propose
io.reactivex.rxjava2:rxjavaas the Maven coordinates for the 2.0 major version release. The details on both group ID naming and artifact ID naming are encapsulated in my blog post.Multiple comments from this issue are addressed in the post:
Covered in the post.
Covered in the post. Group ID changes is the simple way to break this apart.
and
This solution plays to the always-upgrading nature of consumers and some libraries. While it represents a non-zero effort on consumer's part, the naive remain blissfully unaware and allow natural progression of these APIs to take place.
benjchristensen commentedon Mar 24, 2016
Jake, thanks for the followup on this. I'm good with accepting the artifact name you propose.
akarnokd commentedon Mar 24, 2016
👍 to be able to import them the same time.
akarnokd commentedon Jun 17, 2016
Jake's suggestion for
io.reactivex.rxjava2:rxjavasounds reasonable for me. It also allows upgrading the neighboring libraries and have all of 2.x under the same groupId pattern (io.reactivex.rxjava2:rxjava-math).Unfortunately, I'm not sure where this new group ID could be applied (hidden inside the nebula plugin?).
artem-zinnatullin commentedon Jun 17, 2016
@akarnokd yeah, looks like it's in nebula rxjava plugin, but you can override it inside RxJava's
build.gradle, addgroup = 'io.reactivex.rxjava2'. When I run./gradlew publishToMavenLocalit publishes it to overridden group.artem-zinnatullin commentedon Jun 17, 2016
👍 for Jake's proposal about
groupIdchange toio.reactivex.rxjava2.JakeWharton commentedon Jun 17, 2016
Might be a good time to shed some nebula? RxAndroid got rid of all of them
and never looked back.
On Fri, Jun 17, 2016, 8:56 AM Artem Zinnatullin notifications@github.com
wrote:
akarnokd commentedon Jun 17, 2016
Sounds good, @JakeWharton . Was there something in RxAndroid regarding nebula that had to be replaced (such as travis-maven publish on release builds)?
JakeWharton commentedon Jun 17, 2016
Yes. The challenging part was retaining the part which does the release
builds. @dlew helped set it up, and while it's not pretty it doesn't feel
any less brittle than Nebula already was.
On Fri, Jun 17, 2016 at 11:39 AM David Karnok notifications@github.com
wrote:
akarnokd commentedon Jun 17, 2016
Great. Not sure if we can actually test it before RC1 (release RC0 as is at the time of testing?).
stevegury commentedon Jun 18, 2016
👍 for the groupId change.
@akarnokd I can try to find someone from our tools team to help with the migration out of Nebula.
akarnokd commentedon Jun 18, 2016
@stevegury any help in this regard is appreciated, thanks!
akarnokd commentedon Jun 19, 2016
Changing the group ID while still using Nebula does work for the snapshot release: https://oss.jfrog.org/artifactory/libs-snapshot/io/reactivex/rxjava2/rxjava/
The discussion about removing the plugin continues in #4032.