Re: Switch to maven?

[Dominik Stadler]

Hi,

I am also in favor of Gradle, Maven always scares me with it's complex
xml-format.

I just committed an initial build/test setup in Gradle via subprojects,
currently they are defined as "virtual" subprojects under build/... as we
would create a few additional build-directories otherwise and I wanted to
keep the overall impact minimal for now. I still use one step from the
Ant-build, namely "compile-ooxml-xsds", but otherwise everything related to
dependencies, compiling and running tests is done in pure Gradle now. Note:
you likely need to run something like "LANG=en_US.UTF-8 LANGUAGE= LC_ALL=
gradle check" to have locale set to en_US, I could not set this for the
unit-tests in the build.gradle.

Feel free to revamp this if you have more knowledge of Gradle (which is
likely as I only copy/pasted most stuff from elsewhere), I hope this is a
start for a refreshed build-system in POI!

Thanks... Dominik.

On Thu, Sep 22, 2016 at 1:24 PM, Javen O'Neal  wrote:

> Looks like.we will lose Gump support if we upgrade to Maven2 or Gradle, not
> that we have been doing much with the Gump CI build timeout errors.
>
> https://en.wikipedia.org/wiki/Comparison_of_continuous_
> integration_software
>
> On Sep 22, 2016 03:23, "Javen O'Neal"  wrote:
>
> > 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.
> > https://www.google.com/trends/explore?cat=5=Ant,Ivy,Maven,Gradle,SBT
> > which is roughly the same as
> > https://www.google.com/trends/explore?cat=5=build.xml,pom.
> > xml,build.gradle,.sbt
> > 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
> > names.
> > 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=1761871
> >
> > On Thu, Mar 10, 2016 at 4:42 AM, Nick Burch 
> 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: 

Re: Switch to maven?

[Javen O'Neal]

Looks like.we will lose Gump support if we upgrade to Maven2 or Gradle, not
that we have been doing much with the Gump CI build timeout errors.

https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

On Sep 22, 2016 03:23, "Javen O'Neal"  wrote:

> 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.
> https://www.google.com/trends/explore?cat=5=Ant,Ivy,Maven,Gradle,SBT
> which is roughly the same as
> https://www.google.com/trends/explore?cat=5=build.xml,pom.
> xml,build.gradle,.sbt
> 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
> names.
> 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=1761871
>
> On Thu, Mar 10, 2016 at 4:42 AM, Nick Burch  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
> >
>

Re: Switch to maven?

[Javen O'Neal]

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.
https://www.google.com/trends/explore?cat=5=Ant,Ivy,Maven,Gradle,SBT
which is roughly the same as
https://www.google.com/trends/explore?cat=5=build.xml,pom.xml,build.gradle,.sbt
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
names.
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=1761871

On Thu, Mar 10, 2016 at 4:42 AM, Nick Burch  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

Re: Switch to maven?

[Nick Burch]

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

Re: Switch to maven?

[Dominik Stadler]

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 
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 

Re: Switch to maven?

[Nick Burch]

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

Re: Switch to maven?

[Andreas Beeker]

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

Re: Switch to maven?

[Dominik Stadler]

Hi,

if I could choose freely, I would use Gradle by now, Maven still confuses
me quite a lot. However also Gradle has quite a learning curve, so it would
force all committers and users to learn quite a lot, so all-in-all I am
also more inclined to keep the current build-system in place. My suggestion
towards ivy was to standardize a bit how we fetch and use 3rd party stuff
to make it similar to Maven and reduce some of the code in the build.xml

And note that the stuff in sonar/ only does the bare minimum to let Sonar
do the analysis, there is quite a bit more in the Ant build: rat-check,
findbugs, correctly packaging the jars, signing, forbidden-api-check,
integration-tests, proper ooxml-lite, generate-geometry, ...

Dominik.

On Wed, Mar 9, 2016 at 1:20 AM, Nick Burch  wrote:

> On Wed, 9 Mar 2016, Andreas Beeker wrote:
>
>> I'd keen to switch our ant build to a modulized maven build. I guess
>> there were already several discussions about this topic, but I couldn't
>> find them on a quick view.
>>
>
> IIRC, the stuff for building the ooxml-lite jars was felt to be one bit
> which'd be a lot of work to change over. There was also the "haven't you
> got enough real bugs to work on, without breaking something that works" ;-)
>
>
> I expect that this change ...
>> - clean-ups the directory structures
>>
>
> We could do that now, if we wanted, but it risks breaking lots of pending
> patches and private forks
>
> - better documents the external dependencies
>>
>
> Don't the existing ant-generated maven poms have all that in? Plus the
> website, which is where most people seem to look. Well, I say most people,
> based on the stackoverflow questions most people don't bother, guess, guess
> wrong, and whine when people point them at the docs / tell them to use
> maven / etc...
>
> For a start I'd move the poi modules 1:1 to poms, but eventually I'd like
>> to have format based poms for Excel, Powerpoint, ...
>>
>
> See above on large parts of our new users already stuffing things up when
> faced with basically just 3 POI jars. I really worry that if we add more,
> even more beginners won't be able to get it working and will give up /
> waste lots of time. We'd also break 10+ years of "stop being a muppet and
> follow this to fix your build by including the jars the docs tell you to"
> worth of advice out there on the internet
>
> (Just check stackoverflow for people confused by tutorials or guides
> mentioning the poi-contrib package, which we removed some time ago, and the
> crazy stuff they end up doing to try to get it back without understanding
> what they're doing, for why I'm reluctant to change things here without
> very strong reasons!)
>
> Nick
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Switch to maven?

[Nick Burch]

On Wed, 9 Mar 2016, Andreas Beeker wrote:
I'd keen to switch our ant build to a modulized maven build. I guess 
there were already several discussions about this topic, but I couldn't 
find them on a quick view.


IIRC, the stuff for building the ooxml-lite jars was felt to be one bit 
which'd be a lot of work to change over. There was also the "haven't you 
got enough real bugs to work on, without breaking something that works" 
;-)




I expect that this change ...
- clean-ups the directory structures


We could do that now, if we wanted, but it risks breaking lots of pending 
patches and private forks



- better documents the external dependencies


Don't the existing ant-generated maven poms have all that in? Plus the 
website, which is where most people seem to look. Well, I say most people, 
based on the stackoverflow questions most people don't bother, guess, 
guess wrong, and whine when people point them at the docs / tell them to 
use maven / etc...


For a start I'd move the poi modules 1:1 to poms, but eventually I'd 
like to have format based poms for Excel, Powerpoint, ...


See above on large parts of our new users already stuffing things up when 
faced with basically just 3 POI jars. I really worry that if we add more, 
even more beginners won't be able to get it working and will give up / 
waste lots of time. We'd also break 10+ years of "stop being a muppet and 
follow this to fix your build by including the jars the docs tell you to" 
worth of advice out there on the internet


(Just check stackoverflow for people confused by tutorials or guides 
mentioning the poi-contrib package, which we removed some time ago, and 
the crazy stuff they end up doing to try to get it back without 
understanding what they're doing, for why I'm reluctant to change things 
here without very strong reasons!)


Nick

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

Switch to maven?

[Andreas Beeker]

Hi,

I'd keen to switch our ant build to a modulized maven build.
I guess there were already several discussions about this topic,
but I couldn't find them on a quick view.

Most of the work has been already done by Dominik in the sonar builds,
so I hope it's not too time consuming to change.

I expect that this change ...
- clean-ups the directory structures
- obsoletes the maintaining of the sonar poms
- better documents the external dependencies
- maybe provide a better tool integration ... (although I can't complain ...)

Last time I've talked with Dominik about that topic, he favored Apache Ivy (... 
if I remember correctly ...)
I have to admit, that I haven't played much with other dependency managers
and maven might be already out of date ... but as our release artifacts are 
still poms,
this switch don't seem to be so far off ...

For a start I'd move the poi modules 1:1 to poms, but eventually I'd like to 
have format based poms
for Excel, Powerpoint, ...

What do you think?
(if possible, link to an old thread)

Andi


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