Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eclipse IDE doesn't recognize shaded dependencies #259

Open
rzo1 opened this issue Oct 31, 2023 · 2 comments
Open

Eclipse IDE doesn't recognize shaded dependencies #259

rzo1 opened this issue Oct 31, 2023 · 2 comments
Milestone

Comments

@rzo1
Copy link
Contributor

rzo1 commented Oct 31, 2023

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

@rzo1 rzo1 added this to the 2.0.0 milestone Oct 31, 2023
@mawiesne
Copy link
Contributor

mawiesne commented Nov 2, 2023

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 ?

@rzo1 rzo1 modified the milestones: 2.0.0, 2.0.1 Nov 15, 2023
@mawiesne
Copy link
Contributor

@rzo1 agreed that the path forward will be option (1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants