Hi, I am also in favor of Gradle, Maven always scares me with it's complex xml-format.
I just committed an initial build/test setup in Gradle via subprojects, currently they are defined as "virtual" subprojects under build/... as we would create a few additional build-directories otherwise and I wanted to keep the overall impact minimal for now. I still use one step from the Ant-build, namely "compile-ooxml-xsds", but otherwise everything related to dependencies, compiling and running tests is done in pure Gradle now. Note: you likely need to run something like "LANG=en_US.UTF-8 LANGUAGE= LC_ALL= gradle check" to have locale set to en_US, I could not set this for the unit-tests in the build.gradle. Feel free to revamp this if you have more knowledge of Gradle (which is likely as I only copy/pasted most stuff from elsewhere), I hope this is a start for a refreshed build-system in POI! Thanks... Dominik. On Thu, Sep 22, 2016 at 1:24 PM, Javen O'Neal <one...@apache.org> wrote: > Looks like.we will lose Gump support if we upgrade to Maven2 or Gradle, not > that we have been doing much with the Gump CI build timeout errors. > > https://en.wikipedia.org/wiki/Comparison_of_continuous_ > integration_software > > On Sep 22, 2016 03:23, "Javen O'Neal" <one...@apache.org> wrote: > > > I have added Gradle support in r1761871 [1] with one line of code, > > though requires that Ant be installed on the system. > > > > I would like to leapfrog Maven. While it does offer some dependency > > benefits and enjoys pretty high market share, reading and writing XML > > is something that should be reserved exclusively for computers, and > > that's my biggest gripe with Ant. > > > > Whatever solution we go with, we probably want to maintain 2 solutions > > in parallel for a year or more while we rewrite the build targets in > > build.xml into the new build file(s). > > > > Informally, here's the relative popularity of these build tools over > > the last 5 years. Maven is the de facto standard for Java projects, > > but build tools with DSLs (Gradle: Groovy, SBT: Scala, Bazel: Python) > > are gaining popularity. > > https://www.google.com/trends/explore?cat=5&q=Ant,Ivy,Maven,Gradle,SBT > > which is roughly the same as > > https://www.google.com/trends/explore?cat=5&q=build.xml,pom. > > xml,build.gradle,.sbt > > but is less likely to include queries about insects and plants. > > > > Another heartbeat is to search large open source code repositories to > > see what kinds of build tools are being used. Unfortunately, > > github.com/search is garbage if you want to search for exact file > > names. > > Searching google.com for each build filename, we get: > > build.xml (Ant): 2.33 million > > pom.xml (Maven): 3.3 million > > build.gradle (Gradle): 0.49 million > > .sbt (Scala Build Tool): 0.399 million > > Gradle: 1073 > > > > [1] https://svn.apache.org/viewvc?view=revision&revision=1761871 > > > > On Thu, Mar 10, 2016 at 4:42 AM, Nick Burch <apa...@gagravarr.org> > wrote: > > > On Thu, 10 Mar 2016, Dominik Stadler wrote: > > >> > > >> Here a few initial ideas where we could improve this: > > >> > > >> 1. Add some CI to the Github project so that PRs are automatically > > >> verified > > > > > > > > > I think some other Apache projects already do something like this. > Maybe > > ask > > > on dev@community > > > > > >> 2. Move to Git/Github > > > > > > > > > Moving to Github is not allowed. See dev@community and board@ for > > > discussions and details. Other than an experiment with Whimsy, ASF > source > > > control systems (either SVN or GIT-WIP) must remain the canonical > source > > > > > > Moving to Git is possible, and Tika has just done so. Needs > > documentation, > > > and guideance, again dev@community probably the best place to ask for > > advice > > > on that > > > > > >> 5. Use some donation-scheme for bugfixes so people affected by bugs > can > > >> offer some compensation and developers can make some money for fixing > > >> certain bugs > > > > > > > > > You need to take care here - targetted donations are not allowed, and > > no-one > > > can promise that any fix will be accepted by the project. (Someone > could > > pay > > > you to write a patch that removes Excel support, for example, and while > > you > > > could take their money and write them the patch, the community would > veto > > > applying it to trunk! Extreme example, but gives the idea) > > > > > > I'd suggest you go watch / listen to a previous "The Apache Way" talk > :) > > > > > > Bug bounties can be done, but need a bit of care. general@incubator > has > > some > > > discussions on this, probably more than dev@community, as the > incubator > > has > > > more people learning how to adapt to Apache-like development. Ask, > learn, > > > implement! :) > > > > > > Nick > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > >
