Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

Sure that's true, but will the "old crap" using maven-depdency target? I 
don't think so.


And the topic is "Eclipse Platform to prefer use of dependencies from 
Maven Central" so is it relevant that *older* platform releases don't 
support it?


In general for old code I use the old tools, that's why we do releases 
and Tycho is available at maven central back to version 0.12.0 so there 
should be a suitable tool for every ancient use-case.


Am 06.04.22 um 08:28 schrieb Ed Merks:

Christoph,

Comments below.

On 06.04.2022 06:55, Christoph Läubrich wrote:

> Might this approach be a problem for projects with very
> low Java target level?

Is this relevant given that platform already requires Java 11?


This is similar to asking if JDT's compiler stopped supporting Java 11 
is relevant?   Yes, because not everyone is building with the latest 
platform.  I have builds like this:


   https://ci.eclipse.org/emf/job/all-target-platforms/

This thing tests really old crap and uses Tycho do the builds and run 
the tests.


To generalize, of course it's relevant that a build system is able to 
respect the compiler levels and BREEs of the projects being compiled. 
The current Platform is not the center of the universe.




> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.

New features require new version correct, but it should not be an 
issue see above, anyways I'm currently working in fixing a bug [1] for 
compiling java 8 with and tycho has a integration-test for compiling 
with an java 8 jdk so if 'old Java EE levels' not means JSE1.4 or 
something...


> Also everyone using the Target Platform Definition language *.tpd
> might be out, since that tooling cannot generate the new syntax
> I believe.

There is an open issue  [2]for that but it has not gotten much 
attention yet.


> but if you have ever managed targets with 1500 plugins you really
> don't want to go back from such a component based approach, towards
> a single file

From 2022-03 on PDE supports references of other target files [3], so 
you could either use this directly, or have one "main" target with 
maven deps, that includes another that is generated by the TPD files.



[1] https://github.com/eclipse/tycho/issues/51
[2] https://github.com/eclipse-cbi/targetplatform-dsl/issues/115
[3] https://www.eclipse.org/eclipse/news/4.23/pde.php#pde-editor-include


Am 05.04.22 um 20:46 schrieb Michael Keppler:

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Ed Merks]

Christoph,

Comments below.

On 06.04.2022 06:55, Christoph Läubrich wrote:

> Might this approach be a problem for projects with very
> low Java target level?

Is this relevant given that platform already requires Java 11?


This is similar to asking if JDT's compiler stopped supporting Java 11 
is relevant?   Yes, because not everyone is building with the latest 
platform.  I have builds like this:


  https://ci.eclipse.org/emf/job/all-target-platforms/

This thing tests really old crap and uses Tycho do the builds and run 
the tests.


To generalize, of course it's relevant that a build system is able to 
respect the compiler levels and BREEs of the projects being compiled.  
The current Platform is not the center of the universe.




> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.

New features require new version correct, but it should not be an 
issue see above, anyways I'm currently working in fixing a bug [1] for 
compiling java 8 with and tycho has a integration-test for compiling 
with an java 8 jdk so if 'old Java EE levels' not means JSE1.4 or 
something...


> Also everyone using the Target Platform Definition language *.tpd
> might be out, since that tooling cannot generate the new syntax
> I believe.

There is an open issue  [2]for that but it has not gotten much 
attention yet.


> but if you have ever managed targets with 1500 plugins you really
> don't want to go back from such a component based approach, towards
> a single file

From 2022-03 on PDE supports references of other target files [3], so 
you could either use this directly, or have one "main" target with 
maven deps, that includes another that is generated by the TPD files.



[1] https://github.com/eclipse/tycho/issues/51
[2] https://github.com/eclipse-cbi/targetplatform-dsl/issues/115
[3] https://www.eclipse.org/eclipse/news/4.23/pde.php#pde-editor-include


Am 05.04.22 um 20:46 schrieb Michael Keppler:

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Ed Merks]

Dirk,

Indeed, it does not yet though it looks like someone might sponsor the 
development of such support...


Regards,
Ed

It would certainly seem convenient to have a

On 05.04.2022 21:43, Dirk Fauth via cross-project-issues-dev wrote:
Well, with the Generic Editor available I recently dropped all tpd 
files. Now I edit the target files via Generic Editor and also have 
code completion. That is now similar comfortable.


But I think Oomph does not yet support the new Maven location.

Michael Keppler  schrieb am Di., 5. Apr. 2022, 
20:46:


Might this approach be a problem for projects with very low Java
target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd
might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have
ever
managed targets with 1500 plugins, you really don't want to go
back from
such a component based approach, towards a single file, without
comments
etc.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

> Might this approach be a problem for projects with very
> low Java target level?

Is this relevant given that platform already requires Java 11?

> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.

New features require new version correct, but it should not be an issue 
see above, anyways I'm currently working in fixing a bug [1] for 
compiling java 8 with and tycho has a integration-test for compiling 
with an java 8 jdk so if 'old Java EE levels' not means JSE1.4 or 
something...


> Also everyone using the Target Platform Definition language *.tpd
> might be out, since that tooling cannot generate the new syntax
> I believe.

There is an open issue  [2]for that but it has not gotten much attention 
yet.


> but if you have ever managed targets with 1500 plugins you really
> don't want to go back from such a component based approach, towards
> a single file

From 2022-03 on PDE supports references of other target files [3], so 
you could either use this directly, or have one "main" target with maven 
deps, that includes another that is generated by the TPD files.



[1] https://github.com/eclipse/tycho/issues/51
[2] https://github.com/eclipse-cbi/targetplatform-dsl/issues/115
[3] https://www.eclipse.org/eclipse/news/4.23/pde.php#pde-editor-include


Am 05.04.22 um 20:46 schrieb Michael Keppler:

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Dirk Fauth via cross-project-issues-dev]

Well, with the Generic Editor available I recently dropped all tpd files.
Now I edit the target files via Generic Editor and also have code
completion. That is now similar comfortable.

But I think Oomph does not yet support the new Maven location.

Michael Keppler  schrieb am Di., 5. Apr. 2022,
20:46:

> Might this approach be a problem for projects with very low Java target
> level? From my understanding, to be able to use that mechanism they
> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.
>
> Also everyone using the Target Platform Definition language *.tpd might
> be out, since that tooling cannot generate the new syntax I believe.
> https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
> using TPD can just maintain .target files instead, but if you have ever
> managed targets with 1500 plugins, you really don't want to go back from
> such a component based approach, towards a single file, without comments
> etc.
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Michael Keppler]

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Gunnar Wagenknecht]

> On Apr 5, 2022, at 05:11, Aleksandar Kurtakov  wrote:
> I can only encourage everyone to open a ticket for such project and help 
> them to include OSGi meta-data in the first place instead of putting the 
> effort else-where, as adding those does not harm the project but helps 
> integration it with just a few extra lines in the manifest.4
> 
> One such project is Lucene. I never found the time to report against it so 
> far. Help is always more than welcome . 
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/136
>  
> 
I tried that in 2008. https://issues.apache.org/jira/browse/LUCENE-1344 
. It failed and was rejected 
as won't fix.
https://issues.apache.org/jira/browse/LUCENE-7522 
 seems to be another attempt.

Some projects aren't as receptive as you'd think. I that case it would still be 
nice to share the OSGi metadata with other Eclipse projects.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Aleksandar Kurtakov]

On Tue, Apr 5, 2022 at 2:54 PM Christoph Läubrich 
wrote:

>  > When Maven Central is not OSGi artifact  Orbit will be preferred.
>
> I can only encourage everyone to open a ticket for such project and help
> them to include OSGi meta-data in the first place instead of putting the
> effort else-where, as adding those does not harm the project but helps
> integration it with just a few extra lines in the manifest.4
>

One such project is Lucene. I never found the time to report against it so
far. Help is always more than welcome .
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/136


>
> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
> > Hey everyone,
> > With PGP signing support, latest Tycho work and M2E extending PDE so
> > *.target files can refer/use dependencies from Maven Central directly
> > will prefer to use dependencies from Maven Central when updating to new
> > versions of libraries.
> > This would be done only when we update to a new version of libraries or
> > the dependency we use is no longer available in the latest Orbit build.
> > When Maven Central is not OSGi artifact  Orbit will be preferred.
> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
> > Tycho automates what was achieved via EBR as an intermediate step to be
> > part of the regular build.
> > Extra benefits are:
> > * Eclipse will no longer ship modified version of upstream release (PGP
> > signature is in p2 metadata and not modifying the jar as jarsigner does)
> > * Eclipse will not longer ship bundles with symbolic names that do not
> > match upstream developers decision (as it happens with number of Orbit
> > artifacts)
> > * Version updates could be done in chunks rather than all changes at
> > once to work with latest Orbit
> >
> > I strongly encourage other projects to take that path too for third
> > party dependencies.
> >
> >
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Aleksandar Kurtakov]

On Tue, Apr 5, 2022 at 2:57 PM Dirk Fauth via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> @Aleks
> Maybe jetty is already signed correctly? How will be the process for
> unsigned content?
>

This has been an ongoing topic for the last year or so. The core is
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/pom.xml#L38
which defines which key to use to sign (every project has a gpg key which
is available via the Jenkins build).There is a param that defines that only
non-jarsigned content is signed with pgp as it's still preferred for our
own artifacts to be jarsigned but changing upstream artifacts should be
avoided when possible.


>
>
> Christoph Läubrich  schrieb am Di., 5. Apr. 2022,
> 13:54:
>
>>  > When Maven Central is not OSGi artifact  Orbit will be preferred.
>>
>> I can only encourage everyone to open a ticket for such project and help
>> them to include OSGi meta-data in the first place instead of putting the
>> effort else-where, as adding those does not harm the project but helps
>> integration it with just a few extra lines in the manifest.
>>
>> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
>> > Hey everyone,
>> > With PGP signing support, latest Tycho work and M2E extending PDE so
>> > *.target files can refer/use dependencies from Maven Central directly
>> > will prefer to use dependencies from Maven Central when updating to new
>> > versions of libraries.
>> > This would be done only when we update to a new version of libraries or
>> > the dependency we use is no longer available in the latest Orbit build.
>> > When Maven Central is not OSGi artifact  Orbit will be preferred.
>> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
>> > Tycho automates what was achieved via EBR as an intermediate step to be
>> > part of the regular build.
>> > Extra benefits are:
>> > * Eclipse will no longer ship modified version of upstream release (PGP
>> > signature is in p2 metadata and not modifying the jar as jarsigner does)
>> > * Eclipse will not longer ship bundles with symbolic names that do not
>> > match upstream developers decision (as it happens with number of Orbit
>> > artifacts)
>> > * Version updates could be done in chunks rather than all changes at
>> > once to work with latest Orbit
>> >
>> > I strongly encourage other projects to take that path too for third
>> > party dependencies.
>> >
>> >
>> > --
>> > Aleksandar Kurtakov
>> > Red Hat Eclipse Team
>> >
>> > ___
>> > cross-project-issues-dev mailing list
>> > cross-project-issues-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Declaring Orbit Build: S20220403232146 (2022-06 M1)

[Ed Willink]

Hi

https://bugs.eclipse.org/bugs/show_bug.cgi?id=579584 raised to 
re-instate antlr 3.2.0


https://bugs.eclipse.org/bugs/show_bug.cgi?id=579583 raised to 
re-instate lpg.runtime.java


Regards

Ed Willink

On 04/04/2022 16:35, Christian Dietrich wrote:


ok, i found some some orphans
guice 5 (on 2022-06) needs javax.inject
and org.aopalliance which are both no longer part of 2022-06
i wonder if there is tooling to find more of these inconsistencies

i removed our usage of commons.lang
and updated junit to 4.13.2

gson was broken data in local maven repo

Am 04.04.22 um 16:33 schrieb Jonah Graham:

Hi Christian / Ed / Ed / other Orbit consumers,

> @Jonah does this mean i deed to use 10 repos to get the sum of my 
orbit deps?


No, it means if you rely on the old CVS defined orbit bundles you now 
need to make that reference explicit in your target file (i.e to 
R20201118194144 + S20220403232146 for M1) as the Orbit project is not 
maintaining the old CVS defined bundles anymore.


Using the CVS defined orbit is a risk for the project (and up to the 
project to decide how much of a risk that is). We no longer have the 
sources or build machine of the CVS defined bundles and have for the 
last few years been patching the repo*. Because we don't have a way 
to build those old bundles everytime a modification needed to be made 
it was a lot of manual crafting of p2 repos and modifying metadata.


Here is a concrete example. Orbit's upcoming releases do not want to 
recommend org.apache.log4j 1.2.15 anymore (due to CVEs). That bundle 
version is not in S20220403232146, but its replacement is (1.2.19) 
and no one wants to make another derivative of R20201118194144 that 
has it excluded.


As for specific dependencies identified in this thread:

>org.antlr.runtime/3.2.0.v201101311130
That version is available in R20201118194144 and newer versions 
(3.5.2, and numerous 4.x versions) will be in the recommended 2022-06 
release.


>JUnit 4.12
Also in R20201118194144 and newer versions (4.13.2 and 5.x) will be 
in the recommended 2022-06 release.


> com.google.gson 2.8.9
This is in the 2022-06 M1, so not sure what the issue is here.

> javax.inject
Available in R20201118194144. As of now no one has added 
jakarta.inject (the new name for this bundle) to Orbit's git as an 
EBR. The whole javax -> jakarta transition has lots of its own 
problems that so far are being handled piecemeal (and is part of why 
Mylyn stopped working and has been removed from SimRel).


> commons.lang
Available in R20201118194144. As of now no one has added it to 
Orbit's git as an EBR.


> should we create a bugzilla?
There is one - https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936

I hope that clarifies things. Please ask follow-ups.
Jonah


* 
https://download.eclipse.org/tools/orbit/downloads/drops/R20160520211859/ 
was the last recommended build from CVS, 
https://download.eclipse.org/tools/orbit/downloads/drops/R20201118194144/ 
is the many times patched version of that.





~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Mon, 4 Apr 2022 at 01:03, Christian Dietrich 
 wrote:


@Jonah does this mean i deed to use 10 repos to get the sum of my
orbit deps?

i am getting

Error: Failed to resolve target definition

/home/runner/work/xtext-reference-projects/xtext-reference-projects/integrationtests/org.eclipse.xtext.integrationtests.target/org.eclipse.xtext.integrationtests.target.target:
Could not find "org.antlr.runtime/3.2.0.v201101311130" in the
repositories of the current location

is that intentional?

Am 04.04.22 um 01:57 schrieb Jonah Graham:

Hello folks,

I am distributing this wider than normal because of the larger
impact of this change. See details below in the quoted emails.

Following the build process on the wiki[0] I'm declaring
S20220403232146 [1,2] as our contribution for SimRel 2022-06 M1 [3].

*Reminder: *As of 2022-06 this is no longer a composite repo.
The final CVS defined bundles are available
in R20201118194144[4]. If you need these old bundles I highly
recommend you add recipes to orbit[5] or change to other options
like the new Maven in PDE option[6]. We don't really have a way
to rebuild these old bundles therefore having your project
depend on them is a risk in your project.

The following changes are new for 2022-06 M1 since  2022-03 R
(sorry for the noisy commits on build scripts - these changes
used to be hidden in configuration changes on Jenkins, but I
migrated all the build scripts to git):

4322974 Bug 569078: GMF Runtime have fixed their SimRel
contribution (fixup)
fe394e5 Merge "Bug 569078: GMF Runtime have fixed their SimRel
contribution"
467effd Bug 568936: Automatically set name/description of build
0ea4906 Bug 568936: Fix typos/syntax error in build scripts
43f6ea5 Bug 569078: GMF Runtime have fixed their SimRel contribution
 

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Dirk Fauth via cross-project-issues-dev]

Thanks Ed, that was the information I was missing. :)

Ed Merks  schrieb am Di., 5. Apr. 2022, 14:01:

> Dirk,
>
> As of the 2022-03 release, PGP signing is ready and approved for broader
> adoption during the 2022-06 release cycle:
>
> https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/11
>
> On 05.04.2022 13:57, Dirk Fauth via cross-project-issues-dev wrote:
>
> @Aleks
> Maybe jetty is already signed correctly? How will be the process for
> unsigned content?
>
>
> Christoph Läubrich  schrieb am Di., 5. Apr. 2022,
> 13:54:
>
>>  > When Maven Central is not OSGi artifact  Orbit will be preferred.
>>
>> I can only encourage everyone to open a ticket for such project and help
>> them to include OSGi meta-data in the first place instead of putting the
>> effort else-where, as adding those does not harm the project but helps
>> integration it with just a few extra lines in the manifest.
>>
>> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
>> > Hey everyone,
>> > With PGP signing support, latest Tycho work and M2E extending PDE so
>> > *.target files can refer/use dependencies from Maven Central directly
>> > will prefer to use dependencies from Maven Central when updating to new
>> > versions of libraries.
>> > This would be done only when we update to a new version of libraries or
>> > the dependency we use is no longer available in the latest Orbit build.
>> > When Maven Central is not OSGi artifact  Orbit will be preferred.
>> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
>> > Tycho automates what was achieved via EBR as an intermediate step to be
>> > part of the regular build.
>> > Extra benefits are:
>> > * Eclipse will no longer ship modified version of upstream release (PGP
>> > signature is in p2 metadata and not modifying the jar as jarsigner does)
>> > * Eclipse will not longer ship bundles with symbolic names that do not
>> > match upstream developers decision (as it happens with number of Orbit
>> > artifacts)
>> > * Version updates could be done in chunks rather than all changes at
>> > once to work with latest Orbit
>> >
>> > I strongly encourage other projects to take that path too for third
>> > party dependencies.
>> >
>> >
>> > --
>> > Aleksandar Kurtakov
>> > Red Hat Eclipse Team
>> >
>> > ___
>> > cross-project-issues-dev mailing list
>> > cross-project-issues-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Ed Merks]

Dirk,

As of the 2022-03 release, PGP signing is ready and approved for broader 
adoption during the 2022-06 release cycle:


https://gitlab.eclipse.org/eclipse-wg/ide-wg/eclipseide.org/-/issues/11

On 05.04.2022 13:57, Dirk Fauth via cross-project-issues-dev wrote:

@Aleks
Maybe jetty is already signed correctly? How will be the process for 
unsigned content?



Christoph Läubrich  schrieb am Di., 5. Apr. 
2022, 13:54:


 > When Maven Central is not OSGi artifact  Orbit will be preferred.

I can only encourage everyone to open a ticket for such project
and help
them to include OSGi meta-data in the first place instead of
putting the
effort else-where, as adding those does not harm the project but
helps
integration it with just a few extra lines in the manifest.

Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
> Hey everyone,
> With PGP signing support, latest Tycho work and M2E extending
PDE so
> *.target files can refer/use dependencies from Maven Central
directly
> will prefer to use dependencies from Maven Central when updating
to new
> versions of libraries.
> This would be done only when we update to a new version of
libraries or
> the dependency we use is no longer available in the latest Orbit
build.
> When Maven Central is not OSGi artifact  Orbit will be preferred.
>  From releng POV it would simply remove the middle man
(Orbit/EBR) as
> Tycho automates what was achieved via EBR as an intermediate
step to be
> part of the regular build.
> Extra benefits are:
> * Eclipse will no longer ship modified version of upstream
release (PGP
> signature is in p2 metadata and not modifying the jar as
jarsigner does)
> * Eclipse will not longer ship bundles with symbolic names that
do not
> match upstream developers decision (as it happens with number of
Orbit
> artifacts)
> * Version updates could be done in chunks rather than all
changes at
> once to work with latest Orbit
>
> I strongly encourage other projects to take that path too for third
> party dependencies.
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Dirk Fauth via cross-project-issues-dev]

@Aleks
Maybe jetty is already signed correctly? How will be the process for
unsigned content?


Christoph Läubrich  schrieb am Di., 5. Apr. 2022,
13:54:

>  > When Maven Central is not OSGi artifact  Orbit will be preferred.
>
> I can only encourage everyone to open a ticket for such project and help
> them to include OSGi meta-data in the first place instead of putting the
> effort else-where, as adding those does not harm the project but helps
> integration it with just a few extra lines in the manifest.
>
> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
> > Hey everyone,
> > With PGP signing support, latest Tycho work and M2E extending PDE so
> > *.target files can refer/use dependencies from Maven Central directly
> > will prefer to use dependencies from Maven Central when updating to new
> > versions of libraries.
> > This would be done only when we update to a new version of libraries or
> > the dependency we use is no longer available in the latest Orbit build.
> > When Maven Central is not OSGi artifact  Orbit will be preferred.
> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
> > Tycho automates what was achieved via EBR as an intermediate step to be
> > part of the regular build.
> > Extra benefits are:
> > * Eclipse will no longer ship modified version of upstream release (PGP
> > signature is in p2 metadata and not modifying the jar as jarsigner does)
> > * Eclipse will not longer ship bundles with symbolic names that do not
> > match upstream developers decision (as it happens with number of Orbit
> > artifacts)
> > * Version updates could be done in chunks rather than all changes at
> > once to work with latest Orbit
> >
> > I strongly encourage other projects to take that path too for third
> > party dependencies.
> >
> >
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

> When Maven Central is not OSGi artifact  Orbit will be preferred.

I can only encourage everyone to open a ticket for such project and help 
them to include OSGi meta-data in the first place instead of putting the 
effort else-where, as adding those does not harm the project but helps 
integration it with just a few extra lines in the manifest.


Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:

Hey everyone,
With PGP signing support, latest Tycho work and M2E extending PDE so 
*.target files can refer/use dependencies from Maven Central directly 
will prefer to use dependencies from Maven Central when updating to new 
versions of libraries.
This would be done only when we update to a new version of libraries or 
the dependency we use is no longer available in the latest Orbit build. 
When Maven Central is not OSGi artifact  Orbit will be preferred.
 From releng POV it would simply remove the middle man (Orbit/EBR) as 
Tycho automates what was achieved via EBR as an intermediate step to be 
part of the regular build.

Extra benefits are:
* Eclipse will no longer ship modified version of upstream release (PGP 
signature is in p2 metadata and not modifying the jar as jarsigner does)
* Eclipse will not longer ship bundles with symbolic names that do not 
match upstream developers decision (as it happens with number of Orbit 
artifacts)
* Version updates could be done in chunks rather than all changes at 
once to work with latest Orbit


I strongly encourage other projects to take that path too for third 
party dependencies.



--
Aleksandar Kurtakov
Red Hat Eclipse Team

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Aleksandar Kurtakov]

Jetty is already used that way . See
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/130
for details.

On Tue, Apr 5, 2022 at 2:48 PM Aleksandar Kurtakov 
wrote:

> Hey everyone,
> With PGP signing support, latest Tycho work and M2E extending PDE so
> *.target files can refer/use dependencies from Maven Central directly will
> prefer to use dependencies from Maven Central when updating to new versions
> of libraries.
> This would be done only when we update to a new version of libraries or
> the dependency we use is no longer available in the latest Orbit build.
> When Maven Central is not OSGi artifact  Orbit will be preferred.
> From releng POV it would simply remove the middle man (Orbit/EBR) as Tycho
> automates what was achieved via EBR as an intermediate step to be part of
> the regular build.
> Extra benefits are:
> * Eclipse will no longer ship modified version of upstream release (PGP
> signature is in p2 metadata and not modifying the jar as jarsigner does)
> * Eclipse will not longer ship bundles with symbolic names that do not
> match upstream developers decision (as it happens with number of Orbit
> artifacts)
> * Version updates could be done in chunks rather than all changes at once
> to work with latest Orbit
>
> I strongly encourage other projects to take that path too for third party
> dependencies.
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Dirk Fauth via cross-project-issues-dev]

I really like the idea. But what about jar signatures? When I brought up
the topic for reload4j I was told that the jars need to be signed in order
to be included. Is this taken care of?

Aleksandar Kurtakov  schrieb am Di., 5. Apr. 2022,
13:48:

> Hey everyone,
> With PGP signing support, latest Tycho work and M2E extending PDE so
> *.target files can refer/use dependencies from Maven Central directly will
> prefer to use dependencies from Maven Central when updating to new versions
> of libraries.
> This would be done only when we update to a new version of libraries or
> the dependency we use is no longer available in the latest Orbit build.
> When Maven Central is not OSGi artifact  Orbit will be preferred.
> From releng POV it would simply remove the middle man (Orbit/EBR) as Tycho
> automates what was achieved via EBR as an intermediate step to be part of
> the regular build.
> Extra benefits are:
> * Eclipse will no longer ship modified version of upstream release (PGP
> signature is in p2 metadata and not modifying the jar as jarsigner does)
> * Eclipse will not longer ship bundles with symbolic names that do not
> match upstream developers decision (as it happens with number of Orbit
> artifacts)
> * Version updates could be done in chunks rather than all changes at once
> to work with latest Orbit
>
> I strongly encourage other projects to take that path too for third party
> dependencies.
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Aleksandar Kurtakov]

Hey everyone,
With PGP signing support, latest Tycho work and M2E extending PDE so
*.target files can refer/use dependencies from Maven Central directly will
prefer to use dependencies from Maven Central when updating to new versions
of libraries.
This would be done only when we update to a new version of libraries or the
dependency we use is no longer available in the latest Orbit build. When
Maven Central is not OSGi artifact  Orbit will be preferred.
>From releng POV it would simply remove the middle man (Orbit/EBR) as Tycho
automates what was achieved via EBR as an intermediate step to be part of
the regular build.
Extra benefits are:
* Eclipse will no longer ship modified version of upstream release (PGP
signature is in p2 metadata and not modifying the jar as jarsigner does)
* Eclipse will not longer ship bundles with symbolic names that do not
match upstream developers decision (as it happens with number of Orbit
artifacts)
* Version updates could be done in chunks rather than all changes at once
to work with latest Orbit

I strongly encourage other projects to take that path too for third party
dependencies.


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev