Hi, first of all, thank you for your comments.
TL;DR: I put it on hold. > 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] > 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. > ... "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 ... if you work on a budget, you need to do what is requested ... ... whereas on an open source project, you can do what is accepted and hopefully makes sense. So even if there are a few hundred bugs opened, I still prefer to do what I'm interested in (my free time ...) So lets get back to the topic ... > 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 @private forks: do we really care about who is forking us? ... I know this a limited attitude, but keeping our API stable is sometimes already a burden ... I don't want to think about the impact what happens when I modify the internals (e.g. refractoring), just because someone anonymous has modifications on a historical revision of our trunk > Don't the existing ant-generated maven poms have all that in? at least they need to be adapted when new external versions are used. > Plus the website, which is where most people seem to look. ... The info on the website would be still valid for quite some time. > I really worry that if we add more, even more beginners won't be able to get > it working and will give up ... Although I like the idea of scratchpad, i.e. to try something new and not always obey the rules of api stability, the code partitioning in the maven modules are a bit confusing - not sure if this makes more sense, but I would prefer something like: - poi-core : poifs, opcpackage - either poi-ss or poi-xssf/poi-hssf - same for sl, wp, visio 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) > ... 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 ... So currently my motivation to progress in this direction is bit hushed. I thought about creating a branch and using externals to link the trunk to see if for a point X in time the results of the ant and maven build are the same ... but there are some reasons given, which I can't really argue without knowing our users reactions ... so I put it on hold for the time being. Andi [1] https://discuss.gradle.org/t/what-open-source-projects-use-gradle-as-the-default-build-tool/7469 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
