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.
which is roughly the same as
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
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

To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Reply via email to