from:"Scott Lewis"

[cross-project-issues-dev] signing question

2013-01-03 Thread Scott Lewis


Hi Folks,

Until recently, (ECF) has been signing our plugins by 'pushing' our 
plugins to eclipse.org (built on our own builder machine...which is 
*not* running at eclipse.org).   Apparently this is not the appropriate 
way now...rather what Denis indicated was appropriate was to have an 
eclipse.org machine 'pull' our unsigned plugins, sign them, and then put 
the signed versions somewhere.


 I assume that other projects do some/all of their build on non-eclipse 
systems...and need to do this as well.  Are there ant scripts and/or 
documentation on this 'pull' approach for signing?


Thanksinadvance,

Scott



___
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] Status and Outlook for Kepler M6

2013-03-20 Thread Scott Lewis

[1]
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=0a6bd70f1ee6d160dd3317f931e2c568c1247d61

On 3/20/2013 3:33 PM, Scott Lewis wrote:

Hi David,

For first time today I was just able to update the ECF b2aggrcon file
(with ECF 3.6.0) [1]. Hopefully I didn't miss the deadline for
including in build.

Thanks,

Scott

On 3/20/2013 7:37 AM, David M Williams wrote:
Yesterday was a very busy day for the aggregation build ... with the
usual few bumps ... but just a few new ones so far, today.

So, I figure everyone took it to heart to get done early, or else
some might need a reminder that today is the final (+3) day for
contributions to Kepler M6 common repo.
Or, you might need a reminder if you add to your repo, but not your
b3aggrcon file, that you are responsible for manually starting the
aggregation build, at
https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/

We'll say the usual 5 PM (Eastern) deadline unless someone posts a
message here that they need an extra hour or two.

Good luck, let us know if issues.

Thanks,

___
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] RC3 and Final Daze ...

2013-06-05 Thread Scott Lewis


ECF has fixed the about.html problems with bug

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

I've updated the Kepler meta-data...too late for RC3 but fixed for RC4 
obviously.


Scott


On 6/5/2013 11:58 AM, David M Williams wrote:
Here we are, nearly at the end of RC3 (remember, staging repo builds 
close at 5 PM Eastern, unless someone notifies us here they need an 
extra hour or two).


I am a little disappointed there is still so much work for some 
projects to do to meet minimum requirements to be released,
http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt 

http://build.eclipse.org/simrel/kepler/reporeports/reports/verifydiroutput/unsigned.txt 

But, I guess every year there are some projects that like to save it 
to the very end.


The main purpose of this note is to educate everyone on some of the 
mechanics over the next few weeks  what we call the Final daze.
For those of you that have been through it before ... it's all the 
same ... just dates have changed ... but it wouldn't hurt for Project 
Leads and release engineers to re-read.  For those of you new to 
Simultaneous Release, I hope you find it a helpful reference on how to 
make things go smoother, in a more coordinated way.


http://wiki.eclipse.org/Kepler/Final_Daze

After reading it, and the documents it links to, please ask here on 
cross-project list if there are questions, issues, or suggestions.


Thanks,



___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler is GO!

2013-06-26 Thread Scott Lewis


On 6/26/2013 6:53 AM, Tom Schindl wrote:
Now this repo misses at least 
org.eclipse.ecf.provider.filetransfer.httpclient which was in the 
repo at this location at least until yesterday!


I don't understand how that would be possible.   ECF's own 
repo/aggregator contribution didn't change...and I had assumed that the 
aggregator didn't even do another build from yesterday to today...but I 
suppose it's possible that it did do another build and somehow did 
something different.


David...any ideas?

Scott




Tom

On 26.06.13 15:08, David M Williams wrote:

I have turned on the common release update site, at

http://download.eclipse.org/releases/kepler/

Thanks to all committers, contributors, and users who made this release
possible ... and a special thanks to all the expert support from the
Eclipse Foundation staff for helping us at every step of the way.





From: Denis Roy denis@eclipse.org
To: cross-project-issues-dev@eclipse.org,
Date: 06/26/2013 09:01 AM
Subject: [cross-project-issues-dev] Kepler is GO!
Sent by: cross-project-issues-dev-boun...@eclipse.org




Greetings,

I've checked my list twice... looks like mirrors are all populated with
the packages.  We've got an extra 500 Mbps of bandwidth on tap. We're
GO for Kepler!

Please feel free to make your bits available to your eagerly awaiting
users.  The main Downloads page will be updated shortly.
_
__http://wiki.eclipse.org/Kepler/Final_Daze#08:30_EDT_

Congratulations to all!  For those in Ottawa, we'll see you at the Big
Rig at 1:00pm!

Denis
___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler is GO!

2013-06-26 Thread Scott Lewis


On 6/26/2013 7:48 AM, David M Williams wrote:

stuff deleted

But, if ecf.core was supposed to include this too ... then ... not 
sure why that wasn't working.


No, ecf.core is not supposed to include httpclient (or httpclient4).  In 
fact, it would create a problem for us and our consumers if it did, 
because then install of ecf.core into Eclipse could be a problem.


Given the platform's decision to use only httpclient4...and not include 
the legacy httpclient provider...I'm honestly not sure what else we can 
do other than to make our repo available with all filetransfer 
impls...as we have done [1].   Apologies for the surprise, however...the 
platform and aggregator build surprised me/us as well.


Scott

[1] http://www.eclipse.org/ecf/downloads.php
___
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] Source code in simrel aggregate repo

2013-08-08 Thread Scott Lewis


On 8/8/2013 9:53 AM, Konstantin Komissarchik wrote:


I think this illustrates quite well the trouble of leaving such 
decisions to projects, without even providing guidance as to what's 
recommended.




I agree, but I think it also highlights

a) SR projects have different consumers...meaning that for some projects 
some things are expected/required (e.g. source), and for others it's 
not.  Thus the projects are not necessarily wrong to make some 
assumptions about 'the audience'...because their audience may very well 
be different from some other project's audience
b) IMHO it doesn't make sense for the planning council to make/add new 
requirements...or even 'strong recommendations/guidance'...without 
providing some resources to the projects to implement them.   Because 
given (very) limited resources, most of the projects will focus on their 
consumer's needs specifically (e.g. David's WTP example)...because 
that's what they have to do...or drop out of the SR...which has been 
happening to some degree, unfortunately.
c) I agree that all of the projects have a shared interest in having the 
SR be a uniform, easy, positive experience for all consumers.  I also 
think that most project leads (at least) recognize that shared 
interest.   But IMHO...when faced with resource issues, the shared 
interest is easily trumped by a, b.


Scott


It is too easy for projects to make too many assumptions about the 
audience that is using the simrel repository. Note that I am not 
talking about the audience for a particular EPP package. For instance, 
based on current repository composition, plugin developers do use the 
simrel repository, but they like to code against JDT (for instance) 
and not WTP (for instance). This type of inconsistency really reduces 
the value of the simrel repository as it forces developers to go 
hunting for pieces they need elsewhere and hope that they get the 
right version to match pieces they got from simrel repo. It also 
limits the type of EPP packages that can be created, since EPP 
packages can only draw from the simrel repo.


Thanks,

- Konstantin

*From:*cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of 
*David M Williams

*Sent:* Thursday, August 08, 2013 9:37 AM
*To:* Cross project issues
*Subject:* Re: [cross-project-issues-dev] Source code in simrel 
aggregate repo


We did not discuss it to that level (pros and cons of including 
source) ... just that it is good to leave as much as possible up to 
the independent projects to decide for themselves.


Common repository is a misnomer and I should be more careful not to 
call it that. It has never been the intent to provide one repository 
with everything ... the intent is simply to provide a repository for 
the Simultaneous Release: and its purpose is to make it easier for 
users to find and get what they need for what ever task or role that 
are focused on ... and the planning council thinks it is best to leave 
decision or analysis up to the project and their community and adopters.


To give one example, that I just happen to know you are interested in 
:) ... I think WTP decided many years ago not to include source since 
the primary audience, web developers, did not need the source, and 
having it there a) made it more complicated for the casual end-user 
web developer to decide what to get (they likely don't know if they 
need source or not) and b) if source was provided (either 
automatically, or by user selection) it nearly doubles the download 
sizes [just going by my old, possibly inaccurate memories] so it was 
decided not to put source there in Sim. Rel. repo.


I'm just trying to recount history .. and admit it is confusing to 
call the repo by so many names ... not arguing pro or con to include 
source or not ... the important point being that we (Planning Council) 
want each project to be able to decide as much as possible what to 
contribute . And with that, I will bow out of this discussion as it is 
up to the project.


Thanks




From: Konstantin Komissarchik konstantin.komissarc...@oracle.com 
mailto:konstantin.komissarc...@oracle.com
To: 'Cross project issues' cross-project-issues-dev@eclipse.org 
mailto:cross-project-issues-dev@eclipse.org,

Date: 08/08/2013 11:11 AM
Subject: Re: [cross-project-issues-dev] Source code in simrel 
aggregate repo
Sent by: cross-project-issues-dev-boun...@eclipse.org 
mailto:cross-project-issues-dev-boun...@eclipse.org







Thanks for the summary. I would be curious to know what the arguments 
against contributing source were... It seems to me that the status quo 
has led to inconsistency, an antithesis to the point of having a 
common repository.


- Konstantin



*From:*cross-project-issues-dev-boun...@eclipse.org 
mailto:cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of

Re: [cross-project-issues-dev] Question on Kepler SR1 release review

2013-08-14 Thread Scott Lewis


On 8/14/2013 3:15 PM, Doug Schaefer wrote:
I don't remember that being the decision. Another thing that doesn't 
work with projects that want to ship more often and want to update the 
corresponding EPP package with that release.


At the risk of overstating things, I don't think the Planning Council 
equally represents the interests of the many projects that participate 
in the simultaneous release.   That is, I would say that the interests 
of the larger, more well-established projects and their consumers (e.g. 
platform, strategic developers, etc) are overrepresented on the Planning 
Council, and this has resulted in decisions that are counter to the 
increasing needs for innovation from newer/smaller projects...e.g. to 
ship more often, provide more innovation in tooling/IDE, have fewer 
'must have' SR requirements because of resource limitations, etc.


I don't want these comments to be construed as a criticism of chair 
David Williams, or even of the existing Planning Council.  IMHO, the 
problem is more structural.


Scott


___
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] EF plans to raise awareness of Java 8 support

2014-03-27 Thread Scott Lewis


On 3/27/2014 12:37 PM, Mike Milinkovich wrote:

On 27/03/2014 2:31 PM, Scott Lewis wrote:
Would you include links (or other page) to j8-enabled features from 
other EF projects?...In my case it will be ECFs use of j8 with OSGi 
remote services [1]...but there are possibly other EF projects that 
can/could have j8-enabled enhancements for Luna.


We would certainly be willing to keep a page (perhaps a wiki page) 
that contains a list of other Java 8 enabled features. But we do not 
want to bury the lede that JDT is supporting Java 8. 


Unless the implementation is horrific...and I'm expecting it won't 
be...I don't think there's much danger of 'burying the lede' by having 
the smallest bit of EF promotional work around j8 support from 
non-java-IDE EF projects.


Thanks,

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

2014-04-25 Thread Scott Lewis


Hi,

Sorry in advance if this is covered ground somewhere...but I can't seem 
to find it.


For those projects that are still using the 'old way'...and therefore 
need to update the files by hand...I want to clarify what actually needs 
to be updated to meet these requirements...please correct if 
wrong/missing, etc:


In the features:

notice.html  (the SUA in it's own content)
feature.properties   (the SUA in the feature.properties file)

That's it, right?  I've got the new content from the legal git repo, but 
want to verify that this is the extent of the necessary changes.


Has anyone created and shared among EF projects a script to do this?   
Not that I'll actually use it :), but useful to ask.


Thanks,

Scott

On 4/24/2014 1:41 AM, David M Williams wrote:

I'm sure everyone is aware of the new license requirement:
*_Bug 431255_* https://bugs.eclipse.org/bugs/show_bug.cgi?id=431255- 
Need to update the SUA (Software User Agreement)


And now that we in Platform (and MPC) have updated -- which 
demonstrated my updated repo report appears to be working correctly 
-- I thought it'd be a good time to send a reminder.


http://build.eclipse.org/simrel/luna/reporeports/reports/licenseConsistency.html 



It'd be nice to get as many updated as possible for M7, and certainly 
by RC1. It really does give a much better user experience and better 
first impression to those updating/installing to get that simpler, 
more meaningful license dialog.


Thanks,



___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Inconsistency between ECF bundle in Luna M7

2014-05-14 Thread Scott Lewis


It appears to me that this Equinox server feature:

org.eclipse.equinox.server.p2.feature.group

is defined to depend upon an older version of org.eclipse.ecf.identity 
bundle than the o.e.ecf.core.feature (which is in Luna).


I think that the fix would be to have the more recent version of the 
equinox.server.p2.feature be created to use the most recent version of 
ecf.identity (i.e. the one in Eclipse Luna RC1). Another option would be 
for the equinox.server.p2.feature to refer to the 
o.e.e.core.feature...as Eclipse Luna now does...rather than directly to 
the ecf.identity bundle.


I would suggest opening a bug against the Equinox server.p2.feature, and 
please add me directly to the bug.


WRT aggregator checks...frankly I'm not sure where such an enhancement 
would be appropriate...David or others can probably advise.


WRT feature to remove...I would first try removing 
org.eclipse.equinox.server.p2.feature.group.


Thanks,

Scott

On 5/14/2014 12:59 AM, Mickael Istria wrote:

Hi all,

If I try to install most pieces of Luna M7 together in a p2 
installation, or in a target-definition with planner mode (that will 
behave similarly to p2 director), then I see an incompatibility 
between 2 features:


  [ERROR] Cannot resolve project dependencies:
  [ERROR]   Software being installed: 
org.eclipse.ecf.core.feature.feature.group 1.1.0.v20140505-2203
  [ERROR]   Software being installed: 
org.eclipse.equinox.server.p2.feature.group 1.2.100.v20140428-1446
  [ERROR]   Only one of the following can be installed at once: 
[org.eclipse.ecf.identity 3.4.0.v20140505-2203, 
org.eclipse.ecf.identity 3.4.0.v20140428-1446]
  [ERROR]   Cannot satisfy dependency: 
org.eclipse.ecf.core.feature.feature.group 1.1.0.v20140505-2203 
depends on: org.eclipse.ecf.identity [3.4.0.v20140505-2203]
  [ERROR]   Cannot satisfy dependency: 
org.eclipse.equinox.server.p2.feature.group 1.2.100.v20140428-1446 
depends on: org.eclipse.ecf.identity [3.4.0.v20140428-1446]


The Eclipse M7 build ( 
http://download.eclipse.org/eclipse/updates/4.4milestones/S-4.4M7-201405010200/ 
) doesn't contain the 
org.eclipse.ecf.core.feature.feature.group/1.1.0.v20140505-2203 and 
seems to contain an older one which would be compatbile with 
org.eclipse.equinox.server.p2.feature.group/1.2.100.v20140428-1446


So I'm wondering:
* I'd like to open a bug to report that, but I'm not sure who's to 
blame? Aggregation, contribution of a b3aggrcon file, an upstream 
build...?
* Doesn't the aggregator has checks to ensure that everything can be 
installed at once? If not, I'd make it an enhancement request.
* Which feature do you suggest to get rid of to overcome this 
installation issue?

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat http://www.jboss.org/tools
My blog http://mickaelistria.wordpress.com - My Tweets 
http://twitter.com/mickaelistria



___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Luna RC1 staging repo is complete.

2014-05-22 Thread Scott Lewis


Hi Stephan,

For historical/releng reasons, part of ECF (core and filetransfer) could 
not be directly updated in Eclipse.  Prior to Luna, it was necessary to 
patch Eclipse in order update these bundles.


Over the past year, this problem has been dealt with through changes to 
the feature structure [1], and so this patch is not needed for Luna.


ECF would like to continue supporting Kepler, however, and so we need to 
continue distributing the patch so that Kepler users can install ECF 
from the Luna repo.


I agree the wording awkward.   If people have suggestions for rewording 
that would be clearer (i.e. use for Kepler, not for Luna), then 
suggestions would be appreciated.


Thanks,

Scott

On 5/22/2014 6:05 AM, Stephan Herrmann wrote:

I just stumbled upon a feature that doesn't seem to belong here:

  ECF Patch for Eclipse Kepler (4.3). Not needed for Eclipse Luna 
(4.4).


Not sure if
(a) needed for some technical reasons and hence the nice explanation
in the feature name please don't use me, or
(b) simply forgotten from former times?, or
(c) ... (your explanation here) ...

just looks funny ...

best,
Stephan

___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Luna RC1 staging repo is complete.

2014-05-22 Thread Scott Lewis


sorry

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


On 5/22/2014 7:01 AM, Scott Lewis wrote:

Hi Stephan,

For historical/releng reasons, part of ECF (core and filetransfer) 
could not be directly updated in Eclipse.  Prior to Luna, it was 
necessary to patch Eclipse in order update these bundles.


Over the past year, this problem has been dealt with through changes 
to the feature structure [1], and so this patch is not needed for Luna.


ECF would like to continue supporting Kepler, however, and so we need 
to continue distributing the patch so that Kepler users can install 
ECF from the Luna repo.


I agree the wording awkward.   If people have suggestions for 
rewording that would be clearer (i.e. use for Kepler, not for Luna), 
then suggestions would be appreciated.


Thanks,

Scott

On 5/22/2014 6:05 AM, Stephan Herrmann wrote:

I just stumbled upon a feature that doesn't seem to belong here:

  ECF Patch for Eclipse Kepler (4.3). Not needed for Eclipse Luna 
(4.4).


Not sure if
(a) needed for some technical reasons and hence the nice explanation
in the feature name please don't use me, or
(b) simply forgotten from former times?, or
(c) ... (your explanation here) ...

just looks funny ...

best,
Stephan

___
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 mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
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] Luna RC1 staging repo is complete.

2014-05-22 Thread Scott Lewis


On 5/22/2014 10:33 AM, Stephan Herrmann wrote:

Hi Scott,

thanks for explaining.

On 05/22/2014 04:01 PM, Scott Lewis wrote:
ECF would like to continue supporting Kepler, however, and so we need 
to continue
 distributing the patch so that Kepler users can install ECF from the 
Luna repo.


This is the part that looks funny to me:
why should bits explicitly directed at kepler users only
be published in the luna repo among all locations?
I thought the luna repo is for luna users? :)


Yes, of course primarily it is for Luna.  But because we would like to 
allow Kepler users to install some or all of ECF into Kepler (in 
addition to Luna), and we are in this temporary/transitional situation 
(Kepler needs patch, Luna doesn't), this patch allows Kepler users to 
update using the Luna repo rather than us creating/maintaining 
multiple/separate repos.


Agreed it's not wonderful, but alternatives are few.

Scott


___
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] Luna marketing bullets

2014-05-26 Thread Scott Lewis


On 5/26/2014 12:49 PM, Wayne Beaton wrote:


stuff deleted

We've already had the discussion with the press regarding Java 8. I 
still think that it belongs on the list. While I'd like to keep ECF on 
this short list, I'm not sure how much hay we can make from it at 
marketing level. Ian is the expert here, so he and I will make the 
final decision together.


Objection.   Frankly...not to put too fine a point on it...I don't 
really believe in the EF/marketing's judgment here.  ECF has been an EF 
project for almost 10 years now, and I think it's completely fair to say 
that ECF has received little to no promotion by EF marketing during that 
entire time.  Further, it remains an ongoing marketing battle for RT 
projects like ECF to prove that they are relevant not only to the work 
on Java8 (which it clearly is), but also completely relevant to IoT as 
well (which it also clearly is...along with Equinox and probably others).


And...ECF is under consideration as the reference implementation for the 
R6 OSGi Remote Services/Remote Service Admin specifications...which is 
also relevant to the 'cloud' and IoT directions.   This cannot be 
announced...as I would prefer to...because the choice has not yet been 
made and OSGi won't be completing the choice in time for Luna.


Objection.

Scott
___
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] ECF participation in Mars

2014-12-10 Thread Scott Lewis


ECF will be participating in the Mars Simultaneous Release.

ECF Filetransfer is -1 (Platform dependency) and the rest of ECF (e.g. 
remote services) is +1


We plan to contribute version 3.10.0 [1].

Scott

[1] https://projects.eclipse.org/projects/rt.ecf/releases/3.10.0;
___
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] Fw: Proposed schedule for JDK 9

2015-05-06 Thread Scott Lewis


Mike,

Could you or someone comment on Java 9 modularity (jsr 376) and it's 
compatibility with OSGi?  Wayne appears to be on the experts group so 
maybe he knows what's happening there?


Thanks,

Scott

[1] https://jcp.org/en/jsr/detail?id=376

On 5/5/2015 2:51 PM, Mike Milinkovich wrote:

ICYMI, Java 9 is now releasing September 2016.

Mike Milinkovich
mike.milinkov...@eclipse.org
+1.613.220.3223
   Original Message
From: mark.reinh...@oracle.com
Sent: Tuesday, May 5, 2015 12:22 PM
To: jdk9-...@openjdk.java.net
Subject: Proposed schedule for JDK 9

Here is a proposed schedule for JDK 9:

2015-12-10 Feature Complete
2016-02-04 All Tests Run
2016-02-25 Rampdown Start
2016-04-21 Zero Bug Bounce
2016-06-16 Rampdown Phase 2
2016-07-21 Final Release Candidate
2016-09-22 General Availability

The dates here are meant to leave sufficient time for broad review and
testing of the significant features of the release, in particular the
introduction of a module system and the modularization of the platform,
while maintaining the cadence of shipping a major release about every
two years.

The milestone definitions are the same as those for JDK 8 [1].

Comments from JDK 9 Committers are welcome, as are reasoned objections.
If no such objections are raised by 23:00 UTC next Tuesday, 12 May, or
if they're raised and then satisfactorily answered, then per the JEP 2.0
process proposal [2] this will be adopted as the schedule for JDK 9.

(This information is also available on the JDK 9 Project Page [3]).

- Mark


[1] http://openjdk.java.net/projects/jdk8/milestones#definitions
[2] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[3] http://openjdk.java.net/projects/jdk9/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

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

2015-06-09 Thread Scott Lewis


On 6/9/2015 9:49 AM, Andreas Sewe wrote:

stuff deleted
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.


Yes, as per the 'disabling httpcomponents' it is more successful in 
traversing proxies...particularly in the case of NTLMv2.



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?


Right.




 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.


I encourage you to put links to these data and your associated comments 
on bug


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

Scott

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

2015-06-09 Thread Scott Lewis

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

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.


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.


Scott


On 6/9/2015 8:30 AM, Andreas Sewe wrote:

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

[cross-project-issues-dev] usage data collection for RCP apps

2015-07-24 Thread Scott Lewis


Hi,

My apologies for not paying attention, but is there anything of the 
Usage data collection work that could be used within an RCP app? (As 
opposed to Eclipse)


If so, is there any experiences and/or documentation that could be shared?

Thanksinadvance,

Scott
___
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] question about moving up release date

2015-07-24 Thread Scott Lewis


Wayne appears to be inaccessible so I'll ask this list:

Is it possible to edit/change (e.g. move up) a scheduled release in the 
meta-data editor?   If so, how?


Alternatively, I could delete the existing release and create a new one 
with the correct date, but I can't see a way to delete a release.


Thanks,

Scott


___
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] ECF participation in Neon

2015-12-08 Thread Scott Lewis

ECF intends to participate in Neon.   Best guess it that will be with 
ECF 3.13.


Offset
ECF filetransfer: -1
The rest of ECF (remote services, etc):  +1

Scott


___
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] signing problems

2016-04-03 Thread Scott Lewis


Howdy,

I have been trying to do a ECF 3.13.1 release build this weekend and 
it's been failing on signing.  Here are parts of the logs for the last 
three attempts...first failed with End of IO Stream Read and the other 
two with timeouts.


ant] [INFO] You can check signing status by tailing 
'/home/data/httpd/download-staging.priv/arch/signer.log'
[ant] Waiting for signing to complete. This may take more then 20 minutes. 
(Expect to see several 'Remote command failed' messages)
[ant] ls: cannot access 
/home/data/httpd/download-staging.priv/rt/ecf/out20160403023434/site_1646321392.zip:
 No such file or directory
[ant] Target 'assert.output.present.keyfile' failed with message 
'com.jcraft.jsch.JSchException: Session.connect: java.io.IOException: End of IO 
Stream Read'.
ERROR: org.eclipse.core.runtime.CoreException: 
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/signing.ant:164:
 The following error occurred while executing this line:
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/sign

...

and the subsequent ones

  target.arch=x86_64
  
buckminster.output=/opt/hudson/jobs/R-HEAD-sdk.feature/workspace/buckminster.output/org.eclipse.ecf.sdk_3.13.1-eclipse.feature
  localhost=ecf-builds.osuosl.org
  eclipse.home=/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster
  
buckminster.temp=/opt/hudson/jobs/R-HEAD-sdk.feature/workspace/buckminster.temp/org.eclipse.ecf.sdk_3.13.1-eclipse.feature/temp
  
buckminster.home=/opt/hudson/jobs/R-HEAD-sdk.feature/workspace/projects/org.eclipse.ecf.sdk/
[ant] Queueing site_573286944.zip for signing
ERROR: org.eclipse.core.runtime.CoreException: 
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/signing.ant:175:
 Timeout period exceeded, connection dropped.
org.eclipse.core.runtime.CoreException: 
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/signing.ant:175:
 Timeout period exceeded, connection dropped.
at 
org.eclipse.buckminster.ant.AntRunner.handleInvocationTargetException(AntRunner.java:169)

...


  
buckminster.temp=/opt/hudson/jobs/R-HEAD-sdk.feature/workspace/buckminster.temp/org.eclipse.ecf.sdk_3.13.1-eclipse.feature/temp
  
buckminster.home=/opt/hudson/jobs/R-HEAD-sdk.feature/workspace/projects/org.eclipse.ecf.sdk/
[ant] Queueing site_704172407.zip for signing
ERROR: org.eclipse.core.runtime.CoreException: 
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/signing.ant:175:
 Timeout period exceeded, connection dropped.
org.eclipse.core.runtime.CoreException: 
/opt/hudson/tools/Buckminster/Buckminster_4.5/buckminster/configuration/org.eclipse.osgi/22/0/.cp/org/eclipse/buckminster/jarprocessor/antscript/signing.ant:175:
 Timeout period exceeded, connection dropped.

...

Any ideas about what may be going wrong?  Thanks.


___
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] ECF participation in Oxygen

2016-10-05 Thread Scott Lewis

ECF will be participating in Oxygen simultaneous release with offset -1 
for filetransfer and +1 for remote services.


Our planned release will be 3.15.0

Scott



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

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

2017-04-22 Thread Scott Lewis

I am not on planning council, and so have not been able to follow all 
the discussion, but just to be clear ECF has this open bug for Oxygen M7:

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

To meet this we have modified our own build to include these versions 
from Orbit:

org.apache.httpcomponents.httpcore_4.4.6.v20170210-0925.jar
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925.jar

It's our intention to contribute to platform an ECF build including 
these bundles during the week of May 1.

If any of this should change because of issues from this thread, please 
let use know via bug 513888 and/or other bugs.

Scott

On 4/21/2017 2:00 PM, Jeff Johnston wrote:
Just to confirm that the change has been merged to the Neon.3_respin 
branch.

-- Jeff J.

On Fri, Apr 21, 2017 at 4:11 PM, Jeff Johnston > wrote:

I have done another respin.  In this case, I rebuilt the Linux
Tools plug-ins to use the older version
of docker-client and its dependencies which were used in Neon.2. 
I have back-versioned the

Docker tooling plug-ins to 2.3.0 with the current date.

I have just pushed to gerrit for Neon.3_respin branch.

https://git.eclipse.org/r/#/c/95501/

If no-one objects, I will merge into the branch. Verification is
already successful.

-- Jeff J.

On Fri, Apr 21, 2017 at 11:50 AM, Jeff Johnston
> wrote:

Marcel,

Since the respin didn't fix the problem, we will try reverting
the docker-client dependency and keeping as much of the added
Neon.3 functionality as possible
in place and cutting another point release.  I will let the
list know when I have something in place.

-- Jeff J.

On Fri, Apr 21, 2017 at 6:38 AM, Daniel Megert
>
wrote:

Adding eclipse.org-planning-coun...@eclipse.org
 to this
thread.

Dani

From: "Dr. Marcel Bruch" >
To: Cross project issues
>
Date: 21.04.2017 10:17
Subject: Re: [cross-project-issues-dev] Neon.3 Update
Problems: To Fix andHow to Fix?
Sent by: cross-project-issues-dev-boun...@eclipse.org

Hi,

I’ll briefly summarize the discussion we had at the AC
yesterday:

Given that we don’t know how the OSGI resolver will behave
(even after Tom back-ported a fix to Neon) it would be
preferred to just have the Apache HTTP*** versions in
Neon.3 that were already in Neon.2. This would to some
extend “ensure" that we are "at least as as stable as
Neon.2”. This would require us to rollback the changes
that introduced the latest version of HTTPClient. As far
as I know this would especially affect the Docker Tooling.
(maybe more changes than that are needed)

My question to the *Docker Tooling project lead*: Is it
possible to rollback this last minute change and postpone
it to Oxygen for the sake of making EGit, MPC, Oomph, USS,
and Code Recommenders work reliably again - and giving us
more trust that we won’t get into trouble with Neon.3? The
simplest solution may be to contribute the docker tooling
from Neon.2 in Neon.3. WDYT?

Marcel

On 20 Apr 2017, at 18:54, Frederic Gurr
<_frederic.gurr@eclipse.org_
> wrote:

I can see
org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in

/home/data/httpd/_download.eclipse.org/linuxtools/update-docker-2.3.1/plugins_

,
but it's definitely not in the aggregated repo.

On 20.04.2017 18:31, Jeff Johnston wrote:
Fred,

The version of httpclient also changed in our
update-docker-2.3.1 repo from:

org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643

to:

org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925

Not sure why this change isn't being seen as well.

-- Jeff J.

On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr

Re: [cross-project-issues-dev] Intent to update HttpComponents bundles

2017-09-25 Thread Scott Lewis


On 9/25/2017 9:16 AM, Aleksandar Kurtakov wrote:


No component can go in Orbit before a project opens a CQ to get it in.
Please do so for ECF and once legal approval is there, Mat will
provide patches against Orbit.


Aleksandr:   I'm going to ask that the projects that have been 
submitting CQs for httpcomponents continue to do so rather than I/ECF do 
it as they have the history and experience with Orbit migration of 
httpcomponents.


For the version that we are using now of httpcore/httpclient 
(4.5.2/4.4.6) the Orbit submitter was Steffan Pingel [1], and the CQ was 
[2] (submitted by Steffan as well).


Scott

[1] http://download.eclipse.org/tools/orbit/downloads/drops/R20170516192513/
[2] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12682
___
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] Intent to update HttpComponents bundles

2017-09-25 Thread Scott Lewis

On 9/25/2017 8:57 AM, Daniel Megert wrote:

Hi Mat

Two questions:

1. Can you confirm that there is no breakage and we can move to the 
new version without doing any work/investigation?

Answering for ECF here.   Although historically Apache httpcomponents is 
generally pretty good about no regression, we haven't yet tested that 
there is no breakage in the parts used by ECF.   The main reason we 
haven't done so is that these new versions haven't yet been added to 
Orbit, and ECF has traditionally waited until the Orbit migration has 
been done (previously by Mylyn or Linuxtools) before doing the testing, 
as we don't have Orbit commit rights.

As per Ed's recently reply:   I think the next steps with this is to get 
the latest versions into Orbit so that all the consumers...including 
ECF...can test for regression with our existing test suite.  We/ECF 
cannot do that, so part of this is a request to have the existing Orbit 
httpcomponents maintainers take that up.

2. Can we assume that this is for Photon only?

Yes.

Scott

Dani

From: Mat Booth 
To: Cross project issues 
Date: 21.09.2017 10:22
Subject: [cross-project-issues-dev] Intent to update HttpComponents 
bundles

Sent by: cross-project-issues-dev-boun...@eclipse.org

Hi all,

I'd like to make known my intent to update the httpcomponent bundles 
in orbit on behalf of ECF.

There've been releases made upstream for both client and core 
components, so I'd like to make the following updates:

> httpcomponents-client 4.5.3
> httpcomponents-core 4.4.7

I was asked to notify the other consumers on this list so that we can 
coordinate and avoid any potential issues with having multiple 
versions of httpcomponents in the SR repos... So I guess please reply 
and let me know if there are any objections to this.

Thanks,
Mat___
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_cross-2Dproject-2Dissues-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y=4kuPXC5D7jonwbuD1vNY57XuofMpIn1f15cRbTPn_u8=_mwjtQTWrSpt9xpIbrp6PRwthG4fEs2n5l43yzGavrI=

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

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

Re: [cross-project-issues-dev] Make sure you are committing to the right SimRel aggregation branch

2017-09-04 Thread Scott Lewis


On 9/4/2017 6:27 PM, Greg Watson wrote:

Yes, I committed to the Oxygen_update branch when I discovered it wasn't 
included in RC2.


me too

Scott

___
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

2018-06-12 Thread Scott Lewis


WRT ECF:

For Photon, the Platform folks chose to stick with the Oxygen versions 
of httpclient/httpcomponents (4.5.2/4.4.6).  One reason was that the new 
Orbit bundles were added fairly late in the release cycle...leaving 
little time...and no milestone releases...for thorough testing of the 
newer versions.


Scott


On 6/12/2018 3:10 PM, Carsten Reckord wrote:

org.eclipse.jgit.http.apache is an optional bundle which is not used by EGit.
It's used in JGit by org.eclipse.jgit.lfs.server (supports implementation of a 
git
lfs server)
and org.eclipse.jgit.pgm (jgit command line client).

Yes, but it's in the simrel repository and it pulls in the second HttpClient 
version.

Since that version has a higher qualifier than the one bundled with ECF, it 
gets pulled in by installing anything that has a dependency on HttpClient with 
a version range. So it also ends up in all the packages (while the other 
version is brought in, because the ECF feature contains the exact version).
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



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

Re: [cross-project-issues-dev] Heads up: multiple HttpClient versions in simrel

2018-06-13 Thread Scott Lewis


On 6/13/2018 7:48 AM, Aleksandar Kurtakov wrote:



On Wed, Jun 13, 2018 at 10:00 AM, Matthias Sohn 
mailto:matthias.s...@gmail.com>> wrote:


Are 2 months not enough to validate a new version ?



From my chair it's plenty...but as I suspect all are aware there's more 
to it than that.



It was introduced in Orbit I20180417184143
and it seems it's not really a new version but a new Orbit build
of the same version.


So there are two things mixed in this discussion. There was no reason 
for ECF to not adopt the latest rebuild of the same version from Orbit.


True, except that I wasn't aware of this rebuild of the same version (no 
request opened).   As per this bug:


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

I was waiting for httpclient 4.5.5/4.4.9 to appear in Orbit until after 
M7 as Aleksandar says below.


To what I said please don't do it was moving to httpclient 4.5.5 and 
httpcore 4.4.9 (in private email with Scott) on May 10th (aka after 
M7). That would have been even worse case expecting every project to 
move to new version of httpclient post M7.
Scott, would you please move ECF to httpclient 4.5.5 and httpcore 
4.4.9 and give us a build so we can base on the new versions from the 
start of 4.9?


Yes.  Although it will be a couple of weeks from now.
___
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

2018-06-13 Thread Scott Lewis


Hi Aleksandar,



>It is recommended that projects update the Orbit repo they use to 
build for each milestone. That would have catched the issue

> and it would be nice if ECF does so from now on.

Perhaps it would be nice, but I'm not going to do it.   Since this is a 
free service provided by me personally, I'm going to have to depend upon 
others to do the necessary watching.


>Further more it would be really helpful if projects higher in the 
stack help with keeping the release train consistent - help with >that 
is always more than welcome. I can speak for Platform but I bet ECF 
wouldn't mind some help too.


+1

Scott


___
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 to httpclient/httpcore in ECF/Platform

2018-08-01 Thread Scott Lewis



ECF has contributed httpclient/httpcore 4.5.5/4.4.9 for the 2018-09 
release as per [1].


Because of past problems with multiple versions of these bundles, all SR 
projects that depend upon httpclient/httpcore directly will need to use 
Orbit version 4.5.5/4.4.9 as well.


Scott

[1] https://bugs.eclipse.org/536959

___
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 to httpclient/httpcore in ECF/Platform

2018-07-17 Thread Scott Lewis


On 7/13/2018 9:56 AM, Scott Lewis wrote:


The versions Mat proposes:

org.apache.httpcomponents.httpclient  4.5.5
    org.apache.httpcomponents.httpcore   4.4.9

Are the most recent versions in Orbit [1].   This bug [2] was opened 
for ECF and then subsequent Platform adoption.    If these versions 
cannot be adopted by other SR projects, then the discussion should 
occur on 2.


[1] 
http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=520077


To put this on a timeline:

We've completed the incorporation of 4.5.5/4.4.9 along with successfully 
running our test suite.  Unless there are objections raised/discussed on 
2, ECF will contribute this version as part of our 3.14.1 [a] release.  
After that I expect it will be incorporated into platform for Photon.1 SR.


Scott

[a] https://projects.eclipse.org/projects/rt.ecf/releases/3.14.1





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

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



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

Re: [cross-project-issues-dev] Fwd: Re: Update to httpclient/httpcore in ECF/Platform

2018-07-18 Thread Scott Lewis


On 7/17/2018 10:28 PM, Ed Willink wrote:


Hi

(Your message does not seem to have been sent out from the mailing 
list; just the forum/archive.)


You refer to Photon.1 SR. Presumably you mean 2018-09 since 
maintenance releases have now been abandoned.


Please forgive me.   I have name whiplash.

Scott

___
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] ECF participation in 2018-09 simrel

2018-07-11 Thread Scott Lewis

ECF will participate in 2018-09 release with offset -1 for filetransfer 
and +1 for remote services and etc.


Not certain yet what the new version will be, but anticipate 3.14.1 
(Photon was 3.14.0).


Scott


___
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 to httpclient/httpcore in ECF/Platform

2018-07-13 Thread Scott Lewis


On 7/13/2018 2:19 AM, Ed Willink wrote:

Hi

My recollection is that there is a very strong expectation that all 
SimRel projects build against the latest available version in Orbit.


Surely this correspondence should therefore just be a notification 
that new Orbit versions are available and then discussion as to why a 
new version cannot be accommodated and what consequences follow?


The versions Mat proposes:

org.apache.httpcomponents.httpclient  4.5.5
    org.apache.httpcomponents.httpcore   4.4.9

Are the most recent versions in Orbit [1].   This bug [2] was opened for 
ECF and then subsequent Platform adoption.    If these versions cannot 
be adopted by other SR projects, then the discussion should occur on 2.


[1] http://download.eclipse.org/tools/orbit/downloads/drops/R20180606145124/
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=520077



___
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] Downstream Projects of platform to take note - ECF Upgrade in platform

2019-05-27 Thread Scott Lewis


On 5/27/2019 6:52 AM, Daniel Megert wrote:

Hi Scott

I assume that shipping the older httpClient version in addition, would 
not resolve those issues and that it is something that would have to 
be changed/fixed in ECF. Correct?


I believe that the older provider (httpclient4) would resolve these 
issues as this provider has configurable timeouts...for connect and others.


It would also be helpful to enlist the support of the httpclient45 
provider author (Carsten) via  [1] specifically around connect 
timeouts.   Perhaps something can be changed in the new provider to 
handle the timeouts more like the older provider.


Scott

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




Dani



From: Ed Merks 
To: cross-project-issues-dev@eclipse.org
Date: 27.05.2019 15:19
Subject: [EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects 
of platform to take note - ECF Upgrade in platform

Sent by: cross-project-issues-dev-boun...@eclipse.org




FYI, I've run into a number of problems with the latest ECF/httpclient 
code.  Mostly my own fault for how I've hacked ECF to be able to 
collect and submit cookies (so I deserve to suffer). :-P
But also other problems.  For example, the older timeout properties 
not being respected in the newer implementation, i.e., the properties 
from org.eclipse.ecf.filetransfer.IRetrieveFileTransferOptions for 
timeouts are not applied when using the new implementation where the 
default timeout is 120 seconds, so that can have a bad impact if your 
application runs into timeouts and has tried to limit the overall time 
impact using these options.
But worse, the setup archiver application has basically stopped 
functioning with timeouts such as the following:
FAILED to load 
_http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup_
 ERROR: org.eclipse.oomph.util.IOExceptionWithCause: Timeout waiting 
for connection from pool: 
_http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup_0 
0 0


After much investigating I fear that the Apache pool implementation is 
perhaps buggy (or perhaps how ECF uses it).
ECF itself increases the pool's limit in 
org.eclipse.ecf.internal.provider.filetransfer.httpclient45.ECFHttpClientFactory.newClient()as 
follows (so instead of 2 and 20).

builder.setMaxConnPerRoute(100);
        builder.setMaxConnTotal(300);
And while these numbers seem relatively large, the setup archiver 
visits a great many resources on multiple threads (to produce the 
setups.zip used by the installer).  Only by increasing these numbers 
dramatically does the setup archiver application go back to normal 
functioning, completing in 19 second on the build server versus 
thrashing for 20 minutes and failing with connection pool timeouts.
So in the end, I'm a little concerned because p2 also uses ECF to 
access repositories and if there is a problem with the connection pool 
refusing to hand out new leases even when the client has finished with 
the older connections, that could cause bad problems with updates and 
in the installer's ability to install, though fortunately a normal 
install will only access two simple repositories.  But in the real 
world, people have very complex target platforms and very complex 
installations that reference horribly bloated composites.  In these 
scenarios I have already seen connection pool timeouts...


On 22.05.2019 05:57, Manoj Palat wrote:
Hi All,

Please note that platform has moved to latest ECF that includes 
/httpclient45 /(org.eclipse.ecf.filetransfer.httpclient45.feature). 
However, ECF (which is available at the update site: 
_https://download.eclipse.org/rt/ecf/snapshot/site.p2_) has both 
/httpclient4/and /httpclient45/. Platform mirrors /httpclient45 
/(org.eclipse.ecf.filetransfer.httpclient45.feature) only from now on 
- essentially /httpclient4.feature 
/(org.eclipse.ecf.filetransfer.httpclient4.feature) and 
/httpclient4.ssl.feature 
/(org.eclipse.ecf.filetransfer.httpclient4.ssl.feature) are not 
mirrored to platform repository anymore.


Requesting downstream projects to adjust their dependencies accordingly.

Regards,
Manoj

___
cross-project-issues-dev mailing list
_cross-project-issues-dev@eclipse.org_ 

To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

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

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list

Re: [cross-project-issues-dev] Downstream Projects of platform to take note - ECF Upgrade in platform

2019-05-28 Thread Scott Lewis

Filetransfer providers may be disabled at start time via a system 
property [1].


[1] https://wiki.eclipse.org/Disabling_Apache_Httpclient45



On 5/28/2019 12:54 AM, Daniel Megert wrote:

But wouldn't that mean that (affected) clients have to change their code?

Dani



From: Scott Lewis 
To: Daniel Megert , Cross project issues 


Date: 27.05.2019 23:13
Subject: [EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects 
of platform to take note - ECF Upgrade in platform

Sent by: cross-project-issues-dev-boun...@eclipse.org




On 5/27/2019 6:52 AM, Daniel Megert wrote:
Hi Scott

I assume that shipping the older httpClient version in addition, would 
not resolve those issues and that it is something that would have to 
be changed/fixed in ECF. Correct?
I believe that the older provider (httpclient4) would resolve these 
issues as this provider has configurable timeouts...for connect and 
others.
It would also be helpful to enlist the support of the httpclient45 
provider author (Carsten) via  [1] specifically around connect 
timeouts.   Perhaps something can be changed in the new provider to 
handle the timeouts more like the older provider.

Scott
[1] _https://bugs.eclipse.org/bugs/show_bug.cgi?id=57_


Dani



From: Ed Merks __ <mailto:ed.me...@gmail.com>
To: _cross-project-issues-dev@eclipse.org_ 
<mailto:cross-project-issues-dev@eclipse.org>

Date: 27.05.2019 15:19
Subject: [EXTERNAL] Re: [cross-project-issues-dev] Downstream Projects 
of platform to take note - ECF Upgrade in platform
Sent by: _cross-project-issues-dev-bounces@eclipse.org_ 
<mailto:cross-project-issues-dev-boun...@eclipse.org>





FYI, I've run into a number of problems with the latest ECF/httpclient 
code.  Mostly my own fault for how I've hacked ECF to be able to 
collect and submit cookies (so I deserve to suffer). :-P
But also other problems.  For example, the older timeout properties 
not being respected in the newer implementation, i.e., the properties 
from org.eclipse.ecf.filetransfer.IRetrieveFileTransferOptions for 
timeouts are not applied when using the new implementation where the 
default timeout is 120 seconds, so that can have a bad impact if your 
application runs into timeouts and has tried to limit the overall time 
impact using these options.
But worse, the setup archiver application has basically stopped 
functioning with timeouts such as the following:
FAILED to load 
_http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup_
 ERROR: org.eclipse.oomph.util.IOExceptionWithCause: Timeout waiting 
for connection from pool: 
_http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup_0 
0 0


After much investigating I fear that the Apache pool implementation is 
perhaps buggy (or perhaps how ECF uses it).
ECF itself increases the pool's limit in 
org.eclipse.ecf.internal.provider.filetransfer.httpclient45.ECFHttpClientFactory.newClient()asfollows 
(so instead of 2 and 20).

        builder.setMaxConnPerRoute(100);
        builder.setMaxConnTotal(300);
And while these numbers seem relatively large, the setup archiver 
visits a great many resources on multiple threads (to produce the 
setups.zip used by the installer).  Only by increasing these numbers 
dramatically does the setup archiver application go back to normal 
functioning, completing in 19 second on the build server versus 
thrashing for 20 minutes and failing with connection pool timeouts.
So in the end, I'm a little concerned because p2 also uses ECF to 
access repositories and if there is a problem with the connection pool 
refusing to hand out new leases even when the client has finished with 
the older connections, that could cause bad problems with updates and 
in the installer's ability to install, though fortunately a normal 
install will only access two simple repositories.  But in the real 
world, people have very complex target platforms and very complex 
installations that reference horribly bloated composites.  In these 
scenarios I have already seen connection pool timeouts...


On 22.05.2019 05:57, Manoj Palat wrote:
Hi All,

Please note that platform has moved to latest ECF that includes 
/httpclient45 /(org.eclipse.ecf.filetransfer.httpclient45.feature). 
However, ECF (which is available at the update site: 
_https://download.eclipse.org/rt/ecf/snapshot/site.p2_) has both 
/httpclient4/and /httpclient45/. Platform mirrors /httpclient45 
/(org.eclipse.ecf.filetransfer.httpclient45.feature) only from now on 
- essentially /httpclient4.feature 
/(org.eclipse.ecf.filetransfer.httpclient4.feature) and 
/httpclient4.ssl.feature 
/(org.eclipse.ecf.filetransfer.httpclient4.ssl.feature) are not 
mirrored to platform repository anymore.


Requesting downstream projects to adjust

Re: [cross-project-issues-dev] Simultaneous Release 2019-06 opt-in

2019-05-08 Thread Scott Lewis


Hi Wayne,

ECF expects to contribute a version 3.14.5 [1] next week.

Scott

[1] https://projects.eclipse.org/projects/rt.ecf/releases/3.14.5


On 5/8/2019 1:04 PM, Wayne Beaton wrote:

Greetings Simultaneous Release 2019-06 participants.

Per our process, I have started to assemble the participants list for 
2019-06 .


By way of reminder, the process requires 
 
that project teams signal their participation by making a change to 
their aggrcon file in the simrel repository. For project teams that 
intend to drop out of the simultaneous release, the process requires 
that you inform the group and then remove your aggrcon file.


For projects that did participate in the previous simultaneous
release, the project team's representative must touch the
project's aggrcon file by the milestone 2 (M2) date of the release
to indicate that the project wishes to continue participating and
that they project team is paying attention.


AFAICT, 49 project teams have changed their aggrcon file since the 
start of this release cycle. I have captured my best guess at the 
version that each project is participating with. Please have a look 
and let me know what I've gotten wrong.


Note that if you are adding a new version of your content (major, 
minor, or service), you need to create a release record. Make sure 
that your release record has "2019-06-19" as the release date (I did 
notice that least one existing release record showed 2019-06-20 as the 
release date; please have a look and fix your record if this is you).


Please create the release record (or ensure that it has been created) 
before you tell me that I've listed the wrong version.


Version names must include some form of a semantic version. You can 
prefix or suffix version names as you'd like. The convention appears 
to be to not prefix or suffix, or to include the simultaneous release 
name as a suffix.


Note that the PMI doesn't handle numbers appearing before the semantic 
version very well, but I have a fix in the queue that should sort this 
out in time for the release.


I intend to do a pass over the simrel repository again on Friday, May 
10 (M2) to bring the participation list up to date and will start the 
public shaming of those who have not followed the rules sometime 
thereafter.


Per the December 2018 update to the EDP, project teams are not 
required to engage in a release review if they've engaged in one in 
the year leading up to their release date. No review is required. No 
PMC approval is required. No IP log review is required. /Remember that 
whether or not you engage in a review, project teams are required to 
follow the Eclipse IP Due Diligence Process. Your releases must only 
include IP that has been either "license certified" or "approved" by 
the IP Team. /I will initiate a scan of the repository tonight to 
ensure that unvetted IP has not been inadvertently added.


Thanks for your attention.

Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


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

[cross-project-issues-dev] httpclient version for SR

2019-04-22 Thread Scott Lewis


Folks,

A new provider has been offered to ECF [1] that solves several of the 
proxy issues experienced with the apache httpclient provider [2] in some 
environments.


This provider is dependent upon at least versions 4.5.6 of httpclient 
and 4.4.10 of httpcore.    Consequently, ECF is preparing to move to 
using 4.5.6/4.4.10 from Orbit.


In the past there have been problems with multiple versions of 
httpclient/httpcore bundles in the SR repo and so this note is to make 
all simultaneous release projects aware of these plans so that 
consistent versions of httpclient and httpcore can be used for 2019-06 
by all participating projects.


Thanks,

Scott

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

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=422665

___
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] org.apache.commons.codec

2020-02-25 Thread Scott Lewis

ECF updates httpclient/httpcomponents and deps (e.g. codec) in response 
to explicit requests from platform...e.g. [1] in this case.


I'm not sure how to effect in terms of process, but it might be good for 
other release train projects that consume httpclient (e.g. egit) if 
somehow the platform notified them (or just the cross projects list) 
when it makes a request like [1].    This so that only one version of 
httpclient/httpcomponents/deps (codec) end up in release repo as 
multiple versions have caused problems in past.


Scott

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

On 2/25/2020 2:40 AM, Matthias Sohn wrote:

I updated the JGit/EGit contribution
https://git.eclipse.org/r/#/c/158269/
and this now comes with the latest versions of commons codec (1.13.0) 
and Apache httpclient (4.5.10) and httpcore (4.4.12)

https://repo.eclipse.org/content/unzip/releases.unzip/org/eclipse/egit/org.eclipse.egit.repository/5.7.0.202002241735-m3/org.eclipse.egit.repository-5.7.0.202002241735-m3.zip-unzip/plugins/

On Mon, Feb 24, 2020 at 6:39 PM Matthias Sohn > wrote:


I need to update the JGit/EGit contribution to the release train
repository, will do this asap

On Mon, Feb 24, 2020 at 4:32 PM Andrey Loskutov mailto:losku...@gmx.de>> wrote:

Matthias just pushed an update of JGit dependencies that AFAIK
would also use latest Orbit, see https://git.eclipse.org/r/158190
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Montag, 24. Februar 2020 um 15:43 Uhr
*Von:* "Jonah Graham" mailto:jo...@kichwacoders.com>>
*An:* "Cross project issues"
mailto:cross-project-issues-dev@eclipse.org>>
*Betreff:* [cross-project-issues-dev] org.apache.commons.codec
Hi folks,
I am trying to resolve a dependency problem - there are
multiple versions of the following in
https://download.eclipse.org/staging/2020-03/plugins/
org.apache.httpcomponents.httpclient has 4.5.2, 4.5.6 and 4.5.10*
org.apache.commons.codec has versions 1.9.0, 1.10.0 and 1.13.0*
Of those only the * ones are in current orbit.
What is the way to resolve this? At the moment, AFAICT for
example, egit's simrel contribution requires jgit
(org.eclipse.jgit.http.apache.feature.group) which requires
o.a.h.httpclient 4.5.6 which requires o.a.c.codec 1.10.
This is causing me problems for CDT as when I tried to upgrade
our target platform to Eclipse Platform's M3 contribution, I
can no longer resolve egit because current orbit does not have
the org.apache dependencies that egit/jgit needs.
This is not a new problem, 2019-12 had 2 versions of each of
the above libraries, now we are at three of them.
Any suggestions?
Thanks
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
 To change your
delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org

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


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev 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] org.apache.commons.codec

2020-02-26 Thread Scott Lewis


Ed,

I endorse Oomph's approach to managing shared dependencies :).

Might as well use all these release train versioning and 
backward-compatibility rules to both project-specific and cross-project 
advantage.


Scott

On 2/25/2020 9:42 PM, Ed Merks wrote:


Scott,

Of course people would have to pay attention to announcements, but 
yes, such announcements would be a good thing.


With Oomph we're being slightly bad, but in a good way I think...  
While we rely on this component, we don't actually contribute it to 
SimRel under the assumption that someone else will.  Given we depend 
on the Platform and ECF and that we have permissive version ranges, 
that assumption works fine.  As such, Oomph is never responsible for 
the duplicates.


If one looks at the current report:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2020-03/index.html

and filter the Installable Unit's section to "Duplicate", you can see 
the 53 bundles that are have duplicate versions. Many with even with 3 
versions.  Lucene looks to be especially popular!


org.apache.lucene.core 6.1.0.v20170814-1820
org.apache.lucene.core 7.1.0.v20171214-1510
org.apache.lucene.core 7.5.0.v20181003-1532
org.apache.lucene.core 8.0.0.v20190404-1858
org.apache.lucene.core 8.4.1.v20200122-1459

"We" really ought to do a better job coordinating this, especially for 
components that tend to leak into the API and causing wiring problems.


I expect M3 to arrive with unsigned content:

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

I'm not sure if any actions are being taken to fix this before the 
release; this in in the CDT product, so users will notice.


Web tools fixed their problem.  Thanks Nick Boldt!

Also there will continue to be invalid licenses:

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

Action has been taken, but getting it into a build and contributing 
that seems to have stalled.


I've not harped on the rather massive duplication of common components 
because after almost 1/2 a year, we've not gotten past the "signed 
content and valid licenses" phase; we're darned close though!  
Coordinating the common components will be much more challenging, and 
I expect it will not actually happen until the problems it causes 
rears its ugly head to the end-users.


Regards,
Ed

On 26.02.2020 00:54, Scott Lewis wrote:


ECF updates httpclient/httpcomponents and deps (e.g. codec) in 
response to explicit requests from platform...e.g. [1] in this case.


I'm not sure how to effect in terms of process, but it might be good 
for other release train projects that consume httpclient (e.g. egit) 
if somehow the platform notified them (or just the cross projects 
list) when it makes a request like [1].    This so that only one 
version of httpclient/httpcomponents/deps (codec) end up in release 
repo as multiple versions have caused problems in past.


Scott

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

On 2/25/2020 2:40 AM, Matthias Sohn wrote:

I updated the JGit/EGit contribution
https://git.eclipse.org/r/#/c/158269/
and this now comes with the latest versions of commons codec 
(1.13.0) and Apache httpclient (4.5.10) and httpcore (4.4.12)

https://repo.eclipse.org/content/unzip/releases.unzip/org/eclipse/egit/org.eclipse.egit.repository/5.7.0.202002241735-m3/org.eclipse.egit.repository-5.7.0.202002241735-m3.zip-unzip/plugins/

On Mon, Feb 24, 2020 at 6:39 PM Matthias Sohn 
mailto:matthias.s...@gmail.com>> wrote:


I need to update the JGit/EGit contribution to the release train
repository, will do this asap

On Mon, Feb 24, 2020 at 4:32 PM Andrey Loskutov mailto:losku...@gmx.de>> wrote:

Matthias just pushed an update of JGit dependencies that
AFAIK would also use latest Orbit, see
https://git.eclipse.org/r/158190
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Montag, 24. Februar 2020 um 15:43 Uhr
*Von:* "Jonah Graham" mailto:jo...@kichwacoders.com>>
*An:* "Cross project issues"
mailto:cross-project-issues-dev@eclipse.org>>
*Betreff:* [cross-project-issues-dev] org.apache.commons.codec
Hi folks,
I am trying to resolve a dependency problem - there are
multiple versions of the following in
https://download.eclipse.org/staging/2020-03/plugins/
org.apache.httpcomponents.httpclient has 4.5.2, 4.5.6 and
4.5.10*
org.apache.commons.codec has versions 1.9.0, 1.10.0 and 1.13.0*
Of those only the * ones are in current orbit.
What is the way to resolve this? At the moment, AFAICT for
example, egit's simrel contribution requires jgit
(org.eclipse.jgit.http.apache.feature.group) which requires
o.a.h.httpclient 4.5.6 which requires o.a

Re: [cross-project-issues-dev] updating httpcomponents to 5.0.2 for JGit/EGit

2020-10-07 Thread Scott Lewis

I haven't worked with httpcomponents 5 yet, but the major segment change 
from 4-5 could of course signal some non-backward-compatible changes.


It's going to take some resources allocation to check for and fix any 
such required changes...and test of course...in ECF filetransfer/p2.


It may make the most sense to create another provider (alongside 4, 45 
providers) which would allow using the milestones (e.g.) for testing 'in 
the wild'.


Scott

On 10/7/2020 4:14 AM, Matthias Sohn wrote:

This is a heads up regarding usage of Apache httpcomponents.
We are considering to update httpcomponents (httpcore and httpclient) 
to 5.0.2 for JGit/EGit.

See [1] and the changes adding these new versions to Orbit [2].
I still need to add conscrypt to Orbit which is an optional dependency 
for the

http 2.0 implementation in httpcore5-h2.

Let us know if there are any concerns regarding this plan.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=567654
[2] https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170406/1
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170407/1
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170408/1

-Matthias

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

[cross-project-issues-dev] httpclient5/jna5 vs. httpclient45/jna45 in Eclipse and Simrel

2021-05-13 Thread Scott Lewis


Howdy,

Some time ago, ECF was requested to update to use 
httpclient/httpcomponents 5 rather than 4.5 [1], so that JNA 5 could be 
used rather than JNA 4.5.


For context, ECF filetransfer depends on 3 apache bundles from Orbit:   
org.apache.httpcomponents.httpclient 4.5.10, 
org.apache.httpcomponents.httpcore 4.4.12 and 
org.apache.httpcomponents.httpclient.win 4.5.10.  The 
o.a.httpcomponents.httpclient.win jar is the one that has the dependency 
on JNA 4.5.  The others do not.   I am not the author of the ECF code 
that uses httpcomponents4.5.win...rather Carsten Reckord and company 
contributed this.    It requires a specific proxy environment with win32 
just to test.


[1] led to [2].   [2] requests that ECF move to httpclient5, so that the 
httpcomponents4.5 dependency on JNA 4.5 could be eliminated (as 
httpclient5.win depends upon JNA 5).   I've done the work to move the 
bulk of the ECF source code over to httpclient5 as reported on [2].


However, as described in comment [3], there remain two things to be done 
that I cannot do:


1) Get the httpcomponents5.win jar into Orbit as a properly formed 
bundle so we can consume it for step 2.   Currently at maven central [4] 
5.0.2 version is currently just a jar (no bundle meta-data).


2) Write/contribute a httpclient5.win32 version of ECF provider code 
that uses this apache client5.win jar.   Since the package naming of 
httpclient5.win has changed, this can be used with the existing 
httpclient45.win32 provider.  Although I expect this to be 
straightforward for Carsten or others given the existing 
httpclient45.win32 source [5] and his familiarity with that code, it has 
to actually be tested in the appropriate proxy environment.


I don't have the Orbit rights, or resources to do 1, nor the resources 
or environment (testing) to do 2.


My question to all:  Is there enough desire and resources for the above 
two things to happen in time for 2021-06?    If so, how and who?


If these cannot be made to happen then ECF will contribute an updated 
httpclient45 version, but it will *still* depend upon/require JNA 4.5 be 
present for the 4.5.10 version of 
org.apache.httpcomponents.httpclient.win.   I don't know if this is a 
problem or not (multiple versions of JNA in platform?).


Two additional things:

a) I see that at maven central httpclient 5 is up to 5.1.0.   The only 
version of httpclient 5 in Orbit currently is 5.0.2 (excepting 
client5.win...which isn't there at all as described above).


b) Up to now we've had a convention that all simrel projects use the 
same version of httpclient...as the simrel had some unexplained problems 
with dependency confusion with multiple versions of httpclient in the 
simrel repo.   If the we are going to continue to have this restriction, 
and ECF moves to httpclient5 for 2021-06 (1 and 2 get done, etc), then 
this would imply that *all* simrel consumers of httpclient would have to 
move to httpclient5.   This is a much bigger deal since httpclient5 
broke backward compatibility by renaming packages so all the sources 
that use httpclient apis would have to be recompiled (at least).


If the answer to the 2021-06 question is 'yes' then all this has to 
happen pretty fast...as the platform API freeze is end of May, we should 
almost certainly do some testing before the freeze, and I'm resource 
limited.


For specific contributions and discussion please go to [2].

Scott

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

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100#c22

[4] 
https://search.maven.org/artifact/org.apache.httpcomponents.client5/httpclient5-win/5.0.2/jar


[5] 
https://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient45.win32



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

Re: [cross-project-issues-dev] 2021-06 Participating Projects List

2021-05-26 Thread Scott Lewis


Hi,

ECF is going to release 3.14.21 rather than 3.14.20.

Scott

On 5/26/2021 7:07 AM, Wayne Beaton wrote:
I believe that I've made all of the updates requested to the 2021-06 
Release  page.


Please let me know if I've missed anything.

Wayne

On Tue, May 18, 2021 at 10:42 AM Wayne Beaton 
> wrote:


Greetings Folks. It's that time again!

I've created a participation page for the 2021-06 Release
. On it, I've
listed the participating projects along with the version that the
project is contributing to the simultaneous release. Please have a
look and let me know if anything needs to be updated.

Note that you'll need to create a release record for the release
you're contributing if you have not already done so (please do so
before asking me to update your project's participation listing).

Note also that if you have not done so in the last year and you're
contributing a new major or minor release, you'll need to engage
in a release review
.

Intellectual property must be properly accounted for and tracked
at all times. The project team must engage in the Eclipse IP Due
Diligence Process 
on an ongoing basis. The IP Log review and approval that occurs at
the time of either a release review or progress review should be
regarded as a means of confirming that intellectual property is
being properly managed and not as a trigger to engage in a last
minute clean up.

Let me know if you have any questions,

Wayne
-- 


Wayne Beaton

Director of Open Source Projects | Eclipse Foundation



--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation


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

Re: [cross-project-issues-dev] httpclient5/jna5 vs. httpclient45/jna45 in Eclipse and Simrel

2021-05-21 Thread Scott Lewis


Hi Folks,

An update:   There has not been progress on the TBD items described in 
my 5/13 note below, so ECF will be contributing an updated httpclient 
4.5 filetransfer provider to Platform for RC1 next week.  For 
explanation and details see [1].


Scott

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


On 5/13/2021 5:22 PM, Scott Lewis wrote:

Howdy,

Some time ago, ECF was requested to update to use 
httpclient/httpcomponents 5 rather than 4.5 [1], so that JNA 5 could 
be used rather than JNA 4.5.


For context, ECF filetransfer depends on 3 apache bundles from 
Orbit:   org.apache.httpcomponents.httpclient 4.5.10, 
org.apache.httpcomponents.httpcore 4.4.12 and 
org.apache.httpcomponents.httpclient.win 4.5.10.  The 
o.a.httpcomponents.httpclient.win jar is the one that has the 
dependency on JNA 4.5.  The others do not.   I am not the author of 
the ECF code that uses httpcomponents4.5.win...rather Carsten Reckord 
and company contributed this.    It requires a specific proxy 
environment with win32 just to test.


[1] led to [2].   [2] requests that ECF move to httpclient5, so that 
the httpcomponents4.5 dependency on JNA 4.5 could be eliminated (as 
httpclient5.win depends upon JNA 5).   I've done the work to move the 
bulk of the ECF source code over to httpclient5 as reported on [2].


However, as described in comment [3], there remain two things to be 
done that I cannot do:


1) Get the httpcomponents5.win jar into Orbit as a properly formed 
bundle so we can consume it for step 2.   Currently at maven central 
[4] 5.0.2 version is currently just a jar (no bundle meta-data).


2) Write/contribute a httpclient5.win32 version of ECF provider code 
that uses this apache client5.win jar.   Since the package naming of 
httpclient5.win has changed, this can be used with the existing 
httpclient45.win32 provider.  Although I expect this to be 
straightforward for Carsten or others given the existing 
httpclient45.win32 source [5] and his familiarity with that code, it 
has to actually be tested in the appropriate proxy environment.


I don't have the Orbit rights, or resources to do 1, nor the resources 
or environment (testing) to do 2.


My question to all:  Is there enough desire and resources for the 
above two things to happen in time for 2021-06?    If so, how and who?


If these cannot be made to happen then ECF will contribute an updated 
httpclient45 version, but it will *still* depend upon/require JNA 4.5 
be present for the 4.5.10 version of 
org.apache.httpcomponents.httpclient.win.   I don't know if this is a 
problem or not (multiple versions of JNA in platform?).


Two additional things:

a) I see that at maven central httpclient 5 is up to 5.1.0.   The only 
version of httpclient 5 in Orbit currently is 5.0.2 (excepting 
client5.win...which isn't there at all as described above).


b) Up to now we've had a convention that all simrel projects use the 
same version of httpclient...as the simrel had some unexplained 
problems with dependency confusion with multiple versions of 
httpclient in the simrel repo.   If the we are going to continue to 
have this restriction, and ECF moves to httpclient5 for 2021-06 (1 and 
2 get done, etc), then this would imply that *all* simrel consumers of 
httpclient would have to move to httpclient5.   This is a much bigger 
deal since httpclient5 broke backward compatibility by renaming 
packages so all the sources that use httpclient apis would have to be 
recompiled (at least).


If the answer to the 2021-06 question is 'yes' then all this has to 
happen pretty fast...as the platform API freeze is end of May, we 
should almost certainly do some testing before the freeze, and I'm 
resource limited.


For specific contributions and discussion please go to [2].

Scott

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

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=566100#c22

[4] 
https://search.maven.org/artifact/org.apache.httpcomponents.client5/httpclient5-win/5.0.2/jar


[5] 
https://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient45.win32



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

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

[cross-project-issues-dev] Removal of JNA dependency

2021-04-08 Thread Scott Lewis


Howdy,

Some time ago Jonah opened this issue [1].   After some analysis a fix 
has been proposed here [2].


The fix removes the dependency completely...which seems to me a 
reasonable thing to do.   However, Carsten Reckford contributed this 
code and he doesn't seem to be responding to requests for review and/or 
testing from us currently (testing is complicated because full testing 
requires windows clients on an NTLM network).


My request to platform folks:   Please review [2] and either

a) contact Carsten for review and/or testing

b) find persons and environment to regression test and do so

c) simply approve

Thanksinadvance,

Scott

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

[2] https://git.eclipse.org/r/c/ecf/org.eclipse.ecf/+/179005

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

[cross-project-issues-dev] httpclient update to 4.5.13

2021-04-09 Thread Scott Lewis


Howdy,

FYI:  There's been a request for ECF to update to httpclient version 
4.5.13, newly added to Orbit (currently at 4.5.12) [1]


This will very likely be the version in 2021-06 (Eclipse and simrel).

If any objections or concerns please note on [1].

Scott

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

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

Re: [cross-project-issues-dev] jarsigner/build.eclipse.org

2021-09-24 Thread Scott Lewis


Thanks Thomas.

On 9/24/2021 12:44 PM, Thomas Wolf wrote:

On 24.09.21 21:39 , Scott Lewis wrote:

Howdy,

I'm sure this is just me not paying attention to recent cbi/infra 
changes, so my apologies in advance.


See 
https://www.eclipse.org/lists/cross-project-issues-dev/msg18545.html .


[INFO] --- eclipse-jarsigner-plugin:1.1.7:sign (sign) @ 
org.eclipse.ecf.identity ---
[INFO] Signing jar: 
/home/jenkins/agent/workspace/ecf-tycho.master/framework/bundles/org.eclipse.ecf.identity/target/org.eclipse.ecf.identity-3.9.402-SNAPSHOT.jar 



[INFO] I/O exception (java.net.NoRouteToHostException) caught when 
processing request to {}->http://build.eclipse.org:31338: No route to 
host (Host unreachable)

[INFO] Retrying request to {}->http://build.eclipse.org:31338


Update to jarsigner 1.3.2.

Cheers,

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

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

[cross-project-issues-dev] jarsigner/build.eclipse.org

2021-09-24 Thread Scott Lewis


Howdy,

I'm sure this is just me not paying attention to recent cbi/infra 
changes, so my apologies in advance.


Our long-standing build has begun failing in jarsigner with these errors 
(no comm with build.eclipse.org):


[INFO]
[INFO] --- tycho-source-feature-plugin:1.7.0:source-feature 
(source-feature) @ org.eclipse.ecf.identity ---

[INFO]
[INFO] --- eclipse-jarsigner-plugin:1.1.7:sign (sign) @ 
org.eclipse.ecf.identity ---
[INFO] Signing jar: 
/home/jenkins/agent/workspace/ecf-tycho.master/framework/bundles/org.eclipse.ecf.identity/target/org.eclipse.ecf.identity-3.9.402-SNAPSHOT.jar


[INFO] I/O exception (java.net.NoRouteToHostException) caught when 
processing request to {}->http://build.eclipse.org:31338: No route to 
host (Host unreachable)

[INFO] Retrying request to {}->http://build.eclipse.org:31338

[INFO] I/O exception (java.net.NoRouteToHostException) caught when 
processing request to {}->http://build.eclipse.org:31338: No route to 
host (Host unreachable)

[INFO] Retrying request to {}->http://build.eclipse.org:31338

[INFO] I/O exception (java.net.NoRouteToHostException) caught when 
processing request to {}->http://build.eclipse.org:31338: No route to 
host (Host unreachable)

[INFO] Retrying request to {}->http://build.eclipse.org:31338

[WARNING] An exception has been thrown, but the request will be retried 
(attempt 1 / 3)

java.net.NoRouteToHostException: No route to host (Host unreachable)
    at java.net.PlainSocketImpl.socketConnect (Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect 
(AbstractPlainSocketImpl.java:399)
    at java.net.AbstractPlainSocketImpl.connectToAddress 
(AbstractPlainSocketImpl.java:242)
    at java.net.AbstractPlainSocketImpl.connect 
(AbstractPlainSocketImpl.java:224)

    at java.net.SocksSocketImpl.connect (SocksSocketImpl.java:403)
    at java.net.Socket.connect (Socket.java:591)
    at 
org.apache.http.conn.socket.PlainConnectionSocketFactory.connectSocket 
(PlainConnectionSocketFactory.java:75)
    at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect 
(DefaultHttpClientConnectionOperator.java:142)
    at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect 
(PoolingHttpClientConnectionManager.java:374)
    at org.apache.http.impl.execchain.MainClientExec.establishRoute 
(MainClientExec.java:393)
    at org.apache.http.impl.execchain.MainClientExec.execute 
(MainClientExec.java:236)
    at org.apache.http.impl.execchain.ProtocolExec.execute 
(ProtocolExec.java:186)

    at org.apache.http.impl.execchain.RetryExec.execute (RetryExec.java:89)
    at org.apache.http.impl.execchain.RedirectExec.execute 
(RedirectExec.java:110)
    at org.apache.http.impl.client.InternalHttpClient.doExecute 
(InternalHttpClient.java:185)
    at org.apache.http.impl.client.CloseableHttpClient.execute 
(CloseableHttpClient.java:72)
    at org.apache.http.impl.client.CloseableHttpClient.execute 
(CloseableHttpClient.java:221)
    at org.apache.http.impl.client.CloseableHttpClient.execute 
(CloseableHttpClient.java:165)
    at org.apache.http.impl.client.CloseableHttpClient.execute 
(CloseableHttpClient.java:140)
    at org.eclipse.cbi.maven.http.apache.ApacheHttpClient.lambda$send$1 
(ApacheHttpClient.java:81)

    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.ThreadPoolExecutor.runWorker 
(ThreadPoolExecutor.java:1128)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run 
(ThreadPoolExecutor.java:628)

    at java.lang.Thread.run (Thread.java:834)


Here's the maven metadata

Here's the maven metadata:

  
org.eclipse.cbi.maven.plugins
eclipse-jarsigner-plugin
    ${cbi-version}
    
  
    sign
    verify
    
  sign
    
  
    

  

build.eclipse.org doesn't seem to be available at all anymore. Could 
someone point to or clue me in about what changes are needed in our 
build to get jarsigner working again?


Thanksinadvance,

Scott


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

Re: [cross-project-issues-dev] Critical projects?

2022-01-17 Thread Scott Lewis


Another thought

https://www.zdnet.com/article/for-security-alone-we-could-try-paying-open-source-projects-properly/


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

[cross-project-issues-dev] Critical projects?

2022-01-14 Thread Scott Lewis


Hi Simrel folks,

As the lead of long-time participant project (ECF), I've personally 
experienced (as well as watched in horror) the problem of diminishing 
maintenance resources that now seems endemic to simrel projects and to 
the simrel itself.


I heard that yesterday there was a meeting at the White House about 
fears of the 'next log4j' [1].


Today I read this story [2] about Google and IBM suggesting a 'critical 
projects list' as a step toward (reportedly) a better model (read $) for 
ongoing maintenance of 'critical projects'.


My first thought:   Where is Eclipse, EF, simrel and supporting projects 
wrt this/these efforts?  Of course everyone thinks of their own project 
as 'essential' :), but more broadly I would be much more comfortable if 
the choices wrt 'criticality' and what is/is not 'infrastructure' were 
made based upon a clear representation of consumer needs.   It seems 
from the zdnet reporting (which may not be accurate of course) that 
mostly corporate and commercial concerns wrt open source maintenance are 
currently being identified.


I just wanted to raise this among the projects participating in the 
simrel.   I'm not sure how any of this is going to be approached, but am 
hoping that the simrel project leads and teams can find a way to 
participate in these efforts, as I think there is a huge amount of 
knowledge and experience here about open source maintenance via 
transparency, successful, scalable, community collaboration.


Scott

[1] 
https://www.zdnet.com/article/after-log4j-white-house-worries-about-the-next-big-open-source-flaw/


[2] 
https://www.zdnet.com/article/log4j-after-white-house-meeting-google-calls-for-list-of-critical-open-source-projects/


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

51 matches

Mail list logo