Release JWPL 1.2.0

[reckart]

• Resolve all open issues for 1.2.0 (https://github.com/dkpro/dkpro-jwpl/milestone/2)
• Check dependencies
• Run release
• Update website

[reckart]

@zesch @daxenberger @tgalery With #155 being merged now, it might be a good time to do a new release?

[tgalery]

Might be good to go through the issues and see what should be closed as well.

[reckart]

Any volunteers?

[daxenberger]

Any volunteers?

I can do, but not before mid June. I might also make sense to resolve #2 before a release...

[mawiesne]

@daxenberger We (@rzo1 and me) agree that resolving #2 is essential to move the project forward. Several issues (#160, #161) are symptoms for the lack of testability for external developers not directly working with CI servers in Darmstadt.

In an effort to keep the library alive and future-safe, we prose to conduct the following measures:

• solve Use embedded DB for test cases #2 by moving the test code to make use of embedded HSQL databases
• solve PageTest - setupWikipedia() fails but Maven Build still succeeds #161 by changing several test setup issues
• investigate/fix Page.getPlainText broken - PlainTextConverter struggles to discriminate candidate methods and ends in 'VisitorException' #160 with the support of @tgalery
• improve codebase by resolving Extract classes in package 'de.tudarmstadt.ukp.wikipedia.parser.tutorial' into a separate Maven module #163
• provide enhancement associated with [DataMachine] Automatically delete *.bin files after dump creation process #24
• migrate PerformanceTest things to real ITs Migrate 'PerformanceTest' to be a real integration test #180

What do you think? cc: @reckart

[reckart]

@mawiesne I'm in favor of anything that is good for the project. I can help with anything that requires special permissions such as things related to the UKP CI, GitHub project configuration, etc. I can also help with handling CLAs. Unfortunately, I cannot help with implementations.

@mawiesne and @tgalery - I could whitelist you in the UKP CI such that PRs from you are automatically built and such that you could trigger builds on PRs from other people via a comment on the PR. In that way, you could run tests against the UKP database server as long as #2 has not been resolved.

[rzo1]

@reckart My colleague @mawiesne is preparing a PR for #2 atm, which will arrive shortly to remove the burden of MySQL driven test-cases. In the long run, we will try to add Maven profiles as well so we can build the project against MySQL databases in an integration test setup.

[mawiesne]

@reckart Being whitelisted for UKP's CI would be n1. I'd support that. +1

[mawiesne]

@reckart In your first comment on this milestone you mentioned "Check dependencies". Does that include bringing frameworks such as Spring to more recent versions (i.e., 5.0+)? If so: I'd open an issue for this topic under this milestone and process it during the next 1 or 2 weeks.

[reckart]

@mawiesne that depends. E.g Spring should be updated rather conservatively, i.e. only when necessary. Same for Hibernate I guess. Upgrades to such libraries can negatively affect people that integrate JWPL into applications - but I guess you know that better :)

Other libraries (e.g. Apache Commons) should be quite safe to upgrade.

However, what I mainly meant is to ensure that:

• there are no dependencies that are not needed
• there are dependencies on the JARs of all classes that are directly referred (avoid relying on transitive dependencies)
• the scope of the dependencies is correct (mainly test vs. compile)

On the projects that I maintain, I have the Maven Dependency Plugin running at least during the CI builds and in some also in all Maven builds. This checks specifically the first and the second point. The third point is not so easy to check automatically any may be better checked "by eye".

[reckart]

@mawiesne I plan to whitelist you later today when our infrastructure is back from maintenance. If for some reason, I should forget it, please prod me :)

[reckart]

@mawiesne You should be whitelisted now - meaning your PRs should be built automatically when you create one and you should also be able to say "Jenkins, can you test this please." on PRs created by others.

[daxenberger]

@daxenberger We (@rzo1 and me) agree that resolving #2 is essential to move the project forward. Several issues (#160, #161) are symptoms for the lack of testability for external developers not directly working with CI servers in Darmstadt. In an effort to keep the library alive and future-safe, we prose to conduct the following measures: (...)

Sounds reasonable. No objections from my side; I'll help where necessary.
Thanks for the initiative.