mawiesne
commented
10 months ago Personally, I could live with (1). Reading the docs/readme can be expected from dev people. Short term effect: we get out a long-time awaited JWPL release soon(er). +1 @(1)
I see transparency issues with (2), wouldn't consider it further.
Optimal (mid/longterm) way, of course, would be option (4). This might be a target for JWPL 2.1.x, completing the work of jakarta namespace migration. +1 @(4).
As an intermediate goal, I'd choose option (1) for now (=2.0.0), with setting either (4) or alternatively (3) as target for 2.1.x.
Thoughts @reckart ?
Describe the refactoring action
It seems, that Eclipse IDE does not recognize the attached and shaded artifact in https://github.com/dkpro/dkpro-jwpl/tree/master/dkpro-jwpl-deps during an initial import leading to compile issues.
Note: It works fine in IntelliJ or via a plain Maven build.
I see the following options for discussion:
(1) Document the behaviour and the workaround (
mvn clean installand let it in the workspace) for Eclipse users. Drawback: It is still broken during a first import and contributors / devs have to read the documentation(2) We do 2.0.0 and drop the shade afterwards referencing the 2.0.0-shade only. Drawback: It is unclear for end users were the actual source code is and how the shade artifact was created.
(3) We move https://github.com/dkpro/dkpro-jwpl/tree/master/dkpro-jwpl-deps to its own GitHub repository with a different lifecycle than dkpro-jwpl and release that before we do 2.0.0 - we drop the shade in jwpl and use the released artifact from the other repository. Drawback: We have an additiona repository ;-)
(4) We replace the shade with an official Jakarta ready artifact. I have openend https://github.com/sweble/sweble-wikitext/issues/90 for that.
I am in favour of (3) with a long term perspective on (4). WDYT, @reckart @mawiesne ?
Expected benefit
Eclipse users can directly work with JWPL source without doing workarounds