Build tools about spotbugs HOT 11 CLOSED

Got sick of ant xml blobs. For those interested, I started a gradle branch you can follow here.

Right now, with ~80 lines of config + comments, it is able to:

• resolve bcel / ASM dependencies
• build spotbugs.jar
• build spotbugs-ant.jar

This is equivalent of what ant build does when standing on the findbugs directory. In doing this, it's 3 times faster than ant on my machine. Actually, it's even better than what ant is doing:

• ant is generating empty package-info classes. Gradle is currently discarding them if no annotations are present
• the findbugs_de.properties files currently contains unicode entities which ant leaves as is, Gradle is replacing them with the proper char in a utf-8 file.
• the ant build is including a non-existing -SNAPSHOT.jar entry to the class path in the manifest, which gradle is not.

Currently, it can also

• compile and run unit tests (not findbugsTestCases yet)

This is without changing the inputs directory structure. Actually most of the current config is just dealing with the crappy file structure.

To test it, just stand at the project root and run ./gradlew build or ./gradlew test or ./gradlew assemble. More to come.

from spotbugs.

I would be against multiple modules - they will make the setup much more complicated without real benefit. Entire Cloud thing, BlueJ and the rest of not used stuff can go away. Those who want to contribute to them, can revive them from git.

Three things are for sure most important for me: core, ant and Eclipse support, and of course tests for them. Swing GUI isn't interesting for me BTW.

from spotbugs.

I agree the current build process is a disaster.

I personally prefer ant, to maven or gradle, however, if others want to use another build process, i'm ok with that, so long as those 'others' take responsibility for maintaining the pom, or whatever the gradle thing is, as I dont' want to have to burn brain cells trying to figure out that voodoo.

But before we do that, i think we should decide on what the shape of the project should be.

The codebase currently has many tenacles, a bunch of which, i doubt any of us are interested in.

Things like the BlueJ integration, and the cloud thing, do we want to maintain those? I don't. There's a mess of folders that i dont' even know what they are... NullPointerBenchmark? sandbox? etc etc.

If any of you do want to keep those, i'd still hope we could move them to a separate repository (within spotbugs project sure). Even the GUI, and eclipse plugin, i'd be happy to move to separate repositories.

Anyhow, I think we should decide on all that first.

from spotbugs.

I agree on killing cloud.
Update checks can go too.
Dubious projects such as NullPointerBenchmark and sandbox are good to go without asking, if it's not being part of a published binary it's no use.

BlueJ we can probably drop.

Moving GUI to a separate project I agree on. People using it as a lib / ant task can just get the minimum, those wanting it standalone download the whole thing, though I'm in no rush to get it done, unlike other changes.

As for separate repos, I'm not 100% sure. Doing a multimodule build could also be an option (specially if using Gradle / Maven), and would allow changes / refactors to be atomically committed / merged, although I am not sure on how often such changes are to be expected / if it's good enough for plugins to just import the library as a binary. @iloveeclipse can certainly gives us a better insight.

from spotbugs.

I would start with tests.
This enables you to accept patches without spending a day trying to understand if it can break something.
If we can get tests automatically running, we can continue with the rest.
BTW WDYT about this ticket: findbugsproject/findbugs#48? Please note that meanwhile FB requires Java 8, so the test matrix should be not Java 7+8 but Java 8+9.

For the rest: I don't care which build tool will be used if it will just work. I personally dislike Maven, but if it works - why not. I'm OK with the current state so if someone wants some other build tool, please go ahead and add working support for this.

from spotbugs.

You raise an excellent point.

Tests + CI are great, but CI needs build / test automation, which is related to the current issue.
As for testing, I believe the best approach to test detectors in particular are integration tests, which allow to just drop Java source files / class files to analyze, which is great to reproduce FPs / FNs and keep those scenarios for regressions.

I am particularly fond on the approach taken by @h3xstream on find-sec-bugs test lib which allows to perform integration testing from a JUnit test with a Hamcrest Matcher. I've used it on my own SpotBugs plugin

I'm creating a separate issue for testing and for dead code removal.

from spotbugs.

If I would have time for setup the new project I would first make sure I do not brake anything before starting to change everything. So why not just use current ant build and junit tests, which both work today, and setup connection with travis or whatever is useful. Once we have automated this process we can continue with simplifying contributions. This can be a new build system, a code cleanup and dead code removal, new testing approaches etc.
Please note that I can not spend time on new things, my time is limited to keeping things working.

from spotbugs.

@iloveeclipse don't worry, I at least don't expect full time commitment from anyone. I still greatly value your insights and Eclipse plugin system knowledge.

I'm working on setting up Travis as we speak. I will have to probably kill the current JDK check from ant 'though. See travis-ci/travis-ci#6761

from spotbugs.

mind if i switch to using the ant < get.. > task to get those jars? I'm still having troubles (now with the print method) jsotuyod's fix did work, tho.

from spotbugs.

@mebigfatguy sure, I'm not particularly fond of how it is now. As long as you keep the build working I'm good, and for sure you have a greater ant knowledge than I do.

from spotbugs.

As for separate repos, I'm not 100% sure. Doing a multimodule build could also be an option ...

I would be against multiple modules - they will make the setup much more complicated without real benefit. Entire Cloud thing, BlueJ and the rest of not used stuff can go away. Those who want to contribute to them, can revive them from git.

Strong +1 on these.

I'm particularly fond on Gradle

Gradle is a good ant replacement, and has a huge community. We should drop the ant & maven builds as soon as the crap is gone from the code base.

from spotbugs.