Re: [cross-project-issues-dev] News feed working with Java 11

[Andreas Sewe]

Lars Vogel wrote:
> Just learned that code recommenders has been archived.
> https://github.com/eclipse-attic/recommenders So I guess my question
> has been answered.

Yes, the News Feed plug-in was developed (by me, when I was still
working for Codetrails) as part of the Code Recommenders project. It is,
however, completely independent and doesn't even share a "commons"
bundle with the rest of Code Recommenders.

It should thus be pretty easy to resurrect, perhaps as part of the E4
incubator. (FYI, the plug-in tries to use E4 APIs as much as possible,
but as it was my first foray into E4 territory, I am sure you will find
room for improvement. ;-)

So, Lars, feel free to take over if you have time and interest; the
codebase of the plug-in is not that big.

Best wishes,

Andreas

-- 
Dr. Andreas Sewe | s...@cqse.eu | +49 152 56342856
CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas



signature.asc
Description: OpenPGP digital signature
___
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] Simultaneous Release Participation

[Andreas Sewe]

Hi Wayne,

> After some churn, Eclipse Code Recommenders ended up in 2018-12, but is
> now marked as disabled. What is the participation status for this
> project in 2019-03?

I think Code Recommenders is currently lacking the manpower to join the
release train again. In fact, I'm afraid I will have to retire as a Code
Recommenders committer soon, as my day job doesn't leave me enough time
to work on Recommenders.

But maybe Marcel (Cc'ed), as project lead, can chime in.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature
___
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] Errors when running 2018-12 RC2 on Java 11

[Andreas Sewe]

Holger Voormann wrote:
> Eclipse Code Recommenders and the RSS News feature were removed in
> RC2 
> [5] (which IMHO is a big loss) also use the javax.xml.bind package
> (e. 
> g. here [6] without 'Import-Package: javax.xml.bind' [7]).

FYI, the Code Recommenders RSS News feature (not the rest of Code
Recommenders) uses the feed reader from Mylyn Commons, so if the bug
could be fixed upstream (i.e., in Mylyn) like you outlined, the News
Feed could be contributed again.

Best wishes,

Andreas
___
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] Withdrawing Code Recommenders from SimRel

[Andreas Sewe]

Hi Mat,

> Hi Andreas,
> 
> Is there a bug with a summary of the situation so far?

no, not yet. There's  detailing
my attempts to create a 2018-12 target platform and getting it to build
against Java 11, but I am no longer being paid to work on Code
Recommenders in my day job, so my time is limited now. :-(

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Withdrawing Code Recommenders from SimRel

[Andreas Sewe]

Wayne Beaton wrote:
> AFAICT, Eclipse Code Recommenders has been removed from the packages. I
> do, however, see references to what I think look like references to
> org.eclipse.recommenders.news.rcp bundle (optional) and extension point
> in a couple of plugin.xml and MANIFEST files. Should these be removed?

that is not necessary. The News Feed bundle is optional and unrelated to
the rest of Code Recommenders. Unfortunately, it is currently broken as
the Feed Parser in Mylyn broke [1] with Java 11 (JAXB being removed).
The feed declarations are still there to provide users who install the
plugin from the Marketplace automatically are subscribed to the
packages' feed.

> We're very late in the process. Staging for the final RC is currently in
> progress (the final build for RC2 starts at midnight EST). This feels
> like too significant a change to commit after the final RC.
> 
> I believe that we have three choices:
> 
> 1) Stay in 2018-12 and contribute new bits
> 2) Stay in 2018-12 and contribute the old bits
> 3) Drop out of 2018-12 and remove the old bits
> 
> I am I correct in assuming that the second option is actually invalid?

I don't have a running build right now (and can't work full-time on
this) so option 1 seems unlikely at this point; Java 11 simply broke to
many things in our build.

Under Java 11, option 2 logs several errors in the Error Log the first
time the user triggers content assist in a Java file. Thereafter, JDT
completion works as normal and Code Recommenders doesn't.

To ensure that Java users have a smooth out-of-the-box experience, I
personally would vote for option 3.

> I think that we need a final call (from the Project Lead) right now.

@Marcel: What's your take on this?

Hope this helps.

Andreas

[1] 

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Withdrawing Code Recommenders from SimRel

[Andreas Sewe]

Wayne Beaton wrote:
I believe that we have packages that include Eclipse Code Recommenders. 
We'll need to make sure that they adapt accordingly.


Yes, if I can't make the build work, I will prepare a change for the 
org.eclipse.epp.packages project that removes Code Recommenders from the 
packages that contain it.


Best wishes,

Andreas
--
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

___
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] Withdrawing Code Recommenders from SimRel

[Andreas Sewe]

Wayne Beaton wrote:

Starting when?

i.e. is Eclipse Code Recommenders still in for 2018-12?


not answering for the project lead, but just as a regular committer, who 
has ATM unfortunately very little time for maintenance work:


I would like to contribute to 2018-12 *if* I can get Code Recommenders 
to build against 2018-12 and Java 11 in time. But currently, I am moving 
from one built-time error message to another and don't know yet whether 
things settle in time for our simrel contribution. So personally, I 
can't make any promises.


Hope this helps,

Andreas
--
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

___
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] SimRel 2018-09 Release Candidate 1 (RC1) is available

[Andreas Sewe]

Hi,

> The 2018-09 RC1 update repository is now available from:
> 
> => http://download.eclipse.org/releases/2018-09/

do we have "Repo Reports from last successful CLEAN BUILD" available for
2018-09 builds as well? I couldn't find the link (or a CLEAN BUILD job)
at . The last reports are for
Photon.

Best wishes,

Andreas

-- 
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



signature.asc
Description: OpenPGP digital signature
___
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] [epp-dev] 2018-09 M3 EPP packages

[Andreas Sewe]

Hi Martin,

> When I download 2018-09-M3 JEE package for macOS and run it, I get massive 
> amounts of bundles being installed, but not resolved.
> Most of these things seem to go back to:
> 
> org.apache.lucene.queryparser_7.1.0.v20180828-2118
> 
> having issues to resolve a package import for “org.apache.lucene.document”.
> 
> Any idea what is going wrong here?

no, but it doesn't happen for the Java EPP package (checked using "ss |
grep INSTALLED" in the OSGi console), so that should help you narrow it
down somewhat.

At orbit-dev, we also have, so from the above qualifier it looks like
someone is not contributing the latest and greatest from Orbit.

> The following changes are new for RC1 since the M3 milestone :
> 
> 2b1f554 Bug 538365 - Add org.apache.lucene.queryparser 7.1.0.

Hope that helps.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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

[Andreas Sewe]

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
___
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

[Andreas Sewe]

Hi Ed,

> IMHO this means that Code Recommenders must withdraw from SimRel.
> 
> a) all SimRel contributions should use the latest Orbit version

yes, but the emphasis is on *should*.

> b) mismatch of Guava has been a long-running nightmare with Guava
> classes in APIs a known no-no causing projects that integrate diverse
> Guava contributions to fail with bad classes.

As I said last year on this list, the problems show up only if you
expose Guava in your external API and do not have uses constraints in
place. Once you do the latter, you won't see LinkageErrors or similar
problems. It does mean, however, that if your clients use Guava, then
they must use the same version as you. That's the price you have to pay
for using Guava (directly or indirectly) in your external API.

At any rate, the mere presence of another bundle (unless it does some
arcane reflection/class-loading hackery, which AFAICT Guava does not)
should never break your bundle unless your metadata (version ranges and
uses constraints) is not in order. That's the whole point of OSGi:
Different bundles can use different versions of the same library in the
same runtime.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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

[Andreas Sewe]

Nick Boldt wrote:
> Possible impacts:
> 
> As to Lucene removals:
> 
> * org.eclipse.recommenders.models 2.5.3 requires lucene.core 3.5

Again, we can't switch because we need to parse an Lucene 3.x index
downloaded from the model repository, which newer Lucene versions can't
parse anymore. Migration strategy would be to deploy both 3.x and 7.x
indexes to download.eclipse.org, but we don't have the resources to do
this for 2018-09.

> * o.e.epp.logging.aeri.feature requires lucene.analysis 6.1

Similar scenario than Code Recommenders (built by the same guys...).
Here, however, we may get rid of the index downloads, as we have (since
Oxygen.2) a REST API in place that does the queries on demand; under
normal circumstances, they won't be answered from the index anymore.

I'll see what I can do here.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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

[Andreas Sewe]

Hi Roland,

> 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.google.guava 15.0.0, 18.0.0 (use 21.0.0)

Code Recommenders still uses Guava 15 and can't switch without doing a
major release, as Guava classes like ImmutableList and Optional are
unfortunately part of our public API. Switching to a new major version
of Guava would hence mean forcing all our clients to also switch, which
may not be possible.

A major release, possibly moving from Guava Optional to Java 8 Optional
in our public APIs, would eliminate this problem for good, but we don't
have the resources to do that for 2018-09.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Code Recommenders participates in 2018-09

[Andreas Sewe]

Hi all,

Code Recommenders will participate in the 2018-09 SimRel, with offset
+3. The version contributed will be a 2.5.x bug fix release only [1].

Best wishes,

Andreas

[1]


-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Heads up: multiple HttpClient versions in simrel

[Andreas Sewe]

Hi,

> Looks like Code Recommenders also contributes 4.5.2.v20180410-1551 [1].

correction: We don't. Instead, we accidentally contribute
4.5.2.v20170210-0925 from [2], which takes Orbit's Oxygen.3 contribution
as input. Normally, that would have been a bug, but in this case
everything works out. :-)

So no need to do a respin on Code Recommender's behalf.

Best wishes,

Andreas

> [1]
> 

[2]



-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Heads up: multiple HttpClient versions in simrel

[Andreas Sewe]

Carsten Reckord wrote:
> I’ve dug around a bit (for details, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=535821), and the two
> versions are contributed by the Platform
> (org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925) and by JGit
> (org.apache.httpcomponents.httpclient_4.5.2.v20180410-1551 – this one is
> new in RC3). The newer HttpClient version was introduced in Orbit
> I20180417184143 to make it safely co-exist with commons.logging 1.2 and
> commons.codec 1.10, neither of which are currently found in the Simrel
> repository.
> 
> While the version contributed by JGit is the current one from the Orbit
> Photon repository, I think at this point the easiest and safest thing to
> do would be for JGit to go back to the old version to get a consistent
> state of the Simrel repo again. The alternative would be to update ECF
> with the new version, respin the platform, and get the Mylyn SDK to use
> the new version as well.
> 
> What do you think?

Looks like Code Recommenders also contributes 4.5.2.v20180410-1551 [1].
So JGit is not the only one.

Do we have to do another release/contribution, just with a different
o.a.h.httpclient version in the contributed repo? If so, are we sure
that Code Recommenders and JGit are the only two projects contributing
the newer version?

Best wishes,

Andreas

[1]



-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Deprecating the command line JAR signing service (aka /usr/bin/sign) - read if you use Buckminster

[Andreas Sewe]

Hi Sam,

> Actually, I am still not able to get this to work. It resolves the
> plugin now but it doesn't seem to do anything.
> 
> The documentation for eclipse-jarsigner is a bit lacking. I would assume
> that if you invoke the plugin from a pom, it will replace all .jar files
> in the directory containing that pom, and its subdirectories, with
> signed versions, but that doesn't seem to be happening.
> 
> How is it meant to work?

I had to resort to the Wayback Machine, but an old blog post I wrote
some years ago might help:

Explains signing plugins, features, and all things pack200.

Best wishes,

Andreas

-- 
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



signature.asc
Description: OpenPGP digital signature
___
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] Latest platform I-builds requiring Java 9?

[Andreas Sewe]

Hi Jonah,

> As far as I can tell this issue has re-appeared in Photon RC2, but
> with Java 10 this time:
> 
> 13:18:52 [ERROR] Cannot resolve target definition:
> 13:18:52 [ERROR]   Software being installed: org.eclipse.sdk.ide
> 4.8.0.I20180524-0900
> 13:18:52 [ERROR]   Missing requirement: org.eclipse.sdk.ide
> 4.8.0.I20180524-0900 requires 'config.a.jre.javase [10.0.0]' but it
> could not be found

I've also observed this with the switch to Photon RC2.

> I am using Tycho 1.1.0 release version, which earlier comments implies
> fixes the problem, but perhaps that was just for 9 and not future
> versions of Java.
> 
> Applying the fix recommended in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=530207#c1 worked for
> CDT. See 
> https://git.eclipse.org/r/#/c/123384/1/releng/org.eclipse.cdt.target/cdt.target
> for how I changed CDT.

Thanks for sharing this. Unfortunately, I couldn't get this to work for
me (also using Tycho 1.1.0):

  
  
  http://download.eclipse.org/eclipse/updates/4.8milestones/S-4.8RC2-201805240900/"/>

Besides me using 4.8milestones/S-4.8RC2-201805240900 rather than just
4.8milestones the only difference I see is that you use
@includeMode="planner", whereas I used @includeMode="slicer". Any idea
how to make this work for me as well?

BTW, did you already file a bug?

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] HTTPS connections to Eclipse Marketplace time out

[Andreas Sewe]

Andrey Loskutov wrote:
> I believe we have problems with our servers - I saw sporadic 503 bugzilla 
> errors today and also my daily SDK download says it will be done in 10 hours 
> :-(

You may be right.

The HTML of https://www.eclipse.org/downloads/ is decorated with with
"Unable to connect to the database server at this time" errors. So may
be some central piece of infrastructure that's dragging everything else
down.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] HTTPS connections to Eclipse Marketplace time out

[Andreas Sewe]

Hi,

I just noticed that marketplace.eclipse.org cannot be reached over HTTPS
(Time Out). HTTP works fine, though.

>> wget http://marketplace.eclipse.org/
> --2018-04-18 08:55:11--  http://marketplace.eclipse.org/
> Resolving marketplace.eclipse.org (marketplace.eclipse.org)... 198.41.30.197
> Connecting to marketplace.eclipse.org 
> (marketplace.eclipse.org)|198.41.30.197|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 106613 (104K) [text/html]
> Saving to: ‘index.html’
> 
> index.html   
> 100%[=>]
>  104,11K   163KB/sin 0,6s

> 2018-04-18 08:55:12 (163 KB/s) - ‘index.html’ saved [106613/106613]
> 
>> wget https://marketplace.eclipse.org/
> --2018-04-18 08:55:15--  https://marketplace.eclipse.org/
> Resolving marketplace.eclipse.org (marketplace.eclipse.org)... 198.41.30.197
> Connecting to marketplace.eclipse.org 
> (marketplace.eclipse.org)|198.41.30.197|:443... connected.

... takes forever.

Is anyone else seeing this?

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature
___
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] Building with Tycho against Platform M5 products requires some effort

[Andreas Sewe]

Hi all,

> As you may have seen on some other thread, build with latest release of
> Tycho with Platform M5 product (sdk, ide...) in target-platform can
> result in the following error:
> 
> [ERROR] Cannot resolve target definition:
> [ERROR]   Software being installed: org.eclipse.platform.ide
> 4.8.0.I20180122-2000
> [ERROR]   Missing requirement: org.eclipse.platform.ide
> 4.8.0.I20180122-2000 requires 'config.a.jre.javase [9.0.0]' but it could
> not be found
> 
> This would only affect you if you use the Platform *products* in your
> target-platform. It won't affect your build if it only references
> features or bundles directly, which are not the same way by the recent
> changes.

well, that's not entirely true. We don't reference platform products in
our build but use the target-platform-validation-plugin [1], whose
validate-target-platform goal apparently also stumbles over the missing
entries:

> [INFO] --- target-platform-validation-plugin:1.0.0:validate-target-platform 
> (validate-target-platform) @ photon ---
> [INFO] Validating 
> /Users/sewe/Documents/oomph/org.eclipse.recommenders/git/org.eclipse.recommenders/targets/photon/photon.target...
> [INFO] Fetching p2.index from 
> http://download.eclipse.org/eclipse/updates/4.8milestones/S-4.8M5-201801242000/
> [INFO] Adding repository 
> http://download.eclipse.org/eclipse/updates/4.8milestones/S-4.8M5-201801242000
> [INFO] Adding repository 
> http://download.eclipse.org/modeling/emf/emf/updates/2.14milestones
> [INFO] Fetching p2.index from 
> http://download.eclipse.org/tools/orbit/downloads/drops/S20180119201206/repository/
> [INFO] Fetching p2.index from 
> http://download.eclipse.org/tools/orbit/downloads/drops/S20180119201206/repository/
> [INFO] Adding repository 
> http://download.eclipse.org/tools/orbit/downloads/drops/S20180119201206/repository
> [INFO] Fetching p2.index from 
> http://download.eclipse.org/tools/orbit/downloads/drops2/S20180119201206/repository/
> [INFO] Fetching p2.index from 
> http://download.eclipse.org/tools/orbit/downloads/drops2/S20180119201206/repository/
> [ERROR] Cannot resolve target definition:
> [ERROR]   Problems resolving provisioning plan.:
> [ERROR]  Unable to satisfy dependency from org.eclipse.sdk.ide 
> 4.8.0.I20180124-2000 to config.a.jre.javase [9.0.0].
> [ERROR]  Unable to satisfy dependency from org.eclipse.sdk.ide 
> 4.8.0.I20180124-2000 to a.jre.javase [9.0.0].
> [ERROR] 
> [INFO] Failed, see Error log below
> [ERROR] Validation found errors in 1 .target files:
> Could not resolve content of photon.target

Alas, I couldn't get the workaround to work:

> So if you see this error, it requires some action:

> * you can use a workaround to explicitly add the (config.)a.jre.javase
> [9.0.0] units in your target platform. You can simply add these units in
> you .target file from the p2 repo of Eclipse Platform,

This is my .target file:

>  includeMode="slicer" includeSource="true" type="InstallableUnit">
> 
>  version="0.0.0"/>
> 
> 
> 
> 
>  location="http://download.eclipse.org/eclipse/updates/4.8milestones/S-4.8M5-201801242000/"/>
> 

What did work for me, however, is *not* changing the .target file but
adding an  of JavaSE-9 to the
target-platform-validation-plugin's  [2]. Unfortunately,
that option is not documented at all, so I am a little bit mystified why
this works.

Maybe some can enlighten me?

Best wishes,

Andreas

[1]

[2]


-- 
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



signature.asc
Description: OpenPGP digital signature
___
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] Eclipse Photon opt-in deadline is December 15.

[Andreas Sewe]

Hi Wayne,

> If your project is not listed, or is missing release information, please
> announce your intent soon. If you're dropping out let us know that as well.

I have created a preliminary Code Recommenders 2.6.0 release record.
Please link it from the participating projects list (as announced
earlier, we intent to participate in Photon, again at offset +3).

Best wishes,

Andreas

-- 
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



signature.asc
Description: OpenPGP digital signature
___
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] Potential problems with the EPP packages for Oxygen.1 RCs

[Andreas Sewe]

Hi cross-projects-issues-dev, hi epp-dev,

I am afraid we *may* have a problem with the EPP packages for Oxygen.1.

Here's the symptoms I have observed:

- There have been no Oxygen.1 RC1 EPP packages produced by [1]. While
RC1 is supposed to be "a warm-up RC" without acceptance testing [2], I
still feel packages should have been build (if not +1'ed by the package
testers like myself).

- Questions as to the whereabouts of Oxygen.1 RC1 on epp-dev have been
left unanswered [3].

- The nightly EPP build for the OXYGEN branch [1] has been failing
constantly for more than 8 days now.

- There is a bug [4] I discovered yesterday that prevents Gerrit changes
meant for the OXYGEN branch (three so far [5]) to be verified by Hudson.
My request to review a fix has so far been left unanswered [6].

Apologies if I overreacted, but since we are already in the RC
timeframe, I think its worth to speak up early.

And maybe Markus Knauer (in Cc) is listening and can diffuse my worries. ;-)

Best wishes,

Andreas

[1] 
[2] 
[3] 
[4] 
[5]

[6] 

-- 
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



signature.asc
Description: OpenPGP digital signature
___
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] Code Recommenders will participate in Photon (offset +3)

[Andreas Sewe]

Hi,

Code Recommenders will be participating in the Eclipse Photon
Simultaneous release with its usual offset of +3.

According to our current plans, we will contribute Code Recommenders
2.5.0 [1] (or rather some maintenance release thereof, as we hope to get
2.5.0 in for Oxygen.1 or Oxygen.2 already).

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



signature.asc
Description: OpenPGP digital signature
___
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] Nature autodiscovery broken! Blocker? - Was: [epp-dev] Oxygen RC4 EPP packages

[Andreas Sewe]

Hi all,

> the Oxygen RC4 packages are ready for testing at
>  
> https://hudson.eclipse.org/packaging/job/oxygen.epp-tycho-build/318/artifact/org.eclipse.epp.packages/archive/

while testing the RC4 Java package, I discovered an issue related to the
"nature autodiscovery" feature recently introduced (by the Eclipse
Marketplace Client?) that I consider a blocker for Oxygen (hence Cc'ing
to cross-projects).

Creating a new *Java* project with the Eclipse IDE for *Java* Developers
complains that it doesn't have support for the Java nature (which it
does) and that JDT needs to be installed (which already is). This is
obviously not a good first impression.

See Bug 518336 [1] for details.

Best wishes,

Andreas

[1] 

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Guava versions in Oxygen

[Andreas Sewe]

Zoltán Ujhelyi wrote:
> the VIATRA project is not ready to move to Guava 21, as we still use
> Java 7 as a minimum requirement, while Guava 21 requires Java 8. We
> are now in the process of figuring out whether we can set up
> dependency ranges and uses constraints in a way that we can work both
> with Guava 15 and 21 (even if both are installed); if everything
> works as we expect, we will not block moving Oxygen to Guava-only.

As the Code Recommenders project is in a similar situation (still
wanting to support Java 7 on Neon and earlier releases), here's an
important observation *if* you have Guava classes (Optional, Predicate,
and Immutable* are likely candidates) in your *public* API: Your clients
also have to increase their version range to one that at least
encompasses yours, as there is an uses constraint (whether declared or
not is immaterial).

This is a problem for Code Recommenders, which previously imported Guava
[15, 16) and had classes like Optional in its public API. Any client
using both Code Recommenders' API (and thus by extension Guava classes)
would now need to update their version range, as the Optional returned
by Code Recommenders may now be a "Guava 21" Optional. As clients may
call functionality from Guava that is not present in the whole [15, 22)
range, this may break them -- even if Code Recommenders internally uses
only Guava functionality that's been present in all of [15, 22).

Strictly speaking, Code Recommenders would have to increase its *major*
version (as we completely break our public API) if we were to adopt a
broader version range for Guava, as it is part of our public API. IMHO,
that's not something we should do do; it causes huge pain for our
clients and is otherwise totally unwarranted (we planned on a minor
release for Oxygen only [1]). I'm not sure that the planning council was
aware of these far-reaching effects when they issues their
recommendation for Guava 21.

Best wishes,

Andreas

[1]


-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] [eclipse.org-planning-council] Neon.3 update problem status

[Andreas Sewe]

Hi Fred,

> The corresponding EPP repository can be found here:
> 
> https://hudson.eclipse.org/packaging/job/neon.epp-tycho-build/599/artifact/org.eclipse.epp.packages/archive/repository/

as package maintainer, I did my usual round of tests with the Java EPP
package: AFAICT, the package works for me. :-)

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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 problem status

[Andreas Sewe]

Hi,

>> I'd like to run the Neon.3 respin next week, if possible. So please
>> provide test feedback!!
> 
> I’m / we are not able to run deeper tests for Code Recommenders until
> Tuesday (holidays). But we’ll report back on Tuesday morning CEST.

I've tested that Code Recommenders works in each of the steps in the
following scenarios:

- Neon.2 Java package --check for updates-> Neon.3 respin
  (works; keeps httpclient/core 4.3.x)

- Neon.2 Java package --check for updates-> Neon.3 --check for updates->
Neon.3 respin
  (works; keeps httpclient/core 4.3.x)

- Java EPP package build against origin/NEON with Neon.3 respin
repository (mvn clean verify -Pepp.package.java
-Declipse.simultaneous.release.repository="https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/4/artifact/aggregation/final;)
  (works; keeps httpclient/core 4.3.x

So, from Code Recommenders' side all is good for a Neon.3 respin.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> Great, you sound like an expert who has demonstrated a solution.
> 
> Can you contribute a wiki page on how you do it?

I'll try, although the PDE tooling isn't that great [1, 2]. IMHO, bnd is
far better at automatically identifying uses constraints (although you
can still cheat it by using reflection), but most Eclipse projects use
Tycho and manifest-first builds, so I guess that's what the Wiki page
should focus on.

FYI, if you don't mind (and the OCL Oomph setup is up-to-date) I may use
OCL as a running example.

> Can you identify what checks a SimRel report should do to detect
> projects that are doing it wrong?

I agree, reports would be great. I am not aware of any tooling for this,
though. The maven-bundle-plugin focuses on *generating* MANIFEST.MFs
with uses constraints rather than checking the uses constraints of
existing MANIFEST.MFs. Also, I don't think PDE has a tool that could
easily be turned in a manifest checker. :-(

Best wishes,

Andreas

[1] 
[2] 
[3] 

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Andreas Sewe]

Hi,

> If you have a technical solution that allows multiple Guava versions to
> co-exist, please add it to Bug 437107. My current understanding is that
> "uses" directives may be a solution but that no demonstration has been
> performed and so the requirements for tooling are at best guesses and of
> course not yet implemented. It is unlikleyt that any project currently
> complies with any potential "uses" solution.

not true. Code Recommenders has exported interfaces [1] which have Guava
classes in their public signature. However, Code Recommenders [2]
properly declares these uses constraints and has not seen a major
problem since we introduced this in 2013(!).

Yes, if consumers of the org.eclipse.recommenders.models API also want
to use Guava for other purpose, then they are restricted in their choice
of Guava versions by what org.eclipse.recommenders.models uses but
that's how OSGi works.

This is IMHO a small price to pay for generally being able to have two
versions of the same bundle in your runtime. No more "one classpath to
rule them all", which *might* work in the closely coordinated
simultaneous release (although based on [3] I doubt it), but certainly
not once third-party plug-ins come into play.

Best wishes,

Andreas

[1]

[2]

[3]


-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> Please read the
> Bugzillas. https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107

Reading through Bug 427862 comment 8 ff. [1], it seems like OSGi's uses
constraints would solve your problem.

> The problem never occurs for individual projects. It only occurs when an
> integrating project 'inherits' conflicting Guava loads from two distinct
> component projects with Guava in the APIs.
> 
> So Mylyn only is no problem, but something that integrates Mylyn and
> Xtext can encounter obscure failures when the wrong class is re-used on
> a code path in which both are used.
I had a *brief* look at the Papyrus (RT) code and I think I know why you
continue to have problems with Guava:

1.) A bundle like org.eclipse.papyrusrt.umlrt.core requires
com.google.guava, but only provides a lower version bound [2]:

> Require-Bundle: com.google.guava;bundle-version="11.0.0"

This is dangerous, as Guava may change API in incompatible ways between
major versions (and has done so in the past).

2.) Your bundles export packages [3] whose classes have Guava classes in
their public API [4]:

> Export-Package: org.eclipse.papyrus.infra.core.resource

> Optional isReadOnly(...)

The above package should clearly have a uses constraints:

> Export-Package:
org.eclipse.papyrus.infra.core.resource;uses:="com.google.common.base"

Have a look at this article [5] that nicely explains "What is a Uses
Constraint Anyway".

Hope this helps,

Andreas

[1] 
[2]

[3]

[4]

[5] 

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Guava 15/21 warning

[Andreas Sewe]

Hi Ed,

> We have been using Guava 15 for some time.
> 
> The latest Mylyn snapshot (mylyn-3.22.0.v20170308-0427.zip) has moved to
> Guava 21.
> 
> When we changed to Guava 15 for Luna, it was all rather painful:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862

can you please point me to a bug (or better yet, an individual comment
in a bug) that clearly lays out a problem that is *not* due to too lax
version constraints or missing uses directives on the bundle importing
Guava.

I've used the latest Mylyn build (using Guava 21) and Code Recommenders
(using Guava 15) without problems in the same Eclipse instance, so
whatever the problem you perceive is, it doesn't cause things to blow up
straight-away. Hence, I would appreciate a pointer to the evils that
Guava does (presumably using reflection). Thank you.

Best wishes.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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? (Internal Server Error)

[Andreas Sewe]

Denis Roy wrote:
> Actually, it's 4:32 am:)

Still, thank you!

> A SELECT query against the downloads database created a deadlock tying
> up all our db connections.
> 
> I'm looking into why that happened.

There's nothing like a good puzzle to boot your brain early in the morning.

Anyhow, I'm off to report a few IDE crashes now. :-)

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Bugzilla down? (Internal Server Error)

[Andreas Sewe]

Hi,

Bugzilla seems to be down for me; I get an Internal Server Error. Is
anyone else seeing this problem?

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] repo.eclipse.org down?

[Andreas Sewe]

Hi,

repo.eclipse.org seems to be down again; our Hudson jobs have slowed
down to a crawl because of timeouts accessing it:

> [WARNING] Could not transfer metadata 
> org.antlr:antlr-runtime/maven-metadata.xml from/to eclipse-cbi-releases 
> (https://repo.eclipse.org/content/groups/cbi/): Connect to 
> repo.eclipse.org:443 [repo.eclipse.org/198.41.30.233] failed: Connection 
> timed out

Could someone please restart it? Thank you.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Does anyone know an HttpCacheStorage implementation available in Orbit?

[Andreas Sewe]

Hi fellow Eclipse committers,

we at the Automated Error Reporting project are currently trying to make
the client more RESTful. In particular, we want to implement support for
HTTP's Cache-Control header.

Now, Apache HttpComponents offers a CachingHttpClientBuilder [1], which
produces a drop-in replacement of the normal HttpClient that we
currently use, but with full, spec-compliant Cache-Control handling.
Unfortunately, our use case requires a persistent HttpCacheStorage
storage backend [2].

While there exists, e.g., an Ehcache-based backend, AFAICT none of the
backends has its necessary dependencies in Orbit.

But maybe I am mistaken or some other project has already developed
their own HttpCacheStorage that we should know about. Is so, please tell us.

Best wishes,

Andreas

[1]

[2]


-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] setting mirror URL in the p2 repository

[Andreas Sewe]

Hi Lorenzo,

> as suggested here https://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL
> we set the mirror property in our artifacts.jar when releasing.
> 
> We do that by using org.eclipse.wtp.releng.tools.addRepoProperties
> as done in other projects, e.g., 
> https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/repositories/pom.xml
>
>  this has worked up to now, but after we moved to tycho 0.25, which
> also generates the .xml.xz zipped version, we noted that the mirror
> property is not set in the artifacts.xml.xz (but only in
> artifacts.jar).
> 
> Would mirroring still work?

No, if you follow our template (I wrote the Code Recommenders pom.xml)
then mirroring will not work when the client downloads the
artifacts.xml.xz. This is Code Recommenders' Bug 497546 [1].

Now, for us fixing this has rather low priority, as not many people
download Code Recommenders from its update site, now that it is included
out-of-the-box in many EPP packages. But your mileage may vary, of course.

For you I see 3 ways out:

1. Disable XZ compresison in the tycho-p2-repository-plugin and compress
in a separate step, after the tycho-eclipserun-plugin with
rg.eclipse.wtp.releng.tools.addRepoProperties has finished. Maybe the
truezip-maven-plugin [3] or a similar plugin can help here.

2. Push for Tycho Bug 341744 [4] being fixed in such a way that it does
not only support p2.statsURI but also p2.mirrorsURL.

3. Do not set the p2.mirrorsURL in the Tycho build at all, but only when
promoting it to its final resting place. See Bug 498360 [5].

Option 1 certainly requires the most work, but has the advantage that it
just might work right *now*. In the long run, however, I think option 3
is preferable. The build should *not* need to know where the repository
bits will be offered for download, in particular as this may change over
time, e.g., if you move things from download.eclipse.org to
archive.eclipse.org.

Hope that helps.

Andreas

[1] 
[2]

[3] 
[4] 
[5] 

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Update your desktop versions of "cbi aggregator" (aka b3 aggregator)

[Andreas Sewe]

Hi Eike,

> Can you provide me with a patch or Gerrit review for the changes you
> have in mind? It's all declared in this file:
> http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/interim/SimultaneousReleaseTrain.setup

done:

  
  

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Update your desktop versions of "cbi aggregator" (aka b3 aggregator)

[Andreas Sewe]

Hi David,

> Sorry, I gave wrong URL. The latest build is at:
> 
> http://download.eclipse.org/cbi/updates/aggregator/ide/4.5/I20161027-1601/

will this URL make it into the "Simultaneous Release Train" Oomph setup
file? ATM, it still refer to org.eclipse.b3.aggregator.editor.feature
from .

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Upgrading HIPPs to SLES12 (Part 2 - reloaded)

[Andreas Sewe]

Markus Keller wrote:
> It should work out of the box, see 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=387721 Hudson users
> should not have to start their own window managers
> 
> But a centrally-managed workaround script would already be better
> than nothing.

Yes, in particular as the naive change (executing "icewm &") causes
Hudson to complain about leaked file descriptors:

  Process leaked file descriptors. See
http://wiki.hudson-ci.org/display/HUDSON/Spawning+processes+from+build
for more information

Any idea what I need to do to avoid this?

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Upgrading HIPPs to SLES12 (Part 2 - reloaded)

[Andreas Sewe]

Frederic Gurr wrote:
> PLEASE NOTE: all projects that are using UI tests need to adjust
> their scripts to use "icewm" instead of "metacity" as window
> manager.

Is it worth to have a central start-window-manager script that everyone
could use (and which would right now start icewm)? Kind of like the
apache-maven-latest or jdk-1.8.0-latest aliases that are also centrally
administered.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Upgrading HIPPs to SLES12 (Part 2 - reloaded)

[Andreas Sewe]

Frederic Gurr wrote:
> I've started the recommenders HIPP for you.

Thank you.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Upgrading HIPPs to SLES12 (Part 2 - reloaded)

[Andreas Sewe]

Hi,

> We are currently restoring the jobs data, once that's
> finished(~2hours) you should be able to restart your instance and run
> builds as normal.

is it safe now to restart the recommenders HIPP?

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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

[Andreas Sewe]

On 22.09.16 15:55, Matthias Sohn wrote:
> Both Gerrit and Bugzilla respond with internal server error

Both work for me from our office in Darmstadt, Germany.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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



signature.asc
Description: OpenPGP digital signature
___
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] Eclipse Neon Looks Strange and Misbehaves

[Andreas Sewe]

Hi,

> One exception of them occurs for all packages.  Why is this file
> expected to exist at this location?
> 
> java.io.FileNotFoundException:
> D:\sandbox\USER-HOME\jee-latest\eclipse\introData.xml (The system cannot
> find the file specified)

FYI, this is tracked in Bug 487713 [1], which hasn't seen much activity,
however, beyond an initial analysis by Markus.

Best wishes,

Andreas

[1] 

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] A funny thing happened on the way to Mars.2 -- in Orbit

[Andreas Sewe]

Hi,

David M Williams wrote:
> But since there is a "bad" one out there (in Orbit, at least) with the
> same version, I was suggesting to verify if it was in your project
> repositories to make sure you had the good one.
> 
> If it is the good one, you get "jar verified" as above.
> 
> If it is "the bad one" it will be pretty obvious:
> 
> $ jarsigner -verify
> org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar
> jarsigner: java.lang.SecurityException: SHA1 digest error for
> org/apache/http/client/cache/HttpCacheEntry.class

FWIW, I just found out that only the plain JAR in Orbit is "bad"; the
JAR.pack.gz is not, i.e., it unpack200s to a JAR that verifies just fine
[1]. If your build prefers pack200ed JARs over plain JARs, you should
get a "good" JAR from Orbit, but of course it's better to double-check
what you are distributing exactly.

Best wishes,

Andreas

[1] 

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] JDK 9 Early Access with Project Jigsaw

[Andreas Sewe]

Wayne Beaton wrote:
> Include "-jdkinternals" in your invocation.
> 
> e.g.
> 
>  for i in /c/develop/oomph/git/org.eclipse.oomph/plugins/*/bin; do jdeps
> -jdkinternals $i; done >> deps.txt
> 
> Note that jdeps is included in Java 8 as well, so you may need to give
> it a complete path to the executable to get the up-to-date version from
> Java 9.

If your build uses Tycho, you can also try the following:

mvn install jdeps:jdkinternals

I found the output quite easy to digest.

FYI, the "install" phase in the above is necessary as the
"jdeps:jdkinternals" goal apparently tries to obtain your projects'
dependencies from there, even if they are build in the same reactor (no
"workspace resolution").

Also, you may want to switch to a Java 9 toolchain, if your build runs
with an older version of Java. See for more infos. [1].

Hope that helps,

Andreas

[1] 

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Andreas Sewe]

On 21.10.15 16:01, David M Williams wrote:
> Just today I realized I think I was supposed to "disable" everyone,
> until they responded affirmatively that they were participating in Neon.
> 
> Since so many have declared their intent already, I hate to start over,
> by disabling everyone, but, need to come up with a list of "those who
> have declared intent",
> and then I will disable the rest.

Quoting Marcel, who stated this back in August:

>> Code Recommenders will participate with version 2.3.x.
> 
> offset +3

That's still true.

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Proxy Testing Tool?

[Andreas Sewe]

Hi all,

a bit more info.

To analyze the proxy issues plaguing Code Recommenders and the Automated
Error Reporting, we have included a network communication test job in
earlier RCs that just pinged a stats URI at download.eclipse.org using
both Apache HttpComponents or ECF (through p2's
RepositoryTransport.getLastModified(..)).

If anyone is interested, here's the code [1]. You can view the collected
data at [2] using a partial file name of
/stats/recommenders/network-communication-test/.

This yields results like the following:

 /stats/recommenders/network-communication-test/apache/java-1.8.0_45/Windows+7-6.1/Native-none/
 746
 /stats/recommenders/network-communication-test/p2/java-1.8.0_45/Windows+7-6.1/Native-none/
 737

The stats URLs encode the platform, Java version, whether Eclipse was
configured with Native, Manual or Direct proxy settings (General 
Network Communication) and which authentication method (if any) was
mandated by the Proxy-Authenticate header.

In the above, you can see that a Windows 7 configuration using the
Native provider and no authentication method (none) pinged 746 over
Apache HttpComponents and 737 over p2. This *may* mean that p2 had 6
times trouble communicating where plain HttpComponents had not.

Most of the time, the situation is the other way around, however. Here's
a diff of the results, in case anyone can spot a pattern.

In these configuration, we don't see Apache at all:

 java-1.7.0/Windows+7-6.1/Native-NTLM;Basic/   p2  4
 java-1.7.0_60/Windows+7-6.1/Native-unknown/   p2  1
 java-1.7.0_21/Windows+7-6.1/Manual-NEGOTIATE;NTLM;BASIC/  p2  1
 java-1.7.0_67/Windows+7-6.1/Manual-NTLM;BASIC/p2  1
 java-1.7.0_71/Windows+7-6.1/Manual-Basic/ p2  3
 java-1.7.0_72/Windows+8.1-6.3/Native-none/p2  1
 java-1.7.0_79/Windows+7-6.1/Manual-Basic/ p2  6
 java-1.7.0_75/Windows+XP-5.1/Manual-NEGOTIATE;NTLM;BASIC/ p2  1
 java-1.7.0_80/Windows+7-6.1/Manual-NTLM;BASIC/p2  3
 java-1.7.0_79/Windows+7-6.1/Native-unknown/   p2  1
 java-1.7.0_79/Windows+8.1-6.3/Native-unknown/ p2  1
 java-1.7.0_80/Windows+8-6.2/Native-unknown/   p2  1
 java-1.8.0_05/Windows+7-6.1/Manual-BASIC/ p2  3
 java-1.8.0_05/Windows+7-6.1/Manual-Negotiate;NTLM;Basic/  p2  1
 java-1.8.0_31/Mac+OS+X-10.10.3/Direct-unknown/p2  1
 java-1.8.0_31/Windows+7-6.1/Manual-NTLM;Basic/p2  4
 java-1.8.0_31/Windows+7-6.1/Manual-Negotiate;Kerberos;NTLM;Basic/ p2  
 2
 java-1.8.0_31/Windows+7-6.1/Native-Negotiate;Kerberos;NTLM/   p2  1
 java-1.8.0_45/Mac+OS+X-10.10.3/Direct-unknown/p2  3
 java-1.8.0_45/Windows+7-6.1/Manual-Basic/ p2  7
 java-1.8.0_45/Windows+7-6.1/Manual-Negotiate;Basic/   p2  2

Here, we don't see p2 at all:

 java-1.7.0_51/Linux-3.13.0-24-generic/Native-unknown/ apache  1
 java-1.8.0_31/Linux-3.5.0-54-generic/Native-none/ apache  1
 java-1.8.0_31/Windows+7-6.1/Native-unknown/   apache  1

In these configurations, we see small differences (which *may* be
explained by a cache somewhere):

 java-1.7.0_11/Windows+7-6.1/Native-none/  apache  7
 java-1.7.0_11/Windows+7-6.1/Native-none/  p2  8

 java-1.7.0_15/Mac+OS+X-10.10.3/Manual-none/   apache  5
 java-1.7.0_15/Mac+OS+X-10.10.3/Manual-none/   p2  4

 java-1.7.0_45/Linux-3.13.0-53-generic/Native-none/apache  5
 java-1.7.0_45/Linux-3.13.0-53-generic/Native-none/p2  4

 java-1.7.0_51/Linux-3.13.0-24-generic/Native-none/apache  22
 java-1.7.0_51/Linux-3.13.0-24-generic/Native-none/p2  21

 java-1.7.0_75/Linux-2.6.32-504.16.2.el6.x86_64/Native-none/   apache  5
 java-1.7.0_75/Linux-2.6.32-504.16.2.el6.x86_64/Native-none/   p2  4

 java-1.7.0_79/Windows+7-6.1/Native-none/  apache  71
 java-1.7.0_79/Windows+7-6.1/Native-none/  p2  70

 java-1.8.0_05/Windows+8-6.2/Native-none/  apache  3
 java-1.8.0_05/Windows+8-6.2/Native-none/  p2  2

 java-1.8.0_20/Windows+7-6.1/Native-unknown/   apache  3
 java-1.8.0_20/Windows+7-6.1/Native-unknown/   p2  2

 java-1.8.0_20/Windows+8-6.2/Native-none/  apache  7
 java-1.8.0_20/Windows+8-6.2/Native-none/  p2  6

 java-1.8.0_25/Windows+7-6.1/Native-none/  apache  78
 java-1.8.0_25/Windows+7-6.1/Native-none/  p2  77

 java-1.8.0_31/Windows+7-6.1/Native-none/  apache  127
 java-1.8.0_31/Windows+7-6.1/Native-none/  p2  128

 java-1.8.0_40/Mac+OS+X-10.9.5/Direct-none/apache  11
 java-1.8.0_40/Mac+OS+X-10.9.5/Direct-none/p2  10

 java-1.8.0_40/Windows+7-6.1/Manual-BASIC/ apache  1
 java-1.8.0_40/Windows+7-6.1/Manual-BASIC/ p2  4

 java-1.8.0_40/Windows+7-6.1/Native-none/  apache  131
 java-1.8.0_40/Windows+7-6.1/Native-none/  p2  129

 java-1.8.0_40/Windows+7-6.1/Native-unknown/   apache  1
 java-1.8.0_40/Windows+7-6.1/Native-unknown/   p2  2

 java-1.8.0_45/Linux-3.16.0-38-generic/Native-none/apache  19
 

Re: [cross-project-issues-dev] Proxy Testing Tool?

[Andreas Sewe]

Hi Scott,

 For everyone's info, there's been a long discussion of what appear to be
 HttpComponents-based proxy difficulties on this bug
 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=422665

yes, I am aware of that discussion. AFAIK, we never arrived at real test
scenarios, though, which allowed us to open upstream bug, for example.

 ECF (used for p2) has the ability to disable the default
 HttpComponents-based provider and use an JRE URLConnection-based
 provider, which under some proxy use cases and configurations appears to
 work:
 
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=422665#c137
 
 This comment references the documentation to disable the
 HttpComponents-based provider.
 
 https://wiki.eclipse.org/Disabling_Apache_Httpclient
 
 I'm not sure what Code Recommenders and the Automated Error Reporting
 uses of ECF/p2, but if it uses what p2 uses then it also will inherit
 the multi-provider support described above.

Code Recommenders and the Automated Error Reporting use HttpComponents
internally, either directly or through Eclipse Aether (in Code
Recommenders' case).

We use ECF *only* for our communication test, as we got the impression
that ECF is sometimes more successfully in traversing proxies. Our
communication test now uses ECF and HttpComponents and calls home on
*both* channels. If one or both messages get through, we have a data point.

Now, the question is how to interpret these data points. Unfortunately,
it doesn't look like we can make blanket statements like NTLM never
works. It's rather it depends. The question is just on what?

 From the ECF point of view, if anyone is able/willing to do proxy
 testing, and suggest, implement, and test changes or other workarounds
 to ECF, then contributions are welcome.  I can't speak or act for the
 Apache HttpComponents project, however.

I don't thing we have reached the provide a patch stage just yet; we
are still at the pinpoint the problem stage. If anyone can make of the
data more than I can, any pointers would be greatly appreciated.

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Frequent timeouts for download.eclipse.org

[Andreas Sewe]

Hi all,

does anyone else notice frequent timeouts for download.eclipse.org? Both
we at our office and our HIPP instance have trouble fetching stuff from
p2 update sites hosted on download.eclipse.org. :-(

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Frequent timeouts for download.eclipse.org

[Andreas Sewe]

Hi again,

 does anyone else notice frequent timeouts for download.eclipse.org? Both
 we at our office and our HIPP instance have trouble fetching stuff from
 p2 update sites hosted on download.eclipse.org. :-(

whatever the problem was, the server seems to have recovered now. :-)

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Frequent timeouts for download.eclipse.org

[Andreas Sewe]

On 08.06.15 13:32, Denis Roy wrote:
 For some reason, the build server seems to be pushing a lot of traffic..
 we'll look into it.

Thanks, Denis.

Speaking of which, on our HIPP we use -Dtycho.disableP2Mirrors=true so
not to cause outbound traffic. Of course, that means that all requests
go through download.eclipse.org. Is this a problem -- or do you know any
way to switch this from http: to file: transfers without having
different target platforms for HIPP and elsewhere, respectively?

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Is it time to update to Guava 18?

[Andreas Sewe]

Hi Ed, hi Wayne,

 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107

in that bug report I frankly miss a clear analysis as to *why* different
Guava bundles are a problem.

Agreed, incorrect metadata is always a problem in OSGi, such as bundles
exporting com.google.common packages without versions or uses
directives, but at least from Orbit's Guava 12 on this is no longer the
case. This does not prevent non-Eclipse projects from publishing another
Guava bundle with incorrect metadata, of course -- but any
Eclipse-internal policy won't stop them either.

 The Luna experience was that in the absence of tooling, all projects
 MUST use the same Guava, which should be the latest in Orbit.
 
 Mixed Guava is a disaster. So far nobody seems to have moved for Mars.

I just ran a quick test for Eclipse Code Recommenders to assess the
number of API changes in Guava between version 15 and 18 that would
affect our codebase.

Luckily, the list is very short:

- Files.newInputStreamSupplier(File) gone in Guava 18.0

Of course, you would still need to verify that the *behavior* of the
remaining API didn't change. Just because it compiles doesn't mean it works.

FWIW, if other projects want to do this kind of quick-and-dirty check
(Does it still compile?), it's surprisingly easy with Tycho:

- Use pomDependencies=consider in your target-platform-configuration [1]
- Add a POM dependency to com.google.guava:guava:18.0 (the artifact in
  Maven central has proper OSGi headers)
- Use seasrch-and-replace to update your Import-Package and Require-
  Bundle headers
- Run mvn clean install on the projects in question, possible
  building them one by one with -pl :artifactId, as earlier compile
  errors will prevent latter modules from being build at all

Hope this helps others to get a lower bound on the cost that such a
change would impose on their projects.

 If we are to move, I think we should all aim to move in I-builds
 immediately following M6.
 
 There may be a maintenance issue. e.g. Xtext 2.8.0 is out,so moving to
 Guava 18 might force a 2.9.0.
 
 I feel that barely a day before M6 is too late to request this.

Wayne Beaton wrote:
 More generally, I think that we need a policy for these widely-shared
 libraries. Intuitively, it makes sense to me that we should try to use
 the most recent version released in Orbit with the simultaneous release.

 Thoughts?

The big problem with this policy is that it forces projects to maintain
branches for Luna (using the Guava 15 API) and Mars (using the Guava 18
API). Moreover, it forces users to pick the right update site, e.g.,
updates/luna/stable vs. just updates/stable.

Now, Code Recommenders did maintain a branch before (to account for some
changes to the JDT APIs with Kepler, IIRC) and offered special fragments
for Juno and later versions, respectively, but it complicated our build
and testing quite a bit. Of course, integration with JDT is arguably
core to Code Recommenders, so here branching was indeed a necessity.

For a library, however, which supplies only trivial stuff like
Optional and Multimaps, I would like to avoid the maintenance overhead
of branches or fragments *unless* someone can clearly demonstrate and
explain why it is absolutely necessary. IMHO, the discussion in Bug
437107 has so far failed to do that.

Just my 2 cents.

Andreas

[1]
http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Is it time to update to Guava 18?

[Andreas Sewe]

Hi Ed,

 The analysis is indeed unclear because nobody has invested the time to
 debug the problem or solution.
 
 My best theory seems to be all that there is:
 
 The problem seems to arise for a project that integrates the Guava-based
 facilities of A and the Guava-based facilities of B, and when a Guava
 type reference/object from the A domain is checked in the B domain. The
 class loader appears to be able to make a Guava version choice for A
 without regard to B. This does not affect B which may happily use a
 different version Guava. The problem arises when an A-Guava type is
 checked by B. NB the precise meaning of 'checked by' is not clear to me.

The precise meaning is specified here [1], but precise unfortunately
doesn't imply comprehensible. ;-)

That being said, I share your analysis that problems may occur whenever
a bundle C is wired to both bundles A and B which *expose* different
versions of Guava in their public API to C.

There are essentially two cases:

1) If A (wired to Guava version X) and B (wired to version Y) properly
declare uses constraints, then C will silently fail to resolve.

2) If A or B doesn't declare uses constraints, then C will fail at
runtime with a LinkageError or similar, as per [1].

There's also a variant of 1 where a solution to the constraint problem
does exist which would make C resolve, but Equinox will not find it and
needs a -clean. See [2] for an example of this and [3] for a workaround.

 The hopeful solution is that if both A and B have 'uses' directives,
 then the class loader no longer has the ability to make an incompatible
 Guava choices for A and B.
 
 So product teams for A and for B have no problem. It is the user of an
 integration of A and B who may suffer according to some unpredictable
 run-time class loading choices influenced by the number of Guava
 versions available on the classpath(s).

Well, if A and B require incompatible versions X and Y of Guava *and*
expose them in their API, then the developer of the integration C is to
blame.

If, however, A and B require compatible version (ranges) of Guava, then
[2] may occur, where an earlier wiring decision (wire A to version X and
B to version Y) will not be undone (*rewire* A and B to the same
version) and thus present a newly arrived bundle C from being resolved.

 Luna pre-RC4 nightmare: just look at the number of troublesome bug
 reports as Xtext/Acceleo/Code Recommenders/Mylyn interacted with 11,12,15
 
 Luna RC4 fudge: only one version of Guava to make an unpredictable
 choice from.
 
 Mars nightmare: someone introduces a second Guava version.

Possibly, but being open to third-party plugins, we cannot prevent the
presence of multiple Guava versions in general.

Anyway, I think the burden is on the developers of integration bundles
C. You *can* shield yourself from this problem (A and B both exposing
Guava in their API) to wrap one of them into facade that does not expose
Guava in its API.

  +-- A (exposes X) -- X
 /
C
 \
  +-- B' -- B (exposes Y) -- Y

That way, A and B can be wired to different versions of Guava (X and Y,
respectively) but C can still make use of them both.

Granted, this is cumbersome, but (given the way OSGi and Equinox work)
the only solution that is will work in an open ecosystem where *anyone*
may supply another Guava bundle.

Best wishes,

Andreas

[1]
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.3.4
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=438453
[3] https://git.eclipse.org/r/#/c/29698/

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Is it time to update to Guava 18?

[Andreas Sewe]

Hi Ed,

 On 25/03/2015 10:24, Andreas Sewe wrote:
 Possibly, but being open to third-party plugins, we cannot prevent the
 presence of multiple Guava versions in general.

 Anyway, I think the burden is on the developers of integration bundles
 C. You *can* shield yourself from this problem (A and B both exposing
 Guava in their API) to wrap one of them into facade that does not expose
 Guava in its API.

+-- A (exposes X) -- X
   /
 C
   \
+-- B' -- B (exposes Y) -- Y

 That way, A and B can be wired to different versions of Guava (X and Y,
 respectively) but C can still make use of them both.

 Granted, this is cumbersome, but (given the way OSGi and Equinox work)
 the only solution that is will work in an open ecosystem where *anyone*
 may supply another Guava bundle.

 Yes. That could work, but not for Mars because it imposes a new
 requirement on all SimRel products that integrate multiple Guava users.
 But it severely undermines Eclipse as a useful integration platform.

I don't quite understand. What do you mean by SimRel products. IMHO,
the burden is solely with bundles C which depend on multiple bundles A
and B that expose Guava in their API. If the developers of C do their
homework, then the maintainer of a SimRel product (I assume you mean
something like ann EPP package) does not have to worry about multiple
Guava's being shipped as part of that product.

 IMHO, and I think 'uses' does this, then if A and B announce what they
 use, then the class loader for the integrator chooses a jointly
 compatible Guava.

I thought so, too, but (as Thomas Watson explained [1]) with Equinox
this is unfortunately not always the case. Here's the scenario:

 - Bundle A requires either Guava version X or Y
 - Bundle B requires Guava version Y
 - C requires both A and B.

All bundles have correct uses constraints.

 - A is installed first (causing version X to be installed)
 - Equinox wires A to X
 - B is installed second (causing version Y to be installed)
 - Equinox wires B to Y
 - C is installed
 - Equinox cannot wire C to A and B *without* requiring A to Y

As Equinox (without -clean) won't rewire existing bundles, C cannot be
resolved, even though a solution exists.

A similar situation arises if C = B, i.e., C both requires Guava itself
and a bundle A that exposes Guava in its API. But with three bundles
things are easier to explain, even though the two-bundle scenario is
probably more common.

 If this fails, most commonly this will be a compile
 time version failure because A  and B have no overlap; an integrator's
 bug. Rarely it may occur at run-time if no Guava version from the
 overlap is available, a user's bug. Both are sensible, diagnosable and
 fixable leaving Eclipse as a good flexible integration platform.

Sorry, I don't understand what you are saying here. Can you please
reword and possibly expand your explanation?

Best wishes,

Andreas

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

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Weird p2 install behavior: doesn't take mandatory attribute into account

[Andreas Sewe]

Hi all,

we've just noticed a weird behavior of p2 during installation.

Here are the steps to reproduce:

- Install the bare 4.5-M4 SDK [1].

Note that it does not contain any bundles from Eclipse Code
Recommenders, Aether, or m2e.

- Next, install the latest version of Code Recommenders for Java
Developers from [2]

This installs all the bundles from Code Recommenders, some bundles from
Aether (which are made available through [2]) and(!) the bundle
org.eclipse.m2e.maven.runtime from [3], the update site pre-configured
by 4.5 M4.

And herein lies the problem:

 osgi ss recommenders
 Framework is launched.
 
 
 idState   Bundle
 263   INSTALLED   org.eclipse.recommenders.apidocs_2.1.12.v20141202-0751
 264   INSTALLED   org.eclipse.recommenders.apidocs.rcp_2.1.12.v20141202-0751
 265   INSTALLED   org.eclipse.recommenders.calls_2.1.12.v20141202-0751
 266   INSTALLED   org.eclipse.recommenders.calls.rcp_2.1.12.v20141202-0751
 267   STARTINGorg.eclipse.recommenders.chain.rcp_2.1.12.v20141202-0751
 268   STARTING
 org.eclipse.recommenders.completion.rcp_2.1.12.v20141202-0751
 269   STARTINGorg.eclipse.recommenders.injection_2.1.12.v20141202-0751
 270   RESOLVEDorg.eclipse.recommenders.jayes_2.1.12.v20141202-0751
 271   RESOLVEDorg.eclipse.recommenders.jayes.io_2.1.12.v20141202-0751
 272   RESOLVEDorg.eclipse.recommenders.jdt_2.1.12.v20141217-0920
 273   INSTALLED   org.eclipse.recommenders.models_2.1.12.v20141211-1032
 274   INSTALLED   org.eclipse.recommenders.models.rcp_2.1.12.v20141203-0852
 275   RESOLVEDorg.eclipse.recommenders.net_2.1.12.v20141202-0751
 276   INSTALLED   org.eclipse.recommenders.overrides_2.1.12.v20141202-0751
 277   INSTALLED   org.eclipse.recommenders.overrides.rcp_2.1.12.v20141202-0751
 278   STARTINGorg.eclipse.recommenders.rcp_2.1.12.v20141202-0751
 279   RESOLVEDorg.eclipse.recommenders.subwords.rcp_2.1.12.v20141202-0751
 280   RESOLVEDorg.eclipse.recommenders.utils_2.1.12.v20141211-1252

Code Recommenders is totally unusable.

The root cause is that it cannot resolve some package imports of
org.eclipse.aether, even though the org.eclipse.aether.api bundle is
present on the Code Recommenders update site [2].

 osgi diag 273
 org.eclipse.recommenders.models [273]
   Unresolved requirement: Import-Package: 
 org.apache.maven.repository.internal; version=[3.1.0,3.2.0)
 - Export-Package: org.apache.maven.repository.internal; 
 bundle-symbolic-name=org.eclipse.aether.maven; 
 bundle-version=3.1.0.v20140706-2237; version=3.1.0; 
 uses:=com.google.inject,javax.inject,org.eclipse.aether,org.eclipse.aether.artifact,org.eclipse.aether.deployment,org.eclipse.aether.impl,org.eclipse.aether.installation,org.eclipse.aether.repository,org.eclipse.aether.resolution,org.eclipse.aether.spi.locator,org.eclipse.aether.spi.log
org.eclipse.aether.maven [255]
  Unresolved requirement: Import-Package: org.eclipse.aether; 
 version=[0.9.1,1.1.0)

This is due to the fact that p2 has installed the bundle
org.eclipse.m2e.maven.runtime instead as a provider of the package
org.eclipse.aether:

 osgi p org.eclipse.aether
 osgi.wiring.package; bundle-symbolic-name=org.eclipse.m2e.maven.runtime; 
 bundle-version:Version=1.6.0.20141217-0916; provider=m2e; 
 version:Version=1.0.0.v20140518; osgi.wiring.package=org.eclipse.aether; 
 mandatory:=providerorg.eclipse.m2e.maven.runtime_1.6.0.20141217-0916 [261]

But this bundle is not a valid substitute for the org.eclipse.aether.api
bundle, due to the mandatory provider attribute of m2e.

Is this a bug in p2? IMHO, p2 should be able to detect that
org.eclipse.m2e.maven.runtime does not provide the necessary package for
the bundle org.eclipse.aether.maven to import, as the latter's
Import-Package does not use provider=m2e.

FWIW, for the history of the provider=m2e attribute added [4]
precisely to avoid these kind of wiring problems, see Bug 403243 [5].

Any insights as to why p2 behaves the way it does are greatly appreciated.

Best wishes,

Andreas

[1]
http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M4-201412102000/
[2] http://download.eclipse.org/recommenders/updates/head/
[3] http://download.eclipse.org/releases/mars
[4]
https://git.eclipse.org/c/m2e/m2e-core.git/commit/m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml?id=7e198c6ae5cffbd6fc45e0cb3b54492123d7e2e4
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=403243

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Mars M3: Wiring problems with HttpClient/Core 4.2.x and 4.3.x both present

[Andreas Sewe]

Hi,

we at Eclipse Code Recommenders recently got a bug report [1] about a
bundle resolution failure in Mars M3.

Apparently, the fact that Mars M3 ships Apache HttpClient/Core 4.3.x
rather than 4.2.x causes Eclipse Aether (which Code Recommenders uses
internally) to not resolve properly:

   org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
 Unable to resolve resource org.eclipse.aether.transport.http [osgi.identity; 
 osgi.identity=org.eclipse.aether.transport.http; type=osgi.bundle; 
 version:Version=1.0.0.v20140518] because it is exposed to package 
 'org.apache.http.entity' from resources org.apache.httpcomponents.httpcore 
 [osgi.identity; osgi.identity=org.apache.httpcomponents.httpcore; 
 type=osgi.bundle; version:Version=4.2.5.v201311072007] and 
 org.apache.httpcomponents.httpcore [osgi.identity; 
 osgi.identity=org.apache.httpcomponents.httpcore; type=osgi.bundle; 
 version:Version=4.3.2.v201409180530] via two dependency chains.
 
 Chain 1:
   org.eclipse.aether.transport.http [osgi.identity; 
 osgi.identity=org.eclipse.aether.transport.http; type=osgi.bundle; 
 version:Version=1.0.0.v20140518]
 import: 
 ((osgi.wiring.package=org.apache.http.entity)((version=4.2.1)(!(version=4.3.0
  |
 export: osgi.wiring.package: org.apache.http.entity
   org.apache.httpcomponents.httpcore [osgi.identity; 
 osgi.identity=org.apache.httpcomponents.httpcore; type=osgi.bundle; 
 version:Version=4.2.5.v201311072007]
 
 Chain 2:
   org.eclipse.aether.transport.http [osgi.identity; 
 osgi.identity=org.eclipse.aether.transport.http; type=osgi.bundle; 
 version:Version=1.0.0.v20140518]
 import: 
 ((osgi.wiring.package=org.apache.http.conn.ssl)((version=4.2.1)(!(version=4.3.0
  |
 export: osgi.wiring.package=org.apache.http.conn.ssl; 
 uses:=org.apache.http.entity
   org.apache.httpcomponents.httpclient [osgi.identity; 
 osgi.identity=org.apache.httpcomponents.httpclient; type=osgi.bundle; 
 version:Version=4.2.6.v201311072007]
 import: ((osgi.wiring.package=org.apache.http.entity)(version=4.2.5))
  |
 export: osgi.wiring.package: org.apache.http.entity
   org.apache.httpcomponents.httpcore [osgi.identity; 
 osgi.identity=org.apache.httpcomponents.httpcore; type=osgi.bundle; 
 version:Version=4.3.2.v201409180530]

This wiring problem may affect other projects beyond Eclipse Aether as
well (hence the cross-post to cross-project-issues), if they import a
specific *minor* version of Apache HttpClient/Core (Aether requires 4.2.x).

What I don't quite understand is why the bundles are wired as they are,
though, as a solution to the uses constraint problem seems to exist:
Wire org.apache.httpcomponents.httpclient 4.2.6 to
org.apache.httpcomponents.httpcore 4.2.5 rather than 4.3.2. Is it
because of the open-ended Import-Package of [4.2.5,) in
org.apache.httpcomponents.httpclient 4.2.6? (FWIW, 4.3.2 doesn't use
open-ended Import-Packages anymore. :-)

Any advice in how to best proceed with this issue? Should
org.eclipse.aether.transport.http use a broader Import-Package range
including 4.3.x (provided that there were no breaking API changes
between 4.2.x and 4.3.x)?

Best wishes,

Andreas

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

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Mars M3: Wiring problems with HttpClient/Core 4.2.x and 4.3.x both present

[Andreas Sewe]

Hi Alexander,

 that looks similar to what we have been discussing
 at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107.

thanks for the pointer. From what I can tell, however, Bug 437107 is
about an unwanted interaction between Require-Bundle and Import-Package.
But in my case, both Eclipse Aether and Apache HttpClient/Core
exclusively use Import-Package. Also, both have uses directives computed
by bnd (via the bundle-maven-plugin), which I think are complete, since
bnd performs an actual anaylsis of the code to derive them.

So, at least to me the situation seems to be more benign -- but
apparently things still go wrong somehow. :-(

Best wishes,

Andreas

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Bug 438856 - Make Sonar a Foundation managed service

[Andreas Sewe]

Hi,

 But if projects do care about the historical data then we'd have to
 think of a transition plan and keep the old instance running while
 projects switch over.
 
 Any thoughts?

we at Code Recommenders also don't care very much about our sonar
history, as it is rather spotty [1] due to frequent failures when
connecting to the Sonar server [2]. Thus, there's no transition plan
needed for us.

Best wishes,

Andreas

[1] https://dev.eclipse.org/sonar/dashboard/index/79160?did=7
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=419172

-- 
Codetrails GmbH
The knowledge transfer company

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
___
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] Luna RC3 repository is available

[Andreas Sewe]

Hi,

ab bit more context:

Marcel Bruch wrote:
 Might well be that this is due to a restructuring we did on our
 third-party dependencies. We had potential conflicts with Xtext and
 Guice. We removed the Guice inclusion in one of our features and rely
 on p2 that it pulls in the required Guice bundles. Since there is no
 separate source feature that contributes Guice sources now, this
 might explain why it’s not there anymore.

The Code Recommenders/Xtext class is Bug 431781.

Our solution to this bug is to place a do not install manually
3rd-party dependencies feature [2] on our update site which contains all
the third party dependencies we require. Said feature is not depended on
directly by our main features (e.g., [3]); instead, we rely on p2 to
install the necessary bundles included in our 3rd-party dependencies
features *if needed*. As we use Import-Package with version ranges for
most of our third-party dependencies, this occasionally avoids an
unnecessary install as a compatible 3rd-party dependency fulfilling the
Import-Package requirement is already installed.

 I’m OK with it (obviously). If someone else needs it, we should
 rethink how we distribute sources for Guice. I’m generally not aware
 of any good solution how to distribute source bundles for 3rd party
 bundles in the platform. If there is a common way, please let me
 know.

We supply a Tycho-generated source feature that includes all sources of
our 3rd-party dependencies [4]. This makes *manual* install easy. There
is no *automatic* install, however, as  there just isn't a dependency
from the main Code Recommenders feature to this source feature -- and
IMHO there shouldn't, as for the above reasons not every bundle in the
3rd-party feature might actually be installed.

Best wishes,

Andreas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=431781
[2]
https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/features/org.eclipse.recommenders.3rd.feature/feature.xml?id=07646883b0caa90ef9ef85e3bbe858ede01bc8c5
[3]
https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/features/org.eclipse.recommenders.rcp.feature/feature.xml?id=07646883b0caa90ef9ef85e3bbe858ede01bc8c5
[4] http://download.eclipse.org/recommenders/updates/head/?dir=features

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Switch from Luna RC2 to RC3 fails all our Tycho run UI tests: Known issue?

[Andreas Sewe]

Hi,

hope cross-project-issues is the right list for this, but for us it's a
huge issue (none of our builds pass) and I am wondering whether any
other project has encountered this as well:

We use http://download.eclipse.org/releases/luna/ as update site in
our builds. Now, as of today, i.e., the promotion of RC3 from staging to
said update site, Tycho fails to execute all of our UI tests. I have
opened Bug 436858 [1] to document my findings so far, but the short
version is that the UI tests all fail with the tycho-surefire-plugin
saying some along the lines of

 An error has occurred. See the log file .../target/work/data/.metadata/.log.

with the log then containing

 !ENTRY org.eclipse.osgi 4 0 2014-06-06 09:17:04.074
 !MESSAGE Application error
 !STACK 1
 java.lang.NullPointerException
   at 
 org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler.getPreferences(PartRenderingEngine.java:1500)
   at 
 org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler.resetOverriddenPreferences(PartRenderingEngine.java:1470)
   at 
 org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$StylingPreferencesHandler$1.handleEvent(PartRenderingEngine.java:1458)
   at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
   at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4487)
   at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4480)
   at org.eclipse.swt.widgets.Display.release(Display.java:3488)
   at org.eclipse.swt.graphics.Device.dispose(Device.java:249)
   at 
 org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151)
   at 
 org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:31)
   at 
 org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:114)
   at 
 org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:37)
   at 
 org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
   at 
 org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
   at 
 org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
   at 
 org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
   at 
 org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
   at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
   at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
   at org.eclipse.equinox.launcher.Main.main(Main.java:1438)

and possibly a complaint about an invalid thread access (SWTException).

Has anyone else seen this?

Best wishes,

Andreas

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

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Switch from Luna RC2 to RC3 fails all our Tycho run UI tests: Known issue?

[Andreas Sewe]

Hi Thomas, hi Igor,

 This is tracked as Tycho
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=436159
 
 Either use Platform build with 435888 fixed or switch to Tycho
 0.21 snapshot, which should be more tolerate to exceptions during test
 framework shutdown.

thanks for the prompt reply. Really appreciate it. :-)

Look indeed like Bug 435888. Our build used
org.eclipse.e4.ui.workbench.swt 0.12.100.v20140521-1818 from
http://download.eclipse.org/releases/luna/. Now switched to
http://download.eclipse.org/eclipse/updates/4.4-I-builds/, which I
probably should have done all along. That seems to have fixed the issue.

Best wishes,

Andreas

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Update site content cannot be displayed in IE11

[Andreas Sewe]

Hi,

 +1 for Sphinx and EATOP

good to know that the script is useful for other projects as well. :-)

If you want to start re-using our remote-resources bundle right now, you
can grab it from repo.eclipse.org [1]. Please let me know if you have
any problem with integrating this into your Tycho build along the lines
of [2], lines 42-73.

Best wishes,

Andreas

[1]
https://repo.eclipse.org/content/repositories/recommenders/org/eclipse/recommenders/repository-resources/2.0.7/
[2]
https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/repositories/pom.xml?id=ad3fd1f539d0239110ea89c7c9e8764d8e788b0a#n42

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Update site content cannot be displayed in IE11

[Andreas Sewe]

Hi,

 I don't know if there is a recommended format, but my 2 cents are:
 
 From a release engineer's point of view, I'd rather generate the index.html
 statically as part of the build than rely on runtime javascript.

Bug 424691 may be of interest. At Code Recommenders, we use the solution
presented there to include an index.php [1] in our update sites, which
then does the content listing (download.eclipse.org allows PHP). So this
solution falls somewhere between generating the list at build time and
generating it in the user's browser using JavaScript.

If there is a desire to establish a recommended format, I think the
CBI project should offer something akin to our repository-resources
artifact which can be easily included in CBI (= Tycho) builds.

Hope this helps.

Andreas

[1]
https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/releng/repository-resources/resources/index.php.vm

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Weird wiring issue with Code Recommenders and m2e (affects Luna packages)

[Andreas Sewe]

Hi all,

we encountered a weird wiring issue which affects everyone who uses
the latest version of Code Recommenders (2.1.0-SNAPSHOT) and m2e
(1.5.0-SNAPSHOT) respectively, which will both be aboard the Luna
release train.

The issue was initially reported and described in [1]. It manifests
itself as follows:

Installing the latest Code Recommenders Developer Tools feature from [2]
into a fresh Luna M6 Standard package (which contains neither Code
Recommenders nor m2e) works fine (all org.eclipse.recommenders bundles
resolve). But if you thereafter install the latest Maven Integration for
Eclipse feature from [3], large parts of Code Recommenders cease
working, as many org.eclipse.recommenders bundles cannot be resolved
anymore. Strangely, all org.eclipse.m2e bundles can be resolved, but
o.e.r bundles which previously resolved cannot be resolved anymore due
to a uses conflict.

 org.eclipse.recommenders.models [281]
   Bundle was not resolved because of a uses contraint violation.
   org.osgi.service.resolver.ResolutionException: Uses constraint violation. 
 Unable to resolve resource org.eclipse.recommenders.models [osgi.identity; 
 osgi.identity=org.eclipse.recommenders.models; type=osgi.bundle; 
 version:Version=2.1.0.v20140417-0727; singleton:=true] because it is 
 exposed to package 'org.eclipse.aether.impl' from resources 
 org.eclipse.aether.impl [osgi.identity; 
 osgi.identity=org.eclipse.aether.impl; type=osgi.bundle; 
 version:Version=0.9.1.v20140329] and org.eclipse.m2e.maven.runtime 
 [osgi.identity; osgi.identity=org.eclipse.m2e.maven.runtime; 
 type=osgi.bundle; version:Version=1.5.0.20140428-1210; 
 singleton:=false] via two dependency chains.
 
 Chain 1:
   org.eclipse.recommenders.models [osgi.identity; 
 osgi.identity=org.eclipse.recommenders.models; type=osgi.bundle; 
 version:Version=2.1.0.v20140417-0727; singleton:=true]
 import: 
 ((osgi.wiring.package=org.eclipse.aether.impl)((version=0.9.1)(!(version=1.0.0
  |
 export: osgi.wiring.package: org.eclipse.aether.impl
   org.eclipse.aether.impl [osgi.identity; 
 osgi.identity=org.eclipse.aether.impl; type=osgi.bundle; 
 version:Version=0.9.1.v20140329]
 
 Chain 2:
   org.eclipse.recommenders.models [osgi.identity; 
 osgi.identity=org.eclipse.recommenders.models; type=osgi.bundle; 
 version:Version=2.1.0.v20140417-0727; singleton:=true]
 import: 
 ((osgi.wiring.package=org.apache.maven.repository.internal)((version=3.1.0)(!(version=3.2.0
  |
 export: osgi.wiring.package=org.apache.maven.repository.internal; 
 uses:=org.eclipse.aether.impl
   org.eclipse.aether.maven [osgi.identity; 
 osgi.identity=org.eclipse.aether.maven; type=osgi.bundle; 
 version:Version=3.1.0.v20140322-2105]
 import: (osgi.wiring.package=org.eclipse.aether.impl)
  |
 export: osgi.wiring.package: org.eclipse.aether.impl
   org.eclipse.m2e.maven.runtime [osgi.identity; 
 osgi.identity=org.eclipse.m2e.maven.runtime; type=osgi.bundle; 
 version:Version=1.5.0.20140428-1210; singleton:=false]

This behavior mystifies both me and Benjamin Bentmann (who works on
org.eclipse.aether), in particular as changing the installation order
(m2e first, Code Recommenders second) works fine, as does restarting
with -clean. Similarly, installing both features at the same time works.

That being said, we have found a workaround [4]: not making
org.eclipse.recommenders.models a singleton (it doesn't need to be one
anyway). Once the singleton flag is removed, the wiring seems to work. I
would really like to understand why, though.

It would therefore be helpful if someone with more knowledge of OSGi
wiring rules than myself could investigate this one or explain to me
what's going on. If any more information is needed to reproduce the
problem, please comment on Bug 432022.

Best wishes,

Andreas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=432022#c3
[2] http://download.eclipse.org/recommenders/updates/head/
[3]
http://repository.takari.io:8081/nexus/content/sites/m2e.extras/m2e/1.5.0/N/LATEST/
[4] https://git.eclipse.org/r/#/c/25728/

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Reminder to update your feature licenses for Luna

[Andreas Sewe]

Hi Igor,

 With 60+ comments on the bug you linked, it's hard to understand what
 individual projects are expected to do. What license feature are we
 supposed to use now? Is it available from Luna symrel composite repo
 already?

Here's what served us well at Code Recommenders.

In our target file, we use CBI license repository rather then the simrel
repo:

 location includeAllPlatforms=false includeConfigurePhase=false 
 includeMode=slicer includeSource=true type=InstallableUnit
 unit id=org.eclipse.license.feature.group version=0.0.0/
 repository location=http://download.eclipse.org/cbi/updates/license/
 /location

In our feature.xml:

feature ...
   license-feature=org.eclipse.license
   license-feature-version=0.0.0
 
license url=%licenseURL
   %license
/license

This picked up the change in license automatically upon the next
(Tycho-based) build.

Hope that helps.

Andreas

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Build server unavailable

[Andreas Sewe]

Hi Mikael,

 The EMF Compare nightly build failed because it was not able to sign the 
 plugins. The error I get is:
 
 Caused by: org.apache.http.conn.HttpHostConnectException: Connection to 
 http://build.eclipse.org:31338 refused
 
 Anyone experiencing the same issue? Does the server need a restart?

had the same problem on our HIPP instance. Seems to be fixed by now.
Just retrigger the failing builds.

Andreas

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Kepler projects that are missing something that's required for the review

[Andreas Sewe]

Hi Wayne,

 If your project is on this list, you're missing one of three things:
 
 * Review documentation;
 * PMC approval of review documentation; or
 * An IP Team-approved IP Log.
 
 The corresponding records for projects that are doing service releases
 should already be marked as FIXED and so should not be on this list.
 
 If you believe that your project should not be on this list, let me
 know. We juggle a lot of balls with these releases and it's easy to miss
 something.

for of all, thanks for doing all the juggling.

Anyway, I think Code Recommenders should not be on the list. As Bug
408897 [1] states, 1.0.4 is a bugfix release (1.0.0 was
approved/reviewed for Juno) and thus does not require a review (and
hence PMC approval of the review documentation? Not sure about this
one). Also, the IP log has been approved.

Best wishes,

Andreas

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

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi David,

 From the b3 aggregator log, it appears that Code Recommenders is the one
 pulling in version 1.6.4.
 
 Is that on purpose? That is, do you purposely constrain/include that
 older version? Any chance to move up to the latest?

Sure. Will look into this straight away.

Andreas
-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi,

 From the b3 aggregator log, it appears that Code Recommenders is the one
 pulling in version 1.6.4.

 Is that on purpose? That is, do you purposely constrain/include that
 older version? Any chance to move up to the latest?
 
 Sure. Will look into this straight away.

made the move to org.slf4j.api 1.7.2:

http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins

Hope that fixes the problem. If not, please complain (again ;-)!

Andreas
-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] Code Recommenders, Jubula, m2e-wtp and other users of org.slf4j.api and providers of ch.qos.logback.slf4j

[Andreas Sewe]

Hi David,

 Thanks for your quick cooperation ... I bet you will be happier with the
 newest version anyway ... at least I hope!

I bet we won't notice the difference: log.error(..) is still the same as
always.

Anyway, can you just double-check [1] that the other, SLF4J related
plugins like ch.qos.logback.slf4j are also using the right version? Thanks.

Best regards,

Andreas

[1]
http://download.eclipse.org/recommenders/updates/train/e43/?dir=plugins

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
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] com.google.guava versions

[Andreas Sewe]

Ed Willink wrote:
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=401285 and
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=370651 give details on
 com.google issues.

We at Code Recommenders also had some problems [1] with multiple Guava
bundles being installed at the same time, but these could all be solved
by adding the appriate uses directives to our package exports.
(Classes like com.google.commons.base.Optional have a tendency to become
part of your public API and thus should be declared as such.)

Hope that helps.

Andreas

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

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev