Releng for e4.26 #8

[wimjongman]

Move all http to https
Create a new target file

[ruspl-afed]

Wim, I've resolved the conflict in pom.xml. Do you plan to continue here or should I complete this one?

[wimjongman]

Go ahead! Let me know if you need help.

[ruspl-afed]

@wimjongman I advanced to test launch, but it currently fails

[BeckerFrank]

@ruspl-afed, @wimjongman: We actual have the targets in two places.

• org.eclipse.mylyn.commons/org.eclipse.mylyn.commons-target
• org.eclipse.mylyn/org.eclipse.mylyn-target (updated 4 days ago)
  I add the targets for 4.23 - 4.25

So maybe we should look that we can

• keep the target in both parts same (actual on use versions and the other 0.0.0)
• reuse one target in the other

[ruspl-afed]

So maybe we should look that we can

• keep the target in both parts same (actual on use versions and the other 0.0.0)

Well, it will mean having a lot of excessive items and longer fetch each time. Is there any gain in this strategy?

• reuse one target in the othe

Do you have a suggestion how to organize such a "reuse" technically?

@BeckerFrank it depends on the decision are we going to merge git repos or not.

• If yes, we will have one target in a natural way
• if no, I would prefer to have each repo self-sufficient.

[ruspl-afed]

@wimjongman after many hours I've found why it is so tricky to get the test working: the bulk replace "http"->"https".
Please use more specific replace pattern next time 😄

[ruspl-afed]

@BeckerFrank I'm going to merge this one, since it enables CI

Please create an issue to discuss our target platform strategy

[wimjongman]

@wimjongman after many hours I've found why it is so tricky to get the test working: the bulk replace "http"->"https". Please use more specific replace pattern next time 😄

I'm sorry I wasted your time. I did not consider the tests, I just tried to get the build going. I saw that the targets were using http, the features, the update sites, and the license URL, so I figured let's throw a regex at it. 🙏

[wimjongman]

@ruspl-afed, @wimjongman: We actual have the targets in two places.

Yes, I saw that. The mylyn repo is the pom parent of the commons repo. This is a lot of releng to juggle around.

I agree with Alexander that the repos should be self-sufficient. However, it is also the case that some repos have to be built before others.

common itself is in use by other downstream repositories. This requires a cascading build setup: When commons is built, it must trigger its downstream builds.

We can also look at commons (and other upstream repos) as just another third-party dependency. It means that downstream repositories are built with whatever common is currently in the snapshot/nightly repo. When a release is planned, we can make one build that cascades all builds into proper order and then release that result.

[akurtakov]

With my Platform experience having too many repos is an issue - both for releng and for contributors so it's worth first asking which repos deserve to be kept separate before spending time to make them selfsufficient.

[wimjongman]

We are discussing this here: #14

[ruspl-afed]

We can also look at commons (and other upstream repos) as just another third-party dependency.

BTW currently we have circular dependency between org.eclipse.mylyn.monitor.* and org.eclipse.mylyn.context.*, to be resolved later #16 .

With my Platform experience having too many repos is an issue

I fully agree here, one need to think carefully before splitting. However, we with @BeckerFrank identified a potential use case to have at least one Mylyn repo separately - to build/install it for older versions of Java/Eclipse. Please join our discussion #14