poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Burch <apa...@gagravarr.org>
Subject Re: Switch to maven?
Date Thu, 10 Mar 2016 12:01:04 GMT
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-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


Mime
View raw message