Prepare new release 1.8.x

[betoboullosa]

Prepare new release 1.8.x according to guidelines. Also update the release-guide to github (it still has outdated references to the old Google Code website).

Fix issues

• [x] open issue for DKPro Core 1.8.0

Drop modules that are not release-ready

• [x] io.annis targets an ancient version of ANNIS and should be updated before being released again
• [x] io.fangorn depends on libraries not available on Maven Central
• [x] io.graf depends on libraries not available on Maven Central - also round-trip does not work
• [x] flextag depends on DKPro TC and even a SNAPSHOT version - danger of circular dependency Core <-> TC and doesn't compile out of the box
• [x] lbj depends on libraries not available on Maven Central
• [x] auebtools actually I think this is already gone, but we still have some references to it in poms
• [x] cogroo probably still has some problems (check for open issues), can maybe be included partially
• [x] StanfordSentimentAnalyzer and remove the dependency on the Stanford models JAR
• [x] EXPERIMENTAL check if the modules marked as experimental should stay or be dropped, own opinion + opinion of respective contributors

Other cleaning up

• [x] remove any repository declarations in POMs except the one that points to the model repository
• [x] check dependencies status (how is described in the release guide)

Other tasks

• [x] create new model overview for 1.9.0 by copying the 1.8.0 one Google Docs model overview is replaced with auto-generated asciidoc

Release process

• [x] Fix dependencies
• [x] Mvn clean install
• [x] Mvn release:prepare
• [x] Mvn release:perform
• [x] Close staging repository
• [x] Send email to developers list
• [x] Release staging repository
• [x] JavaDocs
• [x] Publish release in GitHub
• [x] Reference guide
• [ ] Announcement

[Horsmann]

Do you already decided on a day for the next release? I would want to have the RfTagger in the next release but I still need a bit time.

[betoboullosa]

Hi, Tobias, we don't have a specific date for the release, it depends on how fast we can have it stable. I'd say that towards mid-January could be a reasonable expected release date.

On 04.12.2015 15:26, Tobias Horsmann wrote:

Do you already decided on a day for the next release? I would want to have the RfTagger in the next release but I still need a bit time.

— Reply to this email directly or view it on GitHub https://github.com/dkpro/dkpro-core/issues/702#issuecomment-161979761.

---

Beto Boullosa, M. Sc. Senior Research Software Engineer Ubiquitous Knowledge Processing (UKP) Lab FB 20 / Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone +496151 16-7477, fax -5455, room S2/02/B117 boullosa@ukp.informatik.tu-darmstadt.de

www.ukp.tu-darmstadt.de

[betoboullosa]

After analyzing the used undeclared dependencies, these are the dependencies that are requesting a version when they are added to the pom:

• org.hamcrest:hamcrest-core:jar:1.3:test
  • dkpro-core-api-resources-asl
  • dkpro-core-api-segmentation-asl
  • dkpro-core-decompounding-asl
• org.codehaus.plexus:plexus-utils:jar:2.0.6
  • de.tudarmstadt.ukp.dkpro.core.io.brat-asl
• org.apache.ivy:ivy:jar:2.3.0
  • de.tudarmstadt.ukp.dkpro.core.decompounding-asl
• com.google.code:cjftransform:jar:1.0.1
  • de.tudarmstadt.ukp.dkpro.core.languagetool-asl
• commons-logging:commons-logging:jar:1.1.1
  • de.tudarmstadt.ukp.dkpro.core.mallet-asl
  • de.tudarmstadt.ukp.dkpro.core.io.web1t-asl
• org.slf4j:slf4j-api:jar:1.7.12
  • de.tudarmstadt.ukp.dkpro.core.mallet-asl

[reckart]

I don't think that any of the following are actually referenced directly in our code:

- org.hamcrest:hamcrest-core:jar:1.3:test
 -  dkpro-core-api-resources-asl
 - dkpro-core-api-segmentation-asl
 - dkpro-core-decompounding-asl
- org.codehaus.plexus:plexus-utils:jar:2.0.6
 - de.tudarmstadt.ukp.dkpro.core.io.brat-asl
- org.apache.ivy:ivy:jar:2.3.0
 - de.tudarmstadt.ukp.dkpro.core.decompounding-asl

• If we actually use hamcrest, a version should be added to the dependency management in the top-level pom.
• plexus-utils in the brat module and ivy in the compound modules look like mistakes. Probably a class was available in apache commons and in plexus and was imported from the wrong place

This version should be added.

-com.google.code:cjftransform:jar:1.0.1
 - de.tudarmstadt.ukp.dkpro.core.languagetool-asl

We should only depend on commons-logging-api, not commons-logging. The Maven dependency analyzer module may be confused about this. I think this can be ignored / we can tell the dependency plugin to ignore this.

- commons-logging:commons-logging:jar:1.1.1
  - de.tudarmstadt.ukp.dkpro.core.mallet-asl

We should not have compile dependencies on SLF4F - could be a test dependency and then requires a version:

- org.slf4j:slf4j-api:jar:1.7.12
  - de.tudarmstadt.ukp.dkpro.core.mallet-asl

[betoboullosa]

• Hamcrest is actually used in the three cited modules, like here
  • Hamcrest version added to the top level pom
• com.google.code version added to the top pom
• commons-logging: I solved this by putting uimafit-core dependency before cc.mallet:mallet dependency in mallet's pom. Doing this, commons-logging 1.1.3 inherited from uimafit will be compiled instead of commons-logging 1.1.1 inherited from mallet.
• plexus-util is used here
  • Should I add it to the top pom?
• org.apache.ivy is used here
  • Should I add it to the top pom?
• slf4j is used here and here
  • Should I add it to the top pom?

[reckart]

• plexus-utils: should be using StringUtils from apache commons-lang
• slf4j: should be using logging classes from commons-logging-api instead
• ivy: ouch... we shouldn't be using classes from ivy here - but switching may be a bit too much effort. Please open issue to switch e.g. to cli4j. ivy is also used in the api-resources module. Please add managed dependency to top pom and make sure that version is not overwritten in modules

[betoboullosa]

Update: in order to fix the commons-logging used undeclared message, I had to move commons-logging:commons-logging-api dependency to the top.

[betoboullosa]

Created issue #867 for switching ivy to cli4j later.

[betoboullosa]

@reckart and the others, please take a look at the release notes of the new release and see if you want to do any changes or additions: https://github.com/dkpro/dkpro-core/releases/tag/de.tudarmstadt.ukp.dkpro.core-1.8.0

[reckart]

I'd prefer going over that on the weekend/some time next week. Please proceed with uploading API docs and asciidoc to gh-pages. We can send out the release announcement later.

[reckart]

I updated the release notes a bit: https://github.com/dkpro/dkpro-core/releases/tag/de.tudarmstadt.ukp.dkpro.core-1.8.0

[carschno]

I've been wondering about the status of the release note. And whether it makes sense to explicitly add the LDA estimation component (Mallet module).

Am 27.06.2016 um 10:31 schrieb Richard Eckart de Castilho:

I updated the release notes a bit: https://github.com/dkpro/dkpro-core/releases/tag/de.tudarmstadt.ukp.dkpro.core-1.8.0

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dkpro/dkpro-core/issues/702#issuecomment-228684235, or mute the thread https://github.com/notifications/unsubscribe/AEeopAMXLf7esKNuaKTpPgf-ezY12qWQks5qP4pkgaJpZM4GuuLd.

Carsten Schnober Doctoral Researcher Ubiquitous Knowledge Processing (UKP) Lab FB 20 / Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone +496151 16-25297, fax -5455, room S2/02/B111 schnober@ukp.informatik.tu-darmstadt.de www.ukp.tu-darmstadt.de

Web Research at TU Darmstadt (WeRC): www.werc.tu-darmstadt.de GRK 1994: Adaptive Preparation of Information from Heterogeneous Sources (AIPHES): www.aiphes.tu-darmstadt.de PhD program: Knowledge Discovery in Scientific Literature (KDSL) www.kdsl.tu-darmstadt.de

[reckart]

@carschno I guess we compiled the notes by skimming over the issues and extracting what seems significant. Please add anything you would consider significant :)