Hi Dale,
I just checked out everything and managed to get things imported in IntelliJ
after a little struggle … this is a good job you did :-)
Right now, it seems as if there were Ant+Gradle+Eclipse build files in there.
While it might seem convenient to be able to build with the build system of
choice, the Flex project currently has big trouble with this as it’s a
nightmare to keep all the different builds in sync. So, if someone is reporting
problems we now usually ask “what build system are you using?” before asking
any other questions or being able to help. So, I would suggest deciding which
one it’s going to be and to stick to that.
From a first glance at the build, it does seem structurally quite simple. But
probably there will be the one or other “rock” with a little “monster”
underneath, if you look closer (there always is …)
The things you mentioned, that you seem to be missing with Gradle (even if I
can’t quite understand why):
- Javadoc
- release bundles
- manifests
etc. are handled quite nicely by default Maven setups.
JavaDoc is generated automatically when running a release build together with
the usual Maven project reports (is even configured in the apache parent POM
together with rat, deployment etc.)
I didn’t quite understand the “Manifest” thing, but the jar plugin does
generate this with reasonable defaults, and can be extended to also export the
dependencies into that (even if I don’t recommend that).
Finally, the assembly-plugin is perfect for generating the binary (and source)
release packages.
In the Flex project, I also setup the build to run SonarQube analysis and
automatically generate the documentation from markdown and/or asciidoctor
(which I think is very convenient) even automatically update and deploy the
project website.
And as I said before, with Gradle you will be able to create an equally good
build … but you will have to do a lot of the configuration manually and it does
always offer the cheap way out. Unfortunately, every now and then someone will
try and use this cheap way out, may the reason be just not knowing better or
needing to get “this little feature out the door before the next release”.
It took me about every free minute for about 2 years to untangle and refactor
the FlexJS Ant build converting it to a clean Maven build. If we had started
working cleanly from the beginning, this wouldn’t have been a problem. Now the
build times went down from 8 hours to 20 minutes, we have Jenkins automatically
build and test all feature branches using the multi-branch pipeline plugin. I’m
really satisfied with the results … well except the fact that I must re-sync
the Ant and Maven build all the time ;-)
I could offer to create a fork on GitHub, create a feature branch there and try
to whip up a set of poms that add Maven as fourth build system to the list …
you could check it out and play around with it. But I’d only do this, if there
is any interest in it.
Chris
Am 24.05.17, 17:08 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
On May 24, 2017, at 9:38 AM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:
...
Regarding the build system … what is the projects general opinion on a
Maven build? I know that Ant and Gradle are a lot more flexible as Maven, but I
think it is a good thing that Maven is this strict, as it forces the developers
to address structural issues instead of using workarounds. Especially in
Open-Source projects with a lot of different levels of build system expertise I
usually always had problems with non Maven builds. But this is just a general
question without having seen the current state
----------------
I think we headed down the gradle path because someone stepped up and
contributed an initial set of gradle build files. And it was simple. But
it omitted
building javadoc, release bundles, the jar manifest class-path that I’ve
mentioned, and maybe some additional stuff (oh, like building java7 based
jars using retrolambda, as well as building for an android tgt).
I don’t know that the project has an overall position on gradle vs maven.
Folks?
I don’t have a strong opinion (though I was happy to see the elimination of
an
xml based build spec :-)
Once “forced to address structural issues instead of using gradle
workarounds",
might one then end up with an equivalently simple/clean gradle based system?
Though the path to get to that point may be less clear :-)
— Dale
