Consider migrating the guides to `jcenter()` about gs-rest-service HOT 9 CLOSED

Despite being a big fan of Bintray I'd like to play devils advocate here. We've already had some discussions internally about the amount of noise in each guide due to configuring the build system (and if that should be hidden or not). We need to think quite carefully before we add more things to that section.

Remember that the guides are designed around some core principals:

• They are about solving a specific problem
• They can be completed from top to bottom
• They assume no deep knowledge of the wider Java ecosystem

The bottom item is especially important since we want the guides to compete with other technologies.

With that in mind, looking at each of the points @jbaruch makes:

1. The restriction on zip files in maven central is not an issue for the guides. We certainly do have projects that publish zip files (e.g. the Spring Boot CLI zip) but these are not consumed by the build scripts that the guides use.
2. The guides are always a few days behind the release process and we always need to get core projects into oss.sonatype.org anyway. If we have guides that only work with jcenter and not with stock maven we are likely to cause confusion.
3. The Bintray features are orthogonal to the use of the jcenter repo. People can still get the benefits Bintray without needing to always download binaries from the service.
4. Speed is a valid issue, however, local caches mean this is probably only an issue once.

And the replies:

1. Although Gradle 1.7 is old, and we wouldn't use it for project builds. If someone does have an older version of Gradle on their path it would be nice if the guides still worked.
2. I think the issue is not so much relying on jcenter() (I've never seen an issue with it), it's more about the additional configuration required.
3. Most of the guides do not need additional repository configuration. I think that a guide on configuring Maven would be a good addition and a natural place to document jcenter.

So to summarize my take:

• If we're happy with requiring Gradle 1.7 I see no reason not to use jcenter()
• I don't think we should require explicit setting for the maven examples
• I think a new guide on configuring Maven could be added to explain things like HTTPS and give some details on the benefits of Bintray.

/cc @olivergierke

from gs-rest-service.

+1 for what @philwebb said.

I agree that switching to jcenter() in the guides adds more noise than benefits. This is particularly true for the Maven folks who don't need to configure Maven Central but would have to configure jcenter.

from gs-rest-service.

To answer some of the questions above:

1. All of the guides are currently at gradle 1.11 (there as some issue with gradle 1.12 when that update was made that I think involved IntelliJ). I don't think requiring gradle 1.7+ is any issue at all. If people want to use an older version,
2. Regarding adding noise, I already have a PR submitted to make it possible hide/show build stuff on http://spring.io/guides (spring-attic/sagan#454). I just need to process the feedback I've received and once merged into sagan, apply a few slight mods to all the guides to make it work.

To educate me, does switching to jcenter basically involve altering the repoositories listings in gradle and maven build files for each guide? If so, I'm not sure that is really that much noise. But if we are talking about another plugin, then I lean towards @rwinch 's point of view. We don't need MORE configuration stuff in the guides. We have already voted against using Spring IO in the guides, because that would require more explanation with little yield in benefit in the area of the guide we DON'T want to grow in size.

from gs-rest-service.

@philwebb, @rwinch I am not sure what noise you are relating to? People who care about build/repositories stuff will benefit from the pros I mentioned, people who don't care just won't notice (maybe faster resolution from non-US locations).

@gregturn thanks for expressing positive feedback.
We only speak about using jcenter() instead of mavenCentral() in the gradle snippets, well, because, spring platform is released on Bintray so it makes sense for it to be consumed from Bintray. Kinda fair, as well.

from gs-rest-service.

@jbaruch In Maven, users would need to include an additional <repository> element. While this is a small amount to include, it would also likely need an explanation. Users might ask...Why not just use Maven Central? These additional details add up to a lot of noise. The problem is that users just want to create an application and move on.

from gs-rest-service.

I am sorry for not being clear enough.
I am mainly talking about Gradle snippets, where it's a pure replacement of mavenCentral() to jcenter(). It's even shorter! We save :-D

Now, for maven it's a whole different story.
First of all, they shouldn't add <repository> element :) That's why. Artifactory even forcibly remove those elements from pom files.

The right way to change repositories in maven is changing user's settings.xml. And thats tons of noise. I really don't suggest doing it only for the sake of changing Maven Central to Bintray, as you all mentioned, the benefits for the "regular" users are not that big to justify it.

But. There are cases, where you instruct users to deal with their settings.xml (I saw an example in spring-boot). In those cases, when user is going to change the repositories anyhow, why not to take advantage and use a better repository?

from gs-rest-service.

Yes, but this is a discussion about guides, so can we stick to that please? There are guides that have unnecessary Maven repository configuration, and I would prefer to chop that out than replace it with something (however perfect) that uses a different repository. For guide reader it is pure noise, nothing more. The same reasoning applies to gradle - the less configuration there the better, no matter what we might be doing elsewhere. I also would hate to use something completely different for gradle and maven, so having them use different repositories and having to explain that is even more noise.

The Getting Started with Gradle/Maven guides obviously can bear the cost of some more configuration and discussion, so can we just put it all there, since as far as I know there are no guides that fail to build because of a repository configuration.

from gs-rest-service.

Dave, as I already mentioned, my bad for adding Maven settings changes to the mix.
Let's stay with gradle snippets.

I'll try to make my point again, looks like I can't express myself clear enough:

1. The amount of configuration remains the same (actually, couple of chars less :D)
2. Maven and Gradle snippets are the same in dependencies declaration (gavc remains the same) but are different already, as of today, in repository declaration (maven does not define repository, gradle does).
3. The only question is - which repository gradle snippet should declare. I listed all the reasons why it should be jcenter(). If your concern is about users asking why, maybe you could put a short explanation why Bintray is a better repo in one central place, e.g. where the "Powered by Bintray" badge is.

from gs-rest-service.

After careful consideration, I think that we will delay moving to jcenter right now.

. Having gradle and maven guides be different requires explanation. I don't want to deal with that.
. This doesn't preclude Spring projects from using bintray/jcenter or showing such steps on their respective project pages.
. In the future, when there is a point where it can easily be flipped with no effort, I would be open to revisiting this discussion.

I think there is little positive on a guide level. I think any real positives would be better evaluated either through http://start.spring.io or at the Spring project pages where download coordinates exist.

from gs-rest-service.