On Thu, 10 Mar 2016, Andreas Beeker wrote:
However also Gradle has quite a learning curve, ...
I've checked their quick start for the first time ... probably I'm
unaware of Gradle as I'm not an android developer, and only a maven user
of spring(/hibernate)/... - at least it seems to grow fast [1]
I've had a play with it, and mostly like it. As with Maven, there's rather
a lot of black magic where defaults apply and "stuff happens", but when
you do want to override things I've found it mostly easier to customise
than Maven, but not as easy as Ant. I'd probably rather switch to Gradle
than Maven, if we had to!
there is quite a bit more in the Ant build ...
yes ... nothing I'd fear about moving ;) ... my motivation for the
switch is the things I forget, when something is changed ... e.g. for a
new library dependency (1) the download in the ant build, (2) the lib
file location, (3) the sonar pom, (4) the maven pom, (5) the eclipse
project needs to be changed. With a build based on maven, only the
corresponding maven pom needs to be changed and the IDEs usually update
their config automatically.
I could probably knock up a quick ant check to warn when dependency
changes aren't matched in those other files, but that's tackling a
symptom!
... "haven't you got enough real bugs to work on, without breaking
something that works"
Off-topic: hmm ... I know that saying from my $dayjob ...
It was meant mostly as a joke :)
clean-ups the directory structures ... risks breaking lots of pending
patches and private forks
@pending patches: I wouldn't change the package structure, so patching
with ignored root folders should be still possible
Package struture would remain, but directory structure would change,
which'd break things. A patch that used to apply to src/scratchpad/src
would now need to apply to scratchpad/src/main/java so would break
@private forks: do we really care about who is forking us? ...
We care about them tracking trunk, and we care about them being able to
give stuff back. If we break their private forks, many will simply freeze
their fork and stop tracking trunk. That means they and their users will
miss out on fixes, and the chances of them contributing new things and
patches drops off.
Apache POI ends up in huge numbers of frameworks and other systems, a
great many of which patch even if only slightly. Many of those lag new
versions, which causes issues for people who want to use POI for other
stuff as well in those versions. (Search for POI + ColdFusion or POI +
Jasper for two examples that immediately come to mind, where I've seen
people struggling). Anything we do to make upgrading a private minor fork
will dramatically lower the chance of that fork upgrading.
(Where that fork might just be half a dozen patches that someone manually
applies to a source download before building and packaging, or might be a
more formal thing closer to a true fork)
but I would prefer something like:
- poi-core : poifs, opcpackage
That means core needs XML stuff. Our XML stuff doesn't play that nicely
with Android, so I believe (from stackoverflow posts) that many android
devs just use poi + poi-scratchpad and avoid the OOXML formats. This plan
would mean, unless we took on board the Android stuff and produced builds
with the workarounds as standard, that many Android projects (amongst
others) would stop upgrading
the (xml-)modules would contain the format specific lite-versions of the
schemas or even the full JAXB schemas. *) So a user needs to reference
only poi-ss (poi-core would be a transitive maven dependency)
*) (sorry again, as I stressed this several times and haven't brought up
a POC with JAXB up till now)
Maybe a move to JAXB is a chance to do this, as we'd be making dramatic
changes then to dependencies and schemas anyway?
... and whine when people point them at the docs / tell them to use
maven / etc...
hmm ... I only know it the other way around, i.e. they whine first and
when pointed to the FAQ (#faq-N10025) it's usually solved ...
I assume that a great many people don't get to the whining stage, they
just give up / bodge something horrible, and that's a set of potential new
developers we've missed out on :/
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
