[
https://issues.apache.org/jira/browse/OPENNLP-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503716#comment-13503716
]
Fergal Monaghan commented on OPENNLP-510:
-----------------------------------------
Anuj, I don't know if this workaround helps your situation, but it works in my
case (I don't need coreference resolution yet): I have sinced switched from
using the opennlp-tools Maven dependency directly to using
cleartk-opennlp-tools, which still depends indirectly on opennlp-tools and
therefore jwnl. This means I use cleartk's typesystem (cleartk-type-system) and
not OpenNLP's, which means that it is transparent which e.g. Tokeniser, Parser
etc. I'm using under the hood (i.e. I could switch OpenNLP out for another
library but keep my data and typesystem the same). However, cleartk does not
wrap OpenNLP's coreference resolution (yet), which apparently is all jwnl is
needed for. This is not a problem for me as I do not require coreference
resolution from OpenNLP (yet).
The cleartk guys include this dependency exclusion for the broken jwnl
dependency in the POM file of cleartk-opennlp-tools:
<dependency>
<groupId>org.apache.opennlp</groupId>
<artifactId>opennlp-tools</artifactId>
<version>1.5.2-incubating</version>
<exclusions>
<!-- only needed for coreference, which we don't wrap
yet -->
<exclusion>
<groupId>jwnl</groupId>
<artifactId>jwnl</artifactId>
</exclusion>
</exclusions>
</dependency>
Now *assuming* you also do not need coreference for your application, you have
2 options. You could *either* (a) include this exclusion in your own POM file,
or (b) you could switch from depending directly on opennlp-tools to depending
on cleartk-opennlp-tools and just reuse their exclusion transparently. Pros of
(a) = you can immediately move forward with no changes to your typesystem or
data. Cons of (a) = if jwnl gets fixed and you want to use coreference, you
will have to be aware of this and remove the exclusion manually yourself. Pros
of (b) = you don't have to care when its fixed, cleartk guys will take care of
that, plus you now have an implementation-agnostic typesystem for lots of
analysis applications. Cons of (b) = you have the once-off cost of having to
switch your typesystem, plus re-process your data with it.
> Maven dependency on jwnl is broken
> ----------------------------------
>
> Key: OPENNLP-510
> URL: https://issues.apache.org/jira/browse/OPENNLP-510
> Project: OpenNLP
> Issue Type: Bug
> Components: Build, Packaging and Test
> Affects Versions: tools-1.5.2-incubating, tools-1.5.3
> Reporter: Fergal Monaghan
> Priority: Blocker
> Attachments: pom.xml.patch
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> Dependency in tools pom for jwnl has groupID and version of a no-longer
> available version of jwnl. An individual developer may be able to sidestep
> this with manual fixes to the local Maven repositroy, but this completely
> breaks continuous integration/build servers etc.. The attached patch fixes
> this by simply updating the dependency to the latest groupID and version for
> jwnl.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
