Proposal: Move gradle plugin to isolated Git repo about discuss HOT 10 CLOSED

To be consistent, all SpotBugs plugins should be moved to separated repos and versions. Eclipse, ant, maven, gradle.

I'm not really sure which way is the best one.

For users having one version on all plugins is a bonus, necause it is easy to understand.

For developers it doesn't make sense, because if we want move from Gradle 3.x to 4.x we are most likely doing a breaking change, but should we bump entire SpotBugs version from 4.x to 5.x just because we broke Gradle compatibility? Nope.

I think if the plugins are properly documented, they can easily overcome the problem "which SpotBugs I'm using inside?". Command line tools can just print the core library version. Ecliose plugin can show it in the "about" part.

So I tend to agree with dedicated versions for every plugin subsystem. If this means dedicated repos, and this allows us to simplify something - why not?

from discuss.

I think there is a technical argument to be made for having different Git repositories per SpotBugs integration, if only an indirect one, based on the tools used to build the respective integration:

1. Gradle Plugin: Gradle
2. Maven plugin: Maven
3. Maven archetype: Maven
4. Eclipse plugin: Gradle, but IMHO much better done with Maven+Tycho

That integration 1 shares a Git repo with SpotBugs core might just be because it accidentally shares the same build tool, whereas 2 and 3 historically have gotten separate Git repos, presumably because we didn’t want a mix of build tools in a single repo. So, to me that fact that 1 and 4 are part of spotbugs/spotbugs, whereas 2 and 3 have their own Git repos is just an accident; it would be clearer to have separate repositories.

On another technical argument, it would force us to have a stable API for integrations.

from discuss.

I'd rather bump the plugin version number to the same as spotbugs itself, and keep it here. It makes it much easier for the users. Other software like spring and kotlin does this. I would actually vouch for moving the maven plugin here as well...

from discuss.

For users having one version on all plugins is a bonus, necause it is easy to understand.

I believe ease of use for our users should be our primary focus, always.

from discuss.

It's possible to use the same release version number across the artifacts whether in same or different scm repos; the scm repo structure does not decide this (the key is keeping each in separate directories, whether they share a common parent directory in one scm repo or they each reside in a separate scm repo).

Can also have a convenience "parent build" module that provides defaults and builds each module, and it too can reside in its own scm repo or as another sister (or parent) directory with the others.

In my experience, the main decision factors become release management (primarily versioning and release together or separately) and developer & user convenience on isolation level - e.g. for issue and development commit tracking. For tracking, it is often easiest to have as separate repositories so the separate products do not comingle. While they are all related, they are each individual products.

I also suggest each in their own git repo, primarily for the tracking and secondarily for the respective cohesive product focus. After that, can independently decide on release version number syncing (to do or not).

from discuss.

I prefer using different release version for each module, because:

1. Each module should have own reason to bump up major version, to break backward compatibility.
   • e.g. Stop supporting legacy version of Gradle
2. Each module should have motivation to control timing to release.
   • e.g. Get more feedback for young project such as new spotbugs plugin
3. I believe that using different version for each modules cannot be severe problem for end users.
   • We can consider to release BOM (Bill Of Materials) if necessary.

from discuss.

@iloveeclipse we're going to ship stable release, then I think it's better to decide our policy about this before the release. At least, we need to decide which version we use for gradle plugin: 1.6 or 2.0.0.

from discuss.

Reading through the comments so far the idea of separate repositories is supported by most people. If someone have not commented yet, please speak up now.

Having this, and reading other arguments, I see that it would be logical to use also defferent versions too. So +1 from me on both proposals.

I think we can proceed with bumping gradle plugin to 2.0.0 if we are going to make breaking API changes, same way as we will bump SpotBugs itself to 4.0.0.

Regarding the move of gradle or other plugins to the separated repos - if someone is going to do this, we should first make sure we have API tools on SpotBugs which will break the build if the API will be changed without changing the version accordingly. This will make sure the plugins will still work. There are few of such tools around. Another important point is to have the history preserved in the separated repos.

For Eclipse the precondition for moving to the separated repo is to enable automated tests, which are currently disabled. This means we most likely are going the build to move to tycho (maven), but I have no time and no knowledge for working on this. May be @sewe have some time.

from discuss.

OK then let's make new repo after 3.1.0 release, and use 1.6.0 as the version of spotbugs-gradle-plugin at that time.

from discuss.

Gradle Plugin is moved to https://github.com/spotbugs/spotbugs-gradle-plugin

I will propose a PR to delete gradlePlugin directory from master branch and release-3.1 branch.

from discuss.