Please keep original feature IDs intact

Question

Please keep original feature IDs intact

merks opened this issue 2 years ago · 35 comments

merks commented 2 years ago

I'm not sure I understand why the feature IDs have changed.

From this:

To this:

That's what causes this failure:

It would be better to avoid changing the feature IDs.

These direct dependencies are broken by that:

If you start disabling those, you need to disable what's downstream from those, and eventually you'll get this far:

At that point you'll notice you need to disable EMF because it depends on Data Tools which is broken, and then you can pretty much disable 2/3 of the train.

This doesn't sound like a viable approach...

vogella commented 2 years ago

#74

Answer 1 · 2022-06-16T11:36:59.000Z

From this:
To this:

Maybe i get it worn,g but should "gef-classic" not actually be using totally different feature names to not interfere with "non classic" and not change any existing "legacy" stuff?

That would make most sense to me... so consumers of "non classic" won't be affected and "legacy" consumers can migrate?

By the way, this would better been a discussion (maybe @vogella can convert) and if there is a conclusion/action a ticket created from the discussion.

Answer 2 · 2022-06-16T11:39:54.000Z

@vogella just curious: Why does tycho-pomless requires feature id changes at all? the id should be derived from the feature itself so I could understand that the artifactId might change but not the other way round...

Answer 3 · 2022-06-16T11:54:10.000Z

@vogella just curious: Why does tycho-pomless requires feature id changes at all? the id should be derived from the feature itself so I could understand that the artifactId might change but not the other way round...

As far as I know, a feature with the same ID as a plugin (e.g. org.eclipse.draw2d feature and org.eclipse.draw2d plugin) causes a conflict in POM-less Tycho, having two artifacts with the same ID.

Answer 4 · 2022-06-16T12:00:14.000Z

You can define an alternative artifactId in the build.properties

pom.model.artifactId = whateveryoulike

You can find all supported properties here: https://github.com/takari/polyglot-maven/blob/master/polyglot-common/src/main/java/org/sonatype/maven/polyglot/mapping/Mapping.java#L26-L33

Answer 5 · 2022-06-16T12:06:24.000Z

If that's true, adding pom.xml would indeed be less nice for the build, but the changing IDs is really, really, very not nice for the downstream consumers so it will be really, really, extremely hard to feed this result into SimRel.

I somehow doubt the feature and bundle artifact IDs collide because .feature.group and .feature.jar are added automatically, at least in the final p2 metadata...

I do see this in PDE:

But here the bundle with the same ID as the feature has a pom.xml.

I wonder if one can set the group ID the same way?

Answer 6 · 2022-06-16T12:07:43.000Z

You can define an alternative artifactId in the build.properties
pom.model.artifactId = whateveryoulike
You can find all supported properties here: https://github.com/takari/polyglot-maven/blob/master/polyglot-common/src/main/java/org/sonatype/maven/polyglot/mapping/Mapping.java#L26-L33

Yes, I see the group ID can also be set... So maybe the problem is easy to solve...

Answer 7 · 2022-06-16T12:14:40.000Z

I somehow doubt the feature and bundle artifact IDs collide because .feature.group and .feature.jar are added automatically, at least in the final p2 metadata...

As mentioned in the other issue regarding deployment of features, there is not a 1:1 mapping of maven "ids" to P2 "ids" or PDE "ids", sometimes both match or even relate, but there is no real direct dependency. So a feature with feature.xml id myfeature, that is mapped in P2 as myfeature.feature.group and myfeature.feature.jar might have a maven GAV of mycompany:my-feature:1.0

Answer 8 · 2022-06-16T13:00:20.000Z

The ID-collision concern was too pessimistic. I tested these changes locally and the local Tycho build works fine producing the desired results:

Note that I added the draw2d SDK to the category.xml. That being missing was probably an oversight...

Answer 9 · 2022-06-16T13:08:10.000Z

@vogella @howlger

The build was successful. So limiting that one can't add a reviewer:

#71

Answer 10 · 2022-06-17T03:59:53.000Z

By the way, there is even a wiki page: https://github.com/eclipse/tycho/wiki/Tycho-Pomless#overwrite-group-and-artifact-ids please enhance if you feel something missing!

Answer 11 · 2022-06-17T06:30:23.000Z

Fortunately pom-less just does the right thing for features.

@vogella @howlger

It would be really nice to have a build with these changes so I can examine the impact of contributing that build to SimRel...

Answer 12 · 2022-06-17T06:43:15.000Z

Thanks @merks https://download.eclipse.org/tools/gef/classic/latest contains the change, please have a look.

@azoitl and @pcdavid please also have a look.

If fine for everyone and once GMF has been updated back (sorry for this @pcdavid) we can create a new release and contribute that to the Simrel.

Answer 13 · 2022-06-17T06:54:58.000Z

Yeah, the new repository is a drop-in replacement for the old one!

So with just these changes:

the other contributions resolve without further changes:

Thanks to everyone who worked on this!

Answer 14 · 2022-06-17T07:40:12.000Z

@pcdavid I would prefer to get a go from you before contributing the new GEF version. Are you available in the next days to have a look at GMF?

Answer 15 · 2022-06-17T08:18:27.000Z

Probably this week-end, but not today.

If you have reverted the id change, wouldn't the exiting GMF Runtime contribution (1.14.2) be compatible?

Answer 16 · 2022-06-17T08:21:50.000Z

@pcdavid Yes, your current contribution https://download.eclipse.org/modeling/gmp/gmf-runtime/updates/releases/R202204130739 is compatible with this newer version of GEF classic, so GEF can contribute without you taking further action at this point, other than reverting your ID changes before you contribute again.

Answer 17 · 2022-06-17T08:24:54.000Z

Thanks @pcdavid for confirming, I wanted to avoid breaking any pending change from you.

Simrel here we come... (as some as re-did the setup for it, I will update the existing Gerrit).

Answer 18 · 2022-06-17T08:43:48.000Z

Thinking about, I should probably create a new release for this "change back".

Answer 19 · 2022-06-17T08:51:41.000Z

@vogella Yes, please use a stable URI for contribution. And note that if you use a simple repository you don't really need to restrict the version of the feature in the *.aggrcon (so that future changes only need to change the URI)...

Answer 20 · 2022-06-17T09:03:42.000Z

@merks new version available at https://download.eclipse.org/tools/gef/classic/latest Is that still good in your opinion?

Answer 21 · 2022-06-17T09:07:00.000Z

That's the one I tested but you should not contribute URI that changes with each and every build. You should contribute something stable that can never change, otherwise we might suddenly find things broken and yet we cannot see that anything has changed in any contribution.

Answer 22 · 2022-06-17T09:08:47.000Z

@merks Yes, understood but I updated it with the 3.14.0 release, which will also be make available via https://download.eclipse.org/tools/gef/classic/releases/3.14.0 and https://download.eclipse.org/tools/gef/classic/releases/3.14.0 would be contributed to simrel.

As I updated latest I wanted to give you a chance to look again.

Answer 23 · 2022-06-17T09:15:56.000Z

@vogella Very good! I tested https://download.eclipse.org/tools/gef/classic/releases/3.14.0 and that works well.

Are you fixing gmf-runtime or shall I contribute a PR?

Answer 24 · 2022-06-17T09:18:06.000Z

@merks if you could help with GMF that would be great.

Any idea why https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/193185/3/gef.aggrcon is failing? I think I did as you suggested.

Answer 25 · 2022-06-17T09:29:29.000Z

You only removed one of the version ranges. You also did not test is first in an IDE. I haven't tested this setup in a while:

https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup&show=true

This works for me locally:

<?xml version="1.0" encoding="ASCII"?>
<aggregator:Contribution xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:aggregator="http://www.eclipse.org/cbi/p2repo/2011/aggregator/1.1.0" label="GEF">
  <repositories location="https://download.eclipse.org/tools/gef/classic/releases/3.14.0" description="GEF-Legacy releases">
    <features name="org.eclipse.gef.sdk.feature.group">
      <categories href="simrel.aggr#//@customCategories[identifier='Modeling']"/>
    </features>
    <features name="org.eclipse.zest.sdk.feature.group">
      <categories href="simrel.aggr#//@customCategories[identifier='Modeling']"/>
    </features>
  </repositories>

I'll be out for a while now. If you still have problems I'll change it for us later...

Answer 26 · 2022-06-17T10:30:24.000Z

Thanks @merks for change works fine.

Indeed I did not test this, the aggregator seems to use its own technology stack which I'm not familiar with. Is this just "legacy" (also known as we used to do this) or is their a hard reason not to use regular Eclipse technolgies like update sites, target platforms? To be honest with you I don't have to time to learn yet another ancient technogie, sorry for this but as I contribute to Eclipse in my personal time without payment this is not something I will be able commit to. I assume that is true for lots of others, so I suggest to you and @jonahgraham to use standard (Eclipse) technolgies if possible.

Answer 27 · 2022-06-17T10:37:12.000Z

https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/193185 merged. Big thanks to @merks

Answer 28 · 2022-06-17T12:44:49.000Z

I don't think anyone has found the time, nor will find the time to re-implement what the aggregator provides, i.e., the ability to compose a repository, with well-defined content, that guaranties that all requirements of all bundles and features in the repo are satisfied purely by the contents of the repo. So yes, there are hard reasons.

I'm really not sure by what measure "standard technology" is defined, but it it almost feels like there are first-class things at Eclipse and then there are "legacy", "ancient" second-class things. So how about if we just call the aggregator "classic" like you've done with GEF, which, like Eclipse, is far more ancient than p2 or the aggregator. :-)

And thanks again for everyone involved in breathing life into GEF!

Answer 29 · 2022-06-17T13:32:36.000Z

I don't think anyone has found the time, nor will find the time to re-implement what the aggregator provides, i.e., the ability to compose a repository, with well-defined content, that guaranties that all requirements of all bundles and features in the repo are satisfied purely by the contents of the repo. So yes, there are hard reasons.

I don't follow. Everyone (my clients, platform, EMF, etc) is able to provide a with well-defined content, that guaranties that all requirements of all bundles and features in the repo are satisfied purely by the contents of the repo.

We use update site, target platform and Tycho. So what is missing? If something is missing, can you and @jonahgraham please create an issue for PDE or Tycho so that we can solve these?

Answer 30 · 2022-06-17T13:36:35.000Z

AFAIK @mickaelistria already has once made some attempt to replace the (B3?) aggregator. I don't think its about standard/ancient/... but more about wider adoption, so currently it feels like only a small set of people has the knowledge to adjust or analyze the current approach so the Truck Factor is quite bad.

On the other hand as @vogella noted there are many projects and developers familiar with what is called "modern" here.

Answer 31 · 2022-06-17T14:00:38.000Z

I think what used to be missing was the option to have nestled target definitions but @laeubi and @HannesWell fixed that.

Answer 32 · 2022-06-17T14:04:35.000Z

If I keep explaining, will it make a difference? I'm doubtful. For each thing that's missing or is deficient, you'll suggest it can and definitely should be added somewhere else, anywhere else... So the conclusion is already reached before the facts are known...

Answer 33 · 2022-06-17T14:10:17.000Z

@merks I'm not familiar with all that aggregator and what it does (or not does...) so for me its more like brainstorming than coming to any conclusion nor can I suggest anything just give some remarks I heard from recent discussions, but maybe I'm missing something here.

I think the original topic is solved anyways, so maybe, if there is anything to be concluded it might be better to open a dedicated discussion at the corresponding repository to keep it "on track".

Answer 34 · 2022-06-17T16:28:02.000Z

If I keep explaining, will it make a difference?

Yes, we could start working on closing the gaps and everytime we complain about this "deadend tech" you could point to the list of missing features.

I'm doubtful.

Hey, we (including you) are nice people trying to streamline the process and keep everything flowing.

For each thing that's missing or is deficient, you'll suggest it can and definitely should be added somewhere else, anywhere
else... So the conclusion is already reached before the facts are known...

We are asking for the facts, please deliver them. I opened eclipse-platform/.github#24 for getting them.