Version 2.x Maven Central Identification #3170
Comments
|
@rspieldenner Rob, I can't figure out what I need to change in the Gradle properties to change the name from If I change Is that what it should be? Or can it be this somehow with just 'rxjava' in the filename? |
|
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 – rxjava – rxjava-2.0.0.jar (I really wish this could work) |
|
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
|
|
A separate project makes things much easier; no need to switch back-and-forth between two branches. We could call it A separate project has also the benefit of not being intermixed with issues and PRs targeting the two versions. |
|
I think changing the group and artifact name are some of the worst things On Fri, Aug 21, 2015 at 1:27 AM, David Karnok notifications@github.com
|
|
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
|
@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 They would then use different types like this: rx.Observable (from rxjava-1) |
|
@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. |
|
@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. |
|
@jkschneider can you give me an example of how that would work? That sounds intriguing. |
|
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? |
|
@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 |
|
@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 |
|
@jkschneider @benjchristensen @zsxwing that could indeed be the case for instance if said user depends on the Couchbase SDK (which in turn depends on |
|
@simonbasle @zsxwing while conflict resolution would evict io.reactivex:rxjava:1.x.y, adding the shim would make any dependency that requires rxjava 1.x happy, just not with the exact same binary it had before. |
I see. However, my concern is that the user has to fix it manually (excluding incompatible dependency and adding new dependency). Sometimes, the dependency tree is very complicated and it's hard for the user to figure out how to fix it. E.g., I remember that I spent several hours on understanding the SLF4J Log4J shim things when I encountered the conflicts at the first time :( |
|
@zsxwing That is a legitimate concern and the principle tradeoff. |
|
Talked with @rspieldenner about this today to get some guidance. We can make RxJava v1 double-publish artifacts for us to solve this. The way it would work is: RxJava v2 onlycompile 'io.reactivex:rxjava:2.x.y'RxJava v1 onlycompile 'io.reactivex:rxjava:1.x.y'RxJava v1 and v2 togetherIf someone needs both, v2 would override v1 and transitive dependencies would break. They would then manually opt-in to having 'rxjava_v1' included and they'll end up with both jars. compile 'io.reactivex:rxjava_v1:1.x.y'
compile 'io.reactivex:rxjava:2.x.y'RxJava v2 and v3 togetherEventually (hopefully never or at least many years from now) if we need to do the same for v2/v3 we could add an artifact for v2 (and yet another set of package names for 3.x): compile 'io.reactivex:rxjava_v2:2.x.y'
compile 'io.reactivex:rxjava:3.x.y'The change from v1 to v2 is too significant for a thin shim. Virtually every single class in the entire project is going to be touched in the move from v1 to v2. Thus, we really do want to just provide all v1 byte code untouched with a different artifact so both can live side-by-side. We also intend on v1 living for a long time (at least while Android doesn't support Java 8), though hope that server-side projects will upgrade over a 12-18 month period from v1 to v2 so that most server environments would only need to be importing v2. So, unless there is dispute with what is stated above, it's time to debate the artifactId. I suggest |
|
👍 for this solution (great one) |
|
@benjchristensen 👍 for your proposal. This is just a tradeoff. Thanks for explaining why you made this choice. |
|
As RxJava 2 has yet to be released, I would like to propose 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. |
|
Jake, thanks for the followup on this. I'm good with accepting the artifact name you propose. |
|
👍 to be able to import them the same time. |
|
Jake's suggestion for Unfortunately, I'm not sure where this new group ID could be applied (hidden inside the nebula plugin?). |
|
@akarnokd yeah, looks like it's in nebula rxjava plugin, but you can override it inside RxJava's |
|
👍 for Jake's proposal about |
|
Might be a good time to shed some nebula? RxAndroid got rid of all of them On Fri, Jun 17, 2016, 8:56 AM Artem Zinnatullin notifications@github.com
|
|
Sounds good, @JakeWharton . Was there something in RxAndroid regarding nebula that had to be replaced (such as travis-maven publish on release builds)? |
|
Yes. The challenging part was retaining the part which does the release On Fri, Jun 17, 2016 at 11:39 AM David Karnok notifications@github.com
|
|
Great. Not sure if we can actually test it before RC1 (release RC0 as is at the time of testing?). |
|
👍 for the groupId change. |
|
@stevegury any help in this regard is appreciated, thanks! |
|
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. |
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
rxjavashould it just berxjava2like this?The text was updated successfully, but these errors were encountered: