Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?

[Roland Grunberg]

On Mon, 2021-12-13 at 17:36 +0100, Ed Merks wrote:
> Roland,
> 
> I think this  would be a good idea.  Could you please let us/me know
> the 
> URL when this is done.

With Matthias' contribution, I've published a release on our downloads
page. The 2.x version from the new repository should no longer be
vulnerable.

-- 
Roland Grunberg

___
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] [orbit-dev] log4j vulnerability in Eclipse?

[Roland Grunberg]

On Sun, 2021-12-12 at 08:18 +0300, Alexander Fedorov wrote:
>  Thanks Matthias!
>  
>  Do we plan to have a service release for Eclipse Orbit to let other
> projects consume this dependency from the trusted source?

I can put out a service release of Orbit that includes the updated
component.

-- 
Roland Grunberg

___
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] Responsible usage of disk space on download.eclipse.org

[Roland Grunberg]

On Mon, 2021-08-30 at 20:11 +0200, Frederic Gurr wrote:
> Hi,
> 
> This is a friendly reminder to act responsible with shared resources,
> in
> this case: disk space on download.eclipse.org.
> 
> The download server is the right place to store all your project's
> deliverables like binaries, update sites, etc.
> See also: https://wiki.eclipse.org/IT_Infrastructure_Doc#Downloads

I've always found http://download.eclipse.org/oomph/archive/eclipse/ to
be a useful page to check for when some manual intervention may be
required.

-- 
Roland Grunberg

___
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] Additional Batik 1.13.0 bundles into Orbit for RC1

[Roland Grunberg]

While we have a small set of Batik 1.13.0 bundles that are used by
projects, there were always additional ones (eg. batik-codec, batik-
transcoder) requested to be updated as well.

There have been issues preventing this work in the past regarding CQ
filing, getting transitive deps right, testing, etc. ShiHeng has
submitted a set of patches to finally complete this and they seem to be
in good shape :

https://git.eclipse.org/r/c/orbit/orbit-recipes/+/172343/1

I've also filed https://eclip.se/569080 and would like to get this in
for RC1 so I wanted to make others aware.

This will not modify any existing Batik 1.13.0 bundles (batik-
{constants,css,i18n,util}), or remove the older ones (1.9.1) as this is
simply an addition. The older ones may be removed in future releases.

Let me know if there's any reason to hold off on this, but otherwise, I
expect to push these changes in by Tuesday, or Wednesday at the latest.

Cheers,
-- 
Roland Grunberg

___
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] "latest" repo for orbit

[Roland Grunberg]

On Sat, 2020-10-24 at 21:56 +0200, Wim Jongman wrote:
> Obviously not :). Is it documented somewhere?
> 
> Thanks for the pointer. I think the repo site should be updated with
> this link. I will add it to the bug.

We can add it to the main downloads page somewhere. Currently we
support latest-X (for X in I,S,R) and the simrel name itself (eg. 2020-
09) which points to the release (since 2019-06 but I guess we could
even add prior ones if needed). Prior to a release they point to the
last milestone build for that release for convenience.

Cheers,
-- 
Roland Grunberg

___
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] Changes In My Contribution Activity (Help On Orbit)

[Roland Grunberg]

Hey everyone,

I just wanted to let people know that I've taken some new
responsibilities within my company that will affect my contribution
level on certain projects. I think the biggest change will probably be
affecting tools.orbit (Eclipse Orbit). I will try to perform some of
the Orbit maintenance/release tasks in the short term, but it would be
great if someone was prepared to jump in as it's likely that I will not
have sufficient time. My activity on JDT (Java Development Tools) may
decrease a bit but I still hope to continue making contributions there.
I will still be contributing within the Eclipse ecosystem going
forward.


Cheers,
-- 
Roland Grunberg

___
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] Container failure with dbus in jdt.ui-gerrit

[Roland Grunberg]

Since https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/5239/ ,
those builds seem to be failing with :

12:34:33 process 3933: D-Bus library appears to be incorrectly set up;
failed to read machine uuid: UUID file '/etc/machine-id' should contain
a hex string of length 32, not length 0, with no other text
12:34:33 See the manual page for dbus-uuidgen to correct this issue.
12:34:33   D-Bus not built with -rdynamic so unable to print a backtrace

I don't think this is related to the change, but If I remember, such an
issue is resolved by ensuring the container runs :

dbus-uuidgen > /etc/machine-id

Has something changed about the underlying containers used to run the
builds ?

Looking at :

https://hub.docker.com/layers/eclipsecbijenkins/jipp-migration-agent/3.35/images/sha256-b6de55ff70862db84a49725f3f39408079d3e4fa916c82b31cd199a663b97716?context=explore

seems like there was an update about a day ago but no idea if that's
what would have caused it.

Cheers,
-- 
Roland Grunberg

___
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] Removing LegacyJavadocCompletionProposalComputer from JDT

[Roland Grunberg]

I just wanted to give a heads-up that http://eclip.se/560450 has been proposed
along with a change up for review to remove only the internal class :

org.eclipse.jdt.internal.ui.text.javadoc.LegacyJavadocCompletionProposalComputer

Although internal, it does handle implementation of IJavadocCompletionProcessor
that are contributed from the 'org.eclipse.jdt.ui.javadocCompletionProcessor'
extension point. It has been deprecated since 2006 ( http://eclip.se/153242 )
and the regular java completion processor extension point has been the
recommended way to contribute java related completions.

Looking through all source bundles in simrel, I could not find anything
still contributing to that extension point but perhaps someone may be
aware of a consumer that still makes use of this.

If there's no opposition to this change then I'll go ahead and merge it by
the end of the week.

Cheers,
Roland Grunberg

___
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 2020-03 and new ASM/JUnit5 Versions

[Roland Grunberg]

On Tue, Jan 28, 2020 at 6:19 AM Dietrich, Christian
 wrote:
> i have seen that there are Buzillas for ASM 7.3.1 and JUnit 5.6 in Orbit.
> Is there already an ETA for these so that projects can start adopting?

For JUnit 5.6, I would aim for having it in an I-build early in the M3 cycle.
I haven't really had enough time to do the update though past updates
have been pretty straightforward. Bug 558875 tracks this.

I'm not sure about ASM 7.3.1. I would ask in Bug 559150 so there's some
awareness by the maintainer(s) adding the bundles that others are
waiting for this.

Cheers,
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Signed-off-by For Committers

[Roland Grunberg]

In a recent review, a discussion came up about whether committers to a
project should be adding the 'Signed-off-by' header to their commits on
that same project.

I'm assuming it's mandatory for all non-committers to a project as
Gerrit will certainly reject the commit. However, I see plenty of
changes by committers (even recently) that do not contain it so Gerrit
is definitely not enforcing it in this case. Is it implicit from the
committer agreement one would have on file ? Is there any reason to
include one anyways ? (eg. stats being collected from it
that we wouldn't appear in). I could definitely see the argument for
saving a line in the log messages.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundle Removals For 2019-09 M1

[Roland Grunberg]

On Thu, 2019-06-27 at 16:56 +0200, Dietrich, Christian wrote:
> 27.1.0 not 27.0.0 correct?

Yes, com.google.guava 27.1.0 .

-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundle Removals For 2019-09 M1

[Roland Grunberg]

On Wed, 2019-06-26 at 21:41 +0100, Ed Willink wrote:
> Hi
> 
> Why two versions of Guava? More than one has been established to be 
> problematic.

I'm completely willing to leave just 27.0.0. If there's no opposition
I'll do that. From a few releases ago, there were issues with some
projects and the most recent version, but by now they should have
migrated.

-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Orbit Bundle Removals For 2019-09 M1

[Roland Grunberg]

Hi,

The following bundles are either in the process of being removed, or
planned as such for the Orbit 2019-09 release. Ideally we'll have them
done for M1 so that there's plenty of time to adapt to the changes.

If there's any opposition to any of the removals, let me know. I
believe there was some to older Lucene but this should be resolved.

- BouncyCastle 1.59.0, 1.60.0
  - 1.61.0 exists
  - https://git.eclipse.org/r/143086 & https://git.eclipse.org/r/143087

- Lucene 5.2.1, 6.1.0, 7.1.0 http://eclip.se/539752
  - 7.5.0 and 8.1.0 exist as replacement
  - 3.5.0 will remain since I believe Recommenders still requires it
and the index that uses it is unlikely to be updated anytime soon

- com.google.guava 15.0.0, 18.0.0
  - 21.0.0 and 27.0.0 exist

- org.tukaani.xz 1.3.0, 1.5.0, 1.6.0
  - 1.8.0 exists

- Felix 0.10.0 https://eclip.se/547314
  - 1.x version exists

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] eclipse-jarsigner-plugin issues on Jenkins builds

[Roland Grunberg]

It's being tracked at https://bugs.eclipse.org/bugs/show_bug.cgi?id=548204 .


On Wed, Jun 12, 2019 at 4:46 PM Nick Boldt  wrote:

> This was once again happening today:
>
>
> https://hudson.eclipse.org/webtools/view/webtools_CI/job/webtools-dali_master/640/console
>
>
> https://hudson.eclipse.org/webtools/view/webtools_CI/job/webtools-webservices_master/591/console
>
> But it seems to have been self-correcting as builds after these two
> passed.
>
> On Sun, Jun 9, 2019 at 4:55 AM Mikaël Barbero <
> mikael.barb...@eclipse-foundation.org> wrote:
>
>> The TSA server was unavailable, which makes digital signing impossible.
>> We have to rely on external service for timestamping (symantec in this
>> case) and have no control over it.
>>
>> Everything is working properly now.
>>
>> Thanks,
>>
>> *Mikaël Barbero *
>> *Team Lead - Release Engineering | Eclipse Foundation*
>>  (+33) 642 028 039 |  @mikbarbero
>> Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open
>> Innovation and Collaboration
>>
>> Le 7 juin 2019 à 20:22, Roland Grunberg  a écrit :
>>
>> Also seems to be happening in
>> https://ci.eclipse.org/releng/job/I-build-4.13/3/console
>> so it's likely affecting other projects as well.
>>
>> On Fri, Jun 7, 2019 at 1:58 PM Roland Grunberg 
>> wrote:
>>
>>
>> I'm seeing the following error on the Orbit [1] and Linux Tools [2]
>> JIPP/JIROs.
>> It seems to have started happening today.
>>
>> [INFO] --- eclipse-jarsigner-plugin:1.1.5:sign (sign) @ org.objectweb.asm
>> ---
>> [INFO] Signing jar:
>>
>> /home/jenkins/workspace/orbit-recipes-pipeline-test/asm/org.objectweb.asm_7.1.0/target/org.objectweb.asm-7.1.0-SNAPSHOT.jar
>> [WARNING] [Fri Jun 07 17:19:40 UTC 2019] HTTP request failed.
>> HTTP Error 500 (reason: Server Error)
>> HTTP Error 500
>> Problem accessing '/jar-signing-service'
>> Reason: Server Error
>>
>> Caused by: java.io.IOException: The
>> '/usr/java/jdk1.8.0_51/bin/jarsigner' command exited with value '1'
>> '/usr/java/jdk1.8.0_51/bin/jarsigner' output:
>> jarsigner: unable to sign jar: java.io.IOException: Server returned
>> HTTP response code: 503 for URL:
>> http://sha256timestamp.ws.symantec.com/sha256/timestamp
>>
>>at
>> org.eclipse.cbi.webservice.signing.jar.JarSigner.signJar(JarSigner.java:231)
>>at
>> org.eclipse.cbi.webservice.signing.jar.SigningServlet.doSign(SigningServlet.java:66)
>>at
>> org.eclipse.cbi.webservice.signing.jar.SigningServlet.doPost(SigningServlet.java:54)
>>at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>>at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>at
>> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:860)
>>at
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535)
>>at
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>>at
>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>>at
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>>at
>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>>at
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>>at
>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>>at
>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>>at
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>>at
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>>at
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>> .. For complete output, see
>>
>> '/home/jenkins/workspace/orbit-recipes-pipeline-test/asm/org.objectweb.asm_7.1.0/target/org.objectweb.asm-7.1.0-SNAPSHOT.jar-7875781808081756076-RemoteJarSigner.log'
>>
>> Cheers,
>> Roland Grunberg
>>
>> [1] https://ci.eclipse.org/orbit/job/orbit-recipes/462/console
>> [2]
>> https://ci.eclipse.org/linuxtools/job/linuxtools-master/64/consoleFull
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org

Re: [cross-project-issues-dev] Orbit To Release An RC2 Build

[Roland Grunberg]

On Sunday, June 2, 2019, Matthias Sohn  wrote:
>
>
> I agree this looks inconsistent. No clue why this happened, comparing the
> sources against 1.60
> didn't reveal the reason why the build decided for JavaSE 9. I pushed a
> fix for review
> https://git.eclipse.org/r/#/c/143182/
>

 I haven't looked too deeply yet but my guess is that the metadata
generation detects a module-info file and treats this as requiring Java 9
at a minimum. The affected property can be manually set as needed though.

Given that the scope is limited, we can do an RC2a. I would just make sure
to test to confirm it works as you expect.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Orbit To Release An RC2 Build

[Roland Grunberg]

Hey everyone,

While we released our RC1 contribution a few days ago, and generally
this ends up being our final release, we expect to have an RC2
contribution.

A newer version of BouncyCastle (bcprov, bcpkix, bcpg) 1.61 will be
introduced [1]. None of the older versions of BouncyCastle will be
removed from 2019-06, but will likely happen for 2019-09.

Cheers,
-- 
Roland Grunberg

[1] https://git.eclipse.org/r/143085/

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Maven 3.6.1 breaks Tycho injecting repositories in pom.xml files

[Roland Grunberg]

On Fri, 2019-05-31 at 18:26 +0300, Aleksandar Kurtakov wrote:
> Hi everyone,
> Please do not use Maven 3.6.1  if your projects add p2 repositories in 
> pom.xml files as it contains an issue that is now reverted in Maven master. 
> https://github.com/apache/maven/commit/763f76c

1000 Thank-yous for finding this. I was hit by this while trying to
build using the JIRO staging instance. Switching to maven-3.5.4
resolved the issues I was having. It even makes sense given that this
only started happening about 3 days ago.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [Bug 547338] Update to guava 24.1.1+ (fix CVE-2018-10237)

[Roland Grunberg]

On Wed, 2019-05-15 at 19:38 +, Homer, Tony wrote:
> Thanks to Fred Bricon who suggested that I contact this list:
> >>Usually, guava versions need to be aligned across all Eclipse projects, so 
> >>you might want to raise the issue in the cross-projects ML 
> My team builds an Eclipse product which includes m2e.
> Our company policy requires us to scan for CVEs and we found several 
> affecting m2e, including CVE-2018-10237, which m2e is exposed to via 
> dependence on a vulnerable version of guava.
> m2e is currently using 21.0.0 which is the latest which is currently 
> available in Orbit.
> The CVE is fixed starting with guava 24.1.1.
> The latest guava release is 27.1.
>  
> In order to work around this issue, my team forked m2e locally and updated 
> our fork to use guava 27.0.1 (as mentioned in Bug 547338).
> I’d like to add guava 27.0.1 or 27.1 (pending compatibility investigation) to 
> orbit so that eclipse projects can switch to a guava that is not vulnerable 
> to any published CVEs.
> I plan to open a change request with Orbit for this.
> What else is needed to move this forward in time for 2019-06?

The Eclipse project expecting to consume the newer Guava, m2e, needs to
file a CQ for this, and it should get marked as mature IP since Guava
21.0 is already shipping in Orbit. From there we could file a bug and
get it into Orbit, and remove the older one(s) from active builds.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Initialization for 2019-06

[Roland Grunberg]

On Sun, 2019-03-31 at 15:50 +0200, Mikaël Barbero wrote:
> Hi Wim,
> 
> > what about also creating an ../updates/latest, ../orbit/latest and 
> > ../packages/latest
> 
> This is ultimately the responsibility of their dedicated projects: 
> respectively platform, orbit and EPP. 

Orbit provides :

/latest-I, /latest-S, /latest-R, and will start providing predictable
names for the milestone builds leading up to the release [1] (eg.
/2019-06).

I guess the one remaining thing would be to document or at least agree
to what the expected format should be.


Cheers,
-- 
Roland Grunberg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=544186

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Java 11 (OpenJDK 11): javax.xml.bind package removed

[Roland Grunberg]

On Tue, 2018-12-04 at 14:02 -0500, Nitin Dahyabhai wrote:
> Trying to actually use the existing version under an AdoptOpenJDK 11 build to 
> marshal/unmarshal runs into problems:
> 
> Caused by: java.lang.ClassNotFoundException: 
> com.sun.xml.internal.bind.v2.ContextFactory
>   at 
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
>   at 
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at 
> org.eclipse.osgi.internal.framework.ContextFinder.loadClass(ContextFinder.java:135)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>   at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:480)
>   at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:184)
>   ... 106 more
> 
> Has anyone else seen this and come up with a workaround other than rewrites?

Would https://bugs.eclipse.org/bugs/show_bug.cgi?id=541264#c15 be a
possibility in your case ? Basically, just replacing mentions of
'org.eclipse.ptp.rm.jaxb.core' in that example, with the bundle that
actually requires 'javax.xml.bind' in your case.

When I looked in ContextFinder, it did seem possible to override the
default behaviour of looking up ContextFactory from the JRE.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Java 11 (OpenJDK 11): javax.xml.bind package removed

[Roland Grunberg]

On Wed, 2018-10-17 at 11:41 -0400, Keith Chong wrote:
> Are other teams affected by the removal of the javax.xml.bind package from 
> Java 11? 
> 
> Web Tools Platform (WTP) Web services has 'unresolved' references when 
> running with Java 11. See 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=539771.
> 
> The solution would simply be to pull the javax.xml.bind package into WTP 
> (from orbit), but, it was originally pulled out of WTP because of 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=446080
> due to OSGi wiring issues. If we proceed with this solution, we might 
> re-introduce the wiring issues when using a Java level (non-Java 11) that 
> contains the deprecated packages. 
> 
> The info in the two bugzillas indicate that other teams might be impacted by 
> this. Dali (eg. eclipselink packages) and MyLyn. Thoughts?

Orbit is affected by this in the sense that there are packages that
depend on javax.xml.bind (versionless) that we ship. In 
http://eclip.se/539515 I've converted all the ones shipped in orbit-
recipes (this is in our M1 contribution) so they'll resolve against our
javax.xml.bind bundle but there's still a few more to fix.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

Ok, so it's settled. This should be provided given that there's enough
demand for it.

Now we just need com.ibm.icu.base 62.1 binary and source jar, which in
the past was provided by IBM [1] or instructions on how to reproduce
the base bundle.

Without that, my best guess is just compare 58.2 base/full bundles to
see what should be included.

-- 
Roland Grunberg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=510163#c3

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

On Wed, 2018-10-03 at 15:44 +0200, Tom Schindl wrote:
> I'm late to this but while trying to bring our products up to 2018-09 I
> found the removal of "com.ibm.icu.base" disturbing.
> 
> The Mail from "Roland" says one should substitute "com.ibm.icu.base"
> with "com.ibm.icu" which I think is a bad idea.
> 
> The sole reason for "com.ibm.icu.base" was/is that you don't ship a 12MB
> jar if you don't need any of the extra functionality "com.ibm.icu" provides.

Hey Tom,

If people would like to have corresponding com.ibm.icu.base for any
version of com.ibm.icu, that's fine. It would just be a matter of
ensuring the "base" version is available for the latest one in use as
I'd rather not accumulate many older versions. This is a similar
situation to things like Batik or Lucene, where platform handles the
set of bundles it cares about, but anyone wanting more has to do the
extra work.

The discussion for Platform to move to plain icu4j (from maven) was in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=536411 (comments 11-17)
so it made sense to have everyone using the same thing, but maybe other
projects outside SimRel may still want a smaller version so I'm not
opposing this. For those projects, there is also the Photon Orbit repo
which has the older versions (containing icu.base) as well.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] massive amount of unresolved bundles in 2018-09 M3 (JEE package)

[Roland Grunberg]

On Wed, 2018-09-05 at 14:20 +0200, Gunnar Wagenknecht wrote:
> > On Sep 5, 2018, at 13:22, Martin Lippert  wrote:
> > 
> > org.apache.lucene.queryparser_7.1.0.v20180828-2118

This should be resolved in the upcoming Orbit RC2 contribution. Nick
requested lucene-queryparser 7.1 not long ago (I believe for DTP).
AFAICT only, org.eclipse.datatools.sqltools.result is requiring it so
once they rebuild, it should no longer cause issues.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

This seems fine. I can always go ahead and remove only the bundles for
which no removal issues have been mentioned.

On Thursday, August 9, 2018, Donát Csikós  wrote:

>  Martin, you are correct, we scheduled the Guava 15 -> 21 update for
> Buildship 3.0 which we plan to contribute to Eclipse 2018-12. Would that be
> a reasonable deadline for the code recommenders project too?
>
> Nick Boldt  ezt írta (időpont: 2018. aug. 8., Sze,
> 22:38):
>
>> I'm still using org.eclipse.epp.logging.aeri.feature.feature.group 
>> 2.0.7.v20170906-1327
>> in my target platform.
>>
>> Perhaps you updated it to  depend on Lucene 7.1.0+ recently ? I see
>> that 2.0.7.v20180504-0806 does have a dep on [7.1.0,8.0.0).
>>
>> Aside: Aeri 2.0.7 was released in Photon. Surely it's time to upversion
>> to 2.0.8? Even if the timestamp is newer, it's good practice to have a new
>> x.y.z version for a new train, even if it's just z+1.
>>
>>
>> On Mon, Aug 6, 2018 at 2:22 PM Andreas Sewe 
>> wrote:
>>
>>> Nick Boldt wrote:
>>> > * o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
>>>
>>> Nick, are you sure? I just checked and all I can see are Import-Packages
>>> on Lucene [7.1.0,8.0.0). Also, the update site [1] offers only Lucene 7.
>>>
>>> Can you please clarify?
>>>
>>> Best wishes,
>>>
>>> Andreas
>>>
>>> [1] 
>>>
>>> --
>>> Codetrails GmbH
>>> The best code possible
>>>
>>> Robert-Bosch-Str. 7, 64293 Darmstadt
>>> Phone: +49-6151-276-7092
>>> Mobile: +49-170-811-3791
>>> http://www.codetrails.com/
>>>
>>> Managing Director: Dr. Marcel Bruch
>>> Handelsregister: Darmstadt HRB 91940
>>>
>>
>>
>> --
>>
>> Nick Boldt
>>
>> Principal Software Engineer, RHCSA
>>
>> Productization Lead :: JBoss Tools & Dev Studio
>>
>> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
>> 
>> TRIED. TESTED. TRUSTED. 
>> @ @redhatnews   Red Hat
>> 
>> 
>>
>>
>> “The Only Thing That Is Constant Is Change” - Heraclitus
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Time extension request for Trace Compass M2 participation

[Roland Grunberg]

Looking at JIPPs, I would think it's :

https://ci.eclipse.org/tracecompass/job/org.eclipse.tracecompass-simrel-publish/94/console

Looking at the folder :

-rwxr--r--  1 bhufmanntools.tracecompass 19021 Aug  2 07:56
create-release.pl
-rwxr-xr--  1 bhufmanntools.tracecompass 20863 Aug 30  2017
create-release.pl.old

So it seems the new script can't be executed by the JIPP due to lacking
group
execute permissions.


On Wed, Aug 8, 2018 at 4:23 PM, Nick Boldt  wrote:

> Could you be more specific about your "access denied" issues? Maybe
> someone can help.
>
> On Wed, Aug 8, 2018 at 4:15 PM Jean-Christian Kouame <
> jean-christian.kou...@ericsson.com> wrote:
>
>> Hello,
>>
>>
>> Trace Compass would like to request a time extension for 2018-09 M2 build.
>>
>> We are experiencing some issues and request a bit more time to resolve it
>> ("access denied").
>>
>>
>> Thank you,
>>
>> Jean-Christian
>>
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> --
>
> Nick Boldt
>
> Principal Software Engineer, RHCSA
>
> Productization Lead :: JBoss Tools & Dev Studio
>
> IM: @nickboldt / @nboldt / http://nick.divbyzero.com
> 
> TRIED. TESTED. TRUSTED. 
> @ @redhatnews   Red Hat
> 
> 
>
>
> “The Only Thing That Is Constant Is Change” - Heraclitus
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

On Wed, 2018-08-01 at 16:53 -0400, Nick Boldt wrote:
> So can you push lucene-queryparser 7.1 into Orbit for 201809M3? 

It should be possible. It looks like it depends on lucene-
{queries,sandbox,codec} but they may have been optional looking at how
6.1.0 was done.

You would need to figure out exactly which bundles are needed, and file
CQs for them.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

On Wed, 2018-08-01 at 16:01 -0400, Nick Boldt wrote:
> As to Lucene removals:
> 
> * org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5
> 
> * o.e.epp.logging.aeri.feature requires lucene.analysis 6.1
> 
> * org.eclipse.datatools.sqltools.result (DTP) and 
> org.eclipse.m2e.wtp.jpa.feature (WTP) both require 
> org.apache.lucene.queryparser 6.1.0.v20161115-1612, which doesn't exist in 
> 7.1 (Lucene loves to add and drop bundles will-nilly, don't they?)
> 
> So... either those bundles / features need updating to use lucene 7.1+ or 
> else they'll have to build against old Orbit... and Simrel will end up having 
> multiple versions of these IUs peppered in the mix.

You've highlighted another issue, which is that sometimes, when a newer
version of a set of bundles gets pushed in, the initial contributor
will handle the ones that are of interest to their project. lucene-
queryparser does exist for > 6.1.0, but likely some class(es) within it
were moved elsewhere and there was no need to include it.

> What version of HttpComponents are you thinking would be included/dropped? 
> Currently I'm using httpcore 4.4.6 and httpclient 4.5.2, but I think I saw a 
> thread about Platform moving to newer versions? cc: @Aleksandar Kurtakov  

Yes, I believe they'd move to httpcore 4.4.9 / httpclient 4.5.5 . I'm
fine with not removing certain sets of bundles (eg. lucene,
httpcomponents) but I did want to clean up some known cases where it's
used/updated by a single project that always migrates to the newer
version.

Cheers,
-- 
Roland Grunberg

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Orbit Bundles To Be Removed From 2018-09 M3

[Roland Grunberg]

Hey all,

I just wanted to give a heads-up that the following bundles (and
corresponding source bundles) are expected to be removed from the Orbit
build towards 2018-09, for M3 [1].

com.ibm.icu 56.1.0, 58.2.0 (use 62.0.0)
com.ibm.icu.base 56.1.0, 58.2.0 (use com.ibm.icu 62.0.0)
org.apache.felix.gogo.runtime 1.0.6 (use 1.1.0)
org.apache.felix.gogo.shell 1.0.0 (use 1.1.0)
org.apache.felix.scr 2.0.8, 2.0.10, 2.0.12 (use 2.0.14)
com.google.guava 15.0.0, 18.0.0 (use 21.0.0)
org.apache.ant 1.9.6, 1.10.3 (use 1.10.5, will be in soon)

There may be some additional bundles but they would be announced later
on (possibly older Lucene, tukaani.xz, ASM, HttpComponents).

If any projects are unable to update for some reason, or there's a good
reason not to remove one of these that I've missed, It would be good to
know ahead of time, though there is always the option to reference an
older build (eg. Photon) that would still contain them as well.

Thank-you,
Roland Grunberg

[1] https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan#Schedule


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problems with Batik 1.9.1 packaging for Photon - might need to revert to previous versions

[Roland Grunberg]

On Tue, 2018-06-05 at 08:46 +0200, Pierre-Charles David wrote:
> We agree, and are considering a respin of Orbit which would remove the 
> problematic JARs and leave only the (safe) ones which are used by the 
> platform [1] [2].

I've declared our new Photon contribution as :

Page : http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/
p2 Repo : 
http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/repository

This still contains the Batik 1.9.1 bundles used by platform.releng and
they remain unchanged, but the other parts of that stack have been
removed. Once the issue is resolved we can add them back in, and
eventually start updating to 1.10.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problems with Batik 1.9.1 packaging for Photon - might need to revert to previous versions

[Roland Grunberg]

On Thu, 2018-05-31 at 09:30 +0200, Pierre-Charles David wrote:
> To my knowledge, this affects the following projects:
> * the platform via its usage of org.apache.batik.css, but I believe they 
> have been using the new version for a while without issue so no change 
> might be needed here.
> * GMF Runtime
> * Sirius
> * Papyrus
> * BIRT
> * Graphiti

The platform doesn't use as many of the Batik bundles so it's likely
they aren't affected. This is also why I've been insisting on not
changing any of the ones that are in use by platform.releng, so as to
reduce likelihood of introducing any new issues for them.

> I'll prepare versions of GMF Runtime and Sirius which revert to Batik 
> versions from Oxygen.3 as a contingency plan (still hoping for a 
> last-minute solution). Other projects might want to prepare for similar 
> reverts. Note that at this moment, all versions of Batik before 1.9.1 
> have been removed from the Orbit repo for Photon, so I'll need to "bring 
> back" the older versions from Oxygen.3's Orbit. Hope this is not agains 
> the SimRel rules.

I think this should be fine as I'm sure there are builds using older
version of Orbit repos. We generally want to use the builds made for
that release to avoid older bundles with same version (different
qualifier), but in this case the version of batik is different than the
newer one.


Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Batik 1.9.1 bundles available (for BIRT, Graphiti, TM4E)

[Roland Grunberg]

On Wed, 2018-04-18 at 16:42 -0400, Roland Grunberg wrote:
> From the discussion in the bug [2], GMF, Papyrus, and Sirius are likely
> to adopt the new version. Does BIRT, Graphiti, and TM4E intend to do so
> as well ? The hope was to eliminate 1.6 and 1.7 entirely but given how
> close this comes to M7, we might have to keep them in if adoption is
> not possible for all projects.

So after looking into the 2 remaining projects that haven't switched
yet to Batik 1.9.1, It doesn't seem like they would be harmed by the
removal of 1.6/1.7 from the Photon Orbit (active) build.

- TM4E only has an optional dependency to Batik 1.7 or higher. The
usage of Batik is limited to org.apache.batik.css.parser.Parser and
between 1.7 and 1.9.1, this class did not change API or make any major
modifications to that class.

- BIRT is still using the R20170307180635 (Neon.3) Orbit build and is
unlikely to switch for Photon.

As a result I'll be removing Batik 1.6 & 1.7 from the Orbit active
build. If anyone is opposed to such a move, or if issues arise, we can
easily undo the change.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Batik 1.9.1 bundles available (for BIRT, Graphiti, TM4E)

[Roland Grunberg]

As of Orbit's (upcoming) contribution to Photon M7, we should have the
full Batik stack we used to have for 1.6/1.7, and quite a few more
available in 1.9.1. For now, there's an I-build [1] that can be used to
test them out. From a look through the Photon release repository, it
seems like BIRT, GMF, Graphiti, Papyrus, Sirius, and TM4E all use the
older versions of Batik (1.6 or 1.7).

>From the discussion in the bug [2], GMF, Papyrus, and Sirius are likely
to adopt the new version. Does BIRT, Graphiti, and TM4E intend to do so
as well ? The hope was to eliminate 1.6 and 1.7 entirely but given how
close this comes to M7, we might have to keep them in if adoption is
not possible for all projects.


Cheers,
-- 
Roland Grunberg

[1] 
http://download.eclipse.org/tools/orbit/downloads/drops/I20180417184143/repository
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=522740
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problems with signed jars on deployed p2 repositories

[Roland Grunberg]

On Tue, 2018-04-10 at 15:35 +0200, Karsten Thoms wrote:
> And how could this be fixed? Do we have to sign again all jars? How do we 
> come to valid repositories again?
> 
> Do other projects have similar problems?

https://bugs.eclipse.org/bugs/attachment.cgi?id=273486 from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=533361 should show (all
?) affected jars.

Many are Orbit jars that that were listed would have to be re-signed.
They would need to be manually re-signed and the artifact repo updated
to reflect the changes.

Only other alternative on Orbit side would be to rebuild them with
identical metadata with the new recipes format but given the number
there are, it could take a while.

I'm also wondering what approach other projects on the list would take
for artifacts they no longer can re-build.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JUnit 5.1 For Photon

[Roland Grunberg]

On Thu, 2018-03-22 at 16:51 -0400, Roland Grunberg wrote:
> Hello,
> 
> The JDT project is planning to get JUnit 5.1 into Orbit, and remove the
> older JUnit 5. [1] Looking at the piggy-back CQs filed against the ATO
> CQ, Tycho could be affected, but they don't seem to have added support
> for JUnit 5 yet.
> 
> Is there any objection to the replacement of Junit 5, with JUnit 5.1
> for the Photon release ?
> 
> Cheers,

Looks like I mistakenly CC'd the cross-project-issues-dev-request
instead of to the list itself.

-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problem with webtools repo for Oxygen.2

[Roland Grunberg]

On Wed, 2017-11-15 at 18:27 +0100, Markus Knauer wrote:
> Thanks for taking care of it... I was investigating the same error because I 
> wasn't able to contribute RAP.
> 
> Can someone check that it isn't possible to push directly to the Git 
> repository without getting a build verification by Gerrit, and that this 
> setting is active for branches other than master?

Looking on Oxygen_update, I can see some recent commits that can't be
found on gerrit at all. A quick giveaway tends to be the lack of
Change-Id.

$ git log --invert-grep --grep="Change-Id" --grep="Merge"

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Confusing org.apache.batik versions

[Roland Grunberg]

On Wed, Sep 27, 2017 at 7:59 AM, Aleksandar Kurtakov
<akurt...@redhat.com> wrote:
> On Wed, Sep 27, 2017 at 1:48 PM, Ed Willink <e...@willink.me.uk> wrote:
>> I suspect that the inconsistent versions are the problem in both cases. Does
>> anyone know what is going on?
>
> Batik versions prior to 1.9 suffer from
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5662
> (batik-svg.jar) but removing part of batik release will raise more
> questions IMHO Orbit should drop all pre 1.9 in Photon stream.

This sounds fine to me. Sorry for the confusion. I'll have them removed
for Photon M3. It was simple enough to ask 1.8 be removed as part of
introducing 1.9 as it was the same project requesting/using the updated
version.

Cheers,
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

[Roland Grunberg]

On Fri, 2017-03-31 at 11:14 +0200, Ed Merks wrote:
> As another data point, if I install the egg-laying-wool-milk-pig for
> Neon.3.  The following happens.  I'm prompted to accept this license:
> Red Hat, Inc. licenses these features and plugins to you under
> certain open source licenses (or aggregations of such licenses),
> which in a particular case may include the Eclipse Public License,
> the GNU Lesser General Public License, and/or certain other open
> source licenses. For precise licensing details, consult the
> corresponding source code, or contact Red Hat, Attn: General Counsel,
> 100 East Davie St., Raleigh NC 27601 USA.
> I'm not sure how this license slipped into the release train.  
> Aren't there checks for this?  (Sorry to digress, but this is also
> unacceptable.)

It appears to be coming from http://git.eclipse.org/c/bpmn2-modeler/org
.eclipse.bpmn2-
modeler.git/log/features/org.eclipse.bpmn2.modeler.runtime.jboss/licens
e.html but I guess the point is if we ran even a basic install on the
content, this would have been caught much earlier.


> Orbit Issues
> 1) Respinning Linux Tools against Oxygen Mx seems to miss the point
> that we should only distribute released versions of bundles,  so no
> Neon build should redistribute any unreleased version of anything. 
> If a new version of something is needed for security reasons or other
> reasons, it should be released first.  And doing that in a
> maintenance train without testing the overall impact is clearly
> something we should never do again (without waving a bunch of red
> flags of warning).  And as Martin Oberhuber asks, is nothing in place
> to check for this?

I think this goes back to having proper branching to prevent things
that have problems (and meant for Oxygen) from getting into a stable
release and more thorough testing of how various plugins coexist when
installed. I could also make sure to be more explicit about where
certain milestone builds can and can't be used.

-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Neon.3 Update Problems

[Roland Grunberg]

On Thu, 2017-03-30 at 17:11 +0200, Ed Merks wrote:
> Hi,
> I'm concerned about the number of problems I see regarding updates to
> Neon.3.  For example, the missing MPC problem:
>   https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#ms
> g_1758538
> It looks just like the problem we've been having with Oxygen M5/M6.  
> That problem I believe traces back to a broken version of httpclient
> that worked its way into Oxygen M5: 
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=511333
> Rather than immediately fixing the problem and fixing M5, the problem
> was allowed to propagate; weird and bizarre things were done to
> modify downstream code to explicitly exclude the broken version:
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=511406
> Of course such upper bound constraints also explicitly exclude the
> new fixed version when it came along, so now it seems M6 is also
> broken, because of wiring issues:
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=513809
> I think the wiring issues arose to a large extent because of the
> things done during M5.  In my opinion what should have happened in M5
> is that the Orbit bundle was immediately fixed (or reverted to the
> older version) and M5 was respun to ensure that no broken version of
> httpclient ever propagated further into the echo system.  The last
> thing I would ever have expected (and I personally would have refused
> to do) is for downstream clients to make changes to explicitly
> exclude a broken version.  Please let's never do that again.  And
> please let's never behave as if the Eclipse Platform project's build
> can't be respun to fix problem.  Surely we can't have a policy in
> place where no matter the state of the platform's build, it must
> remain as is, broken Orbit bundles and all.

Agreed. I should have just let the M4 (this seems to be when the broken
httpclient 4.5.2 was first introduced) build slip and release later
rather than have something adopted that would cause more problems.
While we can provide guidance on what builds are safe to use or not, if
we can't fully control what ends up referenced, then we (particularly
myself) on the Orbit side need to do more to make sure our milestones
aren't harmful to begin with.

For future releases, we'll use separate branches so we can be a lot
more selective about what gets in. This wasn't currently in use as
there was no initial plan to release Orbit builds for Neon.3. However
as the contributions began to add up there were requests for a Neon.3
build containing some of the new bundles and the only things we could
reference were the Oxygen milestones.

> But what seems even worse, though I don't fully understand the
> problem, is how this broken orbit bundle
> id='org.apache.httpcomponents.httpclient' version='4.5.2.v20161115-
> 1643' got into the Neon release train repository.  Given all the
> problems it caused in Oxygen M5 surely we should have avoided that at
> all costs.  I suspect it came from this repository:
>   http://download.eclipse.org/linuxtools/update-neon-docker
> I say that because that repo contains the broken version of
> httpclient and the versions of the docker IUs in that repo are the
> same as the versions in the neon release train, so it seems to me the
> bundles from this repo were aggregated into Neon.
> So now the problems we have in Oxygen M5 and M6 are also problems for
> the users of Neon.3.  That makes me very sad.  Users expect update
> releases to be stable.  Surely we're doing something very wrong to
> get into a state where a bundle known to be problematic nevertheless
> works its way into the final stable update of the Neon...
> I don't know if the EGit update problems are at all related:
>   https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#ms
> g_1758538
> It definitely looks like a different problem, but
> org.slf4j.api_1.7.10.v20160921-1923 also comes from the update-neon-
> docker update site.  And that's not a version that's in http://downlo
> ad.eclipse.org/tools/orbit/downloads/latest-R, i.e., it appears not
> to be a released version.  So again, one has to wonder how this
> worked its way into Neon.3 causing update problems for Neon.3...

Yes, it looks like the update-neon-docker site was built based off of a
pre-M6 Orbit build. As Jeff suggested, a rebuild against Oxygen M6 on
Linuxtools' end can pick up the fixed httpclient so if re-doing
aggregation is possible, this should resolve issues with httpclient
that arose from the missing packages.

-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Works-with CQs with the new PMI

[Roland Grunberg]

On Mon, 2017-03-13 at 17:43 +0100, Jens Reimann wrote:
> Now this sounds like a noob question ...
> 
> ... but how do I create works-with CQs with the new PMI workflow?
> 
> It seems only possible to create a normal 3rd party dependency CQ. I
> don't see any more the option for a works-with/per-requisite
> dependency.

I went through this process a while back with 'vagrant', and 'docker-
machine'. As far as I understand, you file them as regular CQs but
state explicitly that this is a works-with/pre-requisite CQ. Then start
a discussion on tools-pmc where some basic questions about the request
may be asked (eg. how does the plugin handle absence of library, is the
library likely to be found on a user's system, etc.)

https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10263
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10209


Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] HIPPs residing on hipp3 not responding

[Roland Grunberg]

>From https://hudson.eclipse.org/, none of the projects that reside on
hipp3 seem to be responding. Is this a planned outage ? The only thing
I could find related to hipp3 is possible issues relating to disk space
usage from a while ago.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Unable to perform tasks from Developer Portal

[Roland Grunberg]

> Hi Roland
> 
> It works for me.
> 
> Dani

It seems to be working for me as well now.

Thanks,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Unable to perform tasks from Developer Portal

[Roland Grunberg]

I'm just wondering if anyone else is seeing this same behaviour.

- Go to http://portal.eclipse.org/ and log in
- Click on [view] for one of the projects on which you have commit rights

You'll continue to see the loading gif but the page will never load the
content into the Eclipse Projects panel.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Are we distributing software with known security issues?

[Roland Grunberg]

> Thanks for the pointer Roland. It seems there is also a Jenkins plugin. It
> would be nice if that could be made available.
> 
> https://wiki.jenkins-ci.org/display/JENKINS/OWASP+Dependency-Check+Plugin

Assuming the plugin system for Hudson and Jenkins haven't diverged dramatically
this might be possible (does anyone know ?). For Orbit, I may ask simply to be
able to place the commandline tool at some common location for HIPPS.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Remove Older Docker Stack (Jersey/Jackson/HK2/JNR) From New Builds

[Roland Grunberg]

As of Orbit's contribution to Oxygen M4 [1], a newer version of the
Docker Client Stack was added that contained the following versions :

Docker Client (Java) 3.6.8, Jersey 2.22.1, Jackson 2.6.2 and HK2 2.5.0.

The older stack, which is still part of every newer build contains the
following versions :

Docker Client (Java) 3.1.1, Jersey 2.14, Jackson 2.5.0, and HK2 2.4.0.

With the newer versions in place, I would like to remove the old stack from
future builds and encourage those who depend on it to migrate to the newer
versions. If there's any objections or concerns to this, please mention
them.

I hope to be making this change before the end of next week, so it will be
in for Oxygen M5. This would at least give us time to fix any issues or
making additional removals up until M6, which would be the deadline for
such changes.

To be clear, the older stack will continue to be available in builds
R20150519210750 to R20160520211859. We would never touch those. However as
per our retention policy [2], it would be great to clean things up going
forward. So if you continue to reference the older R-builds mentioned, you
won't be affected, but if you follow the latest N/I/S/(eventually R) builds
from Orbit for the bundles mentioned, you'll need to make sure your project
is compatible with the newer versions.

Specifically, the following bundles will be removed from future builds :

com.spotify.docker.client 3.1.1

Jersey 2.14
org.glassfish.jersey.apache.connector
org.glassfish.jersey.bundles.repackaged.jersey-guava
org.glassfish.jersey.core.jersey-client
org.glassfish.jersey.core.jersey-common
org.glassfish.jersey.media.jersey-media-json-jackson   

Jackson 2.5.0
com.fasterxml.jackson.core.jackson-annotations
com.fasterxml.jackson.core.jackson-core
com.fasterxml.jackson.core.jackson-databind
com.fasterxml.jackson.dataformat.jackson-dataformat-yaml
com.fasterxml.jackson.datatype.jackson-datatype-guava
com.fasterxml.jackson.jaxrs.jackson-jaxrs-base
com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider
com.fasterxml.jackson.module.jackson-module-jaxb-annotations

HK2 2.3.0
org.glassfish.hk2.api
org.glassfish.hk2.locator
org.glassfish.hk2.osgi-resource-locator
org.glassfish.hk2.utils

JNR
jnr.constants 0.8.6
jnr.enxio 0.6.0
jnr.ffi 2.0.1
jnr.posix 3.0.9
jnr.unixsocket 0.5.0
(Note that the only project to reference JNR Orbit CQs,
tools.linuxtools has already updated to the latest available version
of JNR bundles)

Cheers,
-- 
Roland Grunberg

[1] http://download.eclipse.org/tools/orbit/downloads/drops/S20161205183421/
[2] 
https://wiki.eclipse.org/Orbit/Promotion,_Release,_and_Retention_Policies#Bundle_Retention_in_active_builds
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Are we distributing software with known security issues?

[Roland Grunberg]

> "*Yes*, we are distributing software with known security issues", is the
> answer to the subject question.

So much for Betteridge's law :)


> To walk through one example, the article named org.apache.commons.fileupload
> version 1.2.1 as being often redistributed, even though known security issue
> (CVE-2014-0050). Versions 1.0 to 3.0 had the flaw, and 1.3.1 is required to
> avoid it. Version 1.3.2 is the most recent Apache version.
> 
> 
> That 'fileupload' package sounded familiar so I began to look around and I
> found that in the Platform's repository they are re-distributing version
> 1.2.2 of that package but (luckily?) in the Sim Release repo we have version
> 1.3.1. In the platform, it is Equinox's Http servlet bundle that has an
> optional prereq on "fileupload" and in Sim Release, it is RAP, apparently,
> that is "pulling in" version 1.3.1.
> 
> = = = = = =
> I call out this flaw in our release practices, here on cross-project list,
> for several reasons:
> 
> 1) I wanted to open a bug on the Platform and Equinox to update that prereq
> (bug 509388 ), but I see that "fileupload" Version 1.3.1 is not available
> from Orbit. *Why not?* That alone appears to be a Simultaneous Releases "no
> no".

I saw your post a while back and thought of
https://www.owasp.org/index.php/OWASP_Dependency_Check . It's available as a
maven-plugin so it should be pretty easy to run such a thing in a separate HIPP.
Seems like Orbit could benefit from such a report and maybe even as one of the
sanity checks done on platform ?

In fact, after running it on the Orbit bundles we ship, fileupload was one of
the high severity ones discovered. I see all of this (OWASP) has already been
suggested on 509389 so this seems like the right thing to do.


Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Git servers not working well?

[Roland Grunberg]

> Yes, I'm seeing the same thing on the linuxtools-gerrit instance. In
> fact even cloning from the commandline fails.
> 
> I'm no longer seeing 'connection reset by peer' now, but I am seeing :
> 'git.eclipse.org[0: 198.41.30.196]: errno=Connection refused'.

I've done a simple reboot of our HIPP and fetching against
git.eclipse.org seems to work. Not sure if the reboot had anything to
do with it, or if it was probably in the process of being fixed
anyways.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Git servers not working well?

[Roland Grunberg]

> Hi,
> 
> A lot of our Hudson builds have been failing with for example:
> Command "git fetch -t
> git://git.eclipse.org/gitroot/tracecompass/org.eclipse.tracecompass.git
> refs/changes/24/84124/2" returned status code 128: fatal: read error:
> Connection reset by peer

Yes, I'm seeing the same thing on the linuxtools-gerrit instance. In
fact even cloning from the commandline fails.

I'm no longer seeing 'connection reset by peer' now, but I am seeing :
'git.eclipse.org[0: 198.41.30.196]: errno=Connection refused'.

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Gerrit and Bugzilla down

[Roland Grunberg]

> Both Gerrit and Bugzilla respond with internal server error

I noticed this as well for Gerrit, a few minutes ago. It seems to be
back up for me (North America).

Cheers,
-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Can Orbit also host "p2-ified" OSGi bundles from Maven?

[Roland Grunberg]

> Hi all,
> Some OSGi bundles are existing on Maven, great. Tycho is able to consume them
> directly with the "pomDependencies=consider" option, great too.
> However, this pomDependencies=consider doesn't have an equivalent in PDE
> target-platform like p2 has. So it makes that using directly OSGi bundles
> from Maven make it tricky to provide a portable target platform definition
> (.target file).
> Do you think it would make sense for Orbit to also host those external
> bundles, without rebuilding them, and pusblish them as p2 artifacts? I'll
> probably need it soon for GSon 2.5.0.

So you want a p2 repository of artifacts directly from maven. If this is the
case then this seems like a special case of what might already happen with the
new orbit-recipes approach.

With the new orbit-recipes approach, we call ebr-maven-plugin to generate a
manifest for some artifact from maven. I think we do this in all cases, but
if a maven artifact already has its own OSGi metadata, then I don't think we
should be re-generating the metadata unless its clearly wrong.

However, we still need to sign the bundles and add about.html, as well as the
license under about_files/ so they wouldn't be completely untouched, but the
metadata could be left as is.

Another thing that's going to change about this new process is that instead of
grabbing the bundles directly from maven-central, Orbit committers will end up
uploading them to an Eclipse-hosted Maven repository [1]. This also handles 
cases
for content that isn't in maven central.


Cheers,
-- 
Roland Grunberg

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=484631
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] bugzilla down?

[Roland Grunberg]

 I am experiencing very slow response times / hangs accessing
 
 http://bugs.eclipse.org/
 
 Is it me or is bugzilla down?
 
 Jan

I seem to be experiencing the same.

-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] p2 repositories ... we can do better

[Roland Grunberg]

I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=373262 on the
p2.mirrorsURL issue and https://bugs.eclipse.org/bugs/show_bug.cgi?id=373445
for the p2.index proposal, at least for tracking these issues.

There's a rough draft on 373262 that attempts to implement the functionality.

-- 
Roland Grunberg
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev