Re: [cross-project-issues-dev] [orbit-dev] Retiring EBR

[Gunnar Wagenknecht]

> On Jan 11, 2023, at 19:44, Christian Dietrich  
> wrote:
> As our releng at Xtext is quite complex and i am alone and have nobody to 
> consult i dont know how to solve all the problems that i see with the maven 
> dependencies in target feature
> 
> https://github.com/eclipse/xtext/issues/2133
> 

If Xtext is consuming Orbit from its p2 repository then it should be possible 
to use the solution Ed is working on as a future technology for Orbit. Orbit 
could be the producer of that shared (central?) p2 repository. The task for 
updating versions becomes even easier.

-Gunnar

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



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

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

[Gunnar Wagenknecht]

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

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

-Gunnar

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



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

Re: [cross-project-issues-dev] Sad News

[Gunnar Wagenknecht]

My deepest condolences to Kit's  family and colleagues. It's sad to hear this. 

-Gunnar

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



> On Mar 1, 2022, at 16:42, Pradeep Balachandran  wrote:
> 
> Dear Friends, 
>  
> I have a sad news to share. 
>  
> Kit Lo, Technical Lead for IBM Eclipse SDK, based out of IBM RTP lab, passed 
> away on Saturday, Feb 26th. He was on a routine run on Saturday and collapsed 
> on the way. Kit has been with IBM for 32+ years, working in various roles and 
> different teams. In the past decade, Kit was the lead for Translation / 
> Globalization efforts across various products. About 5 years ago, Kit took up 
> the IES Technical Lead role. Kit was a very hard worker, continuous learner 
> and always willing to go the extra mile to help those in need. Kit was also 
> very active in Eclipse Open Source Community. He was the co-lead for Eclipse 
> Babel project (community driven translation of strings in Eclipse 
> distribution) and in the past year, he also took up the additional role of 
> Eclipse IDE Release Engineer. 
>  
> We in the Eclipse team in IBM, are still trying to come to terms with the 
> fact that Kit is no longer with us. Kit was a great friend, mentor and guide 
> for those who worked closely with him. We are lucky to have worked with him. 
> Kit will be sorely missed. 
>  
> Pradeep
>  
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto:cross-project-issues-dev@eclipse.org>
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev 
> <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] P2 site mirror for Eclipse builds

[Gunnar Wagenknecht]

> On Feb 21, 2022, at 16:23, Mikael Barbero 
>  wrote:
>> Do we have an artifactory at eclipse which could provide a mirror of
>> the p2 site?
> 
> No.

I think Nexus can also be a mirror.

If this is affecting multiple Eclipse projects and/or EPP - perhaps mirroring 
of such dependencies can become a responsibility of Orbit?

-Gunnar

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



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

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

[Gunnar Wagenknecht]

> On Jan 13, 2022, at 10:55, Aleksandar Kurtakov  wrote:

> IMHO, people should actively remove content from Orbit that has CVEs. Much 
> like with any other project. Even without replacing it with a fixed version. 
> We will be better with less but trusted content than questioning ourselves 
> for each artifact.

Agreed. There is usually a clean-up/removal of unneeded stuff. But the 
downloads are still available for projects consuming the repositories. 

> >[...] That is definitely something 
> > new, since Orbit was a trusted source of 3rd party libraries for many 
> > years.


That's a misconception. Orbit essentially is like Maven Central. Instead of 
Maven Artifacts it distributes Eclipse plug-in artifacts. Maven Central still 
distributes the vulnerable Log4j version and ton of other libraries with CVEs. 
Does that make it a less trustworthy source now? I don't think so. Consumers 
still need to stay on top of those.

-Gunnar


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


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

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

[Gunnar Wagenknecht]

Thanks Matthias!

According to Wayne, 2.15 has already been vetted and is good for use:
https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html 
<https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html>

-Gunnar

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



> On Dec 11, 2021, at 20:36, Matthias Sohn  wrote:
> 
> On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht  <mailto:gun...@wagenknecht.org>> wrote:
> Alexander,
> 
>> On Dec 11, 2021, at 10:16, Alexander Fedorov > <mailto:alexander.fedo...@arsysop.ru>> wrote:
>> It would be great to learn vulnerability clean-up process with Eclipse Orbit 
>> team to then apply it to Eclipse Passage.
> 
> 
> There is no Orbit team. Orbit is driven by project committers using/needing 
> libraries in Orbit.
> I encourage the Eclipse Passage project to submit a Gerrit review for a newer 
> version.
> 
> considering the buzz around this vulnerability I went ahead and pushed an 
> update to log4j 2.15 for orbit
> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768 
> <https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768>
> note that the required clearlydefined score isn't reached yet, if this 
> doesn't change soon
> maybe someone can contribute the missing information to clearlydefined or
> we file CQs to get the license approval for the new version
>  
> You can also try a new way as described by Mickael here:
> https://www.eclipse.org/lists/orbit-dev/msg05509.html 
> <https://www.eclipse.org/lists/orbit-dev/msg05509.html>
> 
> -Gunnar
> ___
> orbit-dev mailing list
> orbit-...@eclipse.org <mailto:orbit-...@eclipse.org>
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/orbit-dev 
> <https://www.eclipse.org/mailman/listinfo/orbit-dev>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

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

[Gunnar Wagenknecht]

Alexander,

> On Dec 11, 2021, at 10:16, Alexander Fedorov  
> wrote:
> It would be great to learn vulnerability clean-up process with Eclipse Orbit 
> team to then apply it to Eclipse Passage.


There is no Orbit team. Orbit is driven by project committers using/needing 
libraries in Orbit.
I encourage the Eclipse Passage project to submit a Gerrit review for a newer 
version.

You can also try a new way as described by Mickael here:
https://www.eclipse.org/lists/orbit-dev/msg05509.html 


-Gunnar___
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] IMHO serious issues in the Eclipse Java IDE 2021-06 M3

[Gunnar Wagenknecht]

It looks like the Maven issue is caused by conflicting SLF4J API versions in 
the installation.

The problematic SLF4J API version is brought into the build by the Eclipse 
project.
https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

-Gunnar


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


> On Jun 2, 2021, at 09:23, Holger Voormann  wrote:
> 
> Hi all,
> 
> IMHO the following two issues of the Eclipse Java IDE 2021-06 M3 are serious, 
> since they probably affect many and since there are no known workarounds for 
> them:
> 
> 1. Empty Maven console
> https://github.com/eclipse-m2e/m2e-core/issues/182
> 
> 2. Creating of a Gradle project via the "New Gradle Project" dialog is broken:
> https://github.com/eclipse/buildship/issues/1077
> 
> 
> In contrast, the following two issues, which I guess will also affect many, 
> are not serious from my point of view, since workarounds are known:
> 
> 3.
> [JEE] .js files opened by default in the Text Editor instead of in the 
> Generic Text Editor
> Workaround: right-click a .js file + "Open With > Other...", select "Generic 
> Text Editor" and choose "Use it for all '.js' files"
> https://eclip.se/573902
> 
> 4.
> WindowBuilder does not work with Java 16
> Workaround: in "eclipse.ini" add the line "--illegal-access=permit"
> https://eclip.se/572210
> 
> 
> It would be great when these issues could be fixed for the 2021-06 release.
> 
> 
> Thanks,
> 
> Holger
> ___
> 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] RAP Tools disabled because of conflicts with Eclipse Platform 4.20 M1 contribution

[Gunnar Wagenknecht]

Are we inventing another way to avoid adding it to Orbit?

Mind everyone that Orbit is not about using/enforcing a specific technology. 
Whatever produces a p2 repo with signed content would work.

-Gunnar

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


> On Apr 13, 2021, at 09:02, Christoph Läubrich  wrote:
> 
> I think Alexander might give some insight if there are other alternatives, 
> but if you are using recent tycho + recent eclipse you can simply copy the 
> "locations" from this file:
> 
> https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736/17/jetty.repository/jetty.target
> 
> into your target and have the jetty ones available.
> 
> Mickael also has written a tool to create a P2 site that mirrors Maven deps, 
> so if such a thing is available it is just a matter of uploading it to some 
> web-server or reference it via file:/... somewhere.
> 
> 
> Am 13.04.21 um 08:56 schrieb Ed Merks:
>> Markus,
>> Apparently this is not trivial.  It looks like for 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569804 the following was added 
>> during the move to 10.x:
>> https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736
>> That provides a new project:
>> https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/jetty.repository
>> Apparently that helps provide the Jetty dependencies.  It seems to me 
>> infeasible though for all the downstream projects that also depend on Jetty 
>> to replicate all this infrastructure.  Surely there should just be a Jetty 
>> 10.x p2 repository we can all reuse...
>> On a related note, I've tried to get the attention of someone human being on 
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=572026 also because of a Jetty 
>> problem, but it seems no human being cares to respond.
>> Regards,
>> Ed
>> On 13.04.2021 08:31, Markus Knauer wrote:
>>> I started yesterday to look into this, unfortunately it'll take some time...
>>> 
>>> We used to consume Jetty from their 9.x p2 repositories, but with 10.x this 
>>> is not possible any more.
>>> 
>>> Eclipse Platform Team, how are you consuming the Jetty bundles now?
>>> That'll help us solve it on our side in the same way.
>>> 
>>> Thanks
>>> Markus
>>> 
>>> On Fri, 9 Apr 2021 at 18:14, Kit Lo >> <mailto:ki...@us.ibm.com>> wrote:
>>> 
>>>During Eclipse Platform 4.20 M1 contribution, we noticed conflicts
>>>with RAP Tools and new version of Jetty.
>>> 
>>>Requesting RAP Tools development team to take a look and re-enable
>>>RAP Tools contribution when the problem is resolved.
>>> 
>>>Regards,
>>>Kit Lo
>>>Eclipse Babel Project Lead
>>>IBM Eclipse SDK (IES) Technical Lead and Release Manager
>>> 
>>> 
>>> 
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, 
>>> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> 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] The "new user -> ECA -> signed-off by" workflow is broken

[Gunnar Wagenknecht]

> On Mar 4, 2021, at 16:47, Jesse McConnell  wrote:
> 
> I added an action item to discuss on AC call next week.

Thanks Jesse. I also added the other two items in the thread to the list.

For visibility, the bug (with further details) around "Signed-off by" is:
https://bugs.eclipse.org/558653

This requires change in IP policy. Nothing the AC can decide but we can capture 
our wish in our meeting notes.

For the others I am collecting ideas (preferably bug numbers that should be 
prioritized) that we can give to Denis & team.

-Gunnar

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



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

Re: [cross-project-issues-dev] Who decided to override my Java installation with JustJ?

[Gunnar Wagenknecht]

Christoph,

> On Dec 17, 2020, at 10:13, Christoph Läubrich  wrote:
> Even worse, if one builds for multiple targets justj is downloaded for each 
> target platform (e.g. linux, mac, windows) wasting a lot of bandwith, disk 
> space and time...

I cannot offer a solution to this issue but a workaround.

Instead of planner I use slicer and 
https://github.com/eclipse-cbi/targetplatform-dsl. It gives me much better 
control of what is in a target platform and is a better versional (and 
re-usable) syntax.

-Gunnar

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



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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Gunnar Wagenknecht]

> On Jan 29, 2020, at 12:44, Sebastian Zarnekow  
> wrote:
> 
> But in general, the current release cadence puts too much of a burden on the 
> shoulders of all maintainers.


As a project lead contributed to the train in the past and as a package 
maintainer, I truly disagree with the "too much of a burden" claim being raised 
here. Once you got all the things in place and compliant I don't ever recall it 
being a problem to put out new bits. 98% of it was automated anyway. It was 
push on Jenkins. The other 2% was bureaucracy in the portal.


> Platform and JDT used to be rock solid with the annual releases. Now we see 
> more releases but also more bugs and complains from users as far as I can 
> tell. Most of the people that I'm talking too are no longer confident in the 
> quality of the release. For them it's nowadays a tradeoff between the bugs 
> the suffer from and know of vs the bugs they will suffer from but don't know 
> yet.

There is some truth here but it really isn't that bad. I'd like to raise two 
things on the positive side, though.

1. The quality is in my subjective impression on par with - if not better - 
than the six-weeks milestone releases Eclipse had previously.
2. I don't have to wait for a full year till I'm able to consume a fix.

Yes, I do face a few bugs. Some of them are annoying. But I'd challenge if they 
are really a result of the faster release cadence *or* a result of funding 
downsizing in involved development teams.


> > Also annual releases will resurrect a number of "service releases" with all 
> > the effort required,
> 
> And with the quality gains. Exactly.

You will only see quality gains *if* the projects are willing to invest into 
maintaining a service branch. I have the impression that it's easier for the 
active projects to simply fix things in main/master and don't worry about back 
porting (which can double work).


In the past the SimRel had its clear purpose. It was a big win for the 
Foundation to be able to coordinate releases across its projects. It really 
made us look big in terms of numbers and successful (year over year at the same 
time, no delays). It came with a ton of bureaucracy. IBM thankfully dedicated 
full-time employees to creating and maintaining the SimRel.

I think it was already a risky decision to continue business as usual when the 
only FTE retired. There is a staffing issue at hand. I don't get the proposal 
of going back to one release per year. What is the solution if SimRel rans into 
a staffing issue again? One release every four years? I think a first step is 
to admit that we cannot maintain the existing process. There simply isn't 
enough funding.

We have to allow and ask the question - is it time to end the SimRel?

FWIW, as a package maintainer I don't care if I consume things from a central 
aggregated repository or from multiple sources. I maintain an EPP package as 
well as an internal distribution. Especially with the later I learned that the 
value of consuming things from the SimRel train repo is lower than I thought. 
Some SimRel participating projects publish updates more frequently to their own 
p2 repos. Some projects continue to think that only one certified version of 
Apache HttpClient, Guava, SLF4J, Commons Logging, whatever can be shipped with 
their release. SimRel never solved that. Things got much easier once I stop 
putting third party plug-ins into feature.xml files and started letting p2 
figure it out. Works great and dramatically reduced the burden to adopt to any 
new Eclipse release.

-Gunnar

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


___
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] Can SLF4J be made the official logging API for Eclipse projects?

[Gunnar Wagenknecht]

> On Jan 24, 2020, at 17:43, Christian Dietrich  
> wrote:
> 
> so this means for new versions we still need CQs?
> e.g. the current slf4j 1.7.30

As 1.7.x is approved and has a CQ this falls under the "service release" 
exception as mentioned! No CQ required.

-Gunnar



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



___
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] Text and / or Icons on Buttons / ToolbarItems

[Gunnar Wagenknecht]

> On Sep 25, 2019, at 16:44, Becker, Matthias  wrote:
> suboptimal UX

I think this statement needs backing by a UX research/study. 

To me, a growing use of icons (especially in addition to text) comes with a lot 
of drawbacks, eg., waste of screen space, make dialogs look way too busy, hard 
to read menu items because of all the colorful icons, removes screen estate. 
Icons serve a particular use case in identifying things. This works somewhat 
well in toolbars. It no longer works well in toolbars with more than 20 icons. 
Again, all personal opinions.

> And what about the eGit tooling? The “interactive rebase” view does use icons 
> and text heavily (and I really like that). Does eGit *not* belong to the 
> “IDE” you are talking about?

It's a decision done by eGit. I'd say it works pretty well in that specific 
case (given the limited set of options). I like that eGit follows common 
conventions and does *not* add buttons to its preference pages. :)

-Gunnar


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



___
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] How to deal with Gerrit changes with outdated ECA?

[Gunnar Wagenknecht]

Karsten, I think you should contact the EMO IP team. They will be able to 
review and decide on a case by case basis. Either email or open a CQ.

FWIW, I think the contribution is still fine. It was contributed at time X and 
the contributed had an ECA on file at time X. The Gerrit/Git hooks don't seem 
to handle that case very well. Thus, I think a manual review process is in 
order.

-Gunnar

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


> On Sep 25, 2019, at 12:38, Karsten Thoms  wrote:
> 
> I will try this for those I stumble over, but the question was more general. 
> What if they could not be contacted or don’t renew their ECA?
> 
>> Am 25.09.2019 um 12:15 schrieb Mickael Istria :
>> 
>> Hi,
>> 
>> Did you try contacting the author?
>> 
>> Cheers,
>> ___
>> 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] UI Monitoring

[Gunnar Wagenknecht]

> On Aug 23, 2019, at 07:55, Ed Merks  wrote:
> Or perhaps the self-hosted launch could be smarter to disable this 
> automatically?

https://bugs.eclipse.org550353

-Gunnar

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




___
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] Request for Respin 2019-06

[Gunnar Wagenknecht]

Christian,

Do you have a "bad impact" analysis if the release goes out with this old 
version of XText, eg., are there known regressions?

-Gunnar

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


> On Jun 18, 2019, at 09:27, Dietrich, Christian  
> wrote:
> 
> Dear PMC & cross-project members,
> 
> the Xtext team is apologising for speaking up in the quiet week of 2019-06.
> SimRel.
> 
> We currently have Xtext 2.18.0 M3 in the simrel since
> https://git.eclipse.org/r/#/c/143227/2/tmf-xtext.aggrcon was never
> merged after the simrel builder server downtime (around june 3rd) and
> it slipped through our minds.
> 
> The hints on the Xtext-Dev Mailing list last week we never saw cause
> the mailing list seems to be broken and i did not receive any mails.
> 
> We are hereby asking Eclipse Modeling PMC to support our request for a respin.
> 
> With kind regards,
> ~Christian
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://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] Bad p2.timestamp in http://download.eclipse.org/releases/2019-03/compositeContent.jar

[Gunnar Wagenknecht]

> On Mar 20, 2019, at 12:47, Frederic Gurr 
>  wrote:
> The RC2 (and GA) composite files contained more than one simrel repo for
> a long time (I stopped checking beyond Luna). If you think this is a
> bug, please open a Bugzilla issue for it.

I have a follow up question here. Let's continue at 
https://bugs.eclipse.org/545584 

-Gunnar___
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] Is jsch finally dead?

[Gunnar Wagenknecht]

It looks like. We use it in the IDE and in EGit.

See here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=540652 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=540652>

-Gunnar

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






> On Nov 2, 2018, at 02:19, Greg Watson  wrote:
> 
> This question has been asked before, but I think it's time to ask it again. 
> The last version of jsch was 0.1.54 in Sep 2016 and there doesn't seem to 
> have been any development since then. Given the number of projects that 
> depend on a decent ssh implementation, and the numerous bugs that still exist 
> in jsch, what are the plans for maintaining and/or replacing it?
> 
> Thanks,
> Greg
> ___
> 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] Github build issues

[Gunnar Wagenknecht]

Wim,

this mailing list is for communication/announcements regarding Release Train 
participation. I suggest trying cbi-dev@ or incubation@ so that the larger 
community can participate.

I appreciate your understanding.

-Gunnar

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






> On Nov 1, 2018, at 13:36, Wim Jongman  wrote:
> 
> Hi,
> 
> A question to the projects that have GitHub + Jenkins stack:
> 
> When a PR build fails in Jenkins for some network reason, how can it be 
> retriggered? I see a Rebuild in Jenkins but that seems like some beta plugin. 
> It does not work.
> 
> E.g. see:
> 
> https://ci.eclipse.org/nebula/job/nebula.stable.github/13/ 
> <https://ci.eclipse.org/nebula/job/nebula.stable.github/13/>
> https://ci.eclipse.org/nebula/job/nebula.stable.github/14/ 
> <https://ci.eclipse.org/nebula/job/nebula.stable.github/14/>  (this is the 
> rebuild)
> https://github.com/eclipse/nebula/pull/14 
> <https://github.com/eclipse/nebula/pull/14>
> 
> Cheers,
> 
> Wim
> ___
> 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] Online Meetings for Eclipse Projects

[Gunnar Wagenknecht]

Hi Simon,

This would be a nice question for incubat...@eclipse.org 
<mailto:incubat...@eclipse.org>. I'll answer there.

Best,
Gunnar


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






> On Oct 30, 2018, at 15:28, Wegendt Simon (AE/PJ-SW5) 
>  wrote:
> 
> Hi all,
>  
> Our projects would like to hold bi-weekly meetings in the open to discuss the 
> current project state and roadmap. Is there a meeting tool available for 
> Eclipse Projects with which we could do this? We need some tool that has 
> voice and video meetings. 
>  
> Best regards 
> 
> Simon Wegendt
> 
> Automotive Electronics, Software Campus 4 (AE/PJ-SW4) 
> Robert Bosch GmbH | Postfach 13 42 | 72703 Reutlingen | GERMANY | 
> www.bosch.com <http://www.bosch.com/> 
> Tel. +49 7121 353 66 50 | Mobil +49 1525 85 93 240 | Fax +49 7121 35-0 | 
> simon.wege...@de.bosch.com <mailto:simon.wege...@de.bosch.com> 
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar 
> Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr. 
> Christian Fischer,
> Dr. Stefan Hartung, Dr. Markus Heyn, Dr. Dirk Hoheisel, Christoph Kübel, Uwe 
> Raschke, Peter Tyroller 
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto: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 
> <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] Intermittent p2 failures, best practices for "mirroring"

[Gunnar Wagenknecht]

Kevin,

Tycho supports official mirrors specified in the p2 repository as well as 
internal mirrors. They have a user mailing list in case you need further help 
setting this up.
https://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors


FWIW, I'd like to take this as an opportunity to remind everyone about the 
purpose of this mailing list. It's for important communication for projects 
participating in the Eclipse Simultaneous Release. I prefer having discussions 
in the proper channels, which allow the whole community to participate (and 
potentially re-discover answers).


-Gunnar

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






> On Oct 25, 2018, at 16:37, Kevin Browder  wrote:
> 
> So we've been occasionally getting failures on 
> http://download.eclipse.org/releases/oxygen/201804111000/content.xml.xz and 
> other similar sites over this past week (including this morning EDT).  From 
> the archive I see this has been an issue this past week so I guess you guys 
> are doing something about it but I have some questions relating to setting up 
> a cache that may save you a small amount of bandwidth.
> 
> 
> Does tycho support some form of fail-over such that if we set up a cache for 
> p2 and that server goes down we can fail back to the internet?  I'm using 
> maven+tycho and at one point it seemed like adding multiple p2 repos didn't 
> really help for some cases of failure (the other repo wouldn't get tried), 
> but this was forever ago so maybe i'm miss-remembering or the situation was 
> very specific.
> 
> Also is there a preference for caching proxies for those of us who want to 
> stay on the FOSS side of things (even if we get support later).  I've used 
> Nexus 2.x (still do) but it's p2 support wasn't great at the time from what i 
> could tell; I'm looking a bit at Artifactory, is it worth switching?  There's 
> nexus 3.x as well
> 
> Any advice would be greatly appreciated
> Thanks
> Kevin
> ___
> 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] massive amount of unresolved bundles in 2018-09 M3 (JEE package)

[Gunnar Wagenknecht]

> On Sep 5, 2018, at 13:22, Martin Lippert  wrote:
> 
> org.apache.lucene.queryparser_7.1.0.v20180828-2118


This looks like https://bugs.eclipse.org/538546 


What other bundles are not resolving?

-Gunnar___
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] Anonymisation of public data

[Gunnar Wagenknecht]

Hi Boris,

I was one of the people asking off-list because I have a concern with 
encryption as a technology for anonymizing data. It immediately raises a red 
flag for me because it allows to de-anonymize the data. Thus, I would like to 
see use of data masking techniques such as hashing instead of encryption. To be 
more clear, I find it suspicious why reversible anonymization must be used in 
the first place.

Can you also be more specific about what public data and which API endpoints 
you are going to use?

I assume it's anything that is public in Git already, which makes this 
discussion obsolete as everything is already public. But I want to confirm that 
non of the API endpoints require authentication to get data you wouldn't get 
without authentication.

Best,
Gunnar

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






> On Apr 26, 2018, at 07:18, Boris Baldassari  wrote:
> 
> Hello good people,
> 
> In the context of the Crossminer research project [1], we plan to publish a 
> number of datasets to the public and for the research community. This 
> includes public data from the Eclipse forge (i.e. data is fetched from public 
> data sources and APIs only), and we want to setup an anonymisation process 
> that would:
> 
> * Efficiently and safely remove all personally identifiable data -- we don't 
> want to help spammers or malicious harvesters, and
> * Still provide valuable information and datasets for the research community 
> -- e.g. ability to identify identical IDs across sources without specifically 
> knowing them.
> 
> The basic idea is to simply replace all identifiers with asymmetrically 
> encrypted strings, so all IDs have the same ciphered result. RSA is used for 
> the encryption, and the private key is thrown away once the encoding is done, 
> making it impossible (according to common encryption standards) to retrieve 
> the original string.
> 
> A prototype has already been published [2, 3] and we would like to ask people 
> to review it so as to make sure that our privacy-preserving mechanism is safe.
> 
> Any feedback, concern or contribution is warmly welcome.
> 
> [1] https://www.crossminer.org/
> [2] https://github.com/borisbaldassari/data-anonymiser
> [3] https://borisbaldassari.github.io/data-anonymiser/
> 
> Thanks in advance, have a wonderful week!
> 
> --
> boris
> ___
> 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] Problems with signed jars on deployed p2 repositories

[Gunnar Wagenknecht]

It looks like you are running into this:
https://stackoverflow.com/questions/21218217/ssl-handshake-exception-algorithm-constraints-check-failed-md5withrsa

It's a disabled algorithm and potentially also a too short key.

-Gunnar

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






> On Apr 10, 2018, at 06:35, Karsten Thoms  wrote:
> 
> We are facing problems with signed jars in Xtext repositories [1] that fail 
> the jarsigner's verification. The problem was initially reported in 
> bug#533359 [2]. Initially it seemed that a specific Orbit library, 
> org.antlr.runtime, was affected, but running
>jarsigner -verify -strict
> on Xtext’s whole composite repository, and there are multiple other jars 
> suffering the same problem. I created a job on Xtext’s JIPP that lists result 
> of jarsigner: [3]
> 
> With additional verbosity of jarsigner’s output the following entries are 
> printed (full text in [1], comment#20)
>   [certificate is valid from 1/29/96 1:00 AM to 8/2/28 1:59 AM]
>   [CertPath not validated: Algorithm constraints check failed: MD2withRSA]
> 
> So how can this be? I’m not familiar with the details behind.
> 
> And how could this be fixed? Do we have to sign again all jars? How do we 
> come to valid repositories again?
> 
> Do other projects have similar problems?
> 
> Kind regards,
> ~Karsten
> 
> [1] 
> http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/ 
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=533359 
> [3] https://ci.eclipse.org/xtext/job/xtext-jarsigner-verify/3/consoleFull
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://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] Bug tracker for Jsch

[Gunnar Wagenknecht]

It looks like the JSch project is in a poor state. 

It has been a one-developer project. The developer did not make any 
contributions on GitHub over the last year.
https://github.com/ymnk <https://github.com/ymnk>

At this point it looks like your best bet is a fork and fixing the issues 
yourself or consider migrating to a more active project.
https://github.com/hierynomus/sshj <https://github.com/hierynomus/sshj>
http://mina.apache.org/sshd-project/sources.html 
<http://mina.apache.org/sshd-project/sources.html>

-Gunnar

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






> On Nov 15, 2017, at 08:02, Matthias Sohn  wrote:
> 
> Does anybody know where to report bugs for the Jsch project?
> 
> Thomas implemented several workarounds for Jsch bugs in JGit:
> * "Work around a Jsch bug: ensure the user name is set from URI" [1]
> * "Yet another work-around for a Jsch bug: timeouts" [2]
> 
> We would like to report these Jsch bugs to its maintainers in order to get 
> them
> fixed upstream but we struggle to find the bug tracker for Jsch. We also tried
> to cc Atsuhiko Yamanaka on bug 526778 but so far we got no response.
> 
> We found this bugtracker in SourceForge [3] but aren't sure if that's correct 
> since
> all bugs raised there in the last years didn't get any response and the last 
> bug
> was closed back in 2013. So it looks like this bug tracker was abandoned.
> I sent an email to JCraft (the company sponsoring the Jsch development) in
> order to find out where we can report bugs but this email bounced.
> 
> [1]
> https://git.eclipse.org/r/#/c/111359/ <https://git.eclipse.org/r/#/c/111359/>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=526778 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=526778>
> 
> [2]
> https://git.eclipse.org/r/#/c/111421/ <https://git.eclipse.org/r/#/c/111421/>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=526867 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=526867>
> 
> [3] https://sourceforge.net/p/jsch/bugs/ 
> <https://sourceforge.net/p/jsch/bugs/>
> 
> -Matthias
> ___
> 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] Eclipse Oxygen.1(a) video

[Gunnar Wagenknecht]

Thanks a lot Holger! I like it. :)

-Gunnar

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






> On Oct 16, 2017, at 11:08, Holger Voormann  wrote:
> 
> Hi,
> 
> I created an Eclipse Oxygen.1/Oxygen.1a video that shows some IDE 
> improvements in action:
> 
> https://youtu.be/wI3VC1lhbK8
> 
> - new Java 9 support (Oxygen.1a)
> - new JUnit 5 support (Oxygen.1a)
> - general bug fixes and minor improvements (Oxygen.1)
> - Gradle improvements (Oxygen.1)
> - PHP bug fixes and minor improvements (Oxygen.1)
> 
> Feel free to use it to promote Eclipse Oxygen (for instance, you could embed 
> the video in an article without attribution).
> 
> Thanks,
> 
> Holger
> ___
> 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] Info Center for Neon.3

[Gunnar Wagenknecht]

> On 13. Apr 2017, at 07:52, Frederic Gurr  wrote:
> I have to disagree on that one. I'm pretty sure that quite a lot of
> people rely on documentation for old releases.

Frederic, I'm basically challenging two things:

1) How different and relevant really is old documentation?

- I don't really by into the "misleading" or "confusing" argument
- API/JavaDoc as well as plug-in development doc is the same
- discovering features and api in newer doc could lead to additional motivation 
for adopting newer versions

2) Spending valuable Foundation resources on things only a small subset of 
people need

- IMHO IT time would be better invested focusing on a reliable infrastructure 
and services for projects and committers.
- If there are commercial interests in providing old documentation, companies 
should be able to come up with options themselves.
- (Commercial) products based on RCP/IDE rarely rely on help.eclipse.org - they 
either host or ship their own help.
- Help is (always was) included in old versions of Eclipse.

If I recall, the goal of help.eclipse.org was to have a public service 
committers/developers/contributors could link/refer to when helping other 
users. IMHO it's also a valuable source when searching/researching something.

Thus, in the interest of keeping things simple and being pragmatic, I suggest 
to only host the latest documentation on help.eclipse.org.

-Gunnar
___
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] Info Center for Neon.3

[Gunnar Wagenknecht]

One overall. Frankly, I don't see a need for presenting old documentation. 

-Gunnar

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






> On 13. Apr 2017, at 06:55, Frederic Gurr  wrote:
> 
> Just to clarify, ONE help center per release or overall?
> 
> On 11.04.2017 20:00, Gunnar Wagenknecht wrote:
>> I'm in favor of running just ONE help center labeled "latest".
>> 
>> We don't have an official SLA around packages. Especially when a new major 
>> release is out we stop providing builds of an older release.
>> 
>> -Gunnar
>> 
> ___
> 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] Info Center for Neon.3

[Gunnar Wagenknecht]

I'm in favor of running just ONE help center labeled "latest".

We don't have an official SLA around packages. Especially when a new major 
release is out we stop providing builds of an older release.

-Gunnar

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






> On 11. Apr 2017, at 03:22, Frederic Gurr  wrote:
> 
> Hi,
> 
> There was no feedback in two weeks, so I consider the info center for
> Neon.3 done.
> 
> I'd like to gather some opinions about the following question:
> 
> Should there be a separate info center for every release and service
> release (e.g. separate info center for Neon.0, Neon.1, Neon.2, Neon.3),
> or should there be only one info center per release with updated content?
> If this has already been decided and defined somewhere, please point me
> to it.
> 
> Regards,
> 
> Fred
> 
> On 28.03.2017 19:44, Frederic Gurr wrote:
>> Hi,
>> 
>> The info center for the Neon.3 release is now available here:
>> http://help.eclipse.org/neon3/index.jsp
>> 
>> As proposed in Bug 499411
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=499411), project's
>> participation in the info center has changed from opt-in to opt-out.
>> 
>> Compared to the Neon info center the following user
>> guides/documentations have been added in Neon.3:
>> 
>> * ACTF Visualization SDK Developer Guide
>> * ACTF Visualization User Guide
>> * BIRT Report Developer Guide
>> * BPEL User Guide
>> * BPMN2 Modeler Table of Contents
>> * Data Tools Platform Plug-in Developer Guide
>> * Data Tools Platform User Documentation
>> * ECF Remote Services Developer Guide
>> * Eclipse Marketplace User Guide
>> * EEF Javadoc
>> * EGF Eclipse Generation Factories Guide
>> * EGit GitHub Documentation
>> * GMF Developer Guide
>> * LDT User Guide
>> * Modeling Workflow Engine Reference
>> * RSE User Guide
>> * Sequoyah User Guide
>> * Shell Script Editor User Guide
>> * Sphinx Developer Guide
>> * Subversive User Guide
>> * Tcl/Xotcl Development User Guide
>> * WindowBuilder Pro User Guide
>> * Xpand Documentation
>> * XSD Developer Guide
>> * Xtend User Guide
>> * Xtext Documentation
>> 
>> The following user guides/documentations are included in the Neon info
>> center, but not in Neon.3:
>> 
>> * JavaServer Faces Tooling Developer Guide
>> * Oomph Utilities Documentation
>> * PTP Developer's Guide
>> * XSL Tools SDK Documentation
>> 
>> If any user guide/documentation should NOT be included in the Neon.3
>> info center or is missing in error (e.g. PTP) please comment on bug
>> 514345 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=514345).
>> 
>> If something is missing, please provide the full path and all files that
>> should be included.
>> 
>> 
>> Regards,
>> 
>> Fred
>> ___
>> 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

___
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] Subversive Dialog (was Re: Neon.3 Update Problems: To Fix and Howto Fix?)

[Gunnar Wagenknecht]

I think that's a good finding. 
https://bugs.eclipse.org/514585 <https://bugs.eclipse.org/514585>

-Gunnar

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






> On 31. Mar 2017, at 17:45, Doug Schaefer  wrote:
> 
> From what I can tell in my quick debug session, it looks like Mylyn (the 
> FocusedTeamUIPlugin)is causing Subversive to load on startup. And it’s 
> actually the bundle activators that kick off this dialog. I suppose ideally, 
> the dialog isn’t needed until an actual SVN repo is needed.
> 
> <6084765B-C032-4C27-9693-30026DBC6948.png>
> 
> From:  <mailto:cross-project-issues-dev-boun...@eclipse.org>> on behalf of Igor 
> Vinnykov mailto:igor.vinny...@polarion.com>>
> Reply-To: Cross project issues  <mailto:cross-project-issues-dev@eclipse.org>>
> Date: Friday, March 31, 2017 at 6:40 AM
> To: 'Cross project issues'  <mailto:cross-project-issues-dev@eclipse.org>>
> Subject: Re: [cross-project-issues-dev] Subversive Dialog (was Re: Neon.3 
> Update Problems: To Fix and Howto Fix?)
> 
>> Hi Ed,
>>  
>> Yes, that's correct, the dialog is displayed only when SVN features are 
>> accessed at the first time, i.e. you open SVN Repositories view, for 
>> example. I don't know why it is opened prematurely in Eclipse distributions 
>> - that's the question to integration authors.
>>  
>> Best regards,
>> Igor Vinnykov
>>  
>> From: cross-project-issues-dev-boun...@eclipse.org 
>> <mailto: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 Ed 
>> Willink
>> Sent: Friday, March 31, 2017 1:21 PM
>> To: cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> Subject: Re: [cross-project-issues-dev] Subversive Dialog (was Re: Neon.3 
>> Update Problems: To Fix and Howto Fix?)
>>  
>> Hi Igor
>> 
>> I just installed Subversive (without any extra integrations) in my workspace 
>> with many modeling projects. I performed a few GIT, CVS activities without 
>> seeing the Subversive dialog. It didn't appear till I opened an SVN 
>> perspective. Reasonable.
>> 
>> This suggests that
>> - Subversive SVN Team Provider is well-behaved
>> - platform / GIT / CVS are well-behaved
>> - some other project/integration is waking up SVN prematurely.
>> 
>> Regards
>> 
>> Ed Willink
>> 
>>  
>> On 31/03/2017 11:01, Ed Willink wrote:
>>> Hi Igor
>>> 
>>> I don't think that it is the Subversive dialog that is the problem; that is 
>>> a necessary inconvenience that you have agreed with Wayne.
>>> 
>>> The problem is the eagerness with which it is displayed. It should not 
>>> appear until the user has indicated that an SVN action is required. A 
>>> GIT/CVS only user should never see the SVN dialog.
>>> 
>>> Perhaps you are putting up the dialog too soon. Perhaps some other project 
>>> tickles all the team providers and so provokes your dialog into premature 
>>> appearance.
>>> 
>>> Regards
>>> 
>>> Ed Willink
>>> 
>>>  
>>> 
>>>  
>>> On 31/03/2017 10:49, Igor Vinnykov wrote:
>>>> Hello,
>>>>  
>>>> I've noticed the Subversive Connectors installation dialog on the 
>>>> screenshot, so are there any questions/problems regarding Subversive 
>>>> connectors distribution? This topic was discussed multiple times with 
>>>> EMO/Wayne, so I can continue this discussion if anybody is interested.
>>>>  
>>>> Best regards,
>>>> Igor Vinnykov
>>>> Subversive Team
>>>>  
>>>> From: cross-project-issues-dev-boun...@eclipse.org 
>>>> <mailto: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 Ed 
>>>> Merks
>>>> Sent: Friday, March 31, 2017 12:14 PM
>>>> To: eclipse.org-planning-coun...@eclipse.org 
>>>> <mailto:eclipse.org-planning-coun...@eclipse.org>; Cross project issues
>>>> Subject: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and 
>>>> Howto Fix?
>>>>  
>>>> Hi,
>>>> 
>>>> The original thread is fractured into many thr

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Gunnar Wagenknecht]

Ed, thanks for cross-posting. I seem to have missed Mickael answer below.

Mickael, my point to the zero predictability about packages was not related to 
the technical possibilities but to how the process is implemented today. If it 
was predictable there wouldn't be three different versions of http 
client/commons in the Oxygen Java/Committers package. With so many projects 
contributing to the repository it's just not predictable. Quite a bit 
communication/synchronization effort is necessary to harmonize versions across 
feature.xml of all participating projects.

-Gunnar

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






> On 31. Mar 2017, at 12:28, Ed Merks  wrote:
> 
> Mickael,
> 
> I believe this kind of direction should be given by the planning council.  
> What you're stating is your opinion (or a suggestion for a change in the long 
> established direction), but we've already heard David's opinion on this, and 
> it was one of caution.  Having managed release trains for years, I put a heck 
> of a lot of weight in David's informed opinions.  So at this point I don't 
> feel we (you) should not be prescribing a new solution to replace the old 
> solution, not until the planning council has determined and agreed that this 
> new solution does in fact solve enough old problems without introducing more 
> new problems compared to the old solution.   Of course I have no issue with 
> discussing new approaches, but best we consider carefully any new path we 
> take, and best we not prescribe a solution before its fully baked.  In other 
> words, I'm cautioning you not to draw a final conclusion.  I've already 
> pointed out some of the tricky questions that will arise, but they were far 
> down in a long note, so I'll repeat them here:
> 
> Don't include Orbit bundles in your project's features.  Sounds like a great 
> idea, but begs endless questions, and while solving a problem might well 
> introduce more new problems than it solves.  The first question (as Carsten 
> points out) is how do these things end up in a repository, and if they are in 
> a repository somehow, how are they categorized?  It's hard to get them in and 
> once you do, they're categorized poorly.  The next question is, how do they 
> end up in the release train, if the projects that need them don't contribute 
> them?   Directly from Orbit you say?  But which ones should be pulled in from 
> Orbit and how is that discovered?   Are those the ones the projects have 
> tested against? Then there is the question of whether an installation is 
> deterministic if the bundle version isn't pinned?  It's not; it will depend 
> on what's in the repos that are available at resolve time.  But Gunnar argues 
> that even packages are not deterministic, which I think is false: if the 
> feature pins the bundle version and the package requires the feature, then 
> the pinned bundle is definitely in that package.  But regardless, Gunnar's 
> important point is that the runtime wiring seems kind of non-determinstic, 
> and while uses constraints might help, who the heck understands those well, 
> what tooling produces it correctly for us, is that nicely integrated in PDE, 
> and will it be properly maintained (in contrast to lower bound constraints 
> which you can pretty expect will remain on whatever stale version they were 
> initially set to).  This may well be the right direction in which to go, but 
> getting there isn't going to be even half the fun...
> 
> Regards,
> Ed
> 
> 
> On 31.03.2017 11:53, Mickael Istria wrote:
>> On 03/31/2017 09:25 AM, Ed Willink wrote:
>>> Hi
>>> 
>>> It is currently necessary to rebundle Orbit bundles because Orbit is not 
>>> included in the xxx release repo.
>>> 
>> One can (and should) include the Orbit bundles in the p2 repo, but not 
>> include them in the feature. So the dependencies are available at 
>> install-time, but not constraining the resolution. The category.xml easily 
>> allows to add any bundle to a p2 repo, those could be Orbit ones.
>> -- 
>> Mickael Istria
>> Eclipse developer for Red Hat Developers <http://developers.redhat.com/>
>> My blog <http://mickaelistria.wordpress.com/> - My Tweets 
>> <http://twitter.com/mickaelistria>
>> 
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org 
>> <mailto:cross-project-issues-dev@eclipse.org>
>> To change your delivery options, retrieve your password, or unsubscribe from 
>> this list, visit
>> https://dev.ecl

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Gunnar Wagenknecht]

> On 31. Mar 2017, at 09:32, Ed Willink  wrote:
> 
> Unfortunately, in some cases specifying that XYZ requires a minimum 1.2.3 
> version gets converted by some builder into exactly 1.2.3 making re-use 
> across Eclipse releases impossible.

That's only the case for feature.xml includes, which has no relevance at 
runtime.

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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Gunnar Wagenknecht]

> On 31. Mar 2017, at 05:38, David Williams  wrote:

>> I think there is also another thing to consider. IMHO projects should stop 
>> hard-pinning specific 3rd party versions in the feature.xml -
> 
> This makes builds and installs non-deterministic.

I think our builds are non-deterministic now, i.e. there is no predictability 
what versions of a 3rd party bundle will be in a package and there is also zero 
predictability which Equinox will pick at runtime for resolving dependencies. 
Keep in mind that features are for assembling/installation but they have zero 
influence on the runtime resolution. 

That's why I'm proposing to defer the decision, what gets put into a package, 
to the package build time. We test packages not individual projects. 

Also, there are many projects that declare they require bundle XYZ with a 
minimum version of 1.2.3 in their dependencies. At the same time they also 
indicate that they are happy with any higher version. Thus, the argument that 
projects only run/support with a very specific version does not hold true. They 
may test with only one very specific version. They are - however - not very 
specific about that in their bundle dependency declaration. 

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

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

[Gunnar Wagenknecht]

> On 30. Mar 2017, at 19:10, Daniel Megert  wrote:
> I have never seen an announcement from Orbit that service release builds for 
> Orbit got dropped, but that seems to be the current reality, see 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19.

I'm not entirely sure we ever officially had a maintenance/service build story 
in Orbit. Shouldn't the retention policy keep old bundles in place so that 
projects referencing those would still consume them during the Neon series?

FWIW, I recall that David did create a "maintenance" branch for a Mars SR back 
in the days but that was more of an "ad-hoc" thing. I never remember using a 
maintenance branch in Orbit.

I think there is also another thing to consider. IMHO projects should stop 
hard-pinning specific 3rd party versions in the feature.xml - at least in the 
feature they submit into the common repo. This triggers p2 to install multiple 
versions into packages. We also have projects that update dependencies at 
different paces. This is concerning from a security perspective. Should we 
consider something more drastic like target platform filtering when building 
the packages?

-Gunnar
___
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] Repo.eclipse.org downtime Monday Mar 27 at 10am EDT (4pm CEST)

[Gunnar Wagenknecht]

Great news! Thanks guys!

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






> On 23 Mar 2017, at 07:07, Webmaster(Matt Ward)  wrote:
> 
> Hi Folks
> 
>  Fred and I have finished building a new server to host the
> repo.eclipse.org virtual server.  The service will be offline for about
> 40 minutes while we transfer the data on Monday.
> 
> If you have any questions please let us know.
> 
> -Matt.
> 
> 
> ___
> 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] Guava 15/21 warning

[Gunnar Wagenknecht]

Ed,

I think a single global bug as well as cross-project is a bad place for 
discussing OSGi questions. We encourage our users not to open bugs for 
questions and be diligent and go the extra mile to do some research and reach 
out via forums. I believe as committers we should behave similar and also use 
such channels for questions and discussions to allow others participate and to 
lower the disruption for people relying on cross-project for 
announcements/project coordination. My apology if I get your intention wrong 
and you are not using cross-project as a general help channel for issues you 
have.

FWIW, I think your best bet right now is StackOverflow. There is a huge OSGi 
community there that can help answering your questions around uses constraint. 
If you feel there is a gap around tooling you could ask there as well what 
other people are using and/or suggest improvements to PDE (if you think there 
is a lack). I agree that uses constraint are almost impossible to get right 
manually. However, the PDE "Organize Manifest" wizard has a checkbox which 
works for straightforward cases.

-Gunnar

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






> On 14 Mar 2017, at 14:59, Ed Willink  wrote:
> 
> Hi Gunnar
> There is no problem with Orbit, given the need to allow Guava to be a 
> non-singleton.
> 
> If you have a technical solution that allows multiple Guava versions to 
> co-exist, please add it to Bug 437107. My current understanding is that 
> "uses" directives may be a solution but that no demonstration has been 
> performed and so the requirements for tooling are at best guesses and of 
> course not yet implemented. It is unlikleyt that any project currently 
> complies with any potential "uses" solution.
> IMHO Bug 437107 requires a solution, not a WONTFIX. Until we have a 
> demonstrable solution with associated tooling, I feel we need to stick with 
> the Luna 'solution'; all project's Guava dependency bounds include at least 
> an agreed version and only that version is bundled, so only that version is 
> used in practice.
> 
> Regards
> 
> Ed Willink

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

Re: [cross-project-issues-dev] Guava 15/21 warning

[Gunnar Wagenknecht]

> On 14 Mar 2017, at 14:34, Ed Willink  wrote:
> Please read the Bugzillas. 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862 
>  
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107 
> Both bugs are assigned 
> to nobody and in the Cross-Project component. I'm not sure who is 
> responsible. However, it seems impossible to address them as there is no 
> clear path to decide on. It looks like their main purpose is a sink for 
> discussions. I'd suggest closing them as WONTFIX. It doesn't look like 
> they'll ever be solved.

> The problem never occurs for individual projects. It only occurs when an 
> integrating project 'inherits' conflicting Guava loads from two distinct 
> component projects with Guava in the APIs.
> 
> So Mylyn only is no problem, but something that integrates Mylyn and Xtext 
> can encounter obscure failures when the wrong class is re-used on a code path 
> in which both are used.
> 

FWIW, there are technical solutions to allow projects to co-exist consuming 
different versions of Guava. Yes it is complicated and gets even more 
complicated when projects are re-exporting Guava as part of their APIs. But 
there are solutions that work.

If you believer there are specific problems with regards to the Guava libraries 
in Orbit please open a bug for Orbit with more details (eg., exceptions). We'll 
look at addressing them.

-Gunnar


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

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

[Gunnar Wagenknecht]

I can confirm the errors. Might be a bogus web node we are hitting.

-Gunnar

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






> On 14 Mar 2017, at 09:29, Pierre-Charles David  
> wrote:
> 
> Le 14/03/2017 à 09:25, Pierre-Charles David a écrit :
>> Both give the same kind of error messages than two days ago:
>> 
>> * https://bugs.eclipse.org/bugs/:  Internal Server Error
>> * https://git.eclipse.org/r/#/: 500 Internal server error
> 
> They seem up again, sorry for the false alarm.
> 
> ___
> 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] Something wrong with bugzilla?

[Gunnar Wagenknecht]

Hi Lars,

That's a sign that there is a replication issue or lag. But I cannot access 
Bugzilla at all currently due to an expired SSL certificate. Previously Chrome 
allowed me to ignore that but not this time it seems.

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






> On 6 Feb 2017, at 11:58, Lars Vogel  wrote:
> 
> Hi,
> 
> my Bugzilla Search Queries do not return my latest updates. First I
> assume bad network did swallow my updates but I just opened a bug for
> JDT and I'm not able to find it again via the search.
> 
> Is this a know issue?
> 
> Best regards, Lars
> 
> -- 
> Eclipse Platform UI and e4 project co-lead
> CEO vogella GmbH
> 
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: 
> http://www.vogella.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://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] Problem with org.apache.httpcomponents.httpclient bundle in Oxygen M5

[Gunnar Wagenknecht]

FWIW, there is an effort to modify the situation again:
https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04658.html 
<https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04658.html>

I agree that the situation is problematic. Are you relying just on the bundle 
symbolic name or are you also using import package in your manifests?

-Gunnar

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






> On 3 Feb 2017, at 18:33, konstantin.komissarc...@oracle.com wrote:
> 
> We are having troubling building our plugin against Oxygen M5. The 
> org.apache.httpcomponents.httpclient bundle in M5 build of root eclipse 
> project is missing org.apache.http.entity.mime package.
>  
> In M5 root Eclipse project repo, the version is 4.5.2 (771KB) and is missing 
> the mime package
> In M5 Orbit repo, the latest version is 4.3.6 (845KB) and does contain the 
> mime package
> On Apache.org <http://apache.org/>, the version 4.5.2 is 1226KB and does 
> contain the mime package
>  
> So, I have the following questions:
>  
> 1. Where did version 4.5.2 in root Eclipse project repo come from, as it’s 
> not in Orbit M5 build?
> 2. Why is this version missing org.apache.http.entity.mime package?
> 3. Why are we shipping a different bundle then what’s produced by the 
> original third-party project? Since we are using the same bundle symbolic 
> name, it’s a rather problematic situation.
>  
> Thanks,
>  
> - Konstantin
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org 
> <mailto: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 
> <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] Are restrictions on Bugzilla worse thanspam?

[Gunnar Wagenknecht]

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






> On 14 Nov 2016, at 16:22, Denis Roy  wrote:

> We're using re-captcha on the sign-up page, but since Bugzilla doesn't have a 
> moderation system it makes it an easy target. Since Bugzilla doesn't have a 
> clean bug deletion process either it makes a messy cleanup.


So it's humans creating accounts and then bots doing the spamming, isn't it? 
What would prevent those users from following the new process? Are you actually 
checking their email addresses?

FWIW, Eclipse.org <http://eclipse.org/> is not the only Bugzilla installation. 
There are many out there. I know you are really interested in fixing this. We 
spoke about options in Ludwigsburg. I think I found another one.

I see the RedHat folks have dealt with the same issue. It seems they found a 
solution to do spam detection on new bug reports before they hit the database. 
AFAIK, Bugzilla allows extensibility via plug-ins. Maybe they have such a 
plug-in for sharing?

See comment 2 here:
https://bugzilla.redhat.com/show_bug.cgi?id=1388782#c2 
<https://bugzilla.redhat.com/show_bug.cgi?id=1388782#c2>

Would it be possible to reach out to the RedHat folks and ask them for 
help/advice?

-Gunnar

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

Re: [cross-project-issues-dev] Are restrictions on Bugzilla worse thanspam?

[Gunnar Wagenknecht]

I agree with Mickael that the situation is not good for an open community. 
Manual moderation does not scale and it is an extra wall for contributing.

Wasn't there is a captcha mechanism in place which prevents robots from 
registering accounts? Can we please prioritize the work to get the account 
sign-up fixed so that only humans can sign up? 

-Gunnar

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






> On 12 Nov 2016, at 17:49, Daniel Megert  wrote:
> 
> The spam wasted at least half an hour of my time every day, so "NO", the spam 
> must not come back. NO WAY!
> 
> If you feel good about the spam I suggest you sign up as moderator for the 
> new accounts.
> 
> Dani
> 
> 
> 
> From:Mickael Istria 
> To:Cross project issues 
> Date:12.11.2016 17:07
> Subject:[cross-project-issues-dev] Are restrictions on Bugzilla worse 
> thanspam?
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> 
> 
> 
> TL;DR: Bugzilla restrictions block new contributors - that's worse than spam.
> Hi all,
> 
> A few weeks ago, because of a spam attack, access to bugzilla and ability to 
> report bugs and comment on bugs for new members was restricted. New members 
> now have to ask webmasters to be whilelisted and allowed to interact with the 
> community.
> 
> I've got some colleague who just registered and tried to contribute and 
> totally failed at it. The message about asking webmasters for whilelist 
> wasn't visible enough apparently so they didn't realize it was necessary and 
> just ended up  with an account which seem unusable to them. So I had to 
> forward messages in their name: 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=506244#c19 
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=506244#c19>
> Moreover, in that case, we're speaking about someone working on week-ends and 
> is ready to contribute on week-ends, and I don't expect webmasters to 
> promptly react to whilelisting request on week-ends. So even if the user 
> would have sent a mail, it could have requested days to be processed.
> If I had not been there to assist my colleague in contributing, he'd just had 
> given up. And I'm pretty sure that several other people have given up 
> contributing since the introduction of this "ask for permission" rule.
> 
> So IMO, the current state is by far worse than having spam. It makes the 
> community more difficult to join for new subscribers and appear more closed 
> than it is. A lot of effort were done in the past to "reduce barriers" from 
> users to contributors, and this Bugzilla thing goes to the opposite direction.
> Can we please have spam and new contributors again? And then consider 
> approaches that have worked for other tools to avoid spam? I don't get why 
> bugs.eclipse.org would be the only service for which reCaptcha wouldn't 
> work...
> 
> Cheers,
> 
> -- 
> Mickael Istria
> Eclipse developer for Red Hat Developers <http://developers.redhat.com/>
> My blog <http://mickaelistria.wordpress.com/> - My Tweets 
> <http://twitter.com/mickaelistria>___
> 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 
> <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
> 

___
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] [aeri] Change to how clients decide which error reports to send

[Gunnar Wagenknecht]

Thanks Marcel!

Comments inline...

> On 21 Oct 2016, at 16:27, Marcel Bruch  wrote:
>> - what is a reporter id?
> 
> A standard UUID. We generate it once per user-home. We use that information 
> to allow searches like “Give me all error reports ±5 minutes around this 
> error report” or to collect how many users actually hit a problem (to assess 
> its severity) etc.

Which is a nice metric. I'm wondering if it is as relevant as how ofter the 
same error has been hit (regardless of user count).

>> - is the reporter id an "opt-in”?
> 
> Yes and no. You opt in to send error reports w/ a uuid when you enable AERI 
> (announced and implemented so from day one).

So it is  opt-in. I don't see any issues then.

> FWIW, there is a change in progress that allows users to generate a fresh 
> UUID on every eclipse startup.

off-topic, but doesn't that make the metric mentioned above impossible?

-Gunnar



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


___
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] [aeri] Change to how clients decide which error reports to send

[Gunnar Wagenknecht]

Hi Marcel,

> On 21 Oct 2016, at 12:24, Marcel Bruch  wrote:
> I’m looking for your input on the second part: whether sending the 
> fingerprint of an error report to eclipse.org  before 
> the user explicitly agrees to send the error itself is considered a privacy 
> issue. My personal take is that the fingerprint itself does not contain any 
> reasonable private information. However, under some conditions committers may 
> be able to “see” which errors a user hits on his machine even if he does not 
> send the error report ( IFF we'd send the reporter id along with the 
> fingerprint or would track the reporter’s IP address - which we do not do!).

I find the last sentence confusing. :)

Can you clarify:
- what is a reporter id?
- how is it related to the proposal, i.e. checking for known error information 
as fingerprints?
- why is it necessary for the proposal?
- is the reporter id an "opt-in"?

Thanks!

-Gunnar

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

Re: [cross-project-issues-dev] Eclipse for Committers

[Gunnar Wagenknecht]

>> 1. Delete the "Eclipse for Committers" package entirely. Recommend that 
>> commiters install the "Eclipse Platform" build (or whatever package it is 
>> that builds  
>> http://download.eclipse.org/eclipse/updates/4.7-I-builds/
>>   ). Update the 
>> oomph scripts to install any extra stuff as part of the oomph install script 
>> rather than as part of the package.
> IMHO, that would make sense. Especially since there is an "Eclipse for 
> RCP/RAP developers" which contains a super-content of the "Eclipse for 
> Committers" one (and no, RAP isn't affecting badly UI nor performance as some 
> thought in the past).

There was informal discussion in the past to merge both into one single 
package. No action yet but I think it's still a valid idea.

> The "Eclipse for Committers" is indeed a bad name for Platform, because it 
> seems to be the standard package for committers, whereas it's actually not 
> the one that works for Platform.

The Eclipse for Committers package is not (and never was) intended as being a 
package just for "platform". It's a package intended for Eclipse committers 
working on projects within the Eclipse infrastructure. The bare platform 
missing essential things such as support for Git, Gerrit and Bugzilla.

It's actually not intended for self-hosted development of Platform UI. But I 
like

>> 3. Keep the current "Eclipse for Committers" package with its current 
>> contents and start running integration builds for it.
> EPP packages are built on any SimRel change, so what you're asking for here 
> is supposed to be available at 
> https://hudson.eclipse.org/packaging/job/oxygen.epp-tycho-build/ 
>  (when 
> there is a good build available).
> Maybe the Platform doc can be updated to recommend using such integration 
> build.

https://bugs.eclipse.org/453575  - this one is 
for a nightly build. However, I think "nightly" in the world of EPP sort of 
means aggregation of I-builds. It would be an aggregation of whatever projects 
submitted to the common repo. I don't think you should point directly to the 
Hudson job in the Platform doc. It's not a reliable piece of infrastructure. 
That's why there is the bug. We need some automation to publish good update 
sites / aggregations on a daily base.

-Gunnar___
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] New UUID in Eclipse Platform

[Gunnar Wagenknecht]

Ian, 

I agree with two concerns raised so far:

- communication way too late in the cycle
- opt-out instead of opt-in

I do understand that opt-in renders the feature pretty much useless.

On 04 Jun 2016, at 13:42, Ian Skerrett  wrote:
> We have no interest or plans to profile actual individuals. We are looking
> at aggregate data. 

I'm trying to understand why a UUID is necessary when you are looking at 
aggregate data. Do you have some sample reports/analysis for sharing? I'm 
really unable to connect the pieces of that puzzle. Maybe an example can help 
me understand.

Also, have you investigated using an anonymized (hashed version) IP address 
that is sent by the clients anyway? Splunk should well be able to handle that.

I also suggest to learn from history:
http://news.softpedia.com/news/Google-Chrome-to-Remove-Unique-ID-137535.shtml 

http://www.theregister.co.uk/2010/03/16/google_chrome_unique_identifier_change/ 


I bet they still have that UUID. But that's a use case I could understand. Even 
though I don't think that a UUID is really necessary to confirm successful 
installations/updates of a product.

-Gunnar___
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] including 3rd party jars on update site

[Gunnar Wagenknecht]

Hi Sam,

> [1] I can't find any relevant CQ for Mylyn. Do we need one?

You might not. From what it looks like, the dependency got approved for the 
Eclipse Platform. Mylyn is depending on and consuming the Eclipse Platform. You 
don't need CQs for 3rdparty dependencies introduced by your project 
dependencies.

> [2] It seems that this is caused by having ECF in our build target, but I 
> don't understand what is happening. We don't have ECF in our update site, so 
> why do we get it's dependencies?

The CQ linked is the Eclipse Platform. Have you checked the Eclipse p2 
repository? p2 seems to have picked the "latest". That's why it ends up in your 
repository.

> [3] The project downloads scanner doesn't flag 4.3 as a problem but it points 
> to CQs that are not for Mylyn 
> (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8934 and 
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8934). I would have thought 
> it would flag these jars unless there were CQs for Mylyn.

So, the download scanner uses an algorithm to detect possible 3rd party 
dependencies which where introduced by other Eclipse projects. For this to work 
it will look for org.eclipse.* bundles in your download directory and identify 
the Eclipse projects.  It then assumes that you depend on those projects. 

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

Re: [cross-project-issues-dev] Eclipse Shields Server

[Gunnar Wagenknecht]

Jens,

That's great project. It sounds like a lot effort though (custom server, 
separate hosting, etc.). Have you thought about submitting a pull request to 
have it supported out of the box by shields.io?

It seems that some services (such as Jenkins, Codeship.io, etc.) are done here:
https://github.com/badges/shields/blob/master/server.js 


-Gunnar




> On 18 May 2016, at 16:51, Jens Reimann  wrote:
> 
> Hi,
> 
> finally I had some time to make a "proof-of-concept" for an Eclipse
> Shields server. The idea is to have "shields.io" [1] like little images,
> which can easily be embedded into web pages, showing some information
> about Eclipse Foundation projects.
> 
> I did start with a basic shield which does show the project name and
> current released version. See it embedded in the README [2]
> 
> The solution is a plain Java EE project, re-using the project
> information which is already in the Eclipse PMI and which is accessible
> using JSON anyway. So there is no need to put in data twice.
> 
> Currently you can create shields using the following URL:
> 
> https://shields-ctron.rhcloud.com/project/   - e.g: project
> id = technology.package-drone
> 
> There are a few things missing, like caching, in order to reduce the
> load. But I do have a:
> - A running instance on OpenShift : https://shields-ctron.rhcloud.com
> (not very useful with additional parameters)
> - A project on GitHub [3]
> - An implementation for a Project/Latest version shield
> 
> Of course the missing stuff can be added quickly. More shield types and
> designs are not that hard as well.
> 
> But before I continue, I wanted to get some feedback if there is
> interest in such a service, if the project itself, including the source
> code and the service could/should be moved to the Eclipse Foundation.
> What additional shields would be of interest.
> 
> Let me know what you think
> 
> Jens
> 
> [1] http://shields.io/
> [2] https://github.com/ctron/shields/blob/master/README.md
> [3] https://github.com/ctron/shields
> 
> -- 
> IBH SYSTEMS GmbH
> D-85235 Pfaffenhofen an der Glonn
> Läutenring 43
> Geschäftsführer / CEO: Dr. Thomas Heitzig
> 
> Amtsgericht München
> Handelsregister Nummer  HRB 197959
> USt ID: DE267945175
> 
> Office Munich
> D 80992 München
> Agnes-Pockels-Bogen 1
> T +49 89 18 9 17 49 0
> 
> The information transmitted is intended only for the person or entity
> to which it is addressed and may contain confidential and/or pivileged
> material. Any review, retransmission, dissemination or other use of,
> or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you
> received this in error, please contact the sender and delete the
> material from any computer.
> 
> 
> ___
> 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] API enabled on wiki?

[Gunnar Wagenknecht]

Jay,

If I open the page it says: MediaWiki API is not enabled for this site. ...

Thus, I think it's disabled.

-Gunnar


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






> Am 11.02.2016 um 22:04 schrieb Jay Jay Billings :
> 
> Does anyone know if the programming API on wiki.eclipse.org/ is enabled? It 
> appears to generate the documentation page if I go to 
> wiki.eclipse.org/api.php, but logging in from a python client fails.
> 
> Thanks,
> Jay
> 
> -- 
> Jay Jay Billings
> Oak Ridge National Laboratory
> Twitter Handle: @jayjaybillings
> ___
> 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

[cross-project-issues-dev] Gyrex participation in Neon

[Gunnar Wagenknecht]

The Gyrex project will participate in the release train but obtain from the 
release train repo.

The message hasn't been very obvious, though.
https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg12503.html

-Gunnar

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






> Am 09.12.2015 um 21:50 schrieb Wayne Beaton :
> 
> Greetings all. For those project teams who are participating in Neon, here 
> are some important dates.
> 
> Dec 18/2015 - Opt-in deadline
> Feb 12/2016 - (Tentative) CQ Submission deadline (specify that the CQ is 
> required for Neon)
> May 26/2016 - (Tentative) IP Log submission deadline
> June 2/2016 - Review materials due
> June 9/2016 - End of Release Review Period
> 
> Note that I have confidence in the two IP-related dates, but have not yet 
> received confirmation from the IP Team (so these dates may change).
> 
> Also note that the opt-in deadline is approaching. AFAICT, the following 
> projects have not yet stated their intent to participate.
>   • Ecore Tools
>   • WindowBuilder
>   • Business Process Model and Notation (BPMN2)
>   • Eclipse Gyrex Project
>   • ATL - A Model Transformation Technology
>   • BPEL Designer
>   • BPMN2 Modeler Project
>   • Graphical Modeling Framework (GMF) Runtime
>   • Graphical Modeling Framework (GMF) Notation
>   • EMF Query
>   • EMF Transaction
>   • EMF Validation
>   • EMF Diff/Merge
>   • Eclipse Web Tools Platform Project
>   • Mylyn
>   • Amalgamation
>   • Graphical Modeling Framework (GMF) Tooling
>   • Eclipse Packaging Project
>   • Marketplace Client
>   • Target Management
> The process that we have established currently is that project teams must 
> announce their intent to participate on this list. Please provide a link to 
> the release record in the PMI and the participation offset. 
> 
> I did actually search the mailing list archives for many of these, but got 
> depressed and stopped looking after about a short while. If you've already 
> announced and I missed it, please accept my apologies and restate your intent 
> on this list.
> 
> The live list of participating projects is here:
> 
> https://projects.eclipse.org/releases/neon
> 
> If your project is listed without a version, please ensure that a release 
> record has been created and let me know. If you're not sure about the version 
> number, please make a good guess with the understanding that you can just 
> change the name/number in the record later and everything will work out 
> (references in the database are by record, not by any particular value).
> 
> FWIW, the reason why we made this explicit opt-in a few years ago was to 
> ensure that everybody was paying attention. Please prove that you're paying 
> attention. Feel free to chastise me if you feel that I've not been paying 
> sufficient attention (e.g. I missed your statement of intent to participate) 
> :-)
> 
> If you have any questions, please ask.
> 
> Thanks,
> 
> Wayne
> 
> -- 
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> <38x138_0.jpg>
> ___
> 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] Announcing JDK 9 support for Eclipse Neon

[Gunnar Wagenknecht]

Thanks Jay!

For anyone at JavaOne - come by the Eclipse Foundation booth. Wayne and I have 
it running on Neon and are showing it to anyone who is interested. 

-Gunnar

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






> Am 26.10.2015 um 04:50 schrieb Jayaprakash Arthanareeswaran 
> :
> 
> Hello everyone,
> 
> On behalf of the Eclipse team, I would like to share with everyone about the 
> beta support for JDK 9 in Eclipse SDK. The update, which is called "Eclipse 
> Java™ 9 Support (BETA) for Neon", can be installed from the following update 
> site or Eclipse Marketplace client. You need Eclipse M2 (build 
> I20150916-2000) or later to install the update successfully. Also note that 
> you need to run Eclipse with JRE 8 or 9 to receive the benefits of the update.
> 
> http://download.eclipse.org/eclipse/updates/4.6-P-builds
> 
> At this point, I would like to call out that JDK 9 is unlike any other JDK 
> versions of the past, notable change being the JAR files (with platform 
> classes) are giving way to a proprietary format. This update is not to be 
> confused with Java 9 support, though, which is about Java modules.
> 
> Regards,
> Jay
> 
> ___
> 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] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Gunnar Wagenknecht]

> Am 24.10.2015 um 07:56 schrieb Max Rydahl Andersen :

>> That brings up a good question ... The Gyrex project will continue to 
>> participate in the release train, but we'll no longer contribute to the 
>> release train repo.
> 
> may i ask why ?

We only contribute(d) "Target Components". It's easier for us (also from a 
support/maintenance perspective) to direct people to reference the repositories 
directly in their target platforms. It's also significant faster to load a 
smaller repo then composites. :)

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

Re: [cross-project-issues-dev] Did I mess up our procedure for Neon? With respect to declaring, and enablement, and our "list of participants"?

[Gunnar Wagenknecht]

David,

That brings up a good question ... The Gyrex project will continue to 
participate in the release train, but we'll no longer contribute to the release 
train repo.

-Gunnar


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






> Am 21.10.2015 um 07:01 schrieb David M Williams :
> 
> Just today I realized I think I was supposed to "disable" everyone, until 
> they responded affirmatively that they were participating in Neon. 
> 
> Since so many have declared their intent already, I hate to start over, by 
> disabling everyone, but, need to come up with a list of "those who have 
> declared intent", 
> and then I will disable the rest. 
> 
> Wayne have you been keeping track? So far, the list at 
> https://projects.eclipse.org/releases/neon
> only shows "Eclipse" is participating. I assume that's set to always be true. 
> :) 
> But the rest need someone to enter the data? 
> 
> If we can get a better list in next week or so, then by M3 I will disable 
> anyone who has not yet declared intent. 
> For example, perhaps BIRT is no longer planning to participate? (For all I 
> know?) 
> 
> 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 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] Announcing a one week slip in the Mars.1 release (from 9/25 to 10/2)

[Gunnar Wagenknecht]

David,

> Am 23.09.2015 um 23:37 schrieb David M Williams :
> If not obvious, this means all participants in "coordinated release train" 
> should not make your releases visible on 9/25, but wait until 10/2 10 AM to 
> make them visible, and announce your official releases. 

This seem unnecessarily restrictive. I don't bother with the announcement part. 
However, I don't recall there is something in the process that requires project 
to wait publishing the release bits. Not making them visible could have a huge 
effect on a project's adopter community.

-Gunnar

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







___
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] jetty versions - Another issue to feed on the topic of semantic versioning

[Gunnar Wagenknecht]

> Am 16.09.2015 um 21:09 schrieb Joakim Erdfelt :
> What would this support layer be call in the Eclipse Equinox?

Equinox does not provide such an implementation. However, if Jetty OSGi 
requires it to be present at runtime then there is like a CQ we could 
piggy-back for reuse. Thus, it shouldn't be an issue for other projects to 
consume the Apache Aries implementation.

However, I think it's a bit too restricted. As a workaround, I was able to get 
it working by using fragments without having to consume Apache Aries bundles. 
Now with the new headers in the manifest it's impossible because the bundle 
won't resolve.

-Gunnar


___
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] Error reporter and third-party code

[Gunnar Wagenknecht]

> Am 25.07.2015 um 14:08 schrieb Marcel Bruch :
> 
> I’ve no strong opinion on that yet (and likely the EF and legal will have to 
> final say). *My* current gut feeling is that it should be opt-in. Opt-outs, 
> however, will be more effective to get a comprehensive view.

Ha! I've struggled myself when writing this and decided on "opt out of 
filtering", which I translate to: filter vendor packages by default like today 
but can say "hey, don't hide my packages". ;)

-Gunnar
___
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] Error reporter and third-party code

[Gunnar Wagenknecht]

> Am 25.07.2015 um 06:32 schrieb Konstantin Komissarchik 
> :
> 
> > is opening and extending automated error reporting to non-eclipse.org 
> > plugins,
> > e.g. to member companies, worth these efforts?
>  
> In my opinion, it’s the only way to achieve the goals you set out to achieve 
> at the beginning of this project. Users view Eclipse as a whole that 
> encompasses third-party plugins and we need to act accordingly to remain 
> competitive.


Marcel,

What about a program that allows any vendor to "opt-out" of the filtering? It 
could be as simple as requesting a vendor to open a Bugzilla and/or submit an 
agreement form to the Eclipse Foundation listening the package namespaces which 
should not be filtered anymore.

-Gunnar

___
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] Error reporter and third-party code

[Gunnar Wagenknecht]

> Am 24.07.2015 um 08:27 schrieb Marcel Bruch :
> 
> Most reports mentioning Sapphire are from the namespaces 
> "oracle.eclipse.tools.*" and "com.liferay.*" Some reports show that Sapphire 
> clients even do not follow the bundle name to package name conventions. 
> Neither oracle.eclipse.* nor com.liferay.* seem to be open source namespaces.

How did you get that information? I thought it's currently not submitted to 
Eclipse.org or any other entity?

-Gunnar

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







___
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] Error reporter and third-party code

[Gunnar Wagenknecht]

Konstantin,

> Am 22.07.2015 um 13:01 schrieb Konstantin Komissarchik 
> :
> 
> Stack frames should not be considered sensitive just because they are from a 
> non-OSS code base. Users post stack traces with commercial code references in 
> forums all the time. 


Just because they "can" doesn't imply the are allowed to. There are all sorts 
of liability questions in here which I can understand as a reason to hide 
those. I think there is no other option. For most commercial code, the user can 
not simply allow disclosing such information but a vendor would have to approve.

Anyway, I have a different view on your particular topic, which might be a 
possible approach for other adopters.

Looking at the stack trace, I read it as some Sapphire code is initializing a 
data service which is implemented/provided by an adopter. That adopter calls 
some WTP code which fails. From a Sapphire perspective it shouldn't matter if 
it's a WTP issue, i.e. it's the adopter's code which is failing. This should be 
handled in a way that an adopter realizes it. For example, Sapphire should 
catch the root exception and wrap it into a Sapphire specific error message 
which is then either presented to the user or logged to a log file. From an 
Eclipse.org error handler perspective, this error message should probably then 
be marked as "log message". It really isn't Sapphires fault here.

BTW, the NPE in WTP is bad, though. But we simply can't now if it's a bug in 
WTP or if the adopter failed to initialize/setup some expected variables. But 
it should be the adopter investigating it.

-Gunnar


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







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

Re: [cross-project-issues-dev] Mars RC3 staging repository is done

[Gunnar Wagenknecht]

> Am 04.06.2015 um 05:35 schrieb David M Williams :

> == Only one unsigned bundle: 
> 
> javax.persistence_2.1.0.v201304241213.jar 
> 
> [And, I know WTP has been working hard to fix this ... so, I'm curious if 
> this is WTP's version, and the fix didn't make RC3? Or, if someone else 
> (Gyrex?) is 
> pulling in old, unsigned version?] 

Pyrex no longer contributes  EclipseLink and Gemini JPA and this bundle in 
particular to the release train repo.

> == Still a few are missing legal files: 

> org.eclipse.gyrex.rap.source_1.0.0.v20150506-0940.jar 
> org.eclipse.gyrex.rap_1.0.0.v20150506-0940.jar 

Thanks for the reminder. A new contribution is underway. :)

-Gunnar

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


___
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] jdt.core move to Java 7 BREE

[Gunnar Wagenknecht]

> Am 04.03.2015 um 13:53 schrieb Mike Milinkovich 
> :
> 
> On 04/03/2015 4:15 PM, Martin Lippert wrote:
>> I am not sure whether this “end of public updates” date reflects what is 
>> going on inside organizations.
>> Oracle still offers support for Java6 until Dec 2015, and extended support 
>> for Dec 2018.
>> 
>> http://www.oracle.com/technetwork/java/eol-135779.html#java-commercial-offerings
> 
> Sure. And I'm also sure if you pay Microsoft enough money you can get support 
> for Windows XP as well. That doesn't make it current.

And we have a solution for this too --> LTS. If someone wants support for 
Eclipse for an older version of Java, then LTS would be the obvious 
recommendation. :)

> I guess we just need to come up with a common definition of what we mean by 
> "current version".

I say: it should be every version receiving security updates public and free 
accessible for the community (committers, contributors and users). As of May 
2015, Java 7 will fall out of that list. But that's just my two cents.

-Gunnar

___
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] Maven Latest Upgraded to 3.2.5

[Gunnar Wagenknecht]

Hi HIPP/Hudson/Build Users,

The “latest” Maven symbolic link has been switched to Maven 3.2.5 now. Thus, if 
you are using “apache-maven-latest” in your build jobs, you’ll be now using 
Maven 3.2.5.

For details see here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=457416

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Observation: Frequent UI freezes when working with files

[Gunnar Wagenknecht]

Marcel,

This seems to be very low level detail. Do you know or can you see if this 
relates to some higher level operation being performed from within in the UI 
thread which shouldn't? 

-Gunnar

> Am 10.12.2014 um 14:53 schrieb Marcel Bruch :
> 
> Hi,
> 
> I just want to share an insight I got from reviewing several ui freezes. One 
> common cause for UI freezes are operations that touch the filesystem. For 
> instance, File.isFile, File.lastModified, or 
> WinNTFileSystem.getBooleanAttributes seem to be very expensive. From what I 
> read on the internet it seems that some of these methods (e.g. getAttributes) 
> may even take up to several seconds to return on windows systems.
> 
> 
> This has been discussed elsewhere in the internet [1] and seems to be a 
> long-standing issue in Java.
> 
> 
> 
> With this mail I’d like to make you aware of this (in case you did not know 
> this before) and would like to encourage you to actually not execute file 
> operations in the ui thread. We may also consider doing some kind of caching 
> but such a discussion would by far be over my knowledge, and thus, should be 
> left to discuss with the platform team. 
> 
> For now, I think we would benefit very much if every project that accesses 
> files/resources would review their code and think about refactoring some part 
> of the FileSystem work (even if it’s only checking a file’s attributes) into 
> background processes.
> 
> Best,
> Marcel
> 
> 
> [1] 
> http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance
> 
> 
> -- 
> Codetrails GmbH
> The knowledge transfer company
> 
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-179-131-7721
> http://www.codetrails.com/
> 
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Provider and feature names

[Gunnar Wagenknecht]

Tom,

> Am 17.11.2014 um 22:26 schrieb Tom Schindl :
> I disagree with you on that. I think it has value that the project name
> is in the feature name and the reason it simple: Better grouping on the
> p2-Update-UI!


Those points seems valid … but isn’t it insane how we constrain ourselves to 
drive a decision because of some broken UI? I actually prefer more descriptive 
feature names and stopped repeating the project name in features.

-Gunnar


-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





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

Re: [cross-project-issues-dev] https repository could not be resolved in Hudson HIPP job

[Gunnar Wagenknecht]

Hi,

AFAIK access to outside is only possible by using a proxy. But you’r project 
build shouldn’t depend on stuff that is hosted outside Eclipse.org 
<http://eclipse.org/>. Every dependency needs to go through the IP process and 
then consumed via Orbit or other means.

-Gunnar

> Am 17.11.2014 um 22:15 schrieb Ma Yue :
> 
> Dear all,
>   
>   I met some problem during the Eclipse Hudson HIPP build. Could you please 
> help?
> 
> It seems that the https repository 
> (https://www.artop.org/containers/artop-eel-update-site-1.0 
> <https://www.artop.org/containers/artop-eel-update-site-1.0>) could not be 
> resolved in Hudson HIPP job, so that the target definition could not be 
> resolved. (However, the target is resolved in local without any problem, but 
> only failed in Hudson.) I'm sure that this repository could be accessed. Does 
> anyone ever meet such problem?
> 
> This problem is detected when I created a new Mars build job. The https 
> repository could not be resolved for Hudson Mars build job. Then I checked 
> the Luna build job, and found that the Luna target (with the same https 
> repository) could be resolved before, but failed now and the cache is used 
> instead. The (Mars and Luna ) console output is as below: 
> 
> Mars build job:
> 
> [INFO] Adding repository 
> https://www.artop.org/containers/artop-eel-update-site-1.0 
> <https://www.artop.org/containers/artop-eel-update-site-1.0>
> [INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
> [INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] 
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.RuntimeException: Failed to resolve target definition 
> /jobs/genie.modeling.eatop/eatop-0.5-mars/workspace/tools/org.eclipse.eatop.targets/mars/mars.target
> [DEBUG] Closing connection to remote
> [ERROR] Internal error: java.lang.RuntimeException: Failed to resolve target 
> definition 
> /jobs/genie.modeling.eatop/eatop-0.5-mars/workspace/tools/org.eclipse.eatop.targets/mars/mars.target:
>  Failed to load p2 metadata repository from location 
> https://www.artop.org/containers/artop-eel-update-site-1.0 
> <https://www.artop.org/containers/artop-eel-update-site-1.0>: Unable to read 
> repository at 
> https://www.artop.org/containers/artop-eel-update-site-1.0/content.xml. 
> <https://www.artop.org/containers/artop-eel-update-site-1.0/content.xml.> 
> Connect to www.artop.org:443 <http://www.artop.org:443/> timed out -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error: 
> java.lang.RuntimeException: Failed to resolve target definition 
> /jobs/genie.modeling.eatop/eatop-0.5-mars/workspace/tools/org.eclipse.eatop.targets/mars/mars.target
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 
> 
> Hudson Luna build:
> 
> [INFO] Adding repository 
> https://www.artop.org/containers/artop-eel-update-site-1.0 
> <https://www.artop.org/containers/artop-eel-update-site-1.0>
> [WARNING] Failed to access p2 repository 
> https://www.artop.org/containers/artop-eel-update-site-1.0 
> <https://www.artop.org/containers/artop-eel-update-site-1.0>, use local cache.
> org.eclipse.equinox.p2.core.ProvisionException: Unable to read repository at 
> https://www.artop.org/containers/artop-eel-update-site-1.0/content.xml. 
> <https://www.artop.org/containers/artop-eel-update-site-1.0/content.xml.>
>   at 
> org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192)
>   at 
> org.eclipse.tycho.p2.remote.RemoteRepositoryCacheManager.createCache(RemoteRepositoryCacheManager.java:66)
> 
> Do you have any idea how to resolve this problem? Thank you in advance,
> 
> Kind regards,
> 
> Yue
> _______
> 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

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Cannot update the "Eclipse Standard" package anymore

[Gunnar Wagenknecht]

Hi Eike,

There is some discussion on https://bugs.eclipse.org/441957 (with a link to 
https://bugs.eclipse.org/381751). The idea is to add a p2.inf late in the Mars 
cycle which will allow updating from a Juno SR? to the new package in Mars. 
I’ve opened https://bugs.eclipse.org/446983 to track the effort.

-Gunnar

Am 13.10.2014 um 06:17 schrieb Eike Stepper :

> Hi,
> 
> I have noticed that the former "Eclipse Standard" package has recently been 
> renamed to "Eclipse IDE for Eclipse Committers". Personally I don't like the 
> new name because it suggests that this package contains something in addition 
> to the (classic) minimum which is only meant for committers and that seems 
> wrong. But more importantly, I think there were two things wrong with the 
> renaming process itself:
> 
> 1) The preceeding discussion took place in http://bugs.eclipse.org/443296 and 
> not on this list. IIRC not even a link to this bug was posted on this list. 
> As a result it seems that the decision was influenced/made by just a handful 
> people.
> 
> 2) This "renaming" wasn't just a change of the user-visible label and sorting 
> order but instead the fundamental IDs of the installable p2 units were 
> changed from "eep.package.standard" to "epp.package.committers"; to the 
> effect that existing Eclipse Standard installations cannot update to Mars 
> (M2) anymore, but fail with mysterious errors about Eclipse Compare conflicts.
> 
> Given that the Eclipse Standard package was by far the most downloaded 
> package by the end of Kepler and still among the 3 (or so) most popular 
> packages for Luna this change of the p2 ID seems extremely disruptive for a 
> very large group of users (must be millions) and I wonder if that was really 
> the intention.
> 
> If there's confusion about the good old "Eclipse Standard" package on the 
> download page I suggest to change its user-visible label on that download 
> page and possibly in the p2 metadata. But unless I miss an important point I 
> suggest to continue to provide package IUs with the existing ID 
> "epp.package.standard" and ideally even change Mars M2 to do so.
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> ___
> 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

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





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

[Gunnar Wagenknecht]

Gyrex will participate in the Mars release.

Offset: +3
Release: https://projects.eclipse.org/projects/rt.gyrex/releases/1.5-mars

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] I am wondering why some "project repos" are different than what's in "staging"?

[Gunnar Wagenknecht]

Hi David,

Thanks for bringing this up. In the case of Gyrex, the link in our b3 
aggregation file points to our composite repository of stable builds. I did do 
a rebuild as I was testing some stuff but that is not required to be picked up 
by the aggregation repo. The plan is to update the b3 file with the link to our 
release build once that is available. That will be the same content (but 
rebuild) we contributed to RC4.

-Gunnar

Am 15.06.2014 um 19:09 schrieb David M Williams :

> It appears GMF, Gyrex, and XWT (at least) have changed their project repo 
> contents after the final Luna build. And this was only a few days after the 
> final build last Wednesday ... I am not sure what it would look like right 
> now. This is disturbing for a number of reasons, and will require that we put 
> a higher priority on changing some of the processes we follow. Details are in 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=419746#c9 
> 
> But, I would like leads of GMF, Gyrex, and XWT to respond in the bug, to 
> explain what's different, and why it was changed. That's not to say we are 
> going to change Luna's staging repo, since no one asked for it, but I'd like 
> to better understand where communication has 'broken down'. Has the purpose 
> of the "aggregated repository" been forgotten (or, misunderstood)? 
> 
> Thanks, 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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

[Gunnar Wagenknecht]

Thanks Mike!

+1

I think it’s very important to raise the awareness. The steps look good and 
until we come to a conclusion about a potential new Kepler release, they seem 
like the only option to me.

-Gunnar


Am 27.03.2014 um 18:42 schrieb Mike Milinkovich :

> 
> I had previously posted this under the "Kepler SR3 for Java 8?" thread, but I 
> think that was a mistake. Rather than hijacking that thread I am going to 
> start a new one.
> 
> Just so everyone knows, the Eclipse Foundation is considering taking the 
> following steps to raise awareness of our Java 8 support. This is coming 
> partially as a result from feedback we got from this week's Javaland 
> conference in Germany where a number of developers made it very clear that 
> they had no idea that Eclipse supported Java 8 at all. Apparently only 
> announcing these things on our internal lists isn't sufficient :)
> 
> Please note that all of this will be done with exactly what we have today. 
> None of this will require any actions on behalf of the Eclipse, EPP or other 
> teams.
> We are going to create a Community Bulletin announcing Java 8 support that 
> will appear on our home page.
> We are going to create a web page which clearly documents how to get an 
> install our existing Java 8 support for both Kepler SR2 and the Luna builds.
> We are going to put a banner on the downloads page (e.g. "Looking for Java 8 
> support?") which links to (2) above.
> We are going to create an (or update the existing) Eclipse Marketplace entry 
> for the Kepler SR2 Java 8 feature 
> This will allow a drag-and-drop install into a Kepler SR2 workbench.
> This will allow discovery and installation via the Marketplace Client (MPC).
> We are going to make this Marketplace entry a "featured product" which will 
> make it visible on the Marketplace website and in the MPC.
> [TBC] We are going to make the Java 8 support a "featured download" to give 
> it some prominence on the download page.
> We welcome any comments or feedback.
> 
> -- 
> Mike Milinkovich
> mike.milinkov...@eclipse.org
> +1.613.220.3223
> 
> _______
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Versioning of artifacts in main and feature branches

[Gunnar Wagenknecht]

Hi Ken,

Am 06.02.2014 um 13:45 schrieb Ken Lee :

> Since some other project teams rely on the changes made in the feature 
> branch, we had to set up another CI build that also deploys the build 
> artifacts to the same Maven repository.

As you figured out already, maintaining different versions on feature branches 
is hard for merges and also prone to error. I think in the sentence above you 
describe the root cause of your problem. Artifacts from feature branches 
shouldn’t go into the master branch Maven repository. I suggest deploying them 
to separate, temp. repositories which you’ll throw away after merging the 
feature back into a branch. You could then work with profiles and local 
settings to make Maven using those repositories for look ups.

HTH,
Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org







signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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] m2e ponders participation in luna

[Gunnar Wagenknecht]

Hi All,

Am 16.12.2013 um 10:16 schrieb Mike Milinkovich :
> What I don't understand is that if these projects are mature enough to be 
> included in production versions of Maven, why don't you simply ask the 
> projects to do a Release Review to get to Mature status? It's not that much 
> work.

That’s clearly a valid option.

I just want to clarify that there are two different things:

  1. Participating in the release train 
  2. Distribution in the release train repo

Both things do not represent the same set of Eclipse projects. We did have 
Eclipse projects in the previous releases which did not participate in the 
release train but ended up in the release train repo because they were a 
required dependency. They are treated like all other 3rd party dependencies 
from Orbit - just JAR files then end in the repo. It must be proper releases 
with an approved IP-log, though. But that is no different than what we expect 
for 3rd party dependencies from Orbit. 

HTH,
Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Release train broken for MacOS?

[Gunnar Wagenknecht]

Hi Eike,

AFAIK you can only install into an ".app" folder if the product was also 
created as such. It’s some magic in p2 that is triggered when the root folder 
is set to ".app" (at build time). That deploys the MacOS launcher 
right into the root folder instead of a nested "Eclipse.app" folder.

-Gunnar

Am 10.12.2013 um 07:52 schrieb Eike Stepper :

> Thank you for the infos. I've found the code that causes my trouble. It's in 
> DirectorApplication.initializeProfile():
> 
>  if (org.eclipse.osgi.service.environment.Constants.OS_MACOSX.equals(os) 
> && destination.getName().endsWith(".app"))
>  {
>env += ',' + org.eclipse.equinox.p2.core.spi.Constants.MACOSX_BUNDLED 
> + "=true"; //$NON-NLS-1$
>  }
> 
> That implies (and I've tested) that the problem goes away if the destination 
> does *not* end with ".app". I'm not a Mac user myself and I have no clue what 
> the consequences are when I leave the ".app" out. Does it impact the way the 
> application is / can be started? Pascal told me that the cool Mac users 
> install into *.app folders because that would flatten out the nested 
> Profile.app folder somehow, which is true in my cross-platform Hudson build 
> for an RCP product. But I found that the Eclipse SDK always appears with a 
> nested Eclipse.app folder, whether the root folder ends with ".app" or not.
> 
> Fails: director -repository "http://download.eclipse.org/releases/luna"; 
> -installIU org.eclipse.sdk.ide -profileProperties 
> "org.eclipse.update.install.features=true" -p2.os macosx -p2.ws cocoa 
> -p2.arch x86_64 -destination *Eclipse.app*
> 
> Works: director -repository "http://download.eclipse.org/releases/luna"; 
> -installIU org.eclipse.sdk.ide -profileProperties 
> "org.eclipse.update.install.features=true" -p2.os macosx -p2.ws cocoa 
> -p2.arch x86_64 -destination *Eclipse*
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> 
> 
> 
> Am 09.12.2013 16:07, schrieb David M Williams:
>>> Is someone actively working on a fix?
>> 
>> It's hard to speak for "everyone", but I am not. Contributions welcome.
>> 
>> To summarize my understanding of the issue (which is easily the wrong 
>> understanding) is that p2 introduced this new IU
>> filter (macosx-bundled) that should be "transparent" to everyone; that we 
>> (in Platform, and Sim. Release repo) do not
>> want this "phantom IU filter"; we have no plans to support or provide it; 
>> and most important, I do not know how to "get
>> rid if it". (There's some vague suggestion that "every time a repo is 
>> mirrored it has to be filtered out" ... but I
>> don't really know what that means or why we should have to if "transparent" 
>> to everyone.)
>> 
>> You don't say ... are you trying to make use of the "macosx-bundled" filter? 
>> Or the legacy layout? If the former, I
>> think you can't ... if the latter, you may be able to refine your filter 
>> statement.
>> 
>> Again, contributions welcome, and bug 407588 is likely best place to discuss 
>> the issues.
>> 
>> 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

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Gyrex Participation in Luna

[Gunnar Wagenknecht]

Hi,

The Gyrex project would like to participate in Luna with its 1.4.0 release.
https://projects.eclipse.org/projects/rt.gyrex/releases/1.4.0

Our offset will continue to be +3.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





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

[Gunnar Wagenknecht]

Am 21.08.2013 um 21:07 schrieb David M Williams :
> But, more important, one of the ones listed was 
> org.eclipse.gemini.jpa_1.1.0.RELEASE.jar 


That has been reported during the Kepler builds and fixed for the next release. 
However, I don't think that will go into Kepler but maybe Luna.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Question on Kepler SR1 release review

[Gunnar Wagenknecht]

Am 14.08.2013 um 02:41 schrieb Matthias Sohn :
> AFAIK if you want to release a pure maintenance release (only bugfixes, no 
> new features)
> you don't need a release review, if you want to ship new features you need 
> the review.

Yes, this is correct. Technically, a pure maintenance (aka. service) releases 
changes only the 'x' of 'a.b.x' version string.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Future of Eclipse IDE

[Gunnar Wagenknecht]

Am 18.07.2013 um 22:17 schrieb John Arthorne :
> However Gunnar's comment says we are even failing on enabling contributors, 
> which vexes me. I actually thought we had made improvements on that in the 
> past couple of years. The Foundation and many committers have been working to 
> reduce barriers to contribution in any way possible.

Sorry John, I definitely didn't want to vex you. I just wrote about my personal 
experience I made a some time ago. So there is some history. But I agree, 
especially *you* and the platform team invested a lot into making contributions 
easier. I also understand that most of the time I was part of the crowd pushing 
you into this and I apologize for not attributing those efforts properly.

> Personally most the time I used to spend directly fixing user reported 
> problems, I now spend reviewing patches and trying to enable others to 
> contribute fixes instead.


Thanks!

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Future of Eclipse IDE

[Gunnar Wagenknecht]

Am 18.07.2013 um 09:59 schrieb Mickael Istria :
> Eclipse Foundation is IMO the only organization which is able to be efficient 
> at listening to the "market" of IDEs


I strongly disagree with this statement. There are many organizations as well 
as companies out there that can perform this equally efficient if not better. 
In fact, there used to be a company in the past. Also, anything the Foundation 
does is an investment as well. Simply put, in the end someone has to pay for 
it.  

BTW, when doing competitive analysis I also disagree with an earlier argument 
that some ide isn't free and therefore doesn't count. There are a bunch of 
people out there that would rather spend a two digit amount for something that 
helps them get their work done more efficiently. 

Anyway, just looking at the raw numbers, the issue is obvious. There were *a 
million* commits in the "eclipse" project (what I consider "platform") within 
three years back in 2004. It was only a good third in the last three years 
(2010-2012).
http://dash.eclipse.org/dash/commits/web-app/summary.cgi

Those commits went into a lot of things truly important for innovation higher 
up the stack (SWT, Text, JFace, Resources). SWT has been in maintenance mode 
since important committers left. Oracle is investing a lot into JavaFX. There 
is some shift towards the web. There is a lot innovation happening at Orion. 
Also, the diversification into areas such as M2M, Polarsys, etc. help the 
Foundation maintaining a steady interest in the Foundation model. But what does 
this mean for the IDE? 

Frankly, I think Orion is too early. There is still much attraction in native 
IDEs. We all have good ideas to improve the Eclipse IDE in ways we can. I've 
put energy into a proposal to address the preference issues within the 
packages. There is progress on this end. I've also put quite a bit energy into 
improving things in the past as well. There is only so much you can do as a 
single contributor not even working full-time on things. But I got frustrated 
along the way. Too much of the platform is still dominated and controlled too 
strictly by that one single company. Contributions got turned away because of 
the "lack of resources" argument and associated maintenance costs long term. To 
some point those arguments aren't completely invalid. I'm at a point of being 
resigned when it comes to contributing to the platform. 

Without a team that is sufficiently funded for an interesting time period, it's 
only the small steps we can do. I'm wondering if those small steps will be 
enough for the IDE to have a future. Well, being a German I am actually more 
concerned than wondering but I consider this a better thing than not caring at 
all. I really appreciate the time and energy people are spending on this 
discussion. 

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] 6 month release cycle

[Gunnar Wagenknecht]

Hi,

Am 03.07.2013 um 00:33 schrieb Henrik Rentz-Reichert :

> some more considerations:
> 
> If we accelerate the release cycle this would also put an extra burden on the 
> Eclipse legal staff, PMO and EMO (IP log approvals, release reviews...)
> Also, in my experience I need to start this process several weeks prior to 
> the planned release.
> A frozen IP log though means that I can't integrate 3rd party contributions 
> any more into the upcoming release.
> 
> Thoughts?

I wouldn't call it "burden" but "challenges". EMO (aka. Wayne) is already doing 
a great job of automating and streamlining as much of this as possible. We 
shouldn't plan our releases based on the process but optimize our process to 
allow for more frequent releases.

+1 to the general idea.

Big +1 to the idea of an "always current" aggregation repo that I can go to and 
fetch updates from. For me as a user it would be really nice to not track all 
projects individually.

The annual release still makes sense, though. It could become a stable baseline 
for LTS.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





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

[Gunnar Wagenknecht]

Hi Tom,

Am 26.06.2013 um 15:53 schrieb Tom Schindl :

> Now this repo misses at least 
> "org.eclipse.ecf.provider.filetransfer.httpclient" which was in the repo at 
> this location at least until yesterday!
> 
> Tom

It was removed very late in the cycle.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408915

Please migrate to HTTP Client 4 if possible. If not possible, than you need to 
look into the ECF p2 repo.

FWIW, there was still a chance to test it a bit. :)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=409818

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





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

[Gunnar Wagenknecht]

Am 05.06.2013 21:35, schrieb Wayne Beaton:

*Gyrex*
Missing about.html in file: org.eclipse.gyrex.*
Missing about.html in file: org.eclipse.gemini.jpa_1.1.0.RELEASE.jar


I've moved the discussion over to the relevant release tracking bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408623#c2

-Gunnar


--
Gunnar Wagenknecht
gun...@wagenknecht.org
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] build problems

[Gunnar Wagenknecht]

Am 19.04.2013 04:42, schrieb Greg Watson:

We're seeing this error on hudson. Is anyone else having problems?


We also have permission issues with our build. It seems that the ACLs 
permissions on /shared are all lost (in our case).


-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] Reminders for Juno SR2 final steps

[Gunnar Wagenknecht]

Am 22.02.2013 11:33, schrieb Markus Knauer:

- If I were a member of the EGit team, I would try to educate my users
how to upgrade to 2.3.1 via wiki, blog posts, newsgroup/forum, mailing
list, other channels...


They are trying really hard. But honestly, would you download a software 
that has a disclaimer next to the download link which says "hey, this is 
broken; you need to update afterwards"? IMHO, in the current state of 
SR2, such a disclaimer has to be put somewhere on the download page.


When it's really too late for SR2, the plan should be made for a SR2a.

-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] Reminders for Juno SR2 final steps

[Gunnar Wagenknecht]

Greetings,

I'm sorry if this has been brought up and discussed elsewhere already. 
But there is a severe bug in EGit that makes EGit 2.3.0 shipped in Juno 
SR2 a high risk for users.


See here for details:
http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html

Am 19.02.2013 18:04, schrieb David M Williams:

This week or next, update your b3aggrcon files with your "final
location" so the Juno aggregator could in theory be ran again. We don't
plan to, but, you never know. (And, don't forget to update Kepler, if
you are using the same input for that.)


Given that there is a severe bug in EGit. Isn't there a chance to update 
the repo and the packages with EGit 2.3.1?


I understand that it's very late in the game. But the packages will stay 
there forever on Eclipse.org for download by everbody. Those packages 
will contain an EGit version that contains a know bug which may delete 
uncommitted source code in a working copy.


-Gunnar

--
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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 readiness for Kepler M1

[Gunnar Wagenknecht]

Hi David,

Am 22.08.2012 07:09, schrieb David M Williams:
> Can some one explain to me what this is about? Some passive aggressive
> protest? Too many people take vacation all summer and don't even check
> Eclipse mailing lists?


Just one quick explanation for Gyrex. We anticipated to contribute our
current development stream to Kepler. However, one over our dependencies
decided to contribute a release with breaking changes to Kepler.

Thus, we are currently in a discussion to decide what we will do. There
are a couple of options. One is to align our planed release with RAP 2.0
and contribute that to Kepler. Another option is to continue with 1.2
and release it with RAP 1.5, migrate to RAP 2.0 after Gyrex 1.2 is
released and join the the release train with our 1.3 development stream
(which would be around Kepler M4ish).

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] Layout and licenses

[Gunnar Wagenknecht]

Hi,

Just to shed some lights into the issue. Gyrex requires Gemini JPA for
its EclipseLink JPA integration. Gemini JPA does not provide a p2
repository. Thus, it's in the Gyrex repo which is part of Juno.

Any ideas how to proceed?

Migrating to some external library just because Gemini isn't
participating in Juno seems wrong to me.

-Gunnar

Am 06.06.2012 15:48, schrieb Thomas Watson:
> I don't know anything about why gemini.jpa or gef3d are getting added to
> the repo, but this made me think about your question:
> 
> "If these bundles are in the repository, shouldn't the owning projects
> be Juno particpants?"
> 
> I don't know the correct answer, but it strikes me as odd that we allow
> non-eclipse third party dependencies to be added to the repo, but when
> it comes to a dependency on another project's bundles we force the other
> owning project to participate fully in the release.  What if the project
> does not want to participate?  What if there is an IP acceptable
> alternative (non-eclipse) project that could be used?  Would we prefer
> the use of that non-eclipse third party technology over the eclipse one
> simple because the owning eclipse project does not want to participate
> in the Juno release?  It seems to me that such cases should be treated
> as any other third party dependency and we should not force the owning
> project to participate in the release.
> 
> Tom
> 
> 
> 
> Inactive hide details for Wayne Beaton ---06/06/2012 08:17:55 AM---Hey
> folks. I'm going through the layout and licenses reportsWayne Beaton
> ---06/06/2012 08:17:55 AM---Hey folks. I'm going through the layout and
> licenses reports today.
> 
> 
> From:
> 
>   
> Wayne Beaton 
> 
> To:
> 
>   
> cross-project-issues-dev@eclipse.org,
> 
> Date:
> 
>   
> 06/06/2012 08:17 AM
> 
> Subject:
> 
>   
> [cross-project-issues-dev] Layout and licenses
> 
> 
> 
> 
> 
> Hey folks. I'm going through the layout and licenses reports today.
> 
> I've already opened a couple of bugs regarding missing about files and
> am just starting into the licenses. These issues need to be addressed
> before any reviews can be declared successful. Note that these are very
> basic requirements that are independent of participation in the
> simultaneous release. If you need help, please ask.
> 
> There a Gemini JPA bundle in the repository. I'm also seeing a GEF3D
> bundle. Why? If these bundles are in the repository, shouldn't the
> owning projects be Juno particpants? Or did I miss a memo?
> 
> org.eclipse.gemini.jpa_1.0.99.v20120225-1927.jar
> org.eclipse.gef3d_0.8.1.v20120528-0244.jar
> 
> Who owns these bundles:
> 
> org.eclipse.rephraserengine.core_8.0.0.201205300709.jar
> org.eclipse.rephraserengine.ui_8.0.0.201205300709.jar
> 
> (I'll guess tools.ptp.photran based on the version number).
> 
> Wayne
> -- 
> Wayne Beaton
> The Eclipse Foundation
> Twitter: @waynebeaton
> Explore _Eclipse Projects_
> ___
> 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] Yet another nag note ... and, I mean it this time!

[Gunnar Wagenknecht]

Am 24.05.2012 14:57, schrieb Thomas Hallgren:
> One could very well argue that an optional non-greedy dependency is 
> completely useless and doesn't fulfill any other 
> purpose but documentation.

We have a bunch of bundles in place that have optional non-greedy
dependencies to allow flexibility at runtime. For example, Logback can
be configured via API, XML or Groovy. Groovy as well as XML
configuration require additional dependencies. Imaging all those
dependencies were greedy.

BTW, they need to be optional for the bundles to properly resolve if the
dependencies aren't there. They need to be declared to allow the bundle
class loader to load them if they are available.

-Gunnar



___
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] Yet another nag note ... and, I mean it this time!

[Gunnar Wagenknecht]

Am 24.05.2012 11:33, schrieb Dennis Hübner:
> You say "must", is the last year default deprecated?

I think it's not explicitly deprecated. But it's "legacy". ;)

> However we have over 250 optional dependency entries in 53
> bundles, instead of creating 53 p2.inf files I used the x-installation
> instruction:
> ;resolution:=optional;x-installation:=greedy,

Yes, that works as well. It's a much easier way. However, I'm wondering
if the report should have detected those as "explicit" and not as "old
default". Are you using the new publisher?

> I tried to make our "product" behaves exactly the same as before the new
> default.

I don't know your product well enough. Are those optional dependencies
necessary for the product or the bundle as well? You may not need to
explicitly set the greedy setting everywhere. Sometimes the new default
is also ok.

IMHO a bundle uses 'resolution:=optional' to indicate either that a
dependency is only necessary when additional functionality is wanted (a)
or that additional functionality is available when the dependency is
available (b).

I see (b) purely as a user driven use case. For example, if Mylyn is
available then integrate with Mylyn but do not install Mylyn when my
bundle is installed. This use case should not use the greedy setting.

A packager might want to provide a "my feature + Mylyn" package. That
can be achieved by creating a feature (or product) which combines both.
But then greedy also isn't necessary because the feature.xml makes an
explicit reference.

For (a) some downstream consumer (another bundle) may require the
dependency because it knows that it calls some extended API that
requires the optional dependency. I think in this case the downstream
consumer should define a non-optional dependency anyway so greedy isn't
technical necessary.

HTH,
Gunnar

___
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] Yet another nag note ... and, I mean it this time!

[Gunnar Wagenknecht]

Hi,

Am 24.05.2012 09:19, schrieb Dennis Hübner:
> Sure there are greedy optional dependencies in the repository, because
> it often just intended by projects. I don't understand, why are you
> talking about *incorrect* greediness? "Not a default" it not the same as
> "wrong".
> IMHO this [1] report  is only useful for statistic purpose.

If it's really *intended* then the bundles should be listed under
"Optional runtime requirement with explicit greedy install." in the
report (or under "new publisher default" if optional dependencies are
included via feature.xml).

There are currently 337 bundles using the "old publisher default". If
the build system producing those bundles is updated to the new publisher
their installation behavior will change. With the new publisher their
optional dependencies will *not* be installed automatically anymore.
Thus, if installation of optional dependencies is really *intended* then
either greedy instructions must be added to p2.inf files or the optional
dependencies must be included within a feature.xml.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] Juno rt contribution

[Gunnar Wagenknecht]

Hi Borislav,

Am 15.03.2012 18:50, schrieb Borislav Kapukaranov:
> All my features and product are marked with the "magic iu" for RT features.

I suggest that you only tag the "Target Components" feature with the
magic IU. That should be the only feature that is "visible"
(categorized) in the Juno repository.

All other features (including your product) do not need to have the
"magic iu". They are usually not categorized/visible in Juno repository.
However, you can make them visible and categorize them in your repo as
you wish.

Thus, when installing using the director you usually don't pick the
"Target Components" feature. It should work then.

> 1. Can we contribute p2 products or just features are accepted?

In the case of RT it's usually just a "Target Components" feature.

> 2. Is the Orbit p2 repo aggregated in the Juno repo - I couldn't find
> some of my required dependencies until I added the Orbit repo along with
> the Juno one to my composite p2 repository?

You have to include them in your product and either mirror them into
your repo or reference Orbit.

> What is the standard procedure in this case, should I package these
> bundles with my features?

Same as with Orbit. I mirror them into my project repo because I don't
reference the Equinox repo in my composite repo. But that may be the
better option (in terms of disc space duplication).

-Gunnar
___
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] jobs having more than 15 old builds

[Gunnar Wagenknecht]

Am 24.02.2012 08:18, schrieb Matthias Sohn:
> I hope this is a temporary measure. For the egit and jgit *.gerrit jobs
> we would 
> like to keep a pretty large number of old builds (something like builds
> of the last 30 days) since these are builds done for code review and when a 
> change stays a bit longer in review and the build results disappear
> before the 
> review is finished this may require rerunning the build for these
> changes which 
> would consume unnecessary cycles of both the involved developers and 
> Hudson.

Matthias, can't you archive those important results/reports to the
"/shared" file system location on the build machines? This makes them
also available via HTTP to the developers/committers.

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

Re: [cross-project-issues-dev] p2.mirrorsURL property - how do different projects handle this?

[Gunnar Wagenknecht]

Am 18.02.2012 12:54, schrieb Stephan Herrmann:
> From the p2 documentation I don't see any connection between
> the ant taks you cite and this question. Am I missing anything?

The template artifact.xml contains the mirrorURL with a placeholder and
is empty. At build time, the placeholder is replaced with the proper
mirror url coresponding download location. When mirroring the IUs to the
download location, p2 then includes the mirror url from the template. I
like this approach because it doesn't require unpacking, manipulating
and re-packing the final metadata jar.

-Gunnar


-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] p2.mirrorsURL property - how do different projects handle this?

[Gunnar Wagenknecht]

Am 17.02.2012 21:22, schrieb Jeff Johnston:
> Do any other projects out there have any insights on how to do this more 
> efficiently/automatically?

We use the p2 mirror Ant task. It allows to specify a template
repository using the "format" parameter.




  
...
  




  
  
  
  ...


-Gunnar
___
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] Heads up for early Juno M6 aggregation breakage due to dependencies on "Indigo Platform"

[Gunnar Wagenknecht]

Hi David,

Am 02.02.2012 23:17, schrieb David M Williams:
> In the types of cases I mentioned, such as if a bundle depended on
> org.mortbay.jetty.server, then a build (or, test, I'd think) would fail on
> Juno and but succeed on Indigo and would require some type of change
> (perhaps different streams, or perhaps just a change of "packaging").

I think "org.mortbay.jetty.server" is a bad example. It's still active
in terms of Orbit builds and AFAIK there are no plans to remove it from
Orbit for Juno. Thus, it's still possible for everybody to consume in
Juno (IMHO).

I think the critical part is an Eclipse project which is depending
(including) an old version of another Eclipse plug-in in its submission
to the common repo. Thus, bringing the Indigo version of an Eclipse
project into the Juno repo. Is that the case?

-Gunnar
___
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] Hudson slave1 blocked?

[Gunnar Wagenknecht]

Am 14.12.2011 14:38, schrieb Denis Roy:
> Just catching up here...  Do I need to restart all of Hudson?

Yes. Please. I got tons of errors on the other slaves.

-Gunnar


-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] Hudson change

[Gunnar Wagenknecht]

Hi Eike,

Am 12.12.2011 07:44, schrieb Eike Stepper:
> Webmasters, wouldn't it be possible to make the jobs/ area, which is now 
> local to the master, somehow readable from 
> build.eclipse.org?

When our build is done, I publish all the interesting pieces to
/shared//. A while back the Webmaster
suggested to use this file system because it available on all machine
and has much more disc space available than the Hudson machines. It
required an extra step after building, though. (PITA)

-Gunnar


-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] deploying snapshot builds from hudson.e.o to oss.sonatype.org

[Gunnar Wagenknecht]

Am 09.12.2011 07:13, schrieb Igor Fedorenko:
> I honestly think you are overreacting. oss.sonatype.org is just an
> artifact repository, a file server essentially.

Vendor neutrality is important. Why isn't it possible to publish to
download.eclipse.org (or whatever.eclipse.org) and then mirror the bits
you need?

Becoming a mirror is dead easy.
http://www.eclipse.org/downloads/mir_request.php

> Third, maven.eclipse.org has to be officially supported part of eclipse
> infrastructure and treated the same way as download.eclipse.org from
> availability and reliability point of view.

>From what I've heard, Maven/Tycho will play an important role in the
coming common build infrastructure. Thus, I think that it may be
possible to support that system like Hudson.

> Things like 365727 [1] simply should not happen.

Frankly, I don't really see who is too blame for the issue. It could
very likely be a bug in the software being used. It could also be a user
error. In any case, you certainly can't expect that such issues won't
happen even if you hire dedicated server operators.

> Fourth, Eclipse Foundation needs to decide if maven.eclipse.org should
> be synced to the Central repository or not and negotiate with Sonatype
> conditions and procedures if the sync is desired.

That confuses me a bit. Anybody is free to setup an Eclipse mirror at
their will. No negotiation is necessary. Can't Sonatype just mirror
maven.eclipse.org as others mirror download.eclipse.org? I'm pretty sure
Denis is willing to allow rsync from maven.eclipse.org as well.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
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] javax.servlet 3.0 -> 2.6

[Gunnar Wagenknecht]

Hi,

Just a heads up that the javax.servlet bundle in Orbit containing the
Servlet API 3.0 changed recently to export all its packages as version
2.6. This change will be in Juno M4!

Thus, if you are currently importing the Java Servlet API packages using
version 3.0 (eg. "[3.0.0,..." or just "3.0") you will need to modify
your imports to use a lower bound of "2.6".

Please have a look at bug 360245 for further details.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245

-Gunnar


-- 
Gunnar Wagenknecht
gun...@wagenknecht.org
http://wagenknecht.org/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev