Does anyone encounter an import issue with org.eclipse.jdt.annotation_v1 module ?

[gayanper]

Hi All,

I have been using vscode java for a while for jdt.core development. Recently when I reload the jdt.core project in vscode, i encounter a issue with org.eclipse.jdt.annotation_v1 module. The issue was vscodejava goes into resolution mode of adding groupid to make project names unique which result in a container path resolution error in the org.eclipse.jdt.annotation module.

In Eclipse when i imported this module was skipped from importing which I assume since it sees the module already imported. correct me if i'm wrong @mickaelistria

So my question is should we keep both of these modules with the same name ? and if so why we need to do that ?

[iloveeclipse]

With "module" you mean Java one, or something internally used by VS Code?

Both projects are needed because annotations have different semantics. How that is supposed to be managed by VS Code is beyond my knowledge. Probably you want open a ticket for VS Code?

[gayanper]

By module i mean maven module. Now this doesn't get imported as a project in eclipse either, because if we import both, its gonna be conflicting since same modules has the same artifact id. And if we make them unique by using groupId-artifactId-version, then the annotation module will fail to resolve a classpath container since it is made using relative project path.

[stephan-herrmann]

As @iloveeclipse mentioned, yes, versions are semantically incompatible. That's why a 2.x exists.

Ten years ago it was important to still ship both versions of the bundle, because we couldn't expect all users to migrate to TYPE_USE annotations instantaneously. Also we figured, we could do this, because OSGi has no issues if both versions are installed (this is generally speaking, I admit this created various releng issues in the past, which we didn't foresee).

Obviously, matters look differently in maven.

And perhaps, after those 10 years it's also permissible, to stop maintaining and shipping the 1.x version. The artifact exists in various repos so people would still be able to use it in many (though not all) scenarios. I don't plan any modifications in the 1.x version any more.

Hence, if anyone wants to remove the v1 bundle from features and thus from the content to be shipped, I wouldn't mind. Before doing so, it should be checked if any member of simrel has references to the v1 bundle. If any, perhaps they could be nudged into migrating to 2.x :)