New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build tools #4
Comments
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. |
I agree on killing cloud. 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. |
I would start with tests. 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. |
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. |
You raise an excellent point. Tests + CI are great, but CI needs build / test automation, which is related to the current issue. 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. |
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. |
@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 |
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. |
@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. |
Strong +1 on these.
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. |
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:
This is equivalent of what
Currently, it can also
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 |
Right now we have a large and complex Ant build, and a smaller but incomplete Maven build.
Keeping the two requires effort and time with dubious benefits if we are not using both ourselves, and given it's status I believe none of us actually use Maven right now.
Ant needs too much configuration, and if you want up-to-date checking, you have to build it yourself, task by task. This alone makes me want to run away from it. I understand Maven has it's issues too, and specially for those that got to use it before Maven 3, raises mistrust on how reliable builds are (I've been there too, throwing the towel and just performing a
mvn clean
).I'm particularly fond on Gradle after using it and contributing to it for the last couple years. It's not XML, it's flexible (the DSL is powerful, but you can write Groovy code if you feel like it), creating custom plugins and tasks is easy (I've done it several times), and has amazing support for up-to-date and incremental builds. Gradle even can use directly ant tasks thanks to Groovy's support.
Also, FindBugs is officially supported by Gradle (no external plugins). They are cool guys :P
I'm eager to know your point of view.
The text was updated successfully, but these errors were encountered: