Hi Andi, On Ant vs. Maven: could we at least combine the Sonar and normal Maven scripts to at least start removing some of the duplication here?
On the general discussion: I also sometimes feel that I am allowed to work on what sounds interesting and do not need to do one bugfix after the other. And I like that you are taking on such tasks so that we do not have a single changelog-entry "bugfixes" in the release announcement. We should find some balance to have a mature and stable product with up-to-date features. POI is open source, everybody who stumbles across a bug can step in. What we should however do is to make it as easy as possible for others to provide bugfixes. Here a few initial ideas where we could improve this: 1. Add some CI to the Github project so that PRs are automatically verified 2. Move to Git/Github 3. Use Apache Yetus to have a default process for verifying patches, see https://yetus.apache.org/, although it does not seem to support SVN, so 2. would be a prerequisite 4. Alternatively we could automate verification of patches in bugzilla to provide quicker response, although I feel that the entries in bugzilla are not streamlined enough to easily automate verification, Github would provide all of this out-of-the-box! 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 5. ... what else? I would like to do at least 1. fairly soon as it can be done very easily just by adding a .travis.yml file with build-definitions. Dominik. On Thu, Mar 10, 2016 at 12:46 AM, Andreas Beeker <kiwiwi...@apache.org> wrote: > 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: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
