Re: [equinox-dev] [eclipse.org-architecture-council] Fwd: Eclipse heads-up

[Thomas Watson]

Thanks, I saw that go by.

Equinox was one of the early adopters of parallel class loaders during its 
design and eventual inclusion in Java 7.  Long ago we stopped needing any such 
flags to prevent deadlock with our non-hierarchical class loaders.  This should 
have no impact for Eclipse projects that are based on Equinox.

Tom

From: equinox-dev  on behalf of Jonah Graham 

Sent: Tuesday, November 1, 2022 1:03 PM
To: eclipse.org-architecture-council 
; Equinox development mailing 
list 
Subject: [EXTERNAL] Re: [equinox-dev] [eclipse.org-architecture-council] Fwd: 
Eclipse heads-up

Forwarding to equinox-dev as I think that is the part of the IDE that has class 
loaders. Jonah ~~~ Jonah Graham Kichwa Coders www. kichwacoders. com On Tue, 1 
Nov 2022 at 13: 37, Ivar Grimstad http://www.kichwacoders.com>


On Tue, 1 Nov 2022 at 13:37, Ivar Grimstad 
mailto:ivar.grims...@eclipse-foundation.org>>
 wrote:
Hi all,

For your awareness, here is a change in the JDK that may impact some of our 
projects. I suspect it may be something to look into at least for the IDE, 
EclipseLink, GlassFish, others?
Not sure how to handle it, or even if the Arch Council is the right place.

Ivar

-- Forwarded message -
From: David Delabassee 
mailto:david.delabas...@oracle.com>>
Date: Tue, Oct 25, 2022 at 6:55 AM
Subject: Eclipse heads-up

Hi Ivar,

To prevent deadlocks, we're planning to remove from the JDK a legacy
parallel class loading workaround for custom class loaders not
registered as parallel capable (see JDK-8295848). We'd like to know if
Eclipse doesn't depend on that legacy workaround and understand if its
custom class loaders using non-hierarchical class delegation model are
parallel-capable.

[1] 
https://bugs.openjdk.org/browse/JDK-8295848

Thanks,




--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse 
Foundation - Community. Code. Collaboration.

___
eclipse.org-architecture-council mailing list
eclipse.org-architecture-coun...@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
___
equinox-dev mailing list
equinox-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Migration of git repositories to github

[Thomas Watson]

I assume the migration will include binaries also 
(https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/) or is that not 
necessary?

Tom

From: equinox-dev  on behalf of Aleksandar 
Kurtakov 
Sent: Wednesday, March 9, 2022 10:06 AM
To: Equinox development mailing list 
Subject: [EXTERNAL] [equinox-dev] Migration of git repositories to github

Hey everyone,
We are about to migrate the repositories (3 active ones only! - framework, 
bundles, p2) from https://git.eclipse.org/c/equinox/ to 
https://github.com/eclipse-equinox next 
Monday.
It will be handled in two steps:
* framework and bundles
* p2

Reason for that is that the open equinox gerrits 
(https://git.eclipse.org/r/q/projects:equinox+status:open) are mostly against 
p2 so some time is needed to clean it up.
Actual steps to be done are described at 
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/24
 .

Please resist opening new gerrits till that is completed and get your existing 
ones in by Sunday to make it easier on people handling the conversion.

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

Re: [equinox-dev] Issue with OSGI Annotations

[Thomas Watson]

The package org.osgi.service.component.annotations is not meant to be imported 
by bundles.  There is no need for a bundle to be wired to these packages at 
runtime.  The JARs the OSGi specification (working group) provides in maven 
central are only meant to be used for compile time dependencies.  As such these 
JARs have a non-resolvable requirement in them (osgi.compile.time.only) so that 
they cannot be used at runtime.  You should not install that "bundle" into your 
framework instance.

I'm not sure I understand your second point.  Is that a question?  It seems to 
state the expected behavior as defined in the current Declarative Services 
specification.

Tom


From: equinox-dev  on behalf of Kanika Khattar 

Sent: Wednesday, February 23, 2022 10:26 PM
To: equinox-dev@eclipse.org 
Subject: [EXTERNAL] [equinox-dev] Issue with OSGI Annotations

Hi All, While using OSGI Annotations in my project, I am getting a few issues. 
It will be great if you can help me with the same. Below are the issues: 1. 
!ENTRY org.osgi.service.metatype.annotations 4 0 2022-02-24 09:43:01.813 
!MESSAGE FrameworkEvent ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi All,

While using OSGI Annotations in my project, I am getting a few issues. It will 
be great if you can help me with the same.

Below are the issues:

1. !ENTRY org.osgi.service.metatype.annotations 4 0 2022-02-24 09:43:01.813

!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: 
org.osgi.service.metatype.annotations [219]
Unresolved requirement: Require-Capability: osgi.compile.time.only; 
filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"


at org.eclipse.osgi.container.Module.start(Module.java:463)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)
at 
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)


!ENTRY org.osgi.service.component.annotations 4 0 2022-02-24 09:43:01.887
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: 
org.osgi.service.component.annotations [239]
Unresolved requirement: Require-Capability: osgi.compile.time.only; 
filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"


at org.eclipse.osgi.container.Module.start(Module.java:463)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)
at 
org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1838)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1781)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1743)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1665)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)


2. Activate method gets called when Configuration Policy is set to OPTIONAL. 
When Configuration Policy is REQUIRE, the activate method is not called.

Thanks & Regards,
Kanika



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

Re: [equinox-dev] [p2-dev] Best way to contribute values (eg PGP keys) with OSGi?

[Thomas Watson]

If all you need is a path to some resource in a bundle then there is no need for a custom header or a custom service interface.  I recommend you define your own capability namespace and define a set of attributes that describe the capability for such a namespace.
 
For example, define a new capability namespace called "org.eclipse.equinox.p2.pgp.key".  I'm not sure what sorts of attributes you need to describe the pgp key outside of just the path to the file in the resource.  But you could have an attribute "path" to describe the path:
 
Bundle-Capability: org.eclipse.equinox.p2.pgp.key; path="/path/to/pgp/key/file"
 
This uses the standard Bundle-Capability header which allows the capability to be reflected with the FrameworkWiring API to discover the available capabilities.
 
Then from p2 you would find the capabilities available in the running framework with code like this:
 
BundleContext bc = ...;
FrameworkWiring fwkWiring = bc.getBundle(Constants.SYSTEM_BUNDLE_LOCATION).adapt(FrameworkWiring.class);
fwlWiring.findCapabilities(pgpReq).forEach(c -> {
    URL key = c.getRevision().getBundle().getEntry(c.getAttributes().get("path");
    // do something with the key
});
 
Where pgpReq is a simple Requirement implementation that uses the org.eclipse.equinox.p2.pgp.key namespace and has empty attributes and directives and a null resource.  Obtaining the URLs will not activate (lazy or otherwise) or even require such bundles to be resolved.  They only need to be installed.
Tom 
 
 
- Original message -From: "Mickael Istria" Sent by: "p2-dev" To: "Equinox development mailing list" , "P2 developer discussions" Cc:Subject: [EXTERNAL] [p2-dev] Best way to contribute values (eg PGP keys) with OSGi?Date: Wed, Dec 1, 2021 9:43 AM  Hi all, In the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=577248 , we need a way for bundles (that were preliminary approved by user) to be capable of contributing some PGP public keys as being "trusted by default".ZjQcmQRYFpfptBannerStart  

This Message Is From an External Sender
This message came from outside your organization. ZjQcmQRYFpfptBannerEnd 
Hi all,
 
In the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=577248 , we need a way for bundles (that were preliminary approved by user) to be capable of contributing some PGP public keys as being "trusted by default". I'm wondering what would be the best way to contribute such extensibility in p2. p2 doesn't define extension points, but uses OSGi Services; but here we only want to contribute a value (that could be the armoured keys, or a path to a resource in the bundle containing such keys...). As far as I am aware -ie not much-, I see 3 possible approaches:
 
1. Define a service interface and let bundles contribute extensions to this interface, eg via OSGI-INF/component.xml
  * Requires to create 1 service/API interace
  * Would consuming the service from a bundle automatically trigger bundle activation? That would be undesired.
 
2. Add support for a custom MANIFEST header, something like `Eclipse-P2-PGP-TrustedKey`.
  * Seems a bit alien, would require some support in tools
 
Are there other solutions you think could fit? What should be preferred?
 
Thanks in advance--
Mickael IstriaEclipse IDE developer, for Red Hat Developers
___p2-dev mailing listp2-...@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/p2-dev
 

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

Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xml

[Thomas Watson]

That is a bit of a dramatic statement that can open a can of worms.  The extension registry and the Eclipse platform model with its many extension points does what it does very well.  If you are developing bundles that plugin to the Eclipse platform do not "feel bad" about using the right technology.  Many times that will be writing an extension and defining a plugin.xml.  If you are not plugging into the Eclipse platform then use the technology that suits your needs.  I agree the OSGi service registry and actually the use of Declarative Services is a very good mechanism that has many advantages.
Tom 
 
 
- Original message -From: "Jürgen Albert" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Eclipse Equinox, OSGi specifications and plugin.xmlDate: Wed, Sep 29, 2021 7:45 AM 
Yes, the plugin.xml is a leftover of the early days. OSGi offers the far superior mechanism of Declarative Services. I'd strongly recommend to avoid the old extensions wherever possible.
Regards,
Jürgen.
Am 29/09/2021 um 14:23 schrieb Mickael Istria:

Right, plugin.xml is an Eclipse-specific format for extensibility, which is not part of OSGi specification. Support for this "extension registry" of plugin.xml files is part of the org.eclipse.equinox.registry bundle. I believe it's totally possible for Equinox to work comforming to OSGi spec without this bundle. 

 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
--Jürgen AlbertCEOChair Eclipse OSGi Working Group Steering CommitteeData In Motion Consulting GmbHKahlaische Str. 407745 JenaMobil:  +49 157-72521634E-Mail: j.alb...@datainmotion.deWeb: www.datainmotion.deXING:   https://www.xing.com/profile/Juergen_Albert5LinkedIn: https://www.linkedin.com/in/juergen-albert-6a1796/RechtlichesJena HBR 513025
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Classloader precedence of osgi.dev entries

[Thomas Watson]

This should work for dev classpath loading.  But I imagine you must be seeing some issue otherwise I doubt you would be asking.  Are you seeing an issue?
Tom 
 
 
- Original message -From: "Christoph Läubrich" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Classloader precedence of osgi.dev entriesDate: Tue, Apr 20, 2021 1:56 AM 
Just to give a more explicit example:if i havemy.bundle=/tmp/test/target/classes,/tmp/test/target/test-classes,/tmp/testorg.junit-4.13.0.v20200204-1500.jar,/tmp/test/org.hamcrest.core-1.3.0.v20180420-1519.jarshould this work or do I need to explode the jar files into a folder?Am 12.04.21 um 16:17 schrieb Thomas Watson:> The dev class path entries are prepended to the value of the> Bundle-ClassPath header value. Normal delegation rules apply for the dev> class path as if they are part of the bundle's Bundle-ClassPath.  That> roughly is the following:>> 1) Import-Package wires, if package is imported the search terminates at> the provider of the import-package wire and the delegation stops.> 2) Require-Bundle wires, each wire is check in order the bundle is> required until a class/resource is found.  If none found move to next step.> 3) Bundles class path is checked, this includes the dev class path> elements if they are specified.  It also checks attached fragments class> path elements. If nothing is found in all the available class path> elements, move on to next step> 4) If dynamic import is specified check if a dynamic resolution can find> an import wire.  If so delegate to the new import wire, this import wire> is then used for all other loads from the package.  If nothing is found> the the class/resource is not found and applicable exception is thrown.>> Tom>>     - Original message ->     From: "Christoph Läubrich" >     Sent by: "equinox-dev" >     To: equinox-dev@eclipse.org>     Cc:>     Subject: [EXTERNAL] [equinox-dev] Classloader precedence of osgi.dev>     entries>     Date: Sun, Apr 11, 2021 8:56 AM>     The property osgi.dev is described as [1]:>>       > This property may also be set to a comma-separated class path>     entries>       > which are added to the class path of each plug-in>>     But how is it applied? Is it used as a last resort if all other options>     (import-package, require-bundle, fragments, Dynamic-Import package) are>     searched and nothing was found?>>>     [1]>     https://help.eclipse.org/2021-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html=osgidev>     <https://help.eclipse.org/2021-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html=osgidev>>     ___>     equinox-dev mailing list>     equinox-dev@eclipse.org>     To unsubscribe from this list, visit>     https://www.eclipse.org/mailman/listinfo/equinox-dev>     <https://www.eclipse.org/mailman/listinfo/equinox-dev>>>>> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev>___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Classloader precedence of osgi.dev entries

[Thomas Watson]

The dev class path entries are prepended to the value of the Bundle-ClassPath header value. Normal delegation rules apply for the dev class path as if they are part of the bundle's Bundle-ClassPath.  That roughly is the following:1) Import-Package wires, if package is imported the search terminates at the provider of the import-package wire and the delegation stops.
2) Require-Bundle wires, each wire is check in order the bundle is required until a class/resource is found.  If none found move to next step.
3) Bundles class path is checked, this includes the dev class path elements if they are specified.  It also checks attached fragments class path elements. If nothing is found in all the available class path elements, move on to next step
4) If dynamic import is specified check if a dynamic resolution can find an import wire.  If so delegate to the new import wire, this import wire is then used for all other loads from the package.  If nothing is found the the class/resource is not found and applicable exception is thrown.
Tom 
 
 
- Original message -From: "Christoph Läubrich" Sent by: "equinox-dev" To: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] [equinox-dev] Classloader precedence of osgi.dev entriesDate: Sun, Apr 11, 2021 8:56 AM 
The property osgi.dev is described as [1]: > This property may also be set to a comma-separated class path entries > which are added to the class path of each plug-inBut how is it applied? Is it used as a last resort if all other options(import-package, require-bundle, fragments, Dynamic-Import package) aresearched and nothing was found?[1]https://help.eclipse.org/2021-03/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html=osgidev___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev 
 

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

Re: [equinox-dev] Native code on Windows 10

[Thomas Watson]

To be clear, the Eclipse IDE doesn't support x86 32-bit.  Nothing in the Equinox Framework prevents you from running on x86 32-bit.
 
Can you run the gogo console in your environment and run the following command?inspect capability osgi.native 0
 
I expect output like this (note this is from my Mac so it will be different on Windows):
 
org.eclipse.osgi_3.16.200.v20201209-1827 [0] provides:--osgi.native with properties:   osgi.native.language = en   osgi.native.osname = [MacOSX, Mac OS X]   osgi.native.osversion = 10.14.6   osgi.native.processor = [x86-64, amd64, em64t, x86_64]
 
 
Note that there will be several other properties.  But the osgi.native ones are what is used to match the Bundle-Native code header.
 
Also, can we have a look at your requirement for the osgi.native namespace?  Use this command, with the bundle ID of the your bundle with the Bundle-NativeCode header: 
inspect requirement osgi.native 
This should give the transformed requirement filter the framework derived from your Bundle-Native code header which is then matched against the osgi.native capability provided by the framework.
 
 
Tom 
 
 
- Original message -From: Todor Dimitrov Sent by: "equinox-dev" To: Equinox development mailing list Cc:Subject: [EXTERNAL] Re: [equinox-dev] Native code on Windows 10Date: Wed, Jan 27, 2021 2:35 PM OK, I didn’t know that x86 support was dropped for Windows. The application used to work with previous equinox versions. Since we don’t really use Windows, this gets tested once every 2 years :-)
 
Isn’t it just better to throw an exception “equinox does not run on Windows x86" and exit?
 
Also: what do you mean by resolve?
 We don’t use bnd but we get an exception like this:
 
Unresolved requirement: Require-Capability: osgi.native
 
Thank you,
Todor
 
On 27. Jan 2021, at 20:39, Jürgen Albert  wrote: 

Hi Todor,
 
I also suspect you use at least the wrong architecture name. The available names can be found under: https://docs.osgi.org/reference/osnames.html
 
Also: what do you mean by resolve? If you use the bnd resolver, you have to make sure you provide the native capabilities to the resolver. Here you need to add: -runsystemcapabilities: ${native_capability} if I'm not mistaken.
 
Regards,
 
Jürgen. 

Jonah Graham  schrieb am Mi., 27. Jan. 2021, 19:52:
Hi Todor,
 
I am not sure if there is special/different support in Equinox, so my answer may be off base.
 
You are using 32-bit Windows - however 32-bit has not been supported by Eclipse since Eclipse 4.10 (2018-12) release. Could that be your problem here?
 
Jonah
 
~~~Jonah GrahamKichwa Coderswww.kichwacoders.com 

On Wed, 27 Jan 2021 at 13:41, Todor Dimitrov  wrote:
Hello,
 
I have a problem resolving native code on Windows 10. The following manifest declaration does not work:
 
Bundle-NativeCode: sqlite-native/windows/x86/sqlitejdbc.dll; processor=x86; osname=win32
 
whereas removing 'processor' and 'osname' seems to solve the problem, i.e.
 
Bundle-NativeCode: sqlite-native/windows/x86/sqlitejdbc.dll
 
I've tried specifying the 'org.osgi.framework.processor' and 'org.osgi.framework.os.name' like so:
 
-Dorg.osgi.framework.processor=x86 -Dorg.osgi.framework.os.name=win32
 
Any ideas? I'm using the following environment:
 
Windows 10 32-bitOracle Java 1.8.0_281
Eclipse 4.16 / Equinox 3.20.200.v20200528-0603
 
Thanks in advance,
Todor___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

[Thomas Watson]

I've certainly made fixes to this code long after Equinox has stopped using it and I don't mind maintaining fixes there when required.  I do care enough to not break existing projects that are using this API.  After all, I do use PDE nearly every day and we are very dependant on tycho to build.  Ed, lets not become overly negative about the maintainers of this old platform.  I've been doing this for a very long time and understand your pain and position.  To be honest, removing this old implementation that I no long use is going to be a large effort to all, and much of that will fall to me as well to guide others to use something else and likely also contribute to their code base in doing so.
 
As of now, because of the way PDE exposes the old resolver API in its own API, I don't see a clear path to removal from the Eclipse Project.  That being said I still think it is worth discussing the possibility of deprecating the API.  This is really a statement to indicate that there is a better way to do something now and we encourage the usage of that better way.  If consumers of the API choose to stay on the old API then that is their decision.  But as of now the users of the old API are left in the dark about it not being our recommended thing to use.
 
Tom 
 
 
- Original message -From: Mickael Istria Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 12:30 PM   

 

Ed,
Thomas said he's not so enthusiast about supporting this legacy API. As you're the one feeling the need for this API to remain maintained, are you willing to maintain it in high enough quality for continued usage by consumers? If so, then it's great, it's one less change to make in Tycho. If not, then let's call a spade a spade and mark unmaintained API as deprecated for honesty towards the consumer community and enable them to make the best technical decision for their continuous success, even if this one is about leaving the Eclipse Platform for something else.
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

[Thomas Watson]

It indeed does look like a deep dark rat hole.
Tom 
 
 
- Original message -From: Ed Merks Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 10:33 AM 
Thomas,
I think you'll find the use of these APIs have gone far a wide.  I count 15 uses of things from this package in my Oomph workspace.  Also 804 in my SDK workspace; you'll find them used in PDE and in p2.  I don't think anyone understands the implications of removing/changing all these things, I don't think there are "replacements" for them, and even if there are, they're used/surfaced in APIs and I don't think anyone (and most certainly not everyone) has time to rework everything downstream to use replacements and make new APIs...
So that's all to say that this looks like a rat hole to me. :-( 

On 08.01.2021 16:02, Thomas Watson wrote:

You are correct, this is a rather a tricky situation.  Especially because of things like org.eclipse.pde.core.plugin.IPluginModelBase.setBundleDescription(BundleDescription)
 
I'm not entirely sure why that is API there, seems like an internal implementation detail to be able to set the BundleDescription which backs the implementation details of IPluginModel. Perhaps a more realistic consideration would be to move the API to PDE.
  Tom 
 
 
- Original message -From: Ed Merks Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 8:50 AM 
What does it mean to deprecate "the API package org.eclipse.osgi.service.resolver"?  Does that affect the use of things like org.eclipse.osgi.service.resolver.VersionRange, org.eclipse.osgi.service.resolver.BundleDescription, and other things in that package?  These things are needed for stuff like org.eclipse.pde.core.plugin.PluginRegistry.findModel(String, VersionRange, PluginFilter) and org.eclipse.pde.core.plugin.IPluginModelBase.getBundleDescription() so surely there is not a suggestion here to deprecate these things too?!
On 08.01.2021 15:40, Thomas Watson wrote:

I would be in favor of deprecating the API package org.eclipse.osgi.service.resolver which is contained in the Equinox Framework (org.eclipse.osgi).  The framework fragment called org.eclipse.osgi.compatibility.state holds the actual implementation, which is internal.  But anything needing to get an instance of the implementation should be using the StateObjectFactory API to do so (See org.eclipse.osgi.service.resolver.StateObjectFactory.defaultFactory)
Tom 
 
 
- Original message -From: Mickael Istria Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 3:47 AM 
Hello,
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=570189 and https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/174392 have revealed some bug in org.eclipse.osgi.compatibility.state. What's the status of the APIs in there? Are they actually deprecated and should be replaced with others whever possible?
If yes, should we mark them all as @Deprecated with hints about which API should be used instead? I guess if this was done, it would hint consumers to progressively adopt newer/better APIs.
 
What do you think?
--
Mickael IstriaEclipse IDE developer, for Red Hat Developers
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
  

 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
  

 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

[Thomas Watson]

You are correct, this is a rather a tricky situation.  Especially because of things like org.eclipse.pde.core.plugin.IPluginModelBase.setBundleDescription(BundleDescription)
 
I'm not entirely sure why that is API there, seems like an internal implementation detail to be able to set the BundleDescription which backs the implementation details of IPluginModel. Perhaps a more realistic consideration would be to move the API to PDE.
  Tom 
 
 
- Original message -From: Ed Merks Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 8:50 AM 
What does it mean to deprecate "the API package org.eclipse.osgi.service.resolver"?  Does that affect the use of things like org.eclipse.osgi.service.resolver.VersionRange, org.eclipse.osgi.service.resolver.BundleDescription, and other things in that package?  These things are needed for stuff like org.eclipse.pde.core.plugin.PluginRegistry.findModel(String, VersionRange, PluginFilter) and org.eclipse.pde.core.plugin.IPluginModelBase.getBundleDescription() so surely there is not a suggestion here to deprecate these things too?!
On 08.01.2021 15:40, Thomas Watson wrote:

I would be in favor of deprecating the API package org.eclipse.osgi.service.resolver which is contained in the Equinox Framework (org.eclipse.osgi).  The framework fragment called org.eclipse.osgi.compatibility.state holds the actual implementation, which is internal.  But anything needing to get an instance of the implementation should be using the StateObjectFactory API to do so (See org.eclipse.osgi.service.resolver.StateObjectFactory.defaultFactory)
Tom 
 
 
- Original message -From: Mickael Istria Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 3:47 AM 
Hello,
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=570189 and https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/174392 have revealed some bug in org.eclipse.osgi.compatibility.state. What's the status of the APIs in there? Are they actually deprecated and should be replaced with others whever possible?
If yes, should we mark them all as @Deprecated with hints about which API should be used instead? I guess if this was done, it would hint consumers to progressively adopt newer/better APIs.
 
What do you think?
--
Mickael IstriaEclipse IDE developer, for Red Hat Developers
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
  

 
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?

[Thomas Watson]

I would be in favor of deprecating the API package org.eclipse.osgi.service.resolver which is contained in the Equinox Framework (org.eclipse.osgi).  The framework fragment called org.eclipse.osgi.compatibility.state holds the actual implementation, which is internal.  But anything needing to get an instance of the implementation should be using the StateObjectFactory API to do so (See org.eclipse.osgi.service.resolver.StateObjectFactory.defaultFactory)
Tom 
 
 
- Original message -From: Mickael Istria Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?Date: Fri, Jan 8, 2021 3:47 AM 
Hello,
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=570189 and https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/174392 have revealed some bug in org.eclipse.osgi.compatibility.state. What's the status of the APIs in there? Are they actually deprecated and should be replaced with others whever possible?
If yes, should we mark them all as @Deprecated with hints about which API should be used instead? I guess if this was done, it would hint consumers to progressively adopt newer/better APIs.
 
What do you think?
--
Mickael IstriaEclipse IDE developer, for Red Hat Developers
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Sources for plugins

[Thomas Watson]

I think there is simply a miscommunication here and nothing to take offence at.  Regardless we have given Ranjana more than enough information.
Tom 
 
 
- Original message -From: "Sravan K Lakkimsetti" Sent by: equinox-dev-boun...@eclipse.orgTo: "Equinox development mailing list" Cc:Subject: [EXTERNAL] Re: [equinox-dev] Sources for pluginsDate: Mon, Nov 23, 2020 2:35 AM    

 

Hi Ed,
 
Demanding something for a bundle which we did not build in first place is something I am not comfortable. If he wants he can get the source from the respective git repositories. 
 
Thanks
Sravan
 
From: Ed Merks Sent: 23 November 2020 13:53To: equinox-dev@eclipse.orgSubject: [EXTERNAL] Re: [equinox-dev] Sources for plugins
 

Sravan,
As far as I understand it, there exists no EPL/legal requirement to provide corresponding source bundles for any binary bundles.   It's of course very nice to have when you want to debug the use of a framework, but it's not an "OSS obligation," whatever that means.  The fact that all the source code itself is in a public git repository is more than sufficient to meet any EPL obligations.
But note too that Rajana's phrasing wasn't entirely clear, i.e., did Rajana require this to meet Bosch's OSS obligations or was Rajana suggesting that we did not fulfill our OSS obligations.  Because the former obligation is not our problem while that latter obligation is something that I don't believe exists.
Regards,Ed
On 23.11.2020 09:02, Sravan K Lakkimsetti wrote:
Hi,
 
We do not support 4.2 release any more. For that matter eclipse platform team did not release the following
org.eclipse.equinox.registry-3.5.201.v20131009-2050org.eclipse.jface.text-3.8.3.v20141001-2118.jar
 
the other bundle is part of 4.2 release. So you may pick up source from there. 
 
Accusing us for not fulfilling OSS obligations for a bundle not built/shipped by equinox/eclipse platform team is not expected from a company of your stature. Please contact the vendor who provided you those bundles.
 
-Sravan 
 
 
From: Ranjana Radhakrishnan (RBEI/EMT2) Sent: 23 November 2020 10:41To: equinox-dev@eclipse.orgSubject: [EXTERNAL] [equinox-dev] Sources for plugins
 
Hello Team,
 
A gentle reminder for the below mail.
 
Regards,
Ranjana R (RBEI/EMT2)
 
From: Ranjana Radhakrishnan (RBEI/EMT2)Sent: Wednesday, November 18, 2020 14:56To: 'equinox-dev@eclipse.org' Subject: RE: Reg org.eclipse.equinox.ds
 
Hello Team,
 
We have integrated the below plugins into our products and we were unable to find the sources for the same. 
The plugin sources are required to fulfil OSS obligations.
 
org.eclipse.equinox.registry-3.5.201.v20131009-2050org.eclipse.jface.text-3.8.3.v20141001-2118.jarorg.eclipse.text-3.5.200.v20120523-1310.jar
 
Kindly provide the sources.
 
Best regards,Ranjana Radhakrishnan (RBEI/EMT2)Robert Bosch Engineering and Business Solutions Private Limited - (CIN: U72400KA1997PTC023164) | GTP 208/2 Kalapatty Main Road | Kalapatty | Coimbatore | Tamilnadu 641048 | INDIA | www.bosch-india-software.comRegistered Office: Robert Bosch Engineering and Business Solutions Private Limited, 123, Industrial Layout,Hosur Road, Koramangala, Bengaluru - 560095, IndiaManaging Director: Mr. Dattatri Salagame ​

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

___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] p2 does not check uses at install time

[Thomas Watson]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=525368
 
Under the covers p2 uses SAT4J to implement a resolver for selecting what to install.  I remember discussing with the original p2 developers the complications of the uses directive such that they could look into encoding the constraint checking necessary for the uses directive into the necessary information for SAT4J to process.  But not much progress was made on that front.  So far p2 usage has been somewhat lucky that this has not posed much of a problem over the years.  It sounds like you may have found a problematic scenario.  I am curious if there is a different choice p2 could have made to get the bundles in your scenario to resolve.
Tom 
 
 
- Original message -From: Jonah Graham Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] p2 does not check uses at install timeDate: Wed, Nov 18, 2020 11:18 AM 
Hello Equinox/p2 folks,
 
Is it a bug that p2 does not check uses constraints at install time?
 
I have a case that I am working on that p2 happily installs bundles, but then they don't resolve.
 
I have hit this while working on Bug 568379 which has uncommitted parts, so I don't have a reproducer yet that is available.
 
The error I get is:
 
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.mylyn.builds.ui [249]  Unresolved requirement: Require-Bundle: org.eclipse.jdt.debug.ui; resolution:="optional"  Unresolved requirement: Require-Bundle: org.eclipse.jdt.junit; resolution:="optional"  Unresolved requirement: Require-Bundle: org.eclipse.jdt.ui; resolution:="optional"  Unresolved requirement: Require-Bundle: org.eclipse.mylyn.tasks.ui; bundle-version="3.8.0"    -> Bundle-SymbolicName: org.eclipse.mylyn.tasks.ui; bundle-version="3.25.2.v20200814-0512"; singleton:="true"       org.eclipse.mylyn.tasks.ui [276]         Unresolved requirement: Require-Bundle: org.eclipse.mylyn.commons.notifications.feed; bundle-version="1.0.0"           -> Bundle-SymbolicName: org.eclipse.mylyn.commons.notifications.feed; bundle-version="1.17.2.v20200813-0821"; singleton:="true"              org.eclipse.mylyn.commons.notifications.feed [254]                No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.mylyn.team.ui; bundle-version="3.8.0"    -> Bundle-SymbolicName: org.eclipse.mylyn.team.ui; bundle-version="3.25.2.v20200828-1617"; singleton:="true"       org.eclipse.mylyn.team.ui [277]         Unresolved requirement: Require-Bundle: org.eclipse.mylyn.tasks.ui; bundle-version="[3.8.0,4.0.0)"           -> Bundle-SymbolicName: org.eclipse.mylyn.tasks.ui; bundle-version="3.25.2.v20200814-0512"; singleton:="true"  Bundle was not resolved because of a uses constraint violation.  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.mylyn.commons.notifications.feed [osgi.identity; osgi.identity="org.eclipse.mylyn.commons.notifications.feed"; type="osgi.bundle"; version:Version="1.17.2.v20200813-0821"; singleton:="true"] because it is exposed to package 'javax.xml.bind' from resources javax.xml.bind [osgi.identity; osgi.identity="javax.xml.bind"; type="osgi.bundle"; version:Version="2.2.0.v201105210648"] and jakarta.xml.bind [osgi.identity; type="osgi.bundle"; version:Version="2.3.3.v20201118-1629"; osgi.identity="jakarta.xml.bind"] via two dependency chains.Chain 1:  org.eclipse.mylyn.commons.notifications.feed [osgi.identity; osgi.identity="org.eclipse.mylyn.commons.notifications.feed"; type="osgi.bundle"; version:Version="1.17.2.v20200813-0821"; singleton:="true"]    require: (&(osgi.wiring.bundle=javax.xml.bind)(bundle-version>=2.2.0))     |    provide: osgi.wiring.bundle: javax.xml.bind  javax.xml.bind [osgi.identity; osgi.identity="javax.xml.bind"; type="osgi.bundle"; version:Version="2.2.0.v201105210648"]Chain 2:  org.eclipse.mylyn.commons.notifications.feed [osgi.identity; osgi.identity="org.eclipse.mylyn.commons.notifications.feed"; type="osgi.bundle"; version:Version="1.17.2.v20200813-0821"; singleton:="true"]    require: (&(osgi.wiring.bundle=com.sun.xml.bind)(bundle-version>=2.2.0))     |    provide: osgi.wiring.bundle; bundle-version:Version="2.3.3.v20201118-1639"; osgi.wiring.bundle="com.sun.xml.bind"  com.sun.xml.bind [osgi.identity; type="osgi.bundle"; version:Version="2.3.3.v20201118-1639"; osgi.identity="com.sun.xml.bind"]    import: (&(osgi.wiring.package=javax.xml.bind)(&(version>=2.3.3)(!(version>=2.3.4     |    export: osgi.wiring.package: javax.xml.bind  jakarta.xml.bind [osgi.identity; type="osgi.bundle"; version:Version="2.3.3.v20201118-1629"; osgi.identity="jakarta.xml.bind"]at org.eclipse.osgi.container.Module.start(Module.java:463)at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1845)at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)at 

Re: [equinox-dev] JAXB with Java 11 in OSGi

[Thomas Watson]

I would try the osgi-dev mailing list: https://mail.osgi.org/mailman/listinfo/osgi-dev
Tom 
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [EXTERNAL] [equinox-dev] JAXB with Java 11 in OSGiDate: Tue, Jul 28, 2020 6:56 AM 
Friends of OSGi,Is anyone aware of an example / description of how to use JAXB withJava 11 in OSGI (Eclipse RCP)? If yes, please share it with me.The examples I found for Java 11 are not inside OSGi and fail for me.Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com ___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev 
 

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

Re: [equinox-dev] [platform-releng-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.framework

[Thomas Watson]

Thanks again Johah,
 
The blame history has been properly restored to the master branch and to the osgiR8 branch using this approach.  My mistake is now properly swept under the rug.
Tom 
 
 
- Original message -From: "Thomas Watson" Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] Re: [equinox-dev] [platform-releng-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Wed, Mar 11, 2020 2:25 PM 
Thanks Jonah!
 
I had not considered doing that.  I will do this to preserve  the blame history.
Tom 
 
 
- Original message -From: Jonah Graham Sent by: equinox-dev-boun...@eclipse.orgTo: "Eclipse platform release engineering list." Cc: Equinox development mailing list Subject: [EXTERNAL] Re: [equinox-dev] [platform-releng-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Wed, Mar 11, 2020 1:08 PM 
Hi Thomas,
 
If you want to maintain the blame history on your revert you can do the following. This will discard the bad merge from blame history without needing a force push.
 
git checkout dabb1b38eaf020bb0f97ea331a3f6c5e5aefe565 -b new_master # the last good commit on master that you want to "revert" to
git merge --strategy=ours origin/master
git push origin new_master:master
 
Doing the above changes the git blame for example from:
 
$ git blame bundles/org.eclipse.osgi.tests/META-INF/MANIFEST.MF--snip--713ce018b1 (Thomas Watson      2020-03-10 16:03:39 -0500  5) Bundle-Version: 3.15.300.qualifier
 
to$ git blame bundles/org.eclipse.osgi.tests/META-INF/MANIFEST.MF--snip--27288b2b5b (Alexander Kurtakov 2020-03-08 14:28:04 +0200  5) Bundle-Version: 3.15.300.qualifier
 
and gives history that looks like this:
 
$ git log  --graph --oneline  | head*   13c9a3027 Fix accidental merge|\  | * 713ce018b Revert "Merge branch 'master' into osgiR8"| * e8778b43b Revert "Update OSGi R8 APIs"| * cee7c1437 Update OSGi R8 APIs| *   bf506346f Merge branch 'master' into osgiR8| |\  | |/  |/|  * | dabb1b38e Bug 560974 - Fix exception type for null map key
 
HTH,
Jonah
 
 
~~~
Jonah GrahamKichwa Coderswww.kichwacoders.com 

On Tue, 10 Mar 2020 at 17:30, Thomas Watson <tjwat...@us.ibm.com> wrote:
I decided to just live with the painful history of reverting the merge commit instead of force pushing to rewind history.  Master is back to where it should be and back open for development.  I needed to do this before the I-Build kicked off today and didn't want to risk waiting for the foundation to do the force push to master for me.
 
Sorry for the bone-headed move on my part.
Tom 
 
 
- Original message -From: Thomas Watson/Austin/IBMTo: equinox-dev@eclipse.org, platform-releng-...@eclipse.orgCc:Subject: Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Tue, Mar 10, 2020 3:35 PM 
I incorrectly merged into master a long running branch I have for OSGi R8 development in the rt.equinox.framework.  I have a bug opened against the foundation asking to get a force push to master to correct things:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=560997
 
As much as I dislike a force push to rewind histroy, in this case I think it is warranted because the OSGi R8 branch has loads of merge commits and it was then itself merged into master.  There is not a simple revert operation here to get master back to where it should be.  As of now consider master closed for rt.equinox.framework until this is sorted out.
Tom 
 ___platform-releng-dev mailing listplatform-releng-...@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
  

___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] [platform-releng-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.framework

[Thomas Watson]

Thanks Jonah!
 
I had not considered doing that.  I will do this to preserve  the blame history.
Tom 
 
 
- Original message -From: Jonah Graham Sent by: equinox-dev-boun...@eclipse.orgTo: "Eclipse platform release engineering list." Cc: Equinox development mailing list Subject: [EXTERNAL] Re: [equinox-dev] [platform-releng-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Wed, Mar 11, 2020 1:08 PM 
Hi Thomas,
 
If you want to maintain the blame history on your revert you can do the following. This will discard the bad merge from blame history without needing a force push.
 
git checkout dabb1b38eaf020bb0f97ea331a3f6c5e5aefe565 -b new_master # the last good commit on master that you want to "revert" to
git merge --strategy=ours origin/master
git push origin new_master:master
 
Doing the above changes the git blame for example from:
 
$ git blame bundles/org.eclipse.osgi.tests/META-INF/MANIFEST.MF--snip--713ce018b1 (Thomas Watson      2020-03-10 16:03:39 -0500  5) Bundle-Version: 3.15.300.qualifier
 
to$ git blame bundles/org.eclipse.osgi.tests/META-INF/MANIFEST.MF--snip--27288b2b5b (Alexander Kurtakov 2020-03-08 14:28:04 +0200  5) Bundle-Version: 3.15.300.qualifier
 
and gives history that looks like this:
 
$ git log  --graph --oneline  | head*   13c9a3027 Fix accidental merge|\  | * 713ce018b Revert "Merge branch 'master' into osgiR8"| * e8778b43b Revert "Update OSGi R8 APIs"| * cee7c1437 Update OSGi R8 APIs| *   bf506346f Merge branch 'master' into osgiR8| |\  | |/  |/|  * | dabb1b38e Bug 560974 - Fix exception type for null map key
 
HTH,
Jonah
 
 
~~~
Jonah GrahamKichwa Coderswww.kichwacoders.com 

On Tue, 10 Mar 2020 at 17:30, Thomas Watson <tjwat...@us.ibm.com> wrote:
I decided to just live with the painful history of reverting the merge commit instead of force pushing to rewind history.  Master is back to where it should be and back open for development.  I needed to do this before the I-Build kicked off today and didn't want to risk waiting for the foundation to do the force push to master for me.
 
Sorry for the bone-headed move on my part.
Tom 
 
 
- Original message -From: Thomas Watson/Austin/IBMTo: equinox-dev@eclipse.org, platform-releng-...@eclipse.orgCc:Subject: Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Tue, Mar 10, 2020 3:35 PM 
I incorrectly merged into master a long running branch I have for OSGi R8 development in the rt.equinox.framework.  I have a bug opened against the foundation asking to get a force push to master to correct things:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=560997
 
As much as I dislike a force push to rewind histroy, in this case I think it is warranted because the OSGi R8 branch has loads of merge commits and it was then itself merged into master.  There is not a simple revert operation here to get master back to where it should be.  As of now consider master closed for rt.equinox.framework until this is sorted out.
Tom 
 ___platform-releng-dev mailing listplatform-releng-...@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-releng-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.framework

[Thomas Watson]

I decided to just live with the painful history of reverting the merge commit instead of force pushing to rewind history.  Master is back to where it should be and back open for development.  I needed to do this before the I-Build kicked off today and didn't want to risk waiting for the foundation to do the force push to master for me.
 
Sorry for the bone-headed move on my part.
Tom 
 
 
- Original message -From: Thomas Watson/Austin/IBMTo: equinox-dev@eclipse.org, platform-releng-...@eclipse.orgCc:Subject: Incorrect merge of osgiR8 branch into master for rt.equinox.frameworkDate: Tue, Mar 10, 2020 3:35 PM 
I incorrectly merged into master a long running branch I have for OSGi R8 development in the rt.equinox.framework.  I have a bug opened against the foundation asking to get a force push to master to correct things:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=560997
 
As much as I dislike a force push to rewind histroy, in this case I think it is warranted because the OSGi R8 branch has loads of merge commits and it was then itself merged into master.  There is not a simple revert operation here to get master back to where it should be.  As of now consider master closed for rt.equinox.framework until this is sorted out.
Tom 
 

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

[equinox-dev] Incorrect merge of osgiR8 branch into master for rt.equinox.framework

[Thomas Watson]

I incorrectly merged into master a long running branch I have for OSGi R8 development in the rt.equinox.framework.  I have a bug opened against the foundation asking to get a force push to master to correct things:  https://bugs.eclipse.org/bugs/show_bug.cgi?id=560997
 
As much as I dislike a force push to rewind histroy, in this case I think it is warranted because the OSGi R8 branch has loads of merge commits and it was then itself merged into master.  There is not a simple revert operation here to get master back to where it should be.  As of now consider master closed for rt.equinox.framework until this is sorted out.
Tom 

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

Re: [equinox-dev] Sources for plugins to fulfil OSS obligations

[Thomas Watson]

All the source can be found in the eclipse git repositories info found at https://git.eclipse.org/c/equinox/rt.equinox.framework.git/ and https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/
 
But for most we do publish the source JARs into maven central:
 
https://search.maven.org/remotecontent?filepath=org/eclipse/platform/org.eclipse.equinox.security.macosx/1.101.0/org.eclipse.equinox.security.macosx-1.101.0-sources.jar
https://search.maven.org/remotecontent?filepath=org/eclipse/platform/org.eclipse.equinox.security.linux.x86_64/1.1.0/org.eclipse.equinox.security.linux.x86_64-1.1.0-sources.jar
https://search.maven.org/remotecontent?filepath=org/eclipse/platform/org.eclipse.equinox.launcher/1.5.0/org.eclipse.equinox.launcher-1.5.0-sources.jar
 
org.eclipse.equinox.launcher.win32.win32.x86_64 one is not as nice.  I'm assuming you are using Eclipse/Equinox 4.8 based on the version of the bundle.  For this one you will have to go to the git source repository to find it and checkout the correct tag: 
git clone https://git.eclipse.org/r/equinox/rt.equinox.framework.git --branch R4_8 --single-branchThe native source is located under features/org.eclipse.equinox.executable.feature and that ends up getting packaged up in the artifact built from bundles/org.eclipse.equinox.launcher.win32.win32.x86_64
 
HTH
Tom
 
 
- Original message -From: "Ranjana Radhakrishnan (RBEI/EMT2)" Sent by: equinox-dev-boun...@eclipse.orgTo: "equinox-dev@eclipse.org" Cc: "Bhuvaneswari Ethiraju \(RBEI/EMT2\)" , "Sakthipriya M Sanalkumar \(RBEI/EMT2\)" Subject: [EXTERNAL] [equinox-dev] Sources for plugins to fulfil OSS obligationsDate: Fri, Nov 1, 2019 2:24 AM  
Hello,
 
We have integrated the below plugins into our products and we were unable to find the sources for the same. 
The plugin sources are required to fulfil OSS obligations.
 
1.  org.eclipse.equinox.security.linux.x86_64_1.1.0.v20171221-2204.jar2.  org.eclipse.equinox.security.macosx_1.101.0.v20171221-2204.jar3.  org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.700.v20180518-12004.  org.eclipse.equinox.launcher_1.5.0.v20180512-1130.jar
 
Kindly provide the respective sources.. 
 
Thanks in advance!
 
Regards,
Ranjana R (RBEI/EMT2)
 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Log Maven version in p2-master and p2-gerrit jobs

[Thomas Watson]

Thanks Mykola, I've done the same for the Equinkox framework and bundles jobs now.
Tom 
 
 
- Original message -From: Mykola Nikishov Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [EXTERNAL] [equinox-dev] Log Maven version in p2-master and p2-gerrit jobsDate: Sat, Jun 1, 2019 3:38 AM 
Hi there,Using apache-maven-latest (which is Maven 3.6.1 now) causes problems[1]. As I understand, this would break any other jobs that are usingapache-maven-latest and has org.eclipse:eclipse-platform-parent as aparent.It is not clear from a build log what Maven version was actuallyused. It makes it harder to troubleshoot build failures when Mavenversion is to blame.I've added '--show-version' to Maven target for both p2-master [2] andp2-gerrit [3] jobs. This would log some useful information about Mavenversion like:--8<---cut here---start->8---Apache Maven 3.6.0Maven home: /usr/share/mavenJava version: 1.8.0_212, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jreDefault locale: en_US, platform encoding: UTF-8OS name: "linux", version: "4.19.0-5-amd64", arch: "amd64", family: "unix"--8<---cut here---end--->8---[1] https://www.eclipse.org/lists/tycho-dev/msg01595.html [2] https://ci.eclipse.org/equinox/job/p2-master/jobConfigHistory/showDiffFiles?timestamp1=2019-03-27_04-40-03=2019-06-01_08-13-22 [3] https://ci.eclipse.org/equinox/job/p2-gerrit/jobConfigHistory/showDiffFiles?timestamp1=2019-05-31_21-05-59=2019-06-01_08-14-25 --MykolaLibre/Free Java Software Developerhttps://manandbytes.gitlab.io/ ___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev  
 

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

Re: [equinox-dev] OS

[Thomas Watson]

That version is over 6 years old and was released before Java 8 was even available so it may have issues with running on the oldest supported Java available and I doubt it will work well on anything Java 9+.  While I suspect it should just work for the most part on Java 8 there will be a few things that may cause issues.  For example, resolving the required execution environments.  Also, for Windows Server 2019 we need to add the OS alias for native code matching.  I opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=546658 for that.
 
If not clear from the statement above, it is highly recommended you use a recent released version of Equinox.
Tom 
 
 
- Original message -From: "liname...@outlook.com" Sent by: equinox-dev-boun...@eclipse.orgTo: "equinox-dev@eclipse.org" Cc:Subject: [equinox-dev] OSDate: Mon, Apr 22, 2019 8:20 PM 
Hello, I am doing an investigation. 
Does Windows Server 2019 support the following products:
 
equinox 3.8.2.v20130124-134944
 
Can it be installed on windows2019?
Is the other version supported?
Can you tell me, thank you very much.
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] All jobs @ Equinox JIPP Instance are disabled now, what's the reason?

[Thomas Watson]

The equinox jobs have been migrated over to the new infrastructure, but we are experiencing some issues with the migration.  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=545352
Tom 
 
 
- Original message -From: Mykola Nikishov Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [equinox-dev] All jobs @ Equinox JIPP Instance are disabled now, what's the reason?Date: Wed, Mar 27, 2019 7:41 AM 
Hi,Does anyone know the reason why all jobs @ Equinox JIPP Instance [1] aredisabled?According to [2], they had been disabled on purpose:--8<---cut here---start->8---Date: 2019-03-27_00-33-24Operation: ChangedUser:sravankum...@in.ibm.com-false+true--8<---cut here---end--->8---[1] https://ci.eclipse.org/equinox/[2] https://ci.eclipse.org/equinox/job/p2-gerrit/jobConfigHistory/showDiffFiles?timestamp1=2018-12-14_03-56-44=2019-03-27_00-33-24--MykolaLibre/Free Java Software Developerhttps://manandbytes.gitlab.io/___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev 
 

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

[equinox-dev] 4,11 Plans

[Thomas Watson]

I've started the 4.11 Equinox planning page at https://wiki.eclipse.org/Equinox/Plan/4.11
 
Please add any major work items you plan to work on for 4.11.
Tom 
 
 
- Original message -From: "Daniel Megert" Sent by: eclipse-dev-boun...@eclipse.orgTo: "General development mailing list of the Eclipse project." Cc:Subject: [eclipse-dev] 4,11 PlansDate: Fri, Dec 14, 2018 11:16 AM Hi TeamPlease start to create the plans for 4.11 like we did for 4.10 (see https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#themes_and_priorities).Let's make sure we have them before we go into the holiday season.Thanks,Dani
___eclipse-dev mailing listeclipse-...@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/eclipse-dev
 

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

Re: [equinox-dev] Tycho Surefire Test fails to load Schemafactory

[Thomas Watson]

I added a comment to the bug report, we can continue the discussion there.
Tom 
 
 
- Original message -From: Guillaume Dufour Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc: tycho-...@eclipse.orgSubject: Re: [equinox-dev] Tycho Surefire Test fails to load SchemafactoryDate: Sat, Nov 24, 2018 4:36 PM 
Yes. And the exemple or reproduction code did It. 
To be precise, IT do 
classLoader.getResources("META-INF/services/javax.xml.validation.SchemaFactory");
 
I will try to débug an eclipse instance jdt  to understand the différence.  
 
Regards
 
Le sam. 24 nov. 2018 à 23:07, Raymond Auge  a écrit :
Technically you shouldn't have to do anything different than what ServiceLoader would normally do:
 
classLoader.getResource("META-INF/services/javax.xml.validation.SchemaFactory");
 
- Ray 

 
On Sat, Nov 24, 2018 at 1:16 PM Guillaume Dufour  wrote:
 
Hello Equinox Team,
 
I try to help by fixing a bug on tycho.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485926
 
I hope i am on a the right mailing list. If the class org.eclipse.osgi.internal.loader.BundleLoader is in your scope normaly yes ;o)
 
As I can see there is a problem during loading a resource : /META-INF/services/javax.xml.validation.SchemaFactory from xercesImpl.jar wich was added by the Bundle-ClassPath. 
When we try to findResources in BundleLoader, the class extract package name : META-INF.services. And try to find this package in required bundle. But my resource is inside an embedded library as bundle classpath. I don't know how eclipse solve this and how to find the resource ? Maybe we must add a specific class loader in our CombinedClassLoader ?
 
Maybe i must do a specific way (call hierarchy) to manage real resource like META-INF data ?
 
Before implementing anything I prefer asking the good way to fix it.
 
Sorry for my english, it's not my native language.
 
Regards
Guillaume Dufour
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Parallel bundle activation?

[Thomas Watson]

Neil and Gunner are correct.  I also question the motivation to running activators in parallel.  In implies some kind of design flaw because you must have some long running BundleActivators if you want to run them in parallel.  You are better off investigating why you must have long running BundleActivators.
Tom 
 
 
- Original message -From: Neil Bartlett Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: Re: [equinox-dev] Parallel bundle activation?Date: Fri, Oct 26, 2018 7:20 AM 
Hi Lars,
 
Activation of a bundle happens when the launcher calls Bundle.start(). You can certainly write a launcher that calls start() on many bundles concurrently from multiple threads.
 
Most existing launchers, including AFAICT the default Eclipse/Equinox launcher, call start() in series.
 
Neil 

On Fri, Oct 26, 2018 at 1:12 PM Gunnar Wagenknecht  wrote:
Hi Lars,
 
Here is a good thread about the topic:
https://www.eclipse.org/forums/index.php/t/206827/
 
TLDR: single thread only
 
-Gunnar
-- Gunnar Wagenknechtgun...@wagenknecht.org, http://guw.io/
 
 
 
On Oct 26, 2018, at 14:09, Lars Vogel  wrote: 

Hi,can Equinox perform bundle activation during startup in parallel?For example, lets assume I have two bundles A and B which have nodependency to each other. Both should be activated during startup. Canthis be done in parallel? Or is the current code single-threaded?Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] Provide new OSGi service API without obsolete API(Dictionary)?

[Thomas Watson]

Dictionary my be documented as obsolete, but it is not deprecated.  I would not want to deprecate a spec'ed API method that takes non-deprecated types.  Anyway, the discussion is happening now in the expert group.
Tom 
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [equinox-dev] Provide new OSGi service API without obsolete API (Dictionary)?Date: Fri, Jun 29, 2018 2:35 AM 
Hi,I wanted to give official feedback that my customers are surprisedthat OSGi service API is based on obsolete data types.From the Javadoc of Dictionary:NOTE: This class is obsolete.This makes the OSGi service API look outdated for several of thecustomers I discussed this. OSGi ds hides this a bit but sometimes thelow-level API must be used.So for those involved in the OSGi spec, maybe you can considerdeprecating the old methods in BundleContext and providing new oneswith non-obsolete API, e.g., Map?I'm aware that this is "just a mailing list" but AFAIK several of thesubscribed people here are involved in the OSGi specification.Best regards, Lars--Eclipse Platform project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] logging jobs

[Thomas Watson]

You probably want the Eclipse Platform forum: https://www.eclipse.org/forums/index.php/f/11/
Tom 
 
 
- Original message -From: Raymond Auge <raymond.a...@liferay.com>Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list <equinox-dev@eclipse.org>Cc:Subject: Re: [equinox-dev] logging jobsDate: Wed, Mar 28, 2018 9:51 AM 
 
 
On Wed, Mar 28, 2018 at 10:37 AM, Thomas Watson <tjwat...@us.ibm.com> wrote:

What do you mean by runtime jobs?  When I hear that in the Eclipse context I think something from org.eclipse.core.jobs. 
 
Maybe?
 
But I suspect that is not what you are asking for.  Are you asking for some tracing for all background operations the framework performs?  I assume you are trying to diagnose an issue of some sorts.  What is the nature of the issue?
 
I'm just wondering if I there's somewhere to track (i.e. log) the items that have come through the "Progress" view of eclipse. 
I can ask somewhere else if that's not relevant question here. 
Sincerely,
- Ray
 
Tom 
 
 
- Original message -From: Raymond Auge <raymond.a...@liferay.com>Sent by: equinox-dev-bounces@eclipse.orgTo: Equinox development mailing list <equinox-dev@eclipse.org>Cc:Subject: [equinox-dev] logging jobsDate: Wed, Mar 28, 2018 9:15 AM 
Is there a way to log all eclipse runtime jobs somewhere? 
thanks,- Ray
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_equinox-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=oUCcvfdb23EIG6lu8kdlu6jgV1aV6VzzhsPjedGzE38=hL_vNYMrS8pEGSlDBLM8C5Ynw8KRi4DSV6E1i_PEd7Y=
 ___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_equinox-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=rCNZXlRQmuSHURQoN2Ebw7k92GGdxYw6jqoyqOnCZ-4=O3nxOmOI9bE4lU5B395FSLjyY7OsjfvQ_Ht_IczhQPk=
 

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

Re: [equinox-dev] logging jobs

[Thomas Watson]

What do you mean by runtime jobs?  When I hear that in the Eclipse context I think something from org.eclipse.core.jobs.  But I suspect that is not what you are asking for.  Are you asking for some tracing for all background operations the framework performs?  I assume you are trying to diagnose an issue of some sorts.  What is the nature of the issue?
Tom 
 
 
- Original message -From: Raymond Auge Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [equinox-dev] logging jobsDate: Wed, Mar 28, 2018 9:15 AM 
Is there a way to log all eclipse runtime jobs somewhere? 
thanks,- Ray
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_equinox-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=oUCcvfdb23EIG6lu8kdlu6jgV1aV6VzzhsPjedGzE38=hL_vNYMrS8pEGSlDBLM8C5Ynw8KRi4DSV6E1i_PEd7Y=
 

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

Re: [equinox-dev] org.osgi.util.promise

[Thomas Watson]

Hi Scott,
 
You are correct.  That package got added to Oxygen when we started using the Felix SCR implementation for our OSGI R6 Declarative Services.
Tom 
 
 
- Original message -From: Scott Lewis Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [equinox-dev] org.osgi.util.promiseDate: Fri, Mar 9, 2018 12:14 PM 
Hi,I want to verify:   org.osgi.util.promise (via org.eclipse.osgi.util)doesn't seem to be in Eclipse Neon, but is available in Oxygen+.Is that right?Scott___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_equinox-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=_dHgi6NYmQc-foqc3kZM6-76NntTLthXYHHaTaS8M1c=bvcUuPmp84MnUtkNjhSOYvUNwrXi2UVg6h9BUmOFSok=
 

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

Re: [equinox-dev] Support for Java 9 modules

[Thomas Watson]

I think we should be explicit in deciding what our automatic module name is instead of depending on what the file name is on disk.  Anyone can rename our bundle file names on disk, that does not change what its OSGi Bundle-SymbolicName is.  Therefore I would advocate we use the Automatic-Module-Name header so we have explicit control over the name which cannot be changed simply by renaming the file.
 
Did you mean to put an underscore _ in for the separator of the version?  I would have expected org.eclipse.equinox.common_3.9.0.v20170207.jar
 
I don't have a good idea on how hard it would be to change the build and consumption of the artifacts with a - (dash) vs _ (underscore).  I do know the osgi.bundles property supports both.  It was a bit tricky to get it to play nicely with discovering both bundles with dash and bundles with underscore.
Tom 
 
 
- Original message -From: Stephan Herrmann <stephan.herrm...@berlin.de>Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: Re: [equinox-dev] Support for Java 9 modulesDate: Thu, Oct 5, 2017 2:00 PM 
We (JDT) have just been toying with the opposite direction:add module-info.java to an existing OSGi bundle.I only then noticed that none of our OSGi bundles can beconsumed as automatic JPMS modules, because the algorithmfor names of automatic modules, fails to cut off the versionfrom jar files like    org.eclipse.equinox.common.3.9.0.v20170207.jarDue to lack of a separating "-" we end up with an illegalmodule name of    org.eclipse.equinox.common.3.9.0.v20170207I'm not even sure if this is a useful exercise, but in caseit might be: should we recommend / request that all futurereleases of Eclipse plug-ins specify a legal module namevia Automatic-Module-Name manifest attribute?Or could the names of jar files be adjusted to use "-" as in    org.eclipse.equinox.common-3.9.0.v20170207.jarI believe, p2 could absorb this change, no? It would then bean issue of convincing tools like PDE and tycho to produce jarswith a modified naming scheme? (Or CBI aggregator for that matter).best,StephanOn 05.10.2017 15:12, Thomas Watson wrote:> Not sure if you are aware of the work I have done for JPMS inter-op [1]> During my prototyping of inter-op I also did try implementing what you suggest, by adapting Java 9 modules to OSGi bundles on the> fly (See [2]).  I know this is possible to do, but much more thought is needed before making any concrete proposal.  In my> experiment the equinox hook discovers the JPMS modules in the VM and then virtualizes them into bundles represented in the OSGi> Framework.  The other part of the solution is to adapt module jars that are installed as bundles by discovering their Java 9> ModuleDescriptor and generating the equivalent OSGi meta-data for the Framework.  Then when the bundles representing the JPMS> modules are resolved they can properly resolve against the virtualized JPMS modules I created for the boot layer modules.> But there are gotchas to this approach that make it seem less useful than you would think.  The tool for interactions between Java 9> modules is to use ServiceLoader.  I've not cracked that nut to get ServiceLoader to work correctly when you do this type of> virtualization of the Java 9 modules into an OSGi Framework's module system.  If that is not made to work seamlessly then I question> the value of using pure JPMS modules in an OSGi Framework without some kind of more advanced transformation of the module.> Beyond that you would need a load of work to get the tools for building your OSGi bundles which depend on the pure JPMS modules such> that the tools know that at runtime this module will really be a bundle with a certain set of capabilities.  That is why I suggested> an easier approach is to build up the tools to make it easy for module developers to insert the necessary OSGi meta-data into their> own Java 9 modules along side their module-info.class files.  This will allow all the existing tools to work with such module jars> along with the existing OSGi Framework implementations.> I do welcome others to come and assist in this experiment though.  If we get something that is more useful then we can consider> bringing it into Equinox or take the steps to standardizing the approach at the OSGi Alliance.> Tom> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.osgi.org_2016_08_osgi-2Dwith-2Djava-2Dmodules-2Dall-2Dway-2Ddown.html=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=U6QQs3MZBjXTlb0O0YWlOW_RFywXsAQsAnJrNbzfhIA=LH3u_xWG6tC9aFqoXCieQ0GYIOAUcIxgmmO9n3UwwmU= > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tjwatson_osgi-2Djpms-2Dlayer_blob_master_osgi.jpms.layer_src_osgi_jpms_internal_layer_EquinoxJPMSSupport.java-23L113=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=U6QQs3MZBjXTlb0O0YWlOW_RFywXsAQsAnJrNbzfhIA=n

Re: [equinox-dev] Support for Java 9 modules

[Thomas Watson]

Not sure if you are aware of the work I have done for JPMS inter-op [1]
 
During my prototyping of inter-op I also did try implementing what you suggest, by adapting Java 9 modules to OSGi bundles on the fly (See [2]).  I know this is possible to do, but much more thought is needed before making any concrete proposal.  In my experiment the equinox hook discovers the JPMS modules in the VM and then virtualizes them into bundles represented in the OSGi Framework.  The other part of the solution is to adapt module jars that are installed as bundles by discovering their Java 9 ModuleDescriptor and generating the equivalent OSGi meta-data for the Framework.  Then when the bundles representing the JPMS modules are resolved they can properly resolve against the virtualized JPMS modules I created for the boot layer modules.
 
But there are gotchas to this approach that make it seem less useful than you would think.  The tool for interactions between Java 9 modules is to use ServiceLoader.  I've not cracked that nut to get ServiceLoader to work correctly when you do this type of virtualization of the Java 9 modules into an OSGi Framework's module system.  If that is not made to work seamlessly then I question the value of using pure JPMS modules in an OSGi Framework without some kind of more advanced transformation of the module.
 
Beyond that you would need a load of work to get the tools for building your OSGi bundles which depend on the pure JPMS modules such that the tools know that at runtime this module will really be a bundle with a certain set of capabilities.  That is why I suggested an easier approach is to build up the tools to make it easy for module developers to insert the necessary OSGi meta-data into their own Java 9 modules along side their module-info.class files.  This will allow all the existing tools to work with such module jars along with the existing OSGi Framework implementations.
 
I do welcome others to come and assist in this experiment though.  If we get something that is more useful then we can consider bringing it into Equinox or take the steps to standardizing the approach at the OSGi Alliance.
 
Tom 
[1] http://blog.osgi.org/2016/08/osgi-with-java-modules-all-way-down.html
[2] https://github.com/tjwatson/osgi-jpms-layer/blob/master/osgi.jpms.layer/src/osgi/jpms/internal/layer/EquinoxJPMSSupport.java#L113
 
 
- Original message -From: Lars Vogel <lars.vo...@vogella.com>Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list <equinox-dev@eclipse.org>Cc:Subject: Re: [equinox-dev] Support for Java 9 modulesDate: Thu, Oct 5, 2017 3:59 AM 
Thanks Tom, for the answer.I was hoping to simplify the consumption of Maven central for RCPdevelopment. From my Android development experience, I can tell thatit is pure fun to try out a new library (simply by adding it to theGradle build file). Doing the same for RCP is relativelytime-consuming (convert the lib and all of its dependencies to becomean OSGi bundle and at it to the target platform).But from your answer, I understand that OSGi / Equinox does currentlynot plan to simplify the consumption of the Java 9 modules. So we haveto stay with the old conversion process.Thanks again for the answer, LarsOn Wed, Oct 4, 2017 at 8:20 PM, Thomas Watson <tjwat...@us.ibm.com> wrote:> Something like that could be done, but I question the approach.  Seem like> something that made it easy to stick OSGi meta-data into a module archive> (jar) would be better.  Something like Eclipse Bundle Recipes or using BND> tools directly.>> Tom>>>>> - Original message -> From: Lars Vogel <lars.vo...@vogella.com>> Sent by: equinox-dev-boun...@eclipse.org> To: Equinox development mailing list <equinox-dev@eclipse.org>> Cc:> Subject: [equinox-dev] Support for Java 9 modules> Date: Wed, Oct 4, 2017 11:22 AM>> Hi,>> are there plans to support Java 9 modules in OSGi / Equinox?>> We used to have the Eclipse 2.0 compatibility layer which converted a> 2.0 style plug-in to a valid OSGi bundle.>> Maybe Equinox could provide a similar thing for converting Java 9> modules to valid OSGi bundles.>> 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:> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vogella.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=3-qYstlOBrDWVXBRYgDzeD3MPiHRf4H1I9lQI7v6zYs=ugHZ-frWDCYQS_Cb3hPN0I0WewjdYO92jPqvcVSG3bw=OzGhQ_mFH_MF8rUrBUtTi_AF3V4lp7nX0vY08nARvJ8=> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsub

[equinox-dev] Consider moving Equinox back to the Eclipse project

[Thomas Watson]

 
Over the years Equinox has become a stable project.  The last major code effort was in the Luna release when the Equinox framework was refactored to use the OSGi generic capability and requirements model along with the OSGi Resolver service.  Over the past few years the list of active committers has dropped to just a handful.  We did add two additional committers this past year, but even the voting turnout from existing committers was pretty low.
 
The Eclipse top-level project itself has also suffered from a drop in active committers.  In an effort to consolidate the committer base and get more active committers across the eclipse project the Eclipse PMC has continued to merge their own committer groups so that they can share the burden of maintaining the rather large code base among the set of active committers included in the top-level Eclipse project.
 
Many years ago the Equinox project was spun out of the Eclipse top-level project to its own project under the top-level RT project.  The Eclipse project continued to heavily depend on Equinox for its runtime and the two projects are still very closely tied together with respect to planning and release engineering for the overall releases produced each year.  It has become apparent to me that separating Equinox out from under the top-level Eclipse project is not serving in the continued best interests of Equinox nor the Eclipse project as a whole.  As Equinox committers, we deal more closely with the Eclipse PMC in planning our release than we do the RT PMC.  I think it is more representative of the work done in Equinox to be placed back under the Eclipse project PMC.  I propose we do a move review to move the Equinox project back under the Eclipse top-level project.
 
I do not anticipate this will change much in the way of how we develop and release Equinox today since much of that is already influenced by the Eclipse Project release engineering team.  I also do not think this will inhibit our ability to change how Equinox is developed, if we so choose.  For example:
 
- having more frequent releases to maven central
- moving to bndtools for development
- etc.
 
We should be able to drive changes into Equinox with the same flexibility as we do under the RT top-level project.  But instead of being under the leadership of the disparate RT PMC (which is largely be design) we will be back under the leadership of the Eclipse PMC which I believe is more cohesive to the day to day activities in Equinox than the overall RT PMC.  Please let me know if you have any concerns or questions about moving Equinox back to the top-level Eclipse project.  If nobody objects then I will start to formalize a plan to do the move.
Tom 

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

[equinox-dev] Consider moving Equinox back to the Eclipse project

[Thomas Watson]

Over the years Equinox has become a stable project.  The last major code 
effort was in the Luna release when the Equinox framework was refactored 
to use the OSGi generic capability and requirements model along with the 
OSGi Resolver service.  Over the past few years the list of active 
committers has dropped to just a handful.  We did add two additional 
committers this past year, but even the voting turnout from existing 
committers was pretty low.
 
The Eclipse top-level project itself has also suffered from a drop in 
active committers.  In an effort to consolidate the committer base and get 
more active committers across the eclipse project the Eclipse PMC has 
continued to merge their own committer groups so that they can share the 
burden of maintaining the rather large code base among the set of active 
committers included in the top-level Eclipse project.
 
Many years ago the Equinox project was spun out of the Eclipse top-level 
project to its own project under the top-level RT project.  The Eclipse 
project continued to heavily depend on Equinox for its runtime and the two 
projects are still very closely tied together with respect to planning and 
release engineering for the overall releases produced each year.  It has 
become apparent to me that separating Equinox out from under the top-level 
Eclipse project is not serving in the continued best interests of Equinox 
nor the Eclipse project as a whole.  As Equinox committers, we deal more 
closely with the Eclipse PMC in planning our release than we do the RT 
PMC.  I think it is more representative of the work done in Equinox to be 
placed back under the Eclipse project PMC.  I propose we do a move review 
to move the Equinox project back under the Eclipse top-level project.
 
I do not anticipate this will change much in the way of how we develop and 
release Equinox today since much of that is already influenced by the 
Eclipse Project release engineering team.  I also do not think this will 
inhibit our ability to change how Equinox is developed, if we so choose. 
For example:
 
- having more frequent releases to maven central
- moving to bndtools for development
- etc.
 
We should be able to drive changes into Equinox with the same flexibility 
as we do under the RT top-level project.  But instead of being under the 
leadership of the disparate RT PMC (which is largely be design) we will be 
back under the leadership of the Eclipse PMC which I believe is more 
cohesive to the day to day activities in Equinox than the overall RT PMC. 
Please let me know if you have any concerns or questions about moving 
Equinox back to the top-level Eclipse project.  If nobody objects then I 
will start to formalize a plan to do the move.

Tom



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

[equinox-dev] OSGi Framework R7 implementation has been merged into master for Photon

[Thomas Watson]

 
I have merged the branch we had for OSGi R7 into master for rt.equinox.framework.
 
I expect there may be a few compilation errors in the next build because of some places where we implement interfaces from the framework which are not intended to be implemented by client code (probably mostly for tests code).  I fixed up one such case in p2 [1], but I did not check all of the eclipse repos for such issues.
 
I'll check in tomorrow to see what else may need to be fixed up after the I-Build so we be sure to have good builds by Monday.
Tom 
[1] http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=0bd6de95a5caa4ebc3f9d05a2453b945ef393621

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

Re: [equinox-dev] singleton:=true leads to bundle activation

[Thomas Watson]

Singleton should have nothing to do with activation.  Do you have a scenario to reproduce?
Tom 
 
 
- Original message -From: Lars Vogel Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox development mailing list Cc:Subject: [equinox-dev] singleton:=true leads to bundle activationDate: Tue, Jun 13, 2017 8:38 AM 
Hi,I'm currently writing a unit test for Platform UI which should preventundesired additional plug-in activation.It looks like that the directive singleton:=true leads to plug-inactivation. Is that intended behavior?AFAIK only plug-ins with OSGi services or activators require activation.Best regards, Lars--Eclipse Platform UI and e4 project co-leadCEO vogella GmbHHaindaalwisch 17a, 22395 HamburgAmtsgericht Hamburg: HRB 127058Geschäftsführer: Lars Vogel, Jennifer Nerlich de VogelUSt-IdNr.: DE284122352Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web: http://www.vogella.com___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

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

[equinox-dev] Welcome Alexander Kurtakov as a new rt.equinox Committer

[portal on behalf of Thomas Watson]

rt.equinox Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Alexander Kurtakov. Alexander
Kurtakov is a new full Committer on the rt.equinox project.

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

Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it exists

[Thomas Watson]

For awareness,
 
I am looking at it, but will be a bit slow while at EclipseConverge and Devoxx.  Looking at the problem it seems that the resolver should find a solution pretty easily but the presence of one of the versions of org.apache.httpcomponents.httpcore_4.4.4.v20161115-1643 (there are three versions of this bundle!!) is causing something to happen where the resolver discards the correct solution.
Tom 
 
 
- Original message -From: Andreas Sewe Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: Re: [equinox-dev] Uses constraint violation: -clean doesn't find solution even though it existsDate: Mon, Mar 20, 2017 7:03 AM 
Hi,> Having only one exporter of a package is generally the best way to avoid> choice :-)I know. Sadly, that's not a (short term) solution to this particularproblem (see below).> The import [4.2.1,4.4) seems very odd. Why the upper limit on 4.4? This> seems to ignore semantic versioning. I would have expected [4.2,5).I would have expected this as well, but am unsure whether the originaldevelopers of Eclipse Aether felt the need to be conservative because ofa prior problem with Apache HttpComponents (non)adherence to semanticversioning.What's worse, the Aether project has been terminated [1] at Eclipse.Newer versions of Aether are only available as non-OSGi bundles underthe name org.apache.maven.resolver [2] (but still withorg.eclipse.aether packages).We can bring those to Orbit, of course, but that takes some time andAFAIK the IP check deadline for Oxygen lies in the past already.Also, we (rather than the Aether developers) are then responsible forgetting all the imports right. ;-)> Similarly [4.3.3,) is too broad. I would have expected [4.3,5). These> version ranges would appear to be hand written as Bnd would not make> those choices.The org.apache.httpcomponents.httpcore 4.3.3 bundle is handwritten. Theorg.eclipse.aether.transport.http bundle uses the maven-bundle-plugin,with the following instructions [3].> org.eclipse.aether.transport.http needs to be fixed to widen the import> range for org.apache.http.I can try bringing it (and the other now-Apache Aether bundles) toOrbit. At least we have bnd-based tooling available for this, but Idon't think this will be possible for Oxygen.Best wishes,Andreas[1][2][3]--Codetrails GmbHThe knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtPhone: +49-6151-276-7092Mobile: +49-170-811-3791http://www.codetrails.com/Managing Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940 
 
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] appending reference to url passed toBundleContext.installBundle

[Thomas Watson]

A 'reference' install will not copy the content of the bundle file into the framework's internal storage.  Instead it will load the bundle directly out of the file URL the 'reference' URL is pointing to.  Note that 'reference' URLs only support embedded 'file' URLs (not http etc.)  This has advantages for management agents that manage bundles in their own bundle store on disk and you want to avoid double copies of the bundle on disk when they are installed into the framework.
 
Any non-reference URL will copy the content of the bundle into the framework's internal storage.  This allows the original content to be deleted after installation and the bundle will remain functional and installed within the framework.
 
HTH
Tom 
 
 
- Original message -From: Yash Bagadia Sent by: equinox-dev-boun...@eclipse.orgTo: "equinox-dev@eclipse.org" Cc:Subject: [equinox-dev] appending reference to url passed to BundleContext.installBundleDate: Tue, Feb 7, 2017 3:33 AM 
I have observed there are 2 ways to pass url to BundleContext.installBundle function as below:
String installURL1 = "file:///abc/def.jar;
 String installURL2 = "reference:file:abc/def.jar";
What is the difference in these 2 and which one is recommended?
 
 
Regards,
Yash Bagadia
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 

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

Re: [equinox-dev] scr, cm, and metatype

[Thomas Watson]

Correct, Equinox EventAdmin uses a single thread for async event delivery.  See https://bugs.eclipse.org/bugs/show_bug.cgi?id=302729
 
That is pretty old bug.  Perhaps more is available in Java 8 to make this more simple to implement.  I have not put thought into this issue in a while though.  If you have some thoughts we can discuss in that bug report.
Tom 
 
 
- Original message -From: Scott Lewis <sle...@composent.com>Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: Re: [equinox-dev] scr, cm, and metatypeDate: Fri, Jan 27, 2017 5:48 PM 
On 1/20/2017 6:38 AM, Thomas Watson wrote:
EventAdmin is also the RI for OSGi R6.  There are no updates to EventAdmin for R7.Thanks.   One follow up on EventAdmin.   I've read that the Equinox EventAdmin uses a single thread for dispatch...i.e. for all topics...and it seems like that's correct given a short glance at the code.    And that there is no way to configure things to (e.g.) use/configure a thread pool.   Is that still true?Thanks,Scott 
CM and DS both have significant updates in R7, but the spec is not going to be finalized in time for Oxygen so it will have to way until the next release.  The DS updates are very significant and that is what motivated me to move to the felix SCR implementation.  There simply was no interest to be found to update the Equinox DS implementation and it was getting very stale WRT spec levels.I have not looked at the CM changes in detail for OSGi R7, but I suspect that should be easily contained in Equinox.  Let me know if anyone is interested in starting a branch to work on CM R7 in the mean time!  And to let folks on this list know again.  The Equinox Framework also continues to be the OSGi RI and ongoing work towards R7 is being done in a branch (twatson/osgiR7).  Again this is not planned to be included in Oxygen because the specification likely will not complete in time.  We could consider it for Oxygen.1 though.TomFrom:        Scott Lewis <sle...@composent.com>To:        equinox-dev@eclipse.orgDate:        01/19/2017 03:59 PMSubject:        Re: [equinox-dev] scr, cm, and metatypeSent by:        equinox-dev-boun...@eclipse.org
On 1/19/2017 12:36 PM, Thomas Watson wrote:Equinox metatype implementation continues to be the reference implementation for OSGi and implements the very latest released specification.I did update the CM implementation to be CM spec version 1.5 a long time ago (3 years?).  OSGi R6 did not update the CM spec, if I recall correctly. The spec doc for OSGi R6 still lists CM spec at version 1.5.  So from my perspective both of the CM and metatype Equinox impls are current with R6.Ok, great...I must have been misinformed about the versions.   Same for EventAdmin?Also...I heard that there were some proposed CM/DS additions for R7.   Are those to be in Equinox Oxygen or not likely?ScottTomFrom:        Scott Lewis <sle...@composent.com>To:        Equinox development mailing list <equinox-dev@eclipse.org>Date:        01/19/2017 12:40 PMSubject:        [equinox-dev] scr, cm, and metatypeSent by:        equinox-dev-boun...@eclipse.org
As per bug [1], Equinox and Eclipse are moving to use Felix SCR v2.0.8for Oxygen.My understanding is that the Equinox ConfigAdmin and Metatypeimplementations are rather old now...and don't support OSGi R6 versionsof those services.Would it be possible to add Apache Felix of ConfigAdmin andMetatype...versions that are at least R6 compatible...to Orbit?The reason I ask is that a number of projects (e.g. ECF, Kura, Karaf,others)...and our/their consumers...use DS+ConfigAdmin+Metatype allthree together, and having the Equinox versions of these services be soold is a problem for them (especially since the spec enhancements overlast few years have been very significant.Or, perhaps the right answer is to update these Equinox impls? Not sure.[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=501950___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 
  

___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev
 
___equinox-dev mailing listequinox-dev@e

Re: [equinox-dev] scr, cm, and metatype

[Thomas Watson]

EventAdmin is also the RI for OSGi R6.  There are no updates to EventAdmin 
for R7.

CM and DS both have significant updates in R7, but the spec is not going 
to be finalized in time for Oxygen so it will have to way until the next 
release.  The DS updates are very significant and that is what motivated 
me to move to the felix SCR implementation.  There simply was no interest 
to be found to update the Equinox DS implementation and it was getting 
very stale WRT spec levels.

I have not looked at the CM changes in detail for OSGi R7, but I suspect 
that should be easily contained in Equinox.  Let me know if anyone is 
interested in starting a branch to work on CM R7 in the mean time!  And to 
let folks on this list know again.  The Equinox Framework also continues 
to be the OSGi RI and ongoing work towards R7 is being done in a branch 
(twatson/osgiR7).  Again this is not planned to be included in Oxygen 
because the specification likely will not complete in time.  We could 
consider it for Oxygen.1 though.

Tom





From:   Scott Lewis <sle...@composent.com>
To: equinox-dev@eclipse.org
Date:   01/19/2017 03:59 PM
Subject:Re: [equinox-dev] scr, cm, and metatype
Sent by:equinox-dev-boun...@eclipse.org



On 1/19/2017 12:36 PM, Thomas Watson wrote:
Equinox metatype implementation continues to be the reference 
implementation for OSGi and implements the very latest released 
specification.

I did update the CM implementation to be CM spec version 1.5 a long time 
ago (3 years?).  OSGi R6 did not update the CM spec, if I recall 
correctly. The spec doc for OSGi R6 still lists CM spec at version 1.5. 
 So from my perspective both of the CM and metatype Equinox impls are 
current with R6.

Ok, great...I must have been misinformed about the versions.   Same for 
EventAdmin?

Also...I heard that there were some proposed CM/DS additions for R7.   Are 
those to be in Equinox Oxygen or not likely?

Scott



Tom





From:Scott Lewis <sle...@composent.com>
To:Equinox development mailing list <equinox-dev@eclipse.org>
Date:01/19/2017 12:40 PM
Subject:[equinox-dev] scr, cm, and metatype
Sent by:equinox-dev-boun...@eclipse.org



As per bug [1], Equinox and Eclipse are moving to use Felix SCR v2.0.8 
for Oxygen.

My understanding is that the Equinox ConfigAdmin and Metatype 
implementations are rather old now...and don't support OSGi R6 versions 
of those services.

Would it be possible to add Apache Felix of ConfigAdmin and 
Metatype...versions that are at least R6 compatible...to Orbit?

The reason I ask is that a number of projects (e.g. ECF, Kura, Karaf, 
others)...and our/their consumers...use DS+ConfigAdmin+Metatype all 
three together, and having the Equinox versions of these services be so 
old is a problem for them (especially since the spec enhancements over 
last few years have been very significant.

Or, perhaps the right answer is to update these Equinox impls? Not sure.

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

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






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



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

Re: [equinox-dev] scr, cm, and metatype

[Thomas Watson]

Equinox metatype implementation continues to be the reference 
implementation for OSGi and implements the very latest released 
specification.

I did update the CM implementation to be CM spec version 1.5 a long time 
ago (3 years?).  OSGi R6 did not update the CM spec, if I recall 
correctly. The spec doc for OSGi R6 still lists CM spec at version 1.5. So 
from my perspective both of the CM and metatype Equinox impls are current 
with R6.

Tom





From:   Scott Lewis 
To: Equinox development mailing list 
Date:   01/19/2017 12:40 PM
Subject:[equinox-dev] scr, cm, and metatype
Sent by:equinox-dev-boun...@eclipse.org



As per bug [1], Equinox and Eclipse are moving to use Felix SCR v2.0.8 
for Oxygen.

My understanding is that the Equinox ConfigAdmin and Metatype 
implementations are rather old now...and don't support OSGi R6 versions 
of those services.

Would it be possible to add Apache Felix of ConfigAdmin and 
Metatype...versions that are at least R6 compatible...to Orbit?

The reason I ask is that a number of projects (e.g. ECF, Kura, Karaf, 
others)...and our/their consumers...use DS+ConfigAdmin+Metatype all 
three together, and having the Equinox versions of these services be so 
old is a problem for them (especially since the spec enhancements over 
last few years have been very significant.

Or, perhaps the right answer is to update these Equinox impls? Not sure.

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

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





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

Re: [equinox-dev] Bundle self-update not delayed until refresh

[Thomas Watson]

I'm not sure I understand the scenario.

What I do know is that in the latest Equinox (since the Luna release) the 
framework will eagerly flush updated or uninstalled class loaders if they 
are not 'reachable' by any other in-use bundle in the framework.  It 
sounds to me like this may be what is effecting you in your scenario.  But 
in my opinion this is acceptable behavior because once a bundle is stopped 
it should no longer be doing any work on any thread.  It should not be 
trying to load additional classes any longer or doing work at all because 
it has stopped.  Now if the updated or uninstalled bundle exported some 
packages that are still in-use by other bundles in the system then the 
class loader for the bundle must remain functional until all in-use 
bundles of the exported package are refreshed also.

Tom





From:   Todor Boev 
To: Equinox development mailing list 
Date:   12/20/2016 03:40 AM
Subject:[equinox-dev] Bundle self-update not delayed until refresh
Sent by:equinox-dev-boun...@eclipse.org



I have a development tool bundle that updates a running equinox framework 
in batch mode.
I.e. it updates a list of bundles via Bundle.update() and then calls 
"FrameworkWiring.refresh()" on the entire batch. Sometimes the list 
includes the updater bundle itself.

In this case the thread that performs the updates needs to complete it's 
job - including the self update and then as the last act of the dead 
revision issue a refresh. In that case I expected that the bundle update 
will succeed with no noticeable effects. Later during the refresh the 
updater will be rebooted as normal. 

Instead however the updater is rebooted within the thread that performs 
Bundle.update(), and subsequently as the updater thread proceeds I hit a 
ClassNotFoundError since the old class loader is already destroyed and the 
old bundle revision jar is removed. I.e. the root cause of the error is a 
FileNotFoundException for the bundle revision to which the 
ModuleClassLoader of the old revision is bound.

I have also noticed such "eager update" mode in other cases that do not 
involve self update. So I though this is a nice occasion to ask when this 
happens and should it happen at all.
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] Way to retrieve the bundles with provides a capability from BundleRequirement

[Thomas Watson]

This is all getting a bit fuzzy for me because PDE is still using the old 
Equinox resolver API which the framework no longer actually uses at 
runtime.  But if I recall correctly Require-Capability reqs are modelled 
with the org.eclipse.osgi.service.resolver.GenericSpecification interface 
which has a getSuppliers() method.  The reason for it being plural is 
because require-capability may specify a cardinality of multiple so they 
can be 'wired' to more than one supplier at a time.  Also see 
org.eclipse.osgi.service.resolver.BundleDescription.getGenericRequires()

HTH

Tom





From:   Lars Vogel 
To: Equinox development mailing list 
Date:   12/20/2016 07:54 AM
Subject:[equinox-dev] Way to retrieve the bundles with provides a 
capability from BundleRequirement
Sent by:equinox-dev-boun...@eclipse.org



Friends of Equinox,

in PDE we have this "Add required" button which allows adding the
bundle requirements to a launch configuration and the product.

Currently is is implemented for required bundles and imported
packages. Equinox provides very simple API for that:

BundleSpecification requiredBundle;
BaseDescription bd = requiredBundle.getSupplier();


Do you have something similar for retrieving the bundles which
provides a capability (provide-capability)?

I found BundleRequirement but see now way to retrieve bundles which
seems to model "require-capability" but was unable to determine the
API to find suppliers.

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] What is the best way to get the version of a bundle

[Thomas Watson]

I'll also state that in Equinox (and AFAIK in Felix) the PackageAdmin 
implementation is not going anywhere for the foreseeable future.

Tom





From:   Pascal Rapicault 
To: Equinox development mailing list 
Date:   12/13/2016 08:46 PM
Subject:[equinox-dev] What is the best way to get the version of a 
bundle
Sent by:equinox-dev-boun...@eclipse.org



With Platform.getBundle officially removed, and PackageAdmin on its way 
out, could someone indicate the API of choice (and recommended code 
snippet) to use to get the version of a given bundle?


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





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

Re: [equinox-dev] What is the best way to get the version of abundle

[Thomas Watson]

I think Pascal is asking how to find an installed bundle given a specific 
BSN and version (range?).  I suggest you take a look at the 
PackageAdminImpl for the getBundles method:

https://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/internal/framework/legacy/PackageAdminImpl.java?h=R4_6_maintenance#n170

The FrameworkWiring.findProviders method is the way to discover 
capabilities of bundles in the framework, including the osgi.identity 
capability which holds the bundles BSN and version.

Tom





From:   Raymond Auge 
To: Equinox development mailing list 
Date:   12/13/2016 10:16 PM
Subject:Re: [equinox-dev] What is the best way to get the version 
of abundle
Sent by:equinox-dev-boun...@eclipse.org



Pascal, from which perspective would you like to get the bundle version?

>From the Bundle itself:

org.osgi.framework.Version version = 
org.osgi.framework.Bundle.getVersion();

Through the resolver API (arguably a little trickier):

Map results = 
org.osgi.service.resolver.Resolver.resolve(org.osgi.service.resolver.ResolveContext
 
ctx);
Resource resource = results.keySet().iterator().next();
List capabilities = 
resource.getCapabilities(IdentityNamespace.IDENTITY_NAMESPACE);
Map attributes = capabilities.get(0).getAttributes();
org.osgi.framework.Version version = 
(org.osgi.framework.Version)attributes.get(IdentityNamespace.CAPABILITY_VERSION_ATTRIBUTE);

There are a number of convenience APIs as well, but as I said earlier it 
really depends from which perspective you are trying... from a running 
framework or from some external agent analyzing a set of bundles.

Sincerely,
- Ray


On Tue, Dec 13, 2016 at 9:45 PM, Pascal Rapicault  
wrote:
With Platform.getBundle officially removed, and PackageAdmin on its way 
out, could someone indicate the API of choice (and recommended code 
snippet) to use to get the version of a given bundle?


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



-- 
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] Felix SCR

[Thomas Watson]

And yes, it will support the latest Declarative Services version 1.3 from 
the R6 specification

Tom





From:   Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   11/29/2016 07:55 AM
Subject:Re: [equinox-dev] Felix SCR
Sent by:equinox-dev-boun...@eclipse.org



Yes, that is the plan.  I had hoped to get it in for M4.  But have not had 
time to get it in.  I will look to put it in for M5.  If it slips past 
that though it will get more difficult to get it in.

Tom





From:Scott Lewis <sle...@composent.com>
To:Equinox development mailing list <equinox-dev@eclipse.org>
Date:11/28/2016 06:07 PM
Subject:[equinox-dev] Felix SCR
Sent by:equinox-dev-boun...@eclipse.org



Hi,

I thought I remembered that Equinox/Eclipse was going with the replacing 
the SCR impl that it's currently using with the Felix SCR implementation 
sometime during the Oxygen release cycle.   Is that still right?   If 
so, when is it planned to happen?   And one final question:   I assume 
it will be using some version of Felix SCR that supports the 1.3+ 
version of the SCR spec...is that true?

Thanksinadvance,

Scott



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



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



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

Re: [equinox-dev] Felix SCR

[Thomas Watson]

Yes, that is the plan.  I had hoped to get it in for M4.  But have not had 
time to get it in.  I will look to put it in for M5.  If it slips past 
that though it will get more difficult to get it in.

Tom





From:   Scott Lewis 
To: Equinox development mailing list 
Date:   11/28/2016 06:07 PM
Subject:[equinox-dev] Felix SCR
Sent by:equinox-dev-boun...@eclipse.org



Hi,

I thought I remembered that Equinox/Eclipse was going with the replacing 
the SCR impl that it's currently using with the Felix SCR implementation 
sometime during the Oxygen release cycle.   Is that still right?   If 
so, when is it planned to happen?   And one final question:   I assume 
it will be using some version of Felix SCR that supports the 1.3+ 
version of the SCR spec...is that true?

Thanksinadvance,

Scott



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





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

Re: [equinox-dev] Convergence between p2 and the OSGiresolver+repository

[Thomas Watson]

I will be interested to see if you can successfully map the OSGi uses 
concept into the SAT solver p2 uses.  I briefly looked at that a long time 
ago when we were refactoring the Equinox framework (Luna) and were 
replacing the old Equinox resolver.  It was far from obvious how you would 
achieve this.  At that time I opt'ed to collaborate with a common resolver 
in Felix for the Equinox framework.  But this is no magic implementation. 
There are still cases where the OSGi resolver algorithm will blow up.  In 
Equinox we try to minimize that possibility by avoiding the resolution of 
all (1) bundles at once.  But as Pascal states, this does leave out 
some possible valid solutions that you will then not discover while 
resolving.

If you do focus on how to map uses into the SAT solver in p2 I would be 
interested in collaborating to see if such a resolver would outperform the 
Felix resolver we use at runtime.  My hope at the time I was looking into 
this was to map an OSGi Resolver service on top of the SAT solver 
implementation.  But I cannot remember how the SAT solver is driven.  I 
suspect the split between the OSGI Resovler and the OSGi ResolveContext 
will not fit well into the SAT implementation model.

Tom





From:   Todor Boev 
To: Equinox development mailing list 
Date:   11/17/2016 02:22 AM
Subject:Re: [equinox-dev] Convergence between p2 and the OSGi 
resolver+repository
Sent by:equinox-dev-boun...@eclipse.org



- Regarding batch resolution:
Ultimately I think the batch processing is about performance. At 
provisioning time where finding the best solution trumps speed the 
resolver can be executed against the entire set. But I have to try this. 
After than the equinox runtime should be able to re-create a correct 
(maybe not identical) resolution from the much smaller set of resources. I 
have tried the resolver against about 700 bundles and it did okay, but 
this is well short of 10,000. More research requiredsome day.

- Regarding the additional p2 concepts:
Can you point me to the documentation of how the resolution problem is 
converted to a SAT formula?

Best regards

On Thu, Nov 17, 2016 at 6:20 AM, Pascal Rapicault  
wrote:
On 11/16/2016 10:49 AM, Todor Boev wrote:
- Regarding resolver behavior: 
  The goal is actually to replace the behavior of the objective function 
with the behavior of the resolver. This is the best way to guarantee that 
both p2 and the OSGi runtime agree on what is a consistent set of bundles. 
For example p2 does not take into account package uses constraints which 
leads to p2 selecting bundles that later fail to resolve at runtime. It 
does not matter which way to resolve is better, so long as they agree. 
Since the OSGi resolver is very unlikely to change it falls on p2 to match 
it's behavior. My current company (software ag) has had quite a number of 
issues where essentially p2 sets up the resolver to fail.

- Regarding resolver scalability:
  The resolution is split between the resolver which processes the current 
set of resources and the resolver context which selects candidates when 
asked. If the goal is to support a very high number of candidates - a 
resolver context impl optimized for searches in a large candidate space 
can be provided. If the goal is to produce a solution that includes a very 
high number of resources - more research is required. Even if the initial 
set is 10,000 the resolver can be asked to process them not all at once, 
but incrementally in batches or even one by one. Which is in fact what 
equinox does today.
The thing is that if you look at a subset of the available bundles, 
you may find a solution that is not the optimal one. p2 will consider all 
the possible candidates in one resolution invocation.


I am trying to determine if it makes sense to invest effort in prototyping 
this given that subtle changes in behavior are in fact a goal, rather than 
an issue.
Even though on the surface p2 resolver looks similar to what the OSGi 
resolver does, p2 has at least 2 additional concepts: 
1) the expression of strict negation
2) the concept of patch

I'm tempted to think that it is probably simpler to add support for the 
uses-clause in p2 (this has been a known issue for years, but I can't seem 
to find the bug tonight) than it is to replace the resolver completely and 
get all the tests to pass. The encoding of dependencies to a SAT formula 
is well documented and so are the optimization functions.


On Wed, Nov 16, 2016 at 4:44 AM, Pascal Rapicault  
wrote:
On 11/15/2016 12:52 PM, Todor Boev wrote:
Hello, 

Are there any plans to bring together p2 and OSGi resolver+repository 
standards?
There is no immediate plan for this.

It should be beneficial to have similar (maybe identical?) dependency 
resolution at provisioning time and later at runtime.
The install time and runtime 

Re: [equinox-dev] Disabling computeUses in ResolverImpl

[Thomas Watson]

Disabling uses is usually not a good idea.  I would be interested to know 
why you want to do this.

To answer your question, I would not disable this in the felix 
ResolverImpl directly.  Instead I would disable it at a higher level in 
the equinox container by hiding the uses directives on the 
osgi.wiring.package capabilities.  This can be achieved now in Oxygen by 
implementing an Equinox framework extension which implements a hook method 
org.eclipse.osgi.internal.hookregistry.StorageHookFactory.StorageHook.adaptModuleRevisionBuilder(ModuleEvent,
 
Module, ModuleRevisionBuilder)

Tom





From:   Roland Grunberg 
To: equinox-dev@eclipse.org
Date:   10/21/2016 02:04 PM
Subject:[equinox-dev] Disabling computeUses in ResolverImpl
Sent by:equinox-dev-boun...@eclipse.org



Hi,

It seems like in older versions of the Equinox framework it was possible 
to 
disable uses constraint checking on startup (osgi.resolver.usesMode).

This doesn't seem to be possible any longer but I'm wondering if the same
behaviour could be mimicked by disabling the computeUses() line in
org.apache.felix.resolver.ResolverImpl [1]. Are there additional side
effects to doing such a thing that weren't present before ?

Cheers,
-- 
Roland Grunberg

[1] 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/felix/src/org/apache/felix/resolver/ResolverImpl.java?h=R4_6_1#n1234

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





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

Re: [equinox-dev] Thousands of exceptions during boot, yet application is running - harmless or symptom of issues which should be solved?

[Thomas Watson]

Moving discussion over to forum:   
https://www.eclipse.org/forums/index.php?t=rview=1744897#msg_1744897

Tom





From:   Michal Siemaszko <michal.siemas...@vnomic.com>
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   10/03/2016 09:09 AM
Subject:Re: [equinox-dev] Thousands of exceptions during boot, yet 
application is running - harmless or symptom of issues which should be 
solved?
Sent by:equinox-dev-boun...@eclipse.org



Hi Tom, 

Thank you for your reply. 

I really was not trying hard to find problems, the only reason I hit these 
is because I need to debug remaining issues which prevent upgraded version 
of said application from running. The only tools (that I know of) at my 
disposal are breakpoints and osgi.debug; my reasoning was (and still is) 
that the underlying cause of these can be caught by looking at these, 
since by the time logging layer is initialized, only symptoms are visible. 
I did start with setting breakpoints in 
'org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader' (in catch 
blocks of #loadClass and #getResource methods), but then started hitting 
those existing exceptions by the thousands, then when osgi.debug was 
enabled all these stack traces were dumped to text file and are being 
analyzed. 

I see many of the stack traces (visible only in osgi.debug, or when 
hitting bps in DefaultClassLoader) then manifest as actual failures 
visible once logging layer kicks in (same classes, etc.)

Since file generated from osgi.debug is over 60 MB and there are over 3300 
exceptions, sharing these is not really possible at this point. 

Are there any other settings in osgi.debug or config.ini that could be 
turned on (many of these are not documented/hard to come across) that 
could help in properly diagnosing these issues? 

Regards, 
Michal

From: equinox-dev-boun...@eclipse.org <equinox-dev-boun...@eclipse.org> on 
behalf of Thomas Watson <tjwat...@us.ibm.com>
Sent: Monday, October 3, 2016 2:58:25 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Thousands of exceptions during boot, yet 
application is running - harmless or symptom of issues which should be 
solved? 
 
It is hard to tell if the exceptions are issues to be concerned about 
without having one as an example.  It is possible that enabling debug is 
just printing out some benign exception that is otherwise ignored by the 
system and not logged.

Yes Equinox should easily handle 1000s of bundles being installed.  There 
are many Eclipse based products that do just that.

Tom





From:Michal Siemaszko <michal.siemas...@vnomic.com>
To:"equinox-dev@eclipse.org" <equinox-dev@eclipse.org>
Date:10/01/2016 06:15 PM
Subject:[equinox-dev] Thousands of exceptions during boot, yet 
application is running - harmless or symptom of issues which should be 
solved?
Sent by:equinox-dev-boun...@eclipse.org



Hi, 

I'm working on upgrading a legacy application which uses Equinox as its 
OSGi runtime. When booted and running, there are close to a thousand 
bundles loaded in the container. 

Since I'm working on upgrading significant parts of the application, and 
debugging issues still present during boot, I discovered thousands of 
exceptions present in the existing (trunk/production version, not the 
upgraded one) of the application after enabling osgi.debug. 

Is seeing so many exceptions - e.g. ClassNotFound exceptions - during boot 
in an application which does boot however and runs, is normal? Or is it a 
symptom of issues which should be addressed and might come out when - e.g. 
now - parts of the application are being upgraded and many new bundles 
added and a critical point is reached where application simply will not 
start until underlying reason for this is solved? 

Is Equinox OSGi well suited for running applications consisting of close 
to a thousand bundles? Are there any potential resource bottleneck related 
issues which should be considered in such large OSGI applications? 

I will greatly appreciate your input, since I have not found much - or 
nothing at all - regarding issues which could cause such.

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

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



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

Re: [equinox-dev] Thousands of exceptions during boot, yet application is running - harmless or symptom of issues which should be solved?

[Thomas Watson]

It is hard to tell if the exceptions are issues to be concerned about 
without having one as an example.  It is possible that enabling debug is 
just printing out some benign exception that is otherwise ignored by the 
system and not logged.

Yes Equinox should easily handle 1000s of bundles being installed.  There 
are many Eclipse based products that do just that.

Tom





From:   Michal Siemaszko 
To: "equinox-dev@eclipse.org" 
Date:   10/01/2016 06:15 PM
Subject:[equinox-dev] Thousands of exceptions during boot, yet 
application is running - harmless or symptom of issues which should be 
solved?
Sent by:equinox-dev-boun...@eclipse.org



Hi, 

I'm working on upgrading a legacy application which uses Equinox as its 
OSGi runtime. When booted and running, there are close to a thousand 
bundles loaded in the container. 

Since I'm working on upgrading significant parts of the application, and 
debugging issues still present during boot, I discovered thousands of 
exceptions present in the existing (trunk/production version, not the 
upgraded one) of the application after enabling osgi.debug. 

Is seeing so many exceptions - e.g. ClassNotFound exceptions - during boot 
in an application which does boot however and runs, is normal? Or is it a 
symptom of issues which should be addressed and might come out when - e.g. 
now - parts of the application are being upgraded and many new bundles 
added and a critical point is reached where application simply will not 
start until underlying reason for this is solved? 

Is Equinox OSGi well suited for running applications consisting of close 
to a thousand bundles? Are there any potential resource bottleneck related 
issues which should be considered in such large OSGI applications? 

I will greatly appreciate your input, since I have not found much - or 
nothing at all - regarding issues which could cause such.

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



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

[equinox-dev] Equinox Framework moving up to Java 7

[Thomas Watson]

Equinox is used in many environments where there is very long-term support 
for older Java levels.  So far I have needed to keep the Equinox Framework 
at a Java 6 level to be able to use the latest versions in these 
environments.

Unfortunately Java 6 is getting harder and harder to support while also 
accommodating new "hurdles" being presented with Java 9 [1].  I will be 
updating the Equinox Framework to Java 7 for Oxygen [2].  Please voice any 
concerns you may have in the bug report [2].  Although I expect very 
little concern since most have already moved onto Java 8!

Tom

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502204
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502425

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

Re: [equinox-dev] Support for Declarative Services 1.3 (OSGi release 6)

[Thomas Watson]

For Oxygen I plan to replace the Equinox DS implementation with the Felix 
DS (SCR) implementation.  See 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=501950

Tom





From:   Todor Boev 
To: equinox-dev@eclipse.org
Date:   09/28/2016 07:31 AM
Subject:[equinox-dev] Support for Declarative Services 1.3 (OSGi 
release 6)
Sent by:equinox-dev-boun...@eclipse.org



Hello,

It seems that the equinox DS bundle currently does not support OSGi 
release 6 standard (DS 1.3).
Are there any plans to upgrade?

In particular I am interested in support for "Component property Types" 
(OSGi enterprise 6, 112.8.2, page 216)

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



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

[equinox-dev] Request to respin I-Build due to bug 500225

[Thomas Watson]

There is a bad endless loop bug in the last I-Build that the Equinox team 
is requesting a respin for.  Markus has already provided a fix for bug 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=500225 and we are ready for 
a respin.

To workaround the issue in the Install dialog ensure that the filter text 
box contains a non-empty string.  For example, using the value * will 
display everything in the repository.  You must use a non-empty filter 
BEFORE selecting any of the items in the tree of installable contents 
otherwise you will hit an endless loop when you select one of the items.

Tom



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

Re: [equinox-dev] Support advanced shell features in eclipse console window when launching a java program

[Thomas Watson]

I may be wrong, but I think the limitations are on the Eclipse console 
view implementation.  You may want to try posting a message to 
https://dev.eclipse.org/mailman/listinfo/jdt-debug-dev to get details on 
enabling that for the eclipse console.

Tom





From:   Christian Schneider 
To: equinox-dev@eclipse.org
Date:   08/17/2016 07:15 AM
Subject:[equinox-dev] Support advanced shell features in eclipse 
console window when launching a java program
Sent by:equinox-dev-boun...@eclipse.org



My use case is to start an OSGi framework with the gogo shell from eclipse
and have support for all the shell features like in a linux terminal.

There is a new gogo jline console which has very nice features like
completion, history, colors (like in karaf).
Seehttps://github.com/apache/felix/tree/trunk/gogo/jline

When I run my OSGi application outside of eclipse all these features work
nicely.

When I start the application from inside eclipse it is started in a 
console
window. There the input seems to work completely different. For example if 
I
type the up key the cursor goes up instead of showing the history.

It seems like the input is first processed for the whole line before it is
given to the application.

Some people hinted me that there might be some raw mode that can be 
switched
on.

So my question: Is it possible to use such advanced input using the 
console
window?
If it is not yet possible I would be very interested to get this
implemented. I am also willing to help if I can but I am a bit lost on how
it all works together and where to start.

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

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





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

[equinox-dev] Experiment with OSGi and JPMS modules (Java 9)

[Thomas Watson]

You may be interested in reading an article that I wrote about 
experimenting with JPMS layers and representing an OSGi framework as a 
JMPS Layer [1].

Tom

[1] http://blog.osgi.org/2016/08/osgi-with-java-modules-all-way-down.html

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

Re: [equinox-dev] receiving a FrameworkEvent.STARTED event?

[Thomas Watson]

It depends on the launcher you are using.  Here I am going to assume you 
are using the Equinox launcher as-is.  The thing about 
FrameworkEvent.STARTED is that it is only fired when the framework has 
reached its "beginning framework start-level" during the call to 
Framework.start(). By default this is start-level 1.  The Equinox launcher 
simply uses the default beginning framework start level of 1 when it 
starts the framework.  Once the framework has been started the 
Framework.STARTED event is fired.  Then the Equinox launcher proceeds to 
set the framework start-level to its final start-level (this defaults to 4 
for the equinox launcher).  That ends up activating all the other bundles 
installed in the system when their start-level is met.  The Equinox 
launcher could have decided to set the configuration of the beginning 
start-level to the final one of 4 instead of starting the framework using 
the default beginning framework start-level

Your bundle is activated at start-level 3, this will be well after the 
Framework.STARTED event was fired.  Similarly the STOPPED events are not 
fired until the framework start-level has reached zero.  At that time your 
bundle will have already been de-activated.  When a bundle is de-activated 
all of its left-over listeners are flushed from the system so the 
framework does not hold onto stale objects and create a leak.  The only 
way to see one of the STOPPED events is to implement your own launcher 
which uses the Framework launching API.

The Equinox launcher could have decided to set the configuration of the 
beginning start-level to the final one of 4 instead of starting the 
framework using the default beginning framework start-level of 1 and then 
later setting the final framework start-level to 4.  That would have 
allowed your bundle to sometimes see teh STARTED event.  But even then 
there are times you would not see the event.  For example, if the bundle 
was installed and started after the framework was already started.

Tom





From:   Cristiano Gavião 
To: Equinox development mailing list 
Date:   07/06/2016 06:15 AM
Subject:[equinox-dev] receiving a FrameworkEvent.STARTED event?
Sent by:equinox-dev-boun...@eclipse.org



Hello all,

I'm facing a problem and would like to ask for some information.

I have a bundle whose activator is registering a FrameworkListener inside 
the start() method. This bundle is set to start at level 3.

frameworkListener = new FrameworkListener() {
public void frameworkEvent(FrameworkEvent event) {
if (event.getType() == FrameworkEvent.STARTED) {
try {
initiateProcess();
} catch (Exception e) {
logger.error("Failure occurred while executing "
+ "initial process.");
}
}
}
pBundleContext.addFrameworkListener(frameworkListener);

When executing that bundle with a OSGi Framework launcher then the unique 
event being captured is STARTLEVEL_CHANGED. I can't find a way to it to 
also receive a FrameworkEvent.STARTED.

And I'm not also receiving the FrameworkEvent.STOP after type a close 
command and leave the session.

Please, could someone explain me what am I missing here?

thanks,

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



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

Re: [equinox-dev] Fwd: Starting a runtime Eclipse fails with Exception in org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of bundle org.eclipse.equinox.simpleconfigurator.

[Thomas Watson]

FYI, I decided to open this bug myself so I could get a fix going while it 
was fresh in my mind: https://bugs.eclipse.org/bugs/show_bug.cgi?id=497094

Although I don't have any way to test this since I would not know how to 
get p2 to install a bundle with no symbolic name.

Tom





From:   Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   06/30/2016 07:51 AM
Subject:Re: [equinox-dev] Fwd: Starting a runtime Eclipse fails 
with Exception in 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of 
bundle org.eclipse.equinox.simpleconfigurator.
Sent by:equinox-dev-boun...@eclipse.org



Some bundle in your environment looks like it has no Bundle-SymbolicName. 
Can you open a bug against p2.  It needs a null check at 
ConfigApplier.refreshPackages(ConfigApplier.java:401)

But I am curious how you got p2 to install a bundle with no 
Bundle-SymbolicName.  I thought that was basically impossible to do.

Tom





From:Lars Vogel <lars.vo...@vogella.com>
To:Equinox development mailing list <equinox-dev@eclipse.org>
Date:06/29/2016 06:29 PM
Subject:[equinox-dev] Fwd: Starting a runtime Eclipse fails with 
Exception in 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of 
bundle org.eclipse.equinox.simpleconfigurator.
Sent by:equinox-dev-boun...@eclipse.org



Hi Friends of Equinox,

if I start an runtime Eclipse from the pde.ui repository I get the
error that org.eclipse.equinox.simpleconfigurator_1.1.200.v20160504-1450
[2439] is not active.

Stack trace below.

Do you have suggestions how to solve this issue? My "normal"
strategies for a Eclipse startup issue don't work (clean workspace,
add required plug-ins, manually add the event plug-ins and its
dependencies, clean configuration area, use -clearPersistedState
flag).

Best regards, Lars

!ENTRY org.eclipse.equinox.simpleconfigurator 4 0 2016-06-30 01:21:22.994
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in
org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of
bundle org.eclipse.equinox.simpleconfigurator.
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:795)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571)
at 
org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:247)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:177)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:402)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:115)
at 
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:326)
at 
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Caused by: java.lang.IllegalArgumentException
at 
org.eclipse.osgi.internal.framework.legacy.PackageAdminImpl.getBundles(PackageAdminImpl.java:172)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.refreshPackages(ConfigApplier.java:401)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:105)
at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:191)
at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:205)
at 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:60)
at 
org.eclipse.osgi.internal.frame

Re: [equinox-dev] Fwd: Starting a runtime Eclipse fails with Exception in org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of bundle org.eclipse.equinox.simpleconfigurator.

[Thomas Watson]

Some bundle in your environment looks like it has no Bundle-SymbolicName. 
Can you open a bug against p2.  It needs a null check at 
ConfigApplier.refreshPackages(ConfigApplier.java:401)

But I am curious how you got p2 to install a bundle with no 
Bundle-SymbolicName.  I thought that was basically impossible to do.

Tom





From:   Lars Vogel 
To: Equinox development mailing list 
Date:   06/29/2016 06:29 PM
Subject:[equinox-dev] Fwd: Starting a runtime Eclipse fails with 
Exception in 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of 
bundle org.eclipse.equinox.simpleconfigurator.
Sent by:equinox-dev-boun...@eclipse.org



Hi Friends of Equinox,

if I start an runtime Eclipse from the pde.ui repository I get the
error that org.eclipse.equinox.simpleconfigurator_1.1.200.v20160504-1450
[2439] is not active.

Stack trace below.

Do you have suggestions how to solve this issue? My "normal"
strategies for a Eclipse startup issue don't work (clean workspace,
add required plug-ins, manually add the event plug-ins and its
dependencies, clean configuration area, use -clearPersistedState
flag).

Best regards, Lars

!ENTRY org.eclipse.equinox.simpleconfigurator 4 0 2016-06-30 01:21:22.994
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Exception in
org.eclipse.equinox.internal.simpleconfigurator.Activator.start() of
bundle org.eclipse.equinox.simpleconfigurator.
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:795)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1600)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571)
at 
org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:247)
at org.eclipse.osgi.container.Module.doStart(Module.java:581)
at org.eclipse.osgi.container.Module.start(Module.java:449)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:177)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383)
at 
org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:402)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:115)
at 
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:326)
at 
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
at org.eclipse.equinox.launcher.Main.run(Main.java:1519)
at org.eclipse.equinox.launcher.Main.main(Main.java:1492)
Caused by: java.lang.IllegalArgumentException
at 
org.eclipse.osgi.internal.framework.legacy.PackageAdminImpl.getBundles(PackageAdminImpl.java:172)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.refreshPackages(ConfigApplier.java:401)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:105)
at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:191)
at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:205)
at 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:60)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:774)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:767)
... 25 more
Root exception:
java.lang.IllegalArgumentException
at 
org.eclipse.osgi.internal.framework.legacy.PackageAdminImpl.getBundles(PackageAdminImpl.java:172)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.refreshPackages(ConfigApplier.java:401)
at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:105)
at 

Re: [equinox-dev] How to find the newest equinox release?

[Thomas Watson]

We just setup a nexus repo for the Equinox project but still need to setup 
the process for populating it with the Equinox releases:

John Ross and I are planning to get a process going soon to get the new 
repo populated.

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

As for the Felix resolver source.  We have needed to keep up with the very 
latest in trunk to fix bugs as needed.  When the bug is critical (for 
example, prevents Eclipse from launching) I fix the bugs first in Equinox 
and (always) immediately contribute back to felix trunk the fix.  Are you 
not able to find the source for Equinox?  The equinox and eclipse SDKs 
contain the source jars which include the felix source included in 
Equinox.

Tom





From:   Christian Schneider 
To: Equinox development mailing list 
Date:   06/21/2016 04:36 AM
Subject:[equinox-dev] How to find the newest equinox release?
Sent by:equinox-dev-boun...@eclipse.org



I currently have problems with Apache Karaf when switching to equinox.

See:
http://apaste.info/btL

It happens with the default equinox that karaf ships which is 3.10.2 
provided by birt in maven central.

I looked into the equinox project pages to find a newer release:
http://download.eclipse.org/equinox/

The latest stable release seems to be mars2 which leads to:
http://download.eclipse.org/equinox/drops/R-Mars.2-201602121500/download.php?dropFile=org.eclipse.osgi_3.10.102.v20160118-1700.jar


Unfortunately this release does not seem to be available in maven central 
at all.
The latest release there seems to be 

org.eclipse.tycho
org.eclipse.osgi
3.10.101.v20150820-1432


So this one seems to be provided by tycho now? Are these releases by birt 
and tycho guaranteed to reflect the real equinox releases or are they 
maybe patching equinox?
Is there any better way? Does equinox have any maven repo where it puts 
its official releases? I think there were discussions about that a while 
ago but the discussion was kind of stuck at some point.

Another question is about the included felix resolver. The last time I 
looked into this the resolver sources were copied into the equinox 
sources. They were not equal to any
release of the felix resolver. Instead as far as I can remember the 
changes were cherry picked from some of the resolver commits. This makes 
it really difficult to tell how equinox behaves.
Is there any improvement in sight? 

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] Avoid usage of RuntimeLog.log

[Thomas Watson]

I am wondering why anything outside of core.runtime and equinox would be 
using this.  Shouldn't you be using one of the following to get an ILog 
object?

org.eclipse.core.runtime.Plugin.getLog()
org.eclipse.core.runtime.Platform.getLog(Bundle)

In Equinox everything eventually ends up going through the OSGi LogService 
API.  But the ILog stuff from Eclipse has additional listener support.  So 
if the UI bundles stop using the ILog API then anything using ILog to 
listen for log entries from the UI may miss them.

Tom





From:   Lars Vogel 
To: Equinox development mailing list 
Date:   05/30/2016 04:58 PM
Subject:[equinox-dev] Avoid usage of RuntimeLog.log
Sent by:equinox-dev-boun...@eclipse.org



Hi,

in Platform UI we use in several places RuntimeLog.log which is internal 
API.

Does Equinox provide an official logging API which we should switch to?

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] Safe logging from a WeavingHook?

[Thomas Watson]

> From: Stephan Herrmann 
> Hi Tom,
> 
> Thanks for your comprehensive answer.
> Yes, we can easily agree that SynchronousLogListener is dangerous :)
> 
> More questions inline ...
> 
> 
> Sounds promising, but ...
> 
> >  But be aware that nobody is going to see your logs until there is
> a org.osgi.service.log.LogService registered to
> > listen to your logs.
> 
> ... is that s.t. I have to register? How?
> Can I hook this up so that all entries do (eventually) appear in the
> Errors view and perhaps the persistent log file?

I did not mean LogService there.  I meant 
org.osgi.service.log.LogListener.  You would have to register a 
LogListener with the LogReaderService using the method:

org.osgi.service.log.LogReaderService.addLogListener(LogListener)

This would be a bit tricky, this listener would get LogEntry events 
asynchronously.  It could then turn around and call the Equinox Logger for 
the with the name "org.eclipse.equinox.logger" to force it into the 
persistent log (which shows up in the log view.

> 
> > The one exception to this rule is when the LogEntry is of type 
> ERROR, in that case the log will be sent to the
> > persistent eclipse log file BUT it WILL NOT be sent to the 
> listeners registered with the org.eclipse.core.runtime.ILog.
> >
> > I'm unsure what you are trying to log, but if it is simply ERRORs 
> then I would use the standard org.osgi.service.log.LogService
> 
> I'm using it for all kinds of things. The particular dangerous case 
> was logging
> profiling data at level INFO.
> 
> 

Then I suggest you use your own logger name and use it to call 
org.eclipse.equinox.log.ExtendedLogService.getLogger(String) and use the 
Logger to log all your messages.  Then register a LogListener with the 
method 
org.eclipse.equinox.log.ExtendedLogReaderService.addLogListener(LogListener, 
LogFilter) with a filter that returns true only when the loggerName equals 
your logger name.  This LogListener would then turn around and call the 
Logger with the name "org.eclipse.equinox.logger" to post the messages to 
the persistent log.  Note this will also send the log to the pesky 
synchronous ILog listeners, but now we are on a separate thread.

Tom


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

Re: [equinox-dev] Safe logging from a WeavingHook?

[Thomas Watson]

I forgot to mention how the framework logs.  Typically we do not actually 
log.  Instead we publish framework events which get picked up by the 
LogService implementation.  Since you are a framework extension you could 
consider doing the same thing using Equinox container APIs.  The container 
allows for events of type error, warning or info.  But not that again only 
the error types will get written to the persistent eclipse log.   One way 
to do this would be with the following code.  Note that I do this only for 
illustration in a bundle activator.  There are lots of ways to get the 
container in your framework extension:

import org.eclipse.osgi.container.Module;
import org.eclipse.osgi.container.ModuleContainer;
import org.eclipse.osgi.container.ModuleContainerAdaptor;
import org.eclipse.osgi.container.ModuleContainerAdaptor.ContainerEvent;
import org.osgi.framework.Bundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

private static BundleContext context;

static BundleContext getContext() {
return context;
}

public void start(BundleContext bundleContext) throws Exception {
Activator.context = bundleContext;
Bundle b = bundleContext.getBundle();
Module m = b.adapt(Module.class);
ModuleContainer container = m.getContainer();
ModuleContainerAdaptor adaptor = container.getAdaptor();
Throwable t = new Throwable("The error message.");
adaptor.publishContainerEvent(ContainerEvent.ERROR, m, t);
}


public void stop(BundleContext bundleContext) throws Exception {
Activator.context = null;
}

}

Tom





From:   Thomas Watson/Austin/IBM@IBMUS
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   05/16/2016 09:15 AM
Subject:Re: [equinox-dev] Safe logging from a WeavingHook?
Sent by:equinox-dev-boun...@eclipse.org



Hi

The Eclipse Log API (org.eclipse.core.runtime.ILog) has the unfortunate 
contract that log listeners registered with it will be called 
synchronously.  This can cause the issues you are seeing with class 
loading if we get into a circularity.  In Equinox we actually have one and 
only one log implementation and this is the OSGi LogService 
implementation.  In Equinox we have an extension of the specification in 
the org.eclipse.equinox.log package.  Here is where we have the interface 
org.eclipse.equinox.log.SynchronousLogListener which allows us to 
implement the contract of org.eclipse.core.runtime.ILog on top of.  All 
other log APIs in Eclipse and Equinox are all implemented on top of this 
single OSGi Log Service implementation.

In the extended API Equinox provides to the OSGi Service API we also have 
the concept of named loggers.  Now the 
org.eclipse.core.runtime.ILogListener that are registered will only listen 
to a very specific logger named "org.eclipse.equinox.logger".  This logger 
happens to also be the logger which also writes to the persistent log for 
eclipse.  You could consider using the equinox extended log service 
instead by calling 
org.eclipse.equinox.log.ExtendedLogService.getLogger(String) and supplying 
your own logger name.  Anything logged here will be sent to LogListeners 
asynchronously, unless you happen to have someone implementing the 
SynchronousLogListener and paying attention to your logger name.  But be 
aware that nobody is going to see your logs until there is a 
org.osgi.service.log.LogService registered to listen to your logs.  The 
one exception to this rule is when the LogEntry is of type ERROR, in that 
case the log will be sent to the persistent eclipse log file BUT it WILL 
NOT be sent to the listeners registered with the 
org.eclipse.core.runtime.ILog.

I'm unsure what you are trying to log, but if it is simply ERRORs then I 
would use the standard org.osgi.service.log.LogService

I should also mention that most all the concepts of the Equinox extended 
logger API in org.eclipse.equinox.log will be included in the future OSGi 
R7 specification.  The one exception is the SynchronousLogListener, which 
I believe to be a dangerous thing to spec, and I think you may agree! :-)

Tom





From:Stephan Herrmann <stephan.herrm...@berlin.de>
To:equinox-dev@eclipse.org
Date:05/15/2016 07:07 AM
Subject:[equinox-dev] Safe logging from a WeavingHook?
Sent by:equinox-dev-boun...@eclipse.org



Hi,

When implementing a WeavingHook, is there a safe way to perform logging?

I'm asking because my current strategy recently broke when adding
the AERI error reporter to the mix:

I'm acquiring a log basically from
   Platform.getLog(bundleContext.getBundle())
(with extra caution to see if the platform is ready).

This works well until others register log liste

Re: [equinox-dev] Safe logging from a WeavingHook?

[Thomas Watson]

Hi

The Eclipse Log API (org.eclipse.core.runtime.ILog) has the unfortunate 
contract that log listeners registered with it will be called 
synchronously.  This can cause the issues you are seeing with class 
loading if we get into a circularity.  In Equinox we actually have one and 
only one log implementation and this is the OSGi LogService 
implementation.  In Equinox we have an extension of the specification in 
the org.eclipse.equinox.log package.  Here is where we have the interface 
org.eclipse.equinox.log.SynchronousLogListener which allows us to 
implement the contract of org.eclipse.core.runtime.ILog on top of.  All 
other log APIs in Eclipse and Equinox are all implemented on top of this 
single OSGi Log Service implementation.

In the extended API Equinox provides to the OSGi Service API we also have 
the concept of named loggers.  Now the 
org.eclipse.core.runtime.ILogListener that are registered will only listen 
to a very specific logger named "org.eclipse.equinox.logger".  This logger 
happens to also be the logger which also writes to the persistent log for 
eclipse.  You could consider using the equinox extended log service 
instead by calling 
org.eclipse.equinox.log.ExtendedLogService.getLogger(String) and supplying 
your own logger name.  Anything logged here will be sent to LogListeners 
asynchronously, unless you happen to have someone implementing the 
SynchronousLogListener and paying attention to your logger name.  But be 
aware that nobody is going to see your logs until there is a 
org.osgi.service.log.LogService registered to listen to your logs.  The 
one exception to this rule is when the LogEntry is of type ERROR, in that 
case the log will be sent to the persistent eclipse log file BUT it WILL 
NOT be sent to the listeners registered with the 
org.eclipse.core.runtime.ILog.

I'm unsure what you are trying to log, but if it is simply ERRORs then I 
would use the standard org.osgi.service.log.LogService

I should also mention that most all the concepts of the Equinox extended 
logger API in org.eclipse.equinox.log will be included in the future OSGi 
R7 specification.  The one exception is the SynchronousLogListener, which 
I believe to be a dangerous thing to spec, and I think you may agree! :-)

Tom





From:   Stephan Herrmann 
To: equinox-dev@eclipse.org
Date:   05/15/2016 07:07 AM
Subject:[equinox-dev] Safe logging from a WeavingHook?
Sent by:equinox-dev-boun...@eclipse.org



Hi,

When implementing a WeavingHook, is there a safe way to perform logging?

I'm asking because my current strategy recently broke when adding
the AERI error reporter to the mix:

I'm acquiring a log basically from
Platform.getLog(bundleContext.getBundle())
(with extra caution to see if the platform is ready).

This works well until others register log listeners of their own.
Such breakage is tracked in https://bugs.eclipse.org/493566
showing a stack trace of what looks like deadly re-entrance,
causing NoClassDefFoundError.

I know that the Equinox framework uses a logger of its own,
which - I assume - does not support any log listeners, right?
Is it possible for a weaving hook implementation to log into
the framework log?

If no safe log is available, are there any points in the hook
protocol, where it is safe to log using a platform log?
I'm thinking of queueing log events until modified(WovenClass),
but even during that method I don't know if any class loading
is active further down the stack that may cause the same problem.
Do I have to maintain my own thread-local stack of classes
being defined to wait for a point when this stack is empty?
Or is it possible to get this information from the framework?

Interesting, how such a basic functionality like logging can blow
up a system, if both class loading and logging are extensible ...

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





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

Re: [equinox-dev] Query in upgrading Equinox

[Thomas Watson]

You probably should open a bug and give the details on how to reproduce. A 
stacktrace may also help and the error log if it exists,  At this point I 
don't understand what is going wrong and I am not sure what to suggest.

With the Luna release (framework org.eclipse.osgi version 3.10) there was 
a major refactoring of the framework implementation.  It is certainly 
possible these changes introduced the situation that is causing your 
failure.

Tom





From:   jayant sable 
To: equinox-dev@eclipse.org
Date:   05/12/2016 01:28 AM
Subject:[equinox-dev] Query in upgrading Equinox
Sent by:equinox-dev-boun...@eclipse.org



Hi,

I'm using org.eclipse.osgi 3.8.1 jar in my project for bundle loading 
purpose.Now I'm trying to upgrade the equinox version to 3.10.1 but facing 
some issues. When I debug the code I found that some code in osgi class 
"ListenerQueue.class" is throwing ClassNotFound Exception for one the 
 bundle that I'm loading. I'll explain to the flow.

It starts from setStartLevel() in EclipseStarter class then it calls 
fwkStartLevel.setStartLevel()
from ModuleContainer class. After that flow goes to 
dispatchEventAsynchronous() in ListenerQueue class where It throws the 
exception in eventThread.PostEvent() method.

I really have now clue why its throwing Class not found exception.

Argument Which is going to eventThread.PostEvent() are 

osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; 
version:Version="3.10.102.v20160118-1700"; singleton:="true" 
[id=0]=[Lorg.osgi.framework.FrameworkListener;@6b23cd35]=org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel@7b758986

with eventAction = 1 and eventObject = 6.

Can you help me with this as I'm stuck here and unable to find workaround.
Also how much different are the jars org.eclipse.osgi 3.8.1 and 
org.eclipse.osgi 3.10.1 from each other. Because I found on web that 
Various changes are made in latest equinox as compared to 3.8.1. And I 
suspect this is the reason why I'm unable to run my project.

Thanks,
Jay___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev



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

Re: [equinox-dev] Merge of equinox committer groups

[Thomas Watson]

I am moving forward with merging the equinox committer groups.

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

Tom


- Forwarded by Thomas Watson/Austin/IBM on 04/06/2016 07:57 AM -

From:   Thomas Watson/Austin/IBM
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   03/25/2016 08:06 AM
Subject:Re: [equinox-dev] Merge of equinox committer groups


OK, to be clear Pascal and Ian.  You are fine moving forward with a single 
committer group for all of Equinox including p2?

Personally I don't see any issues here with merging.  We should be using 
gerrit reviews, especially if a committer is touching code they are not 
familiar with.

Tom





From:   Pascal Rapicault <pas...@rapicault.net>
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   03/24/2016 10:10 PM
Subject:Re: [equinox-dev] Merge of equinox committer groups
Sent by:equinox-dev-boun...@eclipse.org



Well, why not.

On 16-03-22 09:50 PM, Ian Bull wrote:
+1 

Cheers,
Ian

On Tue, Mar 1, 2016 at 8:46 AM, Raymond Auge <raymond.a...@liferay.com> 
wrote:
+1

- Ray

On Tue, Mar 1, 2016 at 10:31 AM, Thomas Watson <tjwat...@us.ibm.com> 
wrote:
I have no objections to merging in p2.  But I would like Pascal and other 
p2 committers to agree first.

Tom





From:Stefan Xenos <sxe...@google.com>
To:Equinox development mailing list <equinox-dev@eclipse.org>
Date:03/01/2016 08:25 AM
Subject:Re: [equinox-dev] Merge of equinox committer groups
Sent by:equinox-dev-boun...@eclipse.org




I strongly agree. In fact, I'd go farther and merge in p2 as well. 
Fragmenting the permissions encourages developers to work around problems 
in the code they have commit rights to rather in the place where the fix 
really belongs, and makes it unnecessarily hard to do large changes such 
as rolling with deprecations.
+1

On Tue, Mar 1, 2016, 5:51 AM Martin Lippert <mlipp...@gmail.com> wrote:
+1

Cheers,
-Martin


> Am 01.03.2016 um 14:49 schrieb Thomas Watson <tjwat...@us.ibm.com>:
>
> Right now the equinox project has the following sub-projects, each with 
their own committer groups
>
> rt.equinox - parent project, no real code here, but it does contain the 
website
> rt.equinox.framework - where the OSGi framework and Equinox native 
launcher lives
> rt.equinox.bundles - where everything else is, besides p2
> rt.equinox.p2 - where p2 is
>
> I plan to request the foundation fold rt.equinox.framework and 
rt.equinox.bundles into the parent project rt.equinox.  I do not think 
there is a need to separate committers of the various equinox bundles from 
committers of the framework/launcher or the website.  I do not plan to 
request p2 be folded into rt.equinox unless the existing p2 community of 
committers request that to happen.  p2 is a fairly large codebase so it 
makes sense to keep it separate if the committers want that.  But the rest 
of Equinox is not that large and maintaining 3 separate committer groups 
is not worth it in my opinion.
>
> Committers, please voice your concerns if you have them.
>
> Tom
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

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


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



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

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



-- 
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource


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

Re: [equinox-dev] [pde-dev] Repackaging org.osgi.service.component.annotations from Equinox

[Thomas Watson]

Equinox will not export the annotation package (via Export-Package) 
because it will lead to a bad practice of using Import-Package for these 
non-runtime packages. Whatever the solution ends up being to get the 
annotations on the classpath of the project, PDE must do so without 
requiring the bundle manifest to declare a runtime dependency on the 
annotation package (Import-Package or Require-Bundle).

Tom





From:   "Daniel Megert" 
To: "Eclipse PDE general developers list." , 
equinox-dev@eclipse.org
Date:   04/04/2016 04:24 AM
Subject:Re: [equinox-dev] [pde-dev] Repackaging 
org.osgi.service.component.annotations  from Equinox
Sent by:equinox-dev-boun...@eclipse.org



I don't like that approach which leaves us with maintaining and shipping 
the same thing twice. Let's continue the discussion in the bug report.

Dani



From:Gunnar Wagenknecht 
To:"Eclipse PDE general developers list." 
Cc:equinox-dev@eclipse.org
Date:04.04.2016 02:24
Subject:Re: [pde-dev] Repackaging 
org.osgi.service.component.annotationsfrom Equinox
Sent by:pde-dev-boun...@eclipse.org



Hi Peter,

I think it's possible for PDE to ship their own jar of the code. You can 
simply copy the sources from Equinox. I think you still need a CQ, though. 
It can be a re-use CQ for a subset of the original CQ. Might be easier to 
jut go with a full re-use.

I've cc'ed equinox-dev because I think this topic may be interesting for 
them, too.

-Gunnar

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






On 03 Apr 2016, at 14:04, Peter Nehrer  
wrote:

Hi,

in order to improve user experience with DS Annotations, I need to 
contribute package org.osgi.service.component.annotations to PDE projects' 
classpath (https://bugs.eclipse.org/bugs/show_bug.cgi?id=488800). This 
package is already part of Equinox's org.eclipse.osgi.services bundle; 
however, in order to make these annotations available to external 
builders, they would need to be in a separate jar (otherwise users would 
have to place the entire bundle on the build path).

Would it be OK to extract that package from Equinox and provide it via PDE 
as a separate JAR? Since this isn't new code contribution, do I need any 
special permissions/process? Thanks!

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


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

Re: [equinox-dev] Merge of equinox committer groups

[Thomas Watson]

OK, to be clear Pascal and Ian.  You are fine moving forward with a single 
committer group for all of Equinox including p2?

Personally I don't see any issues here with merging.  We should be using 
gerrit reviews, especially if a committer is touching code they are not 
familiar with.

Tom





From:   Pascal Rapicault <pas...@rapicault.net>
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   03/24/2016 10:10 PM
Subject:Re: [equinox-dev] Merge of equinox committer groups
Sent by:equinox-dev-boun...@eclipse.org



Well, why not.

On 16-03-22 09:50 PM, Ian Bull wrote:
+1 

Cheers,
Ian

On Tue, Mar 1, 2016 at 8:46 AM, Raymond Auge <raymond.a...@liferay.com> 
wrote:
+1

- Ray

On Tue, Mar 1, 2016 at 10:31 AM, Thomas Watson <tjwat...@us.ibm.com> 
wrote:
I have no objections to merging in p2.  But I would like Pascal and other 
p2 committers to agree first.

Tom





From:Stefan Xenos <sxe...@google.com>
To:Equinox development mailing list <equinox-dev@eclipse.org>
Date:03/01/2016 08:25 AM
Subject:Re: [equinox-dev] Merge of equinox committer groups
Sent by:equinox-dev-boun...@eclipse.org




I strongly agree. In fact, I'd go farther and merge in p2 as well. 
Fragmenting the permissions encourages developers to work around problems 
in the code they have commit rights to rather in the place where the fix 
really belongs, and makes it unnecessarily hard to do large changes such 
as rolling with deprecations.
+1

On Tue, Mar 1, 2016, 5:51 AM Martin Lippert <mlipp...@gmail.com> wrote:
+1

Cheers,
-Martin


> Am 01.03.2016 um 14:49 schrieb Thomas Watson <tjwat...@us.ibm.com>:
>
> Right now the equinox project has the following sub-projects, each with 
their own committer groups
>
> rt.equinox - parent project, no real code here, but it does contain the 
website
> rt.equinox.framework - where the OSGi framework and Equinox native 
launcher lives
> rt.equinox.bundles - where everything else is, besides p2
> rt.equinox.p2 - where p2 is
>
> I plan to request the foundation fold rt.equinox.framework and 
rt.equinox.bundles into the parent project rt.equinox.  I do not think 
there is a need to separate committers of the various equinox bundles from 
committers of the framework/launcher or the website.  I do not plan to 
request p2 be folded into rt.equinox unless the existing p2 community of 
committers request that to happen.  p2 is a fairly large codebase so it 
makes sense to keep it separate if the committers want that.  But the rest 
of Equinox is not that large and maintaining 3 separate committer groups 
is not worth it in my opinion.
>
> Committers, please voice your concerns if you have them.
>
> Tom
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

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


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



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

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



-- 
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource


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


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

Re: [equinox-dev] Where is runtime_registry_compatibility.jar?

[Thomas Watson]

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

This was a classpath entry that optionally could be provided by a 
compatibility fragment.  The compatibility fragment has since been 
deprecated and removed from the Eclipse project.  In Neon the jar has been 
removed from the equinox.registry classpath.

Tom





From:   Niranjan Karunanandham 
To: equinox-dev@eclipse.org
Date:   03/23/2016 06:12 AM
Subject:[equinox-dev] Where is runtime_registry_compatibility.jar?
Sent by:equinox-dev-boun...@eclipse.org



Hi all,

In MANIFEST.MF of org.eclipse.equinox.registry_3.6.0.v20150318-1503.jar, "
runtime_registry_compatibility.jar" is defined as Bundle-ClassPath. But I 
was not able to find this jar 
in org.eclipse.equinox.registry_3.6.0.v20150318-1503.jar or in the Mars2 
SDK. Where is this file located?

Regards,
Niranjan Karunanandham___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Directive for ExtensionClasspath

[Thomas Watson]

Tom Schindl is probably the best person to ask since he did the work to 
get javafx working.  I remember we went through a number of options before 
he landed on an acceptable solution.  I'm pretty sure the solution 
involved some equinox specific hook to grant access to the stuff on the 
extension class loader.

If I was implementing this today I probably would start with a 2 part 
solution.

1) Provide a 'shell' of a bundle that only contains a bundle manifest that 
exports the nashorn API a packages.  This bundle does not actually contain 
nashorn implementation, it is just used to virtualize the exported 
packages so that other bundles can use Import-Package to access them. This 
bundle would also use a Require-Capability requirement that would require 
the functionality provided in part 2

2) Provide an equinox specific system.bundle fragment (using Fragment-Host 
against the Equinox BSN org.eclipse.osgi) and this extension would provide 
an implementation of the hook method 
org.eclipse.osgi.internal.hookregistry.ClassLoaderHook.createClassLoader(ClassLoader,
 
EquinoxConfiguration, BundleLoader, Generation), but it would only return 
a non-null class loader for the 'shell' bundle from part 1.  I would 
probably also mark the 'shell' bundles from part 1 with a capability so 
you can easily identify them without hard coding the BSN of the 'shell' 
bundle here.  The class loader you return would use the extension class 
loader where nashorn is located as its parent classloader so it can load 
classes from it.  This fragment would also use Provide-Capability using 
some namespace you invent such that it can be required by the bundle in 
part 1.

This way when other bundles import-package for nashorn packages they will 
get wired to the 'shell' bundle but the ultimate class load would get 
delegated to the class loader you return from part 2.

Tom





From:   "Gorkem Ercan" 
To: equinox-dev@eclipse.org
Date:   03/10/2016 09:50 AM
Subject:[equinox-dev] Directive for ExtensionClasspath
Sent by:equinox-dev-boun...@eclipse.org



Hi,
While looking for a solution for using Nashorn which lives on the 
extension classpath from Eclipse IDE, I was pointed to an old thread[1].
The thread discusses about Equinox-specific manifest directives that 
would allow a Fragment to use extension classpath. However, I have
been researching and also looked through the equinox code and could not 
find any reference that this discussion has materialized.
Can someone confirm my conclusion? I also welcome any ideas on how to 
solve the extension classpath problem if that is the case.

[1] https://dev.eclipse.org/mhonarc/lists/equinox-dev/msg07323.html

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




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

Re: [equinox-dev] Equinox Server Target and Product

[Thomas Watson]

org.eclipse.equinox.http has been removed and replaced by the jetty backed 
implementation org.eclipse.equinox.http.jetty

Since the Juno release we no longer maintain our own web container 
implementation for the OSGi Http Service implementation.

Tom





From:   
To: 
Date:   03/09/2016 04:36 PM
Subject:[equinox-dev] Equinox Server Target and Product
Sent by:equinox-dev-boun...@eclipse.org



All;

First off, if this is the wrong mailing list for this, then I apologize.

I'm trying to build an HTTP application on top of Equinox (as a server 
platform).

To that end, I'm trying to create a minimal starting point target 
definition, and a minimal starting point product definition.

I'm working partly from 
http://www.amazon.com/OSGi-Equinox-Creating-Modular-Systems/dp/0321585712/ref=sr_1_1?s=books=UTF8=1457562254=1-1=equinox+osgi
 
and 
http://www.amazon.com/Eclipse-RCP-complete-application-development/dp/3943747077/ref=sr_1_2?s=books=UTF8=1457562289=1-2=Eclipse+RCP
 
(to a lesser extent).

Here are the problems I've run into:

I can't locate a functional Equinox SDK p2 to give to my target 
definition.
The zip file available from 
http://download.eclipse.org/equinox/drops/R-Mars.2-201602121500/index.php 
isn't seen as a p2 repository by Eclipse Mars.
I've worked around this by pointing my target at the full Eclipse p2 repo 
http://download.eclipse.org/releases/mars/, but navigating that is a pain.

I can't seem to find org.eclipse.equinox.http, has it been replaced, 
moved, etc.?

It seem like this should be easier, but I can't find it...

Dominic Hilsbos
Director - Information Technology 
Perform Air International Inc.


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




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

Re: [equinox-dev] Merge of equinox committer groups

[Thomas Watson]

I have no objections to merging in p2.  But I would like Pascal and other 
p2 committers to agree first.

Tom





From:   Stefan Xenos <sxe...@google.com>
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date:   03/01/2016 08:25 AM
Subject:Re: [equinox-dev] Merge of equinox committer groups
Sent by:equinox-dev-boun...@eclipse.org



I strongly agree. In fact, I'd go farther and merge in p2 as well. 
Fragmenting the permissions encourages developers to work around problems 
in the code they have commit rights to rather in the place where the fix 
really belongs, and makes it unnecessarily hard to do large changes such 
as rolling with deprecations.
+1

On Tue, Mar 1, 2016, 5:51 AM Martin Lippert <mlipp...@gmail.com> wrote:
+1

Cheers,
-Martin


> Am 01.03.2016 um 14:49 schrieb Thomas Watson <tjwat...@us.ibm.com>:
>
> Right now the equinox project has the following sub-projects, each with 
their own committer groups
>
> rt.equinox - parent project, no real code here, but it does contain the 
website
> rt.equinox.framework - where the OSGi framework and Equinox native 
launcher lives
> rt.equinox.bundles - where everything else is, besides p2
> rt.equinox.p2 - where p2 is
>
> I plan to request the foundation fold rt.equinox.framework and 
rt.equinox.bundles into the parent project rt.equinox.  I do not think 
there is a need to separate committers of the various equinox bundles from 
committers of the framework/launcher or the website.  I do not plan to 
request p2 be folded into rt.equinox unless the existing p2 community of 
committers request that to happen.  p2 is a fairly large codebase so it 
makes sense to keep it separate if the committers want that.  But the rest 
of Equinox is not that large and maintaining 3 separate committer groups 
is not worth it in my opinion.
>
> Committers, please voice your concerns if you have them.
>
> Tom
>
>
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

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


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

[equinox-dev] Merge of equinox committer groups

[Thomas Watson]

Right now the equinox project has the following sub-projects, each with 
their own committer groups

rt.equinox - parent project, no real code here, but it does contain the 
website
rt.equinox.framework - where the OSGi framework and Equinox native 
launcher lives
rt.equinox.bundles - where everything else is, besides p2
rt.equinox.p2 - where p2 is

I plan to request the foundation fold rt.equinox.framework and 
rt.equinox.bundles into the parent project rt.equinox.  I do not think 
there is a need to separate committers of the various equinox bundles from 
committers of the framework/launcher or the website.  I do not plan to 
request p2 be folded into rt.equinox unless the existing p2 community of 
committers request that to happen.  p2 is a fairly large codebase so it 
makes sense to keep it separate if the committers want that.  But the rest 
of Equinox is not that large and maintaining 3 separate committer groups 
is not worth it in my opinion.

Committers, please voice your concerns if you have them.

Tom



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

Re: [equinox-dev] Ensure that a plug-in is valid for Mars but not for Neon

[Thomas Watson]

Mickael is correct.  There is no capability defined which indicates the 
eclipse release name.  The version dependencies are what should be used.

Tom





From:   Mickael Istria 
To: equinox-dev@eclipse.org
Date:   02/24/2016 03:26 AM
Subject:Re: [equinox-dev] Ensure that a plug-in is valid for Mars 
but not for Neon
Sent by:equinox-dev-boun...@eclipse.org



On 02/24/2016 10:22 AM, Lars Vogel wrote:
What is the recommended way to define that a plug-in is valid only for 
Eclipse Mars but not for Eclipse Neon? I currently use a versionized 
manifest dependency to core.runtime with a max value but I'm not sure if 
that is the best approach.
A plugin doesn't really care if it's Neon or Mars, what matters is more 
the version of its dependencies. Instead of checking the version of 
core.runtime, it seems better to identify the bundle or package that makes 
the compatibility and to put the restriction on this one directly.

-- 
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Equinox quick start website update?

[Thomas Watson]

The website is in a git repo.  See 
http://git.eclipse.org/c/www.eclipse.org/equinox.git/

It needs a major scrub.  It would be great if you (or anyone else) would 
want to contribute to fixing up the website.

Thanks.

Tom





From:   "Carlos S." 
To: equinox-dev@eclipse.org
Date:   02/12/2016 12:36 AM
Subject:[equinox-dev] Equinox quick start website update?
Sent by:equinox-dev-boun...@eclipse.org



Hi, 
I been trying to create a deployable install folder template for a small 
bundle, but have not been able to, it seems to me that none of the 
information at the main quickstart pages is up to date

   http://www.eclipse.org/equinox/documents/quickstart.php

The instructions for basic setup no longer work in current releases  (only 
the steps from within eclipse seem to work)
Basic OSGi with Equinox
Embed a server in Equinox 
Embed Equinox in an existing servlet container 

What is the right way to make those guides more current? Could I help?
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Require system.bundle question

[Thomas Watson]

Classes found in the required bundles always take precedence over classes 
contained in the local bundle.  This is also true if you require the 
system.bundle.

Tom





From:   Lars Vogel 
To: Equinox development mailing list 
Date:   02/10/2016 12:02 PM
Subject:[equinox-dev] Require system.bundle question
Sent by:equinox-dev-boun...@eclipse.org



Hi,

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=463292 we are trying
to solve the issue that javax.annotations from the Java installation
should be used if a Java 7 runtime is available. If a Java 6 runtime
is used, then the javax.annotations implementation provided by the
plug-in should be used.

For this we added: "Require-Bundle: system.bundle" to the MANIFEST.MF.

This seems to work. If Java 7 is used as runtime, the
javax.annotations from the Java installation is exported by the
plug-in. And if Java 6 is used the implementation classes from the
plug-in are used.

So my question is: is it assured that the system.bundle classes always
get priority (if available) over the plug-ins implementation?

Or was the observed behavior pure luck and the order of which
implementation is exported is not defined by OSGi / Equinox?

Thanks for the answer. I'm not sure if I was able to describe the
question well enough.

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
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] it is possible to load config.ini from a different location other than -configuration ?

[Thomas Watson]

I think this is probably a bug.  Can you open one?  I suspect most folks 
that use shared configurations are using the equinox launcher which should 
read the parent config.ini before even invoking the framework.  But here 
you are not using the equinox launcher, right?

Tom





From:   Cristiano Gavião 
To: equinox-dev@eclipse.org
Date:   02/03/2016 02:57 PM
Subject:Re: [equinox-dev] it is possible to load config.ini from a 
different location other than -configuration ?
Sent by:equinox-dev-boun...@eclipse.org



Hi again Thomas,

I did a debug again. The only place in the source that I was able to find 
a code that loads a config.ini file was in the method: 
org.eclipse.osgi.internal.framework.EquinoxContainer.loadConfig(EquinoxConfiguration,
 
EquinoxLocations)

private static void loadConfig(EquinoxConfiguration equinoxConfig, 
EquinoxLocations equinoxLocations) {
if 
(Boolean.TRUE.toString().equals(equinoxConfig.getConfiguration(EquinoxConfiguration.PROP_IGNORE_USER_CONFIGURATION)))
return;
Location configArea = equinoxLocations.getConfigurationLocation();
if (configArea == null)
return;

URL location = null;
try {
location = new URL(configArea.getURL().toExternalForm() + 
CONFIG_FILE);
} catch (MalformedURLException e) {
// its ok.  This should never happen
}
equinoxConfig.mergeConfiguration(loadProperties(location, 
equinoxConfig));
}

besides the parent location (from osgi.sharedConfiguration.area ) were 
calculated, nothing was loaded from there.

regards,

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


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

Re: [equinox-dev] osgi application service

[Thomas Watson]

Is there much interest in the osgi application service?  It seemed 
interesting at the time it was spec'ed and it fit OK into the Eclipse 
application story (but not perfectly).  Since then the specification has 
had no updates and I am not really aware of it being used much outside of 
the Eclipse platform.  That being said, we can certainly take 
contributions to the implementation.

I would not separate out the org.osgi.service.application package from the 
implementation.  Instead I would make it a substitutable export (import 
and export the package) so that if there is another exporter of the 
package then it can get wired to that.

We can easily get rid of the PackageAdmin usage and instead use the R5 
FrameworkWiring API.

We may be able to separate out the usage of the registry into a separate 
bundle, but it has been a long time since I have touched this code so I 
don't recall how entangled all that registry code is into the 
implementation.

Tom





From:   Scott Lewis 
To: Equinox development mailing list 
Date:   02/03/2016 01:31 PM
Subject:[equinox-dev] osgi application service
Sent by:equinox-dev-boun...@eclipse.org



Equinox implements the osgi application service 
(org.osgi.service.application) via this bundle:

org.eclipse.equinox.app

This bundle has compile-time dependencies on both the equinox service 
registry (org.eclipse.equinox.registry), and PackageAdmin which for some 
environments are a disadvantage.  The org.osgi.service.application 
package is also present in the same bundle as the implementation, which 
is a debatable choice.

Would there be any appetite to refactor the org.eclipse.equinox.app 
bundle (perhaps into multiple dependent bundles) so as to:

1) Separate the impl of org.osgi.service.application from the parts that 
are dependent upon the equinox service registry (so as to allow use of 
the application service without the service registry)
2) Remove deps to PackageAdmin service
3) Possibly separating the org.osgi.service.application classes from the 
equinox impl.

?

Scott


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




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

Re: [equinox-dev] it is possible to load config.ini from a different location other than -configuration ?

[Thomas Watson]

You should be able to set the osgi.sharedConfiguration.area property.

java -Dosgi.sharedConfiguration.area=/etc/myapp -jar org.eclipse.osgi.jar 
-configuration /var/lib/myapp/

If I recall correctly that should treat the shared configuration directory 
as read-only and load the config.ini from there for the shared config 
settings, but then the framework should use the /var/lib/myapp/ folder for 
its persist storage area, as well as merge in a config.ini from there if 
it exists.  If you were using the standard Framework launching API you 
would pass the osgi.sharedConfiguration.area setting in the framework 
configuration map.

Tom





From:   Cristiano Gavião 
To: equinox-dev@eclipse.org
Date:   02/03/2016 01:24 PM
Subject:Re: [equinox-dev] it is possible to load config.ini from a 
different location other than -configuration ?
Sent by:equinox-dev-boun...@eclipse.org



Hi,

Yep, I've tried to debug the source code using it now... But didn't help

In order to load the config.ini, equinox uses the PROP_CONFIG_AREA 
variable to compose config.ini location. 

If I use the FRAMEWORK_STORAGE pointing to a different location other than 
the -configuration args, equinox will set the PROP_CONFIG_AREA to its 
value.

// Initializes the Location objects for the LocationManager.
// set the osgi storage area if it exists
String osgiStorage = 
equinoxConfig.getConfiguration(Constants.FRAMEWORK_STORAGE);
if (osgiStorage != null)
equinoxConfig.setConfiguration(PROP_CONFIG_AREA, osgiStorage);
--
try {
location = new URL(configArea.getURL().toExternalForm() + 
CONFIG_FILE);
} catch (MalformedURLException e) {
// its ok.  This should never happen
}


And what will happen is that the config.ini will not be found :(


so seems not to be possible to do what I want in current version... unless 
there is something that I'm missing...

thanks

On 03/02/2016 15:38, Raymond Auge wrote:
Have you tried to osgi framework properties?
e.g.
https://osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_STORAGE


I think the eclipse launcher supports those as system properties.

Sincerely,
- Ray

On Wed, Feb 3, 2016 at 1:13 PM, Cristiano Gavião  
wrote:
Hello,

I'm trying to set Equinox to run as a linux systemd service.

I set the service to launch using java -jar org.eclipse.osgi 
-configuration /etc/myapp.

The idea was to install config.ini (set as conffile) at /etc/myapp and let 
the configuration data to be created at /var/lib/myapp directory.

I tried many configurations combination but it always try to create 
storage directories relative to where config.ini file is, which gives some 
errors due the fact that user which is starting it do not had permissions 
to create directories inside /etc dir.

one alternative that comes to mind was to create a symlimk in 
etc/myapp/config.ini  pointinf to var/lib/myapp/config.ini.

anyway, I would be grateful for any opinion.

thanks,

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



-- 
Raymond Augé (@rotty3000) 
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)


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


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

Re: [equinox-dev] How to get Equinox KeplerSR1 Source

[Thomas Watson]

The branch used for Kepler is R3_9_maintenance (
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/log/?h=R3_9_maintenance
).  The tag used for Kepler SR1 release is R4_3_1

If you already cloned the git repo then you can switch branches with:

git fetch --prune origin
git checkout --track -b R3_9_maintenance origin/R3_9_maintenance

Then you can checkout the tag R4_3_1 if you want to get the specific code 
for Kepler SR1:

git checkout R4_3_1

I'm sure you can do all this with eGit but I still use commandline git 
myself.

Tom





From:   Thusitha Thilina Dayaratne 
To: Equinox development mailing list 
Date:   12/03/2015 08:06 AM
Subject:[equinox-dev] How to get Equinox KeplerSR1 Source
Sent by:equinox-dev-boun...@eclipse.org



Hi 
Where can I find the source for Equinoz KeplerSR1? I check the 
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/
But it seems only contains the master branch. 

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


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

Re: [equinox-dev] Concierge and the IDE?

[Thomas Watson]

No the intention is not to replace the existing Equinox framework 
implementation for the IDE.

Tom





From:   Lars Vogel 
To: Equinox development mailing list 
Date:   11/20/2015 10:23 AM
Subject:[equinox-dev] Concierge and the IDE?
Sent by:equinox-dev-boun...@eclipse.org



Hi,
I read in a German newsticker that Concierge is a new OSGi 5.0 
implementation which is super fast and small.
https://projects.eclipse.org/projects/iot.concierge/downloads
I didn't know about this effort. Is the intention to use this runtime for 
the Eclipse IDE in the future?
Best regards, Lars___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Installing into Region

[Thomas Watson]

This sounds pretty strange.  You say RegionManager is not able to see the 
initial bundles?  What version of regions and equinox are you using?  I 
assume the latest from Mars?  I ask because the Mars version of regions is 
a system.bundle fragment and ends up using the system.bundle BundleContext 
to do its work.  So it should be guaranteed that the RegionManager can 
'see' the original Eclipse bundles because the system.bundle context can 
see all bundles no matter what the framework hooks are doing for regions.

I am wondering if the issue is that the bundles are gone from the start of 
the framework initialization or if the simple configurator from the IDE is 
somehow uninstalling them.  But that would be strange because it would 
also mean simple configurator is uninstalling itself also.  If you have a 
reproducible scenario I would have you open a bug report to track this 
down.

Tom





From:   Florian Pirchner 
To: Equinox development mailing list 
Date:   11/16/2015 12:35 PM
Subject:Re: [equinox-dev] Installing into Region
Sent by:equinox-dev-boun...@eclipse.org



Hey Pascal,
I am starting the IDE. At this time all bundles (ids=0..120) from eclipse 
plugins-folder are contained in the rootRegion. 
The IDE starts properly.
Everything fine...
Then my vaaclipse-region bundle (autostart 4) starts and does following:
It creates the Vaaclipse region and installs all bundles (ids=121...200) 
from a defined folder into this region.
Everything fine...
Then I shut down the IDE. The digraph file is created properly.
Then I start the IDE again.
The digraph file is read. But for bundles with bundleId 1..120, no bundles 
could be found by the RegionManager (context.getBundle(id) == null). 
Somehow they seem not to become loaded/installed...
But the bundles with bundleId 121...200 are installed properly and 
available in the vaaclipse-region.
And the IDE can not start since no bundles with id 1...120 are available 
in the root region.
I guess the IDE uses SimpleConfigurator. Do I have to be aware about the 
config-file of SimpleConfigurator too? Or should do region.installBundle 
do all things properly?
Thanks a lot florian.

Pascal Rapicault  schrieb am Mo., 16. Nov. 2015 
19:10:
The usage of regions seems to be a good solution for what you are trying 
to achieve. 
However I'm still not clear about the problem you are running into.


On 15-11-16 12:57 PM, Florian Pirchner wrote:
I need to isolate the IDE e4 stuff from the Vaaclipse e4 stuff and only 
share some defined api like services and packages.

Florian Pirchner  schrieb am Mo., 16. Nov. 
2015 18:53:
Hey Cristiano,
yep. It should become some kind of "Vaaclipse Perspective WYSIWYG Editor". 
The Vaaclipse preview is embedded in the workspace as an MPart. IDE 
instance and "Vaaclipse Designer" run in same OSGi instance.
A launch config in the IDE to launch the designer in an additional 
vaaclipse-e4-instance is not an option ;(
Later I need to create an additional Region "E4 Model Exchange", that 
allows sharing information about the "Vaaclipse Designer" and the 
Xtext-Model. This region will allow to share some services. And provides 
implementations for event-exchange from and two IDE and 
Vaaclipse-Designer. 
Example:
I am changing a setting in the Vaaclipse designer. This sends an event. 
And the IDE will change the Xtext-Model in the XtextResourceSet.
Or I change the Xtext-Model and an event to the Vaaclipse-Designer will 
rerender and/or repaint the Web-UI.
WDYT?
Any ideas?
Thanks

Cristiano Gavião  schrieb am Mo., 16. Nov. 2015 18:29:
Hello.

some doubts...

do you want a preview provider... 

but instead of use the "run as container way" that will open a new 
instance with a set of defined bundles, do you want to use the same 
container instance for both pde/jde/platform and your preview provider 
that will read/use the opening projects from the workspace projects?



2015-11-16 13:46 GMT-03:00 Florian Pirchner :
Hi,

we got a problem using equinox regions.

Our usecase:
We run an Eclipse IDE based on eclipse e4. There is a project called 
vaaclipse that also uses the e4 kernel and added Vaadin renderer to it. 
And we need to show up a "Preview View" for the vaaclipse application in 
the IDE.

The problem:
Installing Vaaclipse into the IDE is not a good idea, since it will 
confuse the IDE by Extensions, OSGi-Services,...

Our approach:
1) Starting up the IDE
2) Creating a new Region called "Vaaclipse"
2a) If a Region was available, we remove it first
2b) Reading all bundles from a specified target folder
2c) Installing the bundles from the target folder into the region
3) Setting startlevels,... and starting the application

For us it seems to be possible, since the "rootRegion" and the "Vaaclipse" 
region are completely decoupled (the have no connection)


But if we do so, stop 

Re: [equinox-dev] Regions and Extension-Registry

[Thomas Watson]

Unfortunately the eclipse extension registry assumes a flat space for 
bundles and depends on the bundles providing extensions to be singletons. 
With that in mind the only way I can see this working is if the equinox 
extension registry is installed into each isolated region such that each 
installation of the extension registry can only see the bundles within its 
corresponding region.

Tom





From:   Florian Pirchner 
To: equinox-dev@eclipse.org
Date:   10/15/2015 11:00 AM
Subject:[equinox-dev] Regions and Extension-Registry
Sent by:equinox-dev-boun...@eclipse.org



Hi,

i got a question about the combination of regions and the 
extension-registry.

In my scenario i will have 2 separated regions. Lets call them A and B.
Additionally there are 2 bundles for each region:
Bundle-A-provider - Is added to region A and provides an equinox-extension 
with ID=foo
Bundle-A-consumer - Is added to region A and consumes an equinox-extension 
with ID=foo
Bundle-B-provider - Is added to region B and provides an equinox-extension 
with ID=foo
Bundle-B-consumer - Is added to region B and consumes an equinox-extension 
with ID=foo
My question:
Can equinox-registry deal with this use case? So will equinox ensure, that 
the provided extension from Bundle-A-provider is only consumeable by 
Bundle-A-consumer? Or will the extension from this provider also become 
used by Bundle-B-consumer?
Thanks,
Florian___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

[equinox-dev] Welcome Stefan Xenos as a new rt.equinox.bundles Committer

[portal on behalf of Thomas Watson]

rt.equinox.bundles Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Stefan Xenos. Stefan Xenos is a
new full Committer on the rt.equinox.bundles project.

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

Re: [equinox-dev] Accessing the log without Activator (extendsPlugin)

[Thomas Watson]

ILog has been around for a very long time, before OSGi as a runtime in 
Eclipse I think.  So its access is a bit static.  If you have motivation 
to access it in an 'OSGi way' then I recommend you enhance the eclipse 
platform to register a ServiceFactory that bundles can use.  The 
ServiceFactory would essentially return the same thing 
Platform.getLog(Bundle) does.  That way you can get injected with your 
bundle's ILog with things like DS.

Tom





From:   Konstantin Komissarchik 
To: Neil Bartlett , Equinox development mailing 
list 
Date:   10/07/2015 11:01 AM
Subject:Re: [equinox-dev] Accessing the log without Activator 
(extendsPlugin)
Sent by:equinox-dev-boun...@eclipse.org



Here is the invocation that I use to get ILog without an Activator:
 
Platform.getLog( Platform.getBundle( "..." ) )
 
Thanks,
 
- Konstantin
 
 
 

From: Neil Bartlett
Sent: Wednesday, October 7, 2015 8:50 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Accessing the log without Activator 
(extendsPlugin)
 
 
Looking at the source code, ILog is not an OSGi service but is constructed 
as a wrapper object around the OSGi LogService. The relevant code is in 
org.eclipse.core.internal.runtime.InternalPlatform.
 
Do you need the full functionality of an ILog, or is standard OSGi 
LogService sufficient? If the latter, then you can use a DS component and 
just inject a reference to the LogService. If you really need ILog then I 
think you have to go through InternalPlatform.getDefault().getLog().
 
Neil
 
 
> On 7 Oct 2015, at 09:38, Lars Vogel  wrote:
> 
> Hi,
> 
> in my Activator based on Plugin, I have this nice method:
> 
> MyActivator.getDefault().getLog() which is basically Plugin.getLog().
> 
> What is the correct way to access the ILog in OSGi without an Activator?
> 
> 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 (032) 221739404, Email: lars.vo...@vogella.com, Web: 
http://www.vogella.com
> ___
> equinox-dev mailing list
> equinox-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
 
 ___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] Checking whether a class is available in the target platform

[Thomas Watson]

What is the bug number where the revert happened and we can discuss the 
alternatives?

If you want to avoid lazy activation of the bundle then we have to avoid 
actually loading the class in the check.  I think you may be able to try 
locating the .class resource instead of actually trying to load the class 
with the bundle class loader.

Tom





From:   Simon Scholz <simon.sch...@vogella.com>
To: equinox-dev@eclipse.org
Date:   10/07/2015 05:14 AM
Subject:[equinox-dev] Checking whether a class is available in the 
target  platform
Sent by:equinox-dev-boun...@eclipse.org



Hello,

we are currently facing problems, when trying to figure out if a class 
is available in the target platform or not.
So in case certain bundles are removed from the target platform the E4 
application model should be cleaned up accordingly, which means that 
referenced model objects, should be removed from the E4 application 
model, if the contributing bundle is not available any more.

Thomas Watson suggested this solution 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=445663#c4, which 
unfortunately causes the bundles to load.
This is undesired and therefore this patch has been reverted: 
https://git.eclipse.org/r/#/c/55249/9/bundles/org.eclipse.ui.ide.application/src/org/eclipse/ui/internal/ide/application/addons/ModelCleanupAddon.java


So is it somehow possible to figure out if a certain class is available, 
when we have the Bundle-SymbolicName and the full qualified classname, 
without activating/loading the bundle?

Thanks in advance and regards,

Simon

-- 
Trainer, Consultant and Developer

vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Tel (040) 78804360, Fax (032) 221739404, Email: simon.sch...@vogella.com, 
Web: http://www.vogella.com

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


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

Re: [equinox-dev] OSGiServiceSupplier

[Thomas Watson]

I have some issues with both examples you gave.  For the code that uses 
ServiceTracker it will end up creating a ServiceTracker and never closing 
it which will leave a ServiceListener leaked (registered) with the 
framework for the lifetime of the active bundle.  Once the bundle is 
stopped the leaked listeners will finally get cleared.  So if you use the 
OSGiTracker in a short lived object that gets created often then you will 
quickly grind the service event bus of the framework to a halt.  You may 
try to limit the damage of that leak by having a finalize() method that 
closes the tracker, but usually finalize() methods are not recommended 
best-practice.

The OSGiSupplier is better but it has the unfortunate side-effect of 
ungetting the service object before even returning it to the client code 
for its first usage.  In general this is not using good practices in OSGi 
because the service registration may be using a ServiceFactory that needs 
to track the state of the using bundles.  Such usage on a ServiceFactory 
registration will cause the service usecount for the bundle to osilate 
between one and zero within the get() method.  Each time the usecount goes 
to zero the service object is thrown away by the framework, then on next 
usage the service object will have to be recreated by the factory.  This 
could result in a performance issue if the creating of the service object 
is expensive.

The classes may have their uses in specific cases and not cause issues if 
used in a specific way.  For example, if you know for a fact that the 
service you are getting is not stateful and does not use a ServiceFactory. 
 Or if you make sure to use the OSGiTracker in an object that has a 
one-to-one relationship with the active lifecycle of the bundle.  I am not 
sure they belong down in Equinox though because I do not believe they 
promote best-practices when dealing with the OSGi service registry.

I also wonder if the latest DS specification helps deal with some of the 
short-comings you mention in your blog.

Finally I do thank you for proposing a solution to a problem and bringing 
it here for discussion, I just don't feel comfortable with the current 
solution :-)

Tom





From:   Alex Blewitt 
To: Equinox development mailing list 
Date:   09/25/2015 01:33 PM
Subject:[equinox-dev] OSGiServiceSupplier
Sent by:equinox-dev-boun...@eclipse.org



I posted on http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.html 
earlier today about using Java 8’s Supplier to acquire a service on-demand 
without having to do expensive client-side coding, and that would fail 
fast in the absence of any OSGi classes and return null in such 
situations.

I’d like to contribute this to Eclipse so that it can be used in places 
where Declarative Services aren’t the right solution (specifically; for 
integrating in where places have static Log or DebugOptions classes).

Which would be the right project/bundle to contribute this into? Clearly 
it could go into something like Platform or Core.runtime, but I wondered 
if it might be sensible to have this in equinox.util or equivalent.

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


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

Re: [equinox-dev] org.eclipse.equinox.security

[Thomas Watson]

That is a great question.  I don't see why the path is restricted like it is.  Perhaps you can open a bug and provide a contribution as well as tests that use a wider range of characters.
 
Tom
 
 
- Original message -From: Nikolis Galerakis Sent by: equinox-dev-boun...@eclipse.orgTo: equinox-dev@eclipse.orgCc:Subject: [equinox-dev] org.eclipse.equinox.securityDate: Fri, Sep 4, 2015 6:57 AM 
Hello all 
I am currently using org.eclipse.equinox.security bundle by using Eclipse Secure Storage . What I want to do is give my users the possibility to save Nodes in the Secure Storage with Names that contain German and French Special characters such as öäÖÄ so what this means is that I would need to loosen up the control in the isValid method in the org.eclipse.equinox.internal.security.storage.SecurePreferences. I want to use the characters with ASCII codes 32-255 the question is : Is there any reason not to do so ? why is the isValid ASCII code ranges from 32-160 at the moment ? 
 
Thanks in advance,
Nikolaos
___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/equinox-dev

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

Re: [equinox-dev] Getting equinox artifacts using maven

[Thomas Watson]

The Equinox SDK includes several bundles that are not actually developed 
as part of the Equinox project.  I'm not sure I want to have Equinox 
publish other Eclipse project's bundles.  I would like to start with 
publishing only the Equinox bits that implement the OSGi specifications.

Tom





From:   Scott Lewis sle...@composent.com
To: equinox-dev@eclipse.org
Date:   07/20/2015 12:56 PM
Subject:Re: [equinox-dev] Getting equinox artifacts using maven
Sent by:equinox-dev-boun...@eclipse.org



On 7/20/2015 5:39 AM, Thomas Watson wrote:
I think it would be great if we could make this happen for all of Equinox. 


BTW jobs is not part of Equinox, it is part of the Eclipse project.  

It appears to be in the Equinox Mars SDK...would it be possible to include 
it in what's being discussed?   

Thanks,

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

Re: [equinox-dev] What's special about the felix bundles in the mars distro

[Thomas Watson]

If I recall correctly the orbit gogo org.apache.felix.gogo.shell bundle 
has a custom gosh_profile file in it.  But I'm not sure what it does 
special other than make the prompt use osgi instead of g!

Tom





From:   Benson Margulies ben...@basistech.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   07/20/2015 01:33 PM
Subject:[equinox-dev] What's special about the felix bundles in 
the marsdistro
Sent by:equinox-dev-boun...@eclipse.org



If I substitute plain vanilla Apache Felix gogo bundles for version
0.10.0 for the bundles included in mars, the shell does not start
properly. It gets a g! prompt and complains that the commands bundle
has not been started.

Is there a way to set up config.ini so that I can drop in the Felix
gogo bundles? I'd like to experiment with using newer versions.
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


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

Re: [equinox-dev] What version of the OSGi stock framework jar corresponds to equinox 3.10.0-v20140606-1445?

[Thomas Watson]

Neil is correct and I see you understand that.  But to answer your 
original question Equinox (org.eclipse.osgi) framework at version 3.10 
implements the OSGi R6 Core specification.

Tom





From:   Benson Margulies ben...@basistech.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   07/16/2015 01:34 PM
Subject:Re: [equinox-dev] What version of the OSGi stock framework 
jar corresponds to equinox 3.10.0-v20140606-1445?
Sent by:equinox-dev-boun...@eclipse.org



On Thu, Jul 16, 2015 at 2:24 PM, Neil Bartlett njbartl...@gmail.com 
wrote:
 Benson, you don't need to put the OSGi core jar on your runtime 
classpath if
 you already have an implementation (such as Equinox or Felix) on there.

 The OSGi core spec jar is only intended to be used as a compile-time
 dependency.

Neil,

I understand that, but due to a combination of stupidity in an IDE and
Maven, I'm having trouble getting rid of it. I don't do it in
production, it's a problem when running a test from the IDE.


 Neil

 --
 Neil Bartlett
 Sent from a phone

 On Thursday, 16 July 2015 at 18:11, Benson Margulies wrote:

 I have ended up with a classpath that contains both the version of
 equinox in the subject and also version 5.0.0 of the OSGi core API
 jar, and I get stomped on by an incompatibility. It's somewhat
 difficult to avoid this state of affairs; can you clue me in on what
 version of the OSGi core I need to avoid trouble?
 ___
 equinox-dev mailing list
 equinox-dev@eclipse.org
 To change your delivery options, retrieve your password, or unsubscribe 
from
 this list, visit
 https://dev.eclipse.org/mailman/listinfo/equinox-dev



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


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

Re: [equinox-dev] Can I get logging corresponding to 'diag'?

[Thomas Watson]

What version of Equinox are you using?  Can you give the example of the 
error message equinox does give you?
Tom





From:   Benson Margulies ben...@basistech.com
To: equinox-dev@eclipse.org
Date:   07/09/2015 12:31 PM
Subject:[equinox-dev] Can I get logging corresponding to 'diag'?
Sent by:equinox-dev-boun...@eclipse.org



When I make a mistake in a manifest, and a bundle has unresolvable 
dependencies, the error message logged is not detailed. (For comparison 
purposes, felix will log the whole story.) The shell command does not help 
me; the situation is failing pax-exam tests, and while I could load up in 
the shell, I'd rather just get the sad story when the test fails.
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Re: [equinox-dev] Can I get logging corresponding to 'diag'?

[Thomas Watson]

I suggest you open a bug against Equinox with step you used to launch the 
framework and install/start the bundles.  I'm still a bit confused by how 
the errors are being logged.  Clearly a better error message should be 
getting logged that describes the unsatisfied requirement.

Tom





From:   Benson Margulies ben...@basistech.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   07/09/2015 01:46 PM
Subject:Re: [equinox-dev] Can I get logging corresponding to 
'diag'?
Sent by:equinox-dev-boun...@eclipse.org





On Thu, Jul 9, 2015 at 2:39 PM, Thomas Watson tjwat...@us.ibm.com wrote:
What version of Equinox are you using?  Can you give the example of the 
error message equinox does give you?
Tom

I'm embarrassed to  report that I've misplaced the log. I can, however, 
try to surround the question, as follows.


I am using, in Maven terms:

org.eclipse:osgi:jar:3.10.0-v20140606-1445

The problem was the following.

 Bundle 'fred' imports com.basistech.george;version=[34.0.0,35.0.0)

I stupidly included bundle 'george' with version 35.0.0.

The error message simply said that 'fred' could not be resolved, and cited 
a number in [] brackets.

Later on I can reconstruct this stupidity by checking out from the right 
(wrong) commit and running the build, but perhaps this is helpful?

In comparison, when I swapped in Felix, I got a lengthy diagnosis that the 
problem was the lack of com.basistech.george at the required version.









From:Benson Margulies ben...@basistech.com 
To:equinox-dev@eclipse.org 
Date:07/09/2015 12:31 PM 
Subject:[equinox-dev] Can I get logging corresponding to 'diag'? 
Sent by:equinox-dev-boun...@eclipse.org 



When I make a mistake in a manifest, and a bundle has unresolvable 
dependencies, the error message logged is not detailed. (For comparison 
purposes, felix will log the whole story.) The shell command does not help 
me; the situation is failing pax-exam tests, and while I could load up in 
the shell, I'd rather just get the sad story when the test fails. 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev 

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

Re: [equinox-dev] Can I get logging corresponding to 'diag'?

[Thomas Watson]

To use the console you need the following 4 bundles from the Equinox SDK:

org.apache.felix.gogo.command
org.apache.felix.gogo.runtime
org.apache.felix.gogo.shell
org.eclipse.equinox.console

You will need a file located next to the equinox jar 
configuration/config.ini and place the following in it:

osgi.bundles=org.apache.felix.gogo.command, \
 org.apache.felix.gogo.runtime, \
 org.apache.felix.gogo.shell, \
 org.eclipse.equinox.console

Then put these 4 bundles also next to the equinox framework jar from the 
Equinox SDK:  
http://download.eclipse.org/equinox/drops/R-Mars-201506032000/download.php?dropFile=equinox-SDK-Mars.zip

Tom





From:   Benson Margulies ben...@basistech.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date:   07/09/2015 08:52 PM
Subject:Re: [equinox-dev] Can I get logging corresponding to 
'diag'?
Sent by:equinox-dev-boun...@eclipse.org



Either that or some piece of pax-exam is filter-feeding log messages.
I found a way to customize it to just install a framework listener to
get the data.

Meanwhile, could you possibly deconfuse me about starting up the shell
with java -jar? I assume that I'm missing something pretty minimal.


On Thu, Jul 9, 2015 at 9:48 PM, Thomas Watson tjwat...@us.ibm.com wrote:
 Perhaps the Felix implementation of Bundle.toString displays resolution
 results?

 Tom





 From:Benson Margulies ben...@basistech.com
 To:Equinox development mailing list equinox-dev@eclipse.org
 Date:07/09/2015 06:03 PM
 Subject:Re: [equinox-dev] Can I get logging corresponding to 
'diag'?
 Sent by:equinox-dev-boun...@eclipse.org
 



 I built a test case. What it proves is that there is no Equinox problem
 here, there's a pax-exam problem.

 When I run Equinox directly from my own code, I get:

 org.osgi.framework.BundleException: Could not resolve module:
 com.basistech.equinox-logging-demo-problem [2]
   Unresolved requirement: Import-Package: org.apache.commons.io;
 version=[1.4.0,1.4.1)

 which is perfectly fine.

 pax-exam manages to obfuscate this to:

 1065 [main] ERROR org.ops4j.pax.exam.nat.internal.NativeTestContainer  -
 Bundle [com.basistech.equinox-logging-demo-problem_0.0.1.SNAPSHOT [14]] 
is
 not resolved

 So, I'll be taking this up with them.


 On Thu, Jul 9, 2015 at 3:49 PM, Benson Margulies ben...@basistech.com
 wrote:
 In an effort to get a clearer picture, I tried:

 java -jar
 
~/.m2/repository/org/eclipse/osgi/3.10.0-v20140606-1445/osgi-3.10.0-v20140606-1445.jar
 -console

 as per the getting started page, but it just sits there. I am sure this 
is
 density on my part.


 On Thu, Jul 9, 2015 at 3:01 PM, Benson Margulies ben...@basistech.com
 wrote:
 Tom,

 I can do that.

 Thanks.



 On Thu, Jul 9, 2015 at 2:58 PM, Thomas Watson tjwat...@us.ibm.com 
wrote:
 I suggest you open a bug against Equinox with step you used to launch 
the
 framework and install/start the bundles.  I'm still a bit confused by 
how
 the errors are being logged.  Clearly a better error message should be
 getting logged that describes the unsatisfied requirement.

 Tom





 From:Benson Margulies ben...@basistech.com
 To:Equinox development mailing list equinox-dev@eclipse.org
 Date:07/09/2015 01:46 PM
 Subject:Re: [equinox-dev] Can I get logging corresponding to 
'diag'?
 Sent by:equinox-dev-boun...@eclipse.org
 





 On Thu, Jul 9, 2015 at 2:39 PM, Thomas Watson tjwat...@us.ibm.com 
wrote:
 What version of Equinox are you using?  Can you give the example of the
 error message equinox does give you?
 Tom

 I'm embarrassed to  report that I've misplaced the log. I can, however, 
try
 to surround the question, as follows.


 I am using, in Maven terms:

 org.eclipse:osgi:jar:3.10.0-v20140606-1445

 The problem was the following.

  Bundle 'fred' imports com.basistech.george;version=[34.0.0,35.0.0)

 I stupidly included bundle 'george' with version 35.0.0.

 The error message simply said that 'fred' could not be resolved, and 
cited a
 number in [] brackets.

 Later on I can reconstruct this stupidity by checking out from the right
 (wrong) commit and running the build, but perhaps this is helpful?

 In comparison, when I swapped in Felix, I got a lengthy diagnosis that 
the
 problem was the lack of com.basistech.george at the required version.









 From:Benson Margulies ben...@basistech.com
 To:equinox-dev@eclipse.org
 Date:07/09/2015 12:31 PM
 Subject:[equinox-dev] Can I get logging corresponding to 'diag'?
 Sent by:equinox-dev-boun...@eclipse.org
 



 When I make a mistake in a manifest, and a bundle has unresolvable
 dependencies, the error message logged is not detailed. (For comparison
 purposes, felix will log the whole story.) The shell command does not 
help
 me; the situation is failing pax-exam tests, and while I

Re: [equinox-dev] Signed content support in Equinox

[Thomas Watson]

The authorization support in Equinox was provisional and got removed as 
part of the Luna (Equinox 4.3) release.  It seems the documentation did 
not make it clear that this was provisional and also did not remove the 
authorization option from the docs.

With that said, you should be able to implement your own support for this 
by implementing a system bundle fragment that checks for authorization of 
the bundle signers and then forces the bundles to be unresolved if they 
are not authorized by using a ResolverHook.

Another option is to open a bug against Equinox and we can look to 
contributing back support for the authorization engine into Equinox.  At 
the time it was removed was when the framework was being rewritten to no 
longer use our internal resolve and instead use a standard OSGi Resolver 
service.  Our internal resolver implementation had a straight forward way 
to disable bundles and provide useful resolution error messages for why it 
was disabled.  The authorization support used this resolver API to 
disabled unauthorized bundles.  The same can be accomplished with the OSGi 
resolver through the use of resolver hooks, but there is not a good way to 
provide a nice error message.  We would have to look at how to make that 
work nicely.

Tom





From:   Achim Finke achim.fi...@googlemail.com
To: equinox-dev@eclipse.org
Date:   06/30/2015 09:05 AM
Subject:[equinox-dev] Signed content support in Equinox
Sent by:equinox-dev-boun...@eclipse.org



Hi all,

In Equinox 3.9 (Eclipse 4.3) it was possible to configure the following 
properties in eclipse.ini to enable Authorization.
osgi.signedcontent.support=all
osgi.signedcontent.authorization.engine.policy=trusted
osgi.framework.keystore=file:truststore.jks

Setting up the same properties in Equinox 3.10 (Eclipse 4.4) seems to have 
no effect. I can start the application regardless wether my bundles are 
signed with the right key or not.
I already asked this question on Stackoverflow but the use case seems not 
to be that common as I thought so I didn't get an answer. Hope you can 
help :-).

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

Re: [equinox-dev] Unsync equinox packages between EPP and Equinox Target Components feature?

[Thomas Watson]

org.eclipse.equinox.coordinator_1.3.100.v20150410-1453 is the expected 
version for Mars.  When I look at all the features contained in the 
Equinox Target Components feature they refer to this version of the 
coordinator.  What if you create a new target and install the Equinox 
Components into that instead of into your running installation?

That is what I did to confirm the contents of Equinox Components which are 
staged to the mars site.

Tom





From:   Cristiano Gavião cvgav...@gmail.com
To: Equinox equinox-dev@eclipse.org
Date:   06/22/2015 03:07 PM
Subject:[equinox-dev] Unsync equinox packages between EPP and 
Equinox Target Components feature?
Sent by:equinox-dev-boun...@eclipse.org



Hello,

I've created an installation using oomph installer. I can see that in the 
.~/.p2/pool directory there is this package:

org.eclipse.equinox.coordinator_1.3.100.v20150410-1453.jar

Then I tried to install the feature in my local target platform: Equinox 
Target Components  3.11.0.v20150527-1706 from  
http://download.eclipse.org/releases/mars

after have received a cannot perform operation with (Equinox Target 
Componentswill be ignored because a newer version is already installed). 
Then I selected one computed alternative solution and installed. 
But I'm seeing the version 1.3.0.v20140327-1650 in tp.

which one will be delivered with mars? if it is 1.3.100.v20150410-1453 how 
can I install it in my tp?

thanks,

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

Re: [equinox-dev] New felix resolver 1.4.0 in equinox framework and custom release?

[Thomas Watson]

 
 So I got some questions:
 - When is the next planned release of the equinox framework that would 
 contain the new resolver sources?

Our Mars Equinox release (version 4.5) is eminent (June 25th).  The last 
felix resolver fix that will go into this release of Equinox is:

https://issues.apache.org/jira/browse/FELIX-4897

That is svn revision 1680878

I'm guessing you also want 
https://issues.apache.org/jira/browse/FELIX-4914
I need to understand that fix better.  I don't like the idea of modelling 
fragment identity as hosted by their host bundles since these are not 
payload capabilities.  I fear something is being overlooked.  I need to 
get a testcase up in equinox to take a better look at the issue.

Assuming the current fix is good or we find a proper alternative I think 
we could target this fix for the Mars service release 1 (which is in 
September).  But for now could you open an Equinox framework bug to track 
the fixes you want made to the Felix resolver code within Equinox?

 - For my custom release which tag of equinox should I base my fork on? 
 M20150204-0900?

Eventually we will create a new tag R4_5 in git, but this will not happen 
until the end of this week.  But unless something really catastrophic 
occurs that would force us to respin I can tell you that the commit at tag 
I20150603-2000 will be used for the R4_5 tag.  I would go ahead and use 
that for your fixes so that you have the latest Mars release + the latest 
Felix resolver code.

 - I would like to create a suffixed version for my custom release so it 
 can be easily distinguished from the original equinox release. I tried 
 several variants like 3.10.2-Talend or 3.10.2.1 but all lead to an error 

 during the build. So how can I create a suffixed custom version?

'-' cannot be used as a version separator for the qualifier.  How are you 
trying to specify the qualifier.  During the build the qualifier is filled 
in because the key word 'qualifier' is used in the manifest.  I assume you 
instead just try to fill this in with your own custom qualifier?

 - In maven central there are several artifacts for the equinox framework 

 (org.eclipse.osgi).  Which of these is the official one from the equinox 

 project?

That is a sore topic.  Unfortunately there is not one that we can call 
official from the equinox project.  Perhaps we can work out with Ray Auge 
how to publish all the latest from Mars once it is available. 
Unfortunately this is not automatic right now.

 
 Cheers
 
 Christian
 
 -- 
 Christian Schneider
 http://www.liquid-reality.de
 
 Open Source Architect
 http://www.talend.com
 
___
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev

[equinox-dev] Late discovery of a breaking change in Equinox that impacts Equinox hook implementations

[Thomas Watson]

In Mars M6 a fix [1] went into Equinox that allows an Equinox extension 
hook implementation to return resource URLs that use a different protocol 
than the built-in bundleresource protocol.  For example, Virgo has the 
need to return the VM built-in jar or file URLs in some scenarios.  While 
doing the final testing of the Mars release candidates I found this change 
causes a breaking change in the behavior for resource URL lookups when 
equinox hooks are present which want to augment the content of the bundle 
resources [2].  This must be fixed for Mars in my opinion.  But in order 
to fix this any equinox extension hooks that want to change the protocol 
used for resource URLs will need to override a different method.  For more 
information please see [2]. 

Unfortunately this change is not available in RC3, but this late change 
impacts a very small number of projects.  I really only know of it 
impacting Virgo.  Please comment in the bug [2] if you have concerns.

Tom

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

Re: [equinox-dev] Latest release of org.eclipse.equinox.region bundle

[Thomas Watson]

You can find the region bundle in the equinox SDK for Luna at 
http://download.eclipse.org/equinox/drops/R-LunaSR2-201502041700/download.php?dropFile=equinox-SDK-LunaSR2.zip

The latest available builds for the upcoming Mars release is 
http://download.eclipse.org/equinox/drops/S-MarsRC2a-201505222000/download.php?dropFile=equinox-SDK-MarsRC2a.zip

I'm not aware of a fix that went in to address this NPE.  It seems that 
there is a bundle that may have gotten uninstalled while another bundle is 
being installed?  Have you tried running subsystems on the Equinox 
framework?  Does it reproduce on the Equinx framework?  Is this a timing 
issue or it always happens?

Tom





From:   David Bosschaert david.bosscha...@gmail.com
To: equinox-dev@eclipse.org
Date:   05/28/2015 06:30 AM
Subject:[equinox-dev] Latest release of org.eclipse.equinox.region 
bundle
Sent by:equinox-dev-boun...@eclipse.org



Hi all,

I'm seeing the a NPE in the Equinox Region bundle [1] when used with
the Apache Aries subsystems implementation. The current version used
is 1.1.0.v20120522-1841 which is the only version available via Maven
central [2]. Does anyone know whether a newer release of this bundle
exist that might potentially address this issue? I could not find the
download area on the Eclipse website for this bundle...

Many thanks,

David

[1] Caused by: java.lang.NullPointerException: null
at 
org.eclipse.equinox.internal.region.hook.RegionBundleCollisionHook.filterCollisions(RegionBundleCollisionHook.java:75)
at 
org.apache.felix.framework.util.SecureAction.invokeBundleCollisionHook(SecureAction.java:1131)
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1303)
at org.apache.felix.framework.BundleImpl.init(BundleImpl.java:113)
at org.apache.felix.framework.Felix.installBundle(Felix.java:2976)

[2] 
http://search.maven.org/#artifactdetails%7Corg.eclipse.equinox%7Corg.eclipse.equinox.region%7C1.1.0.v20120522-1841%7Cjar

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


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