You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 install and 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 ;-)
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.
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 install
and 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 Strategy of migrating to the Jakarta Namespace? sweble/sweble-wikitext#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
The text was updated successfully, but these errors were encountered: