David M Williams | 31 Oct 19:09 2014
Picon

Eclipse 4.5 M3 and Equinox (Mars M3) are available ...

Happy Halloween!

Check out the treats: New and Noteworthy

And ... no tricks!

        Eclipse downloads:
        http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M3-201410292000/

        Update existing (non-production) installs:
        http://download.eclipse.org/eclipse/updates/4.5milestones/

        Specific repository good for building against:
        http://download.eclipse.org/eclipse/updates/4.5milestones/S-4.5M3-201410292000/

        Equinox specific downloads:
        http://download.eclipse.org/equinox/drops/S-MarsM3-201410292000/


Thanks to all who made this milestone possible!

<div>Happy Halloween! 
<br><br>Check out the treats: <a href="http://www.eclipse.org/eclipse/news/4.5/M3/">New
and Noteworthy</a> 
<br><br>And ... no tricks! 
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Eclipse
downloads:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M3-201410292000/">http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M3-201410292000/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Update existing
(non-production) installs:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/updates/4.5milestones/">http://download.eclipse.org/eclipse/updates/4.5milestones/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Specific
repository good for building against:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/updates/4.5milestones/S-4.5M3-201410292000/">http://download.eclipse.org/eclipse/updates/4.5milestones/S-4.5M3-201410292000/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Equinox
specific downloads:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/equinox/drops/S-MarsM3-201410292000/">http://download.eclipse.org/equinox/drops/S-MarsM3-201410292000/</a>
<br><br><br>Thanks to all who made this milestone
possible!
<br><br>
</div>
Cristiano Gavião | 29 Oct 19:07 2014
Picon

(no subject)

Iwould like to create a master table of installed OSGi framework containers in the network (using Zookeeper or other like it) and centralize configuration properties for them.

Initially I thought about using the org.osgi.framework.Constants.FRAMEWORK_UUID property. But I found that this value is generated every time the framework is relaunched.

--
"Tudo vale a pena se a alma não é pequena..."
<div><div dir="ltr">Iwould like to create a master table of installed OSGi framework containers in the network (using Zookeeper or other like it) and centralize configuration properties for them.<br><br>Initially I thought about using the org.osgi.framework.Constants.FRAMEWORK_UUID property. But I found that this value is generated every time the framework is relaunched.<br clear="all"><br>-- <br>"Tudo vale a pena se a alma n&atilde;o &eacute; pequena..."
</div></div>
David Cao | 29 Oct 17:21 2014
Picon

Pass system properties to Equinox Servlet

Hello there,

I have a bundle in Equinox Servlet in Tomcat that expects a value passed by a system properties. I can do it as a java vm -D argument. But I would like to find an alternate way using either launch.ini or config.ini.

I tried appending this 2 line in launch.ini,

-vmargs
-Dmy.property=my.value

But it didn't seem to work. And I could not find how to do it via config.ini.

Can someone show what I did wrong? Thanks a lot,

David

<div><div dir="ltr">Hello there,<div><br></div>
<div>I have a bundle in Equinox Servlet in Tomcat that expects a value passed by a system properties. I can do it as a java vm -D argument. But I would like to find an alternate way using either launch.ini or config.ini.</div>
<div><br></div>
<div>I tried appending this 2 line in launch.ini,</div>
<div><br></div>
<div>
<div>-vmargs</div>
<div>-Dmy.property=my.value</div>
</div>
<div><br></div>
<div>But it didn't seem to work. And I could not find how to do it via config.ini.</div>
<div><br></div>
<div>Can someone show what I did wrong? Thanks a lot,</div>
<div><br></div>
<div>David</div>
<div><br></div>
</div></div>
David Cao | 29 Oct 14:20 2014
Picon

Refresh a single bundle in Equinox Servlet

Hello there,

We have Equinox LunaRC4 running in Tomcat Servlet bridge. Since we could not have OSGi console in production, we use Felix Webconsole 4.2.2 to manage bundles. 

One problem now is if we just want to refresh one changed bundle, we have to do it via sp_redeploy via servlet which redeploys every bundle. (Felix webconsole does not help either; but I will ask them seperately)

So, is there an Equinox native way to automatically detect a bundle jar update and refresh the single bundle?

thanks!
David
<div><div dir="ltr">Hello there,<div><br></div>
<div>We have Equinox LunaRC4 running in Tomcat Servlet bridge. Since we could not have OSGi console in production, we use Felix Webconsole 4.2.2 to manage bundles.&nbsp;</div>
<div><br></div>
<div>One problem now is if we just want to refresh one changed bundle, we have to do it via sp_redeploy via servlet which redeploys every bundle. (Felix webconsole does not help either; but I will ask them seperately)</div>
<div><br></div>
<div>So, is there an Equinox native way to automatically detect a bundle jar update and refresh the single bundle?</div>
<div><br></div>
<div>thanks!</div>
<div>David</div>
</div></div>
Martin Lippert | 15 Oct 14:49 2014
Picon

issue with optional imports

Hey!

I have an issue with optionally imported packages and I have no idea what is exactly going on or how to
diagnose this in more detail.
We have a bundle that defines Import-Package, marked as optional.

org.apache.maven.project;resolution:=optional

There is a bundle (org.eclipse.m2e.maven.runtime) that exports this package and everything is wired
just fine.
Now I install a new version of m2e and therefore the exporting bundle is updated to a new version.

But after the update, the optional package import is not wired again. I would expect this to be wired to the
new version of that org.eclipse.m2e.maven.runtime bundle, but that doesn’t happen. There are no
other bundles in the system that export this package. A “diag <bundleID>” (with the bundle ID of the
importing bundle) doesn’t return anything.

Any idea what might be going on? All this is on Equinox 3.10.1.v20140909-1633 (Luna SR1, I think).
Or any idea how to investigate this in more detail?

(I already tried to restart Eclipse with -clean, but the result is the same, the optional import isn’t
wired and I don’t see a potentially package-use conflict anywhere)

Thanks a lot for your help!
-Martin

Artem Zhirkov | 9 Oct 13:30 2014

Equinox console not working

Hello,

I've just downloaded the recent release version of equinox and tried to 
follow the quick start guide, but even launching OSGI console didn't 
work for me.
I tried to launch it like that:

$ java -jar org.eclipse.osgi_3.10.1.v20140909-1633.jar -console

and it didn't return anything, it seems like it launched but not 
returned a console.

I'm running ubuntu 14.04 x64 and have OpenJDK Runtime Environment 
(IcedTea 2.5.2) (7u65-2.5.2-3~14.04) installed.

Any suggestions?

Best regards

Thomas Watson | 8 Oct 17:44 2014
Picon

Plans to update to jetty 9 followed by update to the Http Service implementation

To keep folks informed.  We plan to make an update to use Jetty 9 in the coming week [1].  I hope to have this released by the I-Build next week.  This will require an update to use Servlet 3.1 as well as a requirement on Java 7 in order to run Jetty 9.  Equinox bundles themselves will not require Java 7, it is only the servlet 3.1 API bundle and the Jetty 9 bundles that will require Java 7.  Also note that the Equinox Mars release will no longer ship support for Jetty 8.

After that I plan to get Ray's contribution to the update the Equinox HttpService to the latest R6 Http Whiteboard service merged into master [2].

These are two of the major items planned for the Mars release.  It would be great for those in the community that have an interest in the Equinox Http Service to test out the next Milestones for Mars.

Tom

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

<div>To keep folks informed. &nbsp;We plan to
make an update to use Jetty 9 in the coming week [1]. &nbsp;I hope to have
this released by the I-Build next week. &nbsp;This will require an update
to use Servlet 3.1 as well as a requirement on Java 7 in order to run Jetty
9. &nbsp;Equinox bundles themselves will not require Java 7, it is only
the servlet 3.1 API bundle and the Jetty 9 bundles that will require Java
7. &nbsp;Also note that the Equinox Mars release will no longer ship support
for Jetty 8.
<br><br>After that I plan to get Ray's contribution
to the update the Equinox HttpService to the latest R6 Http Whiteboard
service merged into master [2].
<br><br>These are two of the major items planned
for the Mars release. &nbsp;It would be great for those in the community
that have an interest in the Equinox Http Service to test out the next
Milestones for Mars.
<br><br>
Tom<br>
<br>[1] <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=401784">https://bugs.eclipse.org/bugs/show_bug.cgi?id=401784</a>
<br>[2] <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=436698">https://bugs.eclipse.org/bugs/show_bug.cgi?id=436698</a>
<br><br>
</div>
Thomas Watson | 8 Oct 14:41 2014
Picon

Re: Question about uses constraints in a constellation involving fragments

What you describe should not be allowed.  The uses directive on the export of org.slf4j.impl from ch.qos.logback.slf4j should not allow bundle slf4j.api (id=927) from wiring to the logback version.  Running the osgi> command 'bundle 927' should give you the packages that bundle 927 is wired to.  That should tell us if it really is wired to the one from logback which is being hosted by orbit slf4j bundle.  Your analysis sounds correct for the IncombatibleClassChangeError, but I don't understand how it is getting wired to the logback version of the impl package.

Tom





From:        Andreas Sewe <andreas.sewe-KCAAB0pqD+vegbzhZkK2zA@public.gmane.org>
To:        Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
Date:        10/07/2014 11:22 AM
Subject:        [equinox-dev] Question about uses constraints in a constellation        involving fragments
Sent by:        equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org



Hi,

I've come across a weird constellation involving uses constraints and
fragments and need an OSGi expert to double-check my logic. I hope this
is the right mailing list. If not, please accept my apologies.

I've just had fun making sense of the following bug report [1] (which
exhibits similar symptoms as these other reports [2,3,4]).

>     java.lang.IncompatibleClassChangeError: Class ch.qos.logback.classic.LoggerContext does not implement the requested interface org.slf4j.ILoggerFactory
>     at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)
>     at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)

The situation in which this occurs seems to be like this:

> osgi> ss slf4j
> "Framework is launched."
>
> id    State       Bundle
> 5    RESOLVED    ch.qos.logback.slf4j_1.0.7.v20121108-1250
>                 Master=836
> 836    RESOLVED    org.slf4j.api_1.7.2.v20121108-1250
>                 Fragments=5
> 908    RESOLVED    jcl.over.slf4j_1.7.2
> 924    ACTIVE      org.sonar.ide.eclipse.slf4j.pde_3.4.0.20140404-0949-RELEASE
> 927    RESOLVED    slf4j.api_1.7.2

So, we have two SLF4J API bundles (836, 927). The former comes from
Orbit, the latter is shipped with the SonarQube Eclipse plugin. The
plugin from Orbit uses a neat implementation trick where a fragment (5)
is used to give the org.slf4j.api bundle (836) access to the package
org.slf4j.impl and thereby make it use Logback as an API implementation.

osgi> h 5
Bundle headers:
Bundle-Localization = fragment
Bundle-ManifestVersion = 2
Bundle-Name = Logback Native SLF4J Logger Module
Bundle-RequiredExecutionEnvironment = J2SE-1.5,JavaSE-1.6,JavaSE-1.7
Bundle-SymbolicName = ch.qos.logback.slf4j
Bundle-Vendor = Eclipse.org
Bundle-Version = 1.0.7.v20121108-1250
Eclipse-SourceReferences =
scm:cvs:pserver:dev.eclipse.org:/cvsroot/tools:org.eclipse.orbit/ch.qos.logback.slf4j;tag=v20121108-1250
Export-Package = org.slf4j.impl;
uses:="org.slf4j.spi,ch.qos.logback.classic.util,org.slf4j.helpers,ch.qos.logback.classic,ch.qos.logback.core,ch.qos.logback.classic.selector,ch.qos.logback.core.joran.spi,org.slf4j,ch.qos.logback.core.util";version="1.7.2"
Fragment-Host = org.slf4j.api;bundle-version="[1.7.2,1.7.3)"
Manifest-Version = 1.0
Require-Bundle =
ch.qos.logback.core;bundle-version="[1.0.7,1.0.8)",ch.qos.logback.classic;bundle-version="[1.0.7,1.0.8)"

Now, my explanation for the IncompatibleClassChangeError is that whoever
calls org.slf4j.LoggerFactory.getLogger(...) is for some reason wired to
the slf4j.api (927) shipped with SonarQube. Now, that bundle's manifest
looks like this:

> osgi> h 927
> Bundle headers:
>  Archiver-Version = Plexus Archiver
>  Build-Jdk = 1.6.0_23
>  Built-By = ceki
>  Bundle-Description = The slf4j API
>  Bundle-ManifestVersion = 2
>  Bundle-Name = slf4j-api
>  Bundle-RequiredExecutionEnvironment = J2SE-1.3
>  Bundle-SymbolicName = slf4j.api
>  Bundle-Vendor = SLF4J.ORG
>  Bundle-Version = 1.7.2
>  Created-By = Apache Maven
>  Export-Package = org.slf4j;version=1.7.2, org.slf4j.spi;version=1.7.2, org.slf4j.helpers;version=1.7.2
>  Implementation-Title = slf4j-api
>  Implementation-Version = 1.7.2
>  Import-Package = org.slf4j.impl;version=1.6.0
>  Manifest-Version = 1.0

And here's where I think things can go wrong. Instead of getting wired
to the org.slf4j.impl package from org.sonar.ide.eclipse.slf4j.pde
(924), the slf4j.api bundle (927) gets wired to the org.slf4j.api bundle
(836) + ch.qos.logback.slf4j fragment (5) from Orbit. And the
ch.qos.logback.classic.LoggerContext from the fragment of course
implements the interface org.slf4j.ILoggerFactory exported from its host
bundle, not from the conflicting slf4j.api bundle (927). Hence the
IncompatibleClassChangeError.

So far for my theory. There is one thing, however, that puzzles me. The
fragment dutifully exports org.slf4j.impl with a uses constraint:

> org.slf4j.impl; uses:="...,org.slf4j,...";version="1.7.2"

Shouldn't this constraint prevent the slf4j.api bundle (927) from wiring
to the org.slf4j.api bundle (836) + fragment in the first place? Or does
the fact that the slf4j.api bundle (927) itself *defines* the org.slf4j
package (rather importing another, conflicting instance) does not
constitute a *use* that would violate the constraint and hence prevent
the two bundles from being wired together?

Can someone more knowledgeable of OSGi please explain to me what's going
on? Is this a constellation where uses constraints just don't help? Or
is my theory simply wrong and there exists another possible wiring that
explains the IncompatibleClassChangeError?

Any help is greatly appreciated.

Best wishes,

Andreas

[1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=446167>
[2]
<http://sonarqube.15.x6.nabble.com/SonarQube-Eclipse-3-4-0-not-compatible-with-Eclipse-Luna-4-4-0-td5026057.html>
[3] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=438161>
[4] <https://issuetracker.springsource.com/browse/STS-1620>

--
Codetrails GmbH
The knowledge transfer company

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

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev


<div>What you describe should not be allowed.
&nbsp;The uses directive on the export of org.slf4j.impl from ch.qos.logback.slf4j
should not allow bundle slf4j.api (id=927) from wiring to the logback version.
&nbsp;Running the osgi&gt; command 'bundle 927' should give you the packages
that bundle 927 is wired to. &nbsp;That should tell us if it really is
wired to the one from logback which is being hosted by orbit slf4j bundle.
&nbsp;Your analysis sounds correct for the IncombatibleClassChangeError,
but I don't understand how it is getting wired to the logback version of
the impl package.
<br><br>
Tom<br><br>
<br><br><br><br>From: &nbsp; &nbsp; &nbsp;
&nbsp;Andreas Sewe &lt;andreas.sewe@...&gt;
<br>To: &nbsp; &nbsp; &nbsp;
&nbsp;Equinox development
mailing list &lt;equinox-dev@...&gt;
<br>Date: &nbsp; &nbsp; &nbsp;
&nbsp;10/07/2014 11:22 AM
<br>Subject: &nbsp; &nbsp;
&nbsp; &nbsp;[equinox-dev]
Question about uses constraints in a constellation &nbsp; &nbsp; &nbsp;
&nbsp;involving fragments
<br>Sent by: &nbsp; &nbsp;
&nbsp; &nbsp;equinox-dev-bounces@...
<br><br><br><br>Hi,<br><br>
I've come across a weird constellation involving uses constraints and<br>
fragments and need an OSGi expert to double-check my logic. I hope this<br>
is the right mailing list. If not, please accept my apologies.<br><br>
I've just had fun making sense of the following bug report [1] (which<br>
exhibits similar symptoms as these other reports [2,3,4]).<br><br>
&gt; &nbsp; &nbsp; java.lang.IncompatibleClassChangeError: Class ch.qos.logback.classic.LoggerContext
does not implement the requested interface org.slf4j.ILoggerFactory<br>
&gt; &nbsp; &nbsp; at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)<br>
&gt; &nbsp; &nbsp; at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)<br><br>
The situation in which this occurs seems to be like this:<br><br>
&gt; osgi&gt; ss slf4j<br>
&gt; "Framework is launched."<br>
&gt; <br>
&gt; id &nbsp; &nbsp;State &nbsp; &nbsp; &nbsp; Bundle<br>
&gt; 5 &nbsp; &nbsp;RESOLVED &nbsp; &nbsp;ch.qos.logback.slf4j_1.0.7.v20121108-1250<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Master=836<br>
&gt; 836 &nbsp; &nbsp;RESOLVED &nbsp; &nbsp;org.slf4j.api_1.7.2.v20121108-1250<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Fragments=5<br>
&gt; 908 &nbsp; &nbsp;RESOLVED &nbsp; &nbsp;jcl.over.slf4j_1.7.2<br>
&gt; 924 &nbsp; &nbsp;ACTIVE &nbsp; &nbsp; &nbsp;org.sonar.ide.eclipse.slf4j.pde_3.4.0.20140404-0949-RELEASE<br>
&gt; 927 &nbsp; &nbsp;RESOLVED &nbsp; &nbsp;slf4j.api_1.7.2<br><br>
So, we have two SLF4J API bundles (836, 927). The former comes from<br>
Orbit, the latter is shipped with the SonarQube Eclipse plugin. The<br>
plugin from Orbit uses a neat implementation trick where a fragment (5)<br>
is used to give the org.slf4j.api bundle (836) access to the package<br>
org.slf4j.impl and thereby make it use Logback as an API implementation.<br><br>
osgi&gt; h 5<br>
Bundle headers:<br>
 Bundle-Localization = fragment<br>
 Bundle-ManifestVersion = 2<br>
 Bundle-Name = Logback Native SLF4J Logger Module<br>
 Bundle-RequiredExecutionEnvironment = J2SE-1.5,JavaSE-1.6,JavaSE-1.7<br>
 Bundle-SymbolicName = ch.qos.logback.slf4j<br>
 Bundle-Vendor = Eclipse.org<br>
 Bundle-Version = 1.0.7.v20121108-1250<br>
 Eclipse-SourceReferences =<br>
scm:cvs:pserver:dev.eclipse.org:/cvsroot/tools:org.eclipse.orbit/ch.qos.logback.slf4j;tag=v20121108-1250<br>
 Export-Package = org.slf4j.impl;<br>
uses:="org.slf4j.spi,ch.qos.logback.classic.util,org.slf4j.helpers,ch.qos.logback.classic,ch.qos.logback.core,ch.qos.logback.classic.selector,ch.qos.logback.core.joran.spi,org.slf4j,ch.qos.logback.core.util";version="1.7.2"<br>
 Fragment-Host = org.slf4j.api;bundle-version="[1.7.2,1.7.3)"<br>
 Manifest-Version = 1.0<br>
 Require-Bundle =<br>
ch.qos.logback.core;bundle-version="[1.0.7,1.0.8)",ch.qos.logback.classic;bundle-version="[1.0.7,1.0.8)"<br><br>
Now, my explanation for the IncompatibleClassChangeError is that whoever<br>
calls org.slf4j.LoggerFactory.getLogger(...) is for some reason wired to<br>
the slf4j.api (927) shipped with SonarQube. Now, that bundle's manifest<br>
looks like this:<br><br>
&gt; osgi&gt; h 927<br>
&gt; Bundle headers:<br>
&gt; &nbsp;Archiver-Version = Plexus Archiver<br>
&gt; &nbsp;Build-Jdk = 1.6.0_23<br>
&gt; &nbsp;Built-By = ceki<br>
&gt; &nbsp;Bundle-Description = The slf4j API<br>
&gt; &nbsp;Bundle-ManifestVersion = 2<br>
&gt; &nbsp;Bundle-Name = slf4j-api<br>
&gt; &nbsp;Bundle-RequiredExecutionEnvironment = J2SE-1.3<br>
&gt; &nbsp;Bundle-SymbolicName = slf4j.api<br>
&gt; &nbsp;Bundle-Vendor = SLF4J.ORG<br>
&gt; &nbsp;Bundle-Version = 1.7.2<br>
&gt; &nbsp;Created-By = Apache Maven<br>
&gt; &nbsp;Export-Package = org.slf4j;version=1.7.2, org.slf4j.spi;version=1.7.2,
org.slf4j.helpers;version=1.7.2<br>
&gt; &nbsp;Implementation-Title = slf4j-api<br>
&gt; &nbsp;Implementation-Version = 1.7.2<br>
&gt; &nbsp;Import-Package = org.slf4j.impl;version=1.6.0<br>
&gt; &nbsp;Manifest-Version = 1.0<br><br>
And here's where I think things can go wrong. Instead of getting wired<br>
to the org.slf4j.impl package from org.sonar.ide.eclipse.slf4j.pde<br>
(924), the slf4j.api bundle (927) gets wired to the org.slf4j.api bundle<br>
(836) + ch.qos.logback.slf4j fragment (5) from Orbit. And the<br>
ch.qos.logback.classic.LoggerContext from the fragment of course<br>
implements the interface org.slf4j.ILoggerFactory exported from its host<br>
bundle, not from the conflicting slf4j.api bundle (927). Hence the<br>
IncompatibleClassChangeError.<br><br>
So far for my theory. There is one thing, however, that puzzles me. The<br>
fragment dutifully exports org.slf4j.impl with a uses constraint:<br><br>
&gt; org.slf4j.impl; uses:="...,org.slf4j,...";version="1.7.2"<br><br>
Shouldn't this constraint prevent the slf4j.api bundle (927) from wiring<br>
to the org.slf4j.api bundle (836) + fragment in the first place? Or does<br>
the fact that the slf4j.api bundle (927) itself *defines* the org.slf4j<br>
package (rather importing another, conflicting instance) does not<br>
constitute a *use* that would violate the constraint and hence prevent<br>
the two bundles from being wired together?<br><br>
Can someone more knowledgeable of OSGi please explain to me what's going<br>
on? Is this a constellation where uses constraints just don't help? Or<br>
is my theory simply wrong and there exists another possible wiring that<br>
explains the IncompatibleClassChangeError?<br><br>
Any help is greatly appreciated.<br><br>
Best wishes,<br><br>
Andreas<br><br>
[1] &lt;<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=446167">https://bugs.eclipse.org/bugs/show_bug.cgi?id=446167</a>&gt;<br>
[2]<br>
&lt;<a href="http://sonarqube.15.x6.nabble.com/SonarQube-Eclipse-3-4-0-not-compatible-with-Eclipse-Luna-4-4-0-td5026057.html">http://sonarqube.15.x6.nabble.com/SonarQube-Eclipse-3-4-0-not-compatible-with-Eclipse-Luna-4-4-0-td5026057.html</a>&gt;<br>
[3] &lt;<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=438161">https://bugs.eclipse.org/bugs/show_bug.cgi?id=438161</a>&gt;<br>
[4] &lt;<a href="https://issuetracker.springsource.com/browse/STS-1620">https://issuetracker.springsource.com/browse/STS-1620</a>&gt;<br><br>
-- <br>
Codetrails GmbH<br>
The knowledge transfer company<br><br>
Robert-Bosch-Str. 7, 64293 Darmstadt<br>
Phone: +49-6151-276-7092<br>
Mobile: +49-170-811-3791<br><a href="http://www.codetrails.com/">http://www.codetrails.com/</a><br><br>
Managing Director: Dr. Marcel Bruch<br>
Handelsregister: Darmstadt HRB 91940<br>
_______________________________________________<br>
equinox-dev mailing list<br>
equinox-dev@...<br>
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit<br><a href="https://dev.eclipse.org/mailman/listinfo/equinox-dev">https://dev.eclipse.org/mailman/listinfo/equinox-dev</a><br><br>
<br>
</div>

Welcome Raymond Auge as a new rt.equinox.bundles Committer

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

Welcome!
Raymond Auge | 29 Sep 18:51 2014

fileinstall & equinox solution

Will there ever be a solution to the fileinstall on equinox issue?

It seems that fileinstall has not worked on equinox for some time due to the concurrency issue with package refresh.

I believe 3.1.10 is the last version that works on equinox.

--
Raymond Augé ( <at> rotty3000)
Senior Software Architect
Liferay, Inc. ( <at> Liferay)

<div><div dir="ltr">Will there ever be a solution to the fileinstall on equinox issue?<div><br></div>
<div>It seems that fileinstall has not worked on equinox for some time due to the concurrency issue with package refresh.</div>
<div><br></div>
<div>I believe 3.1.10 is the last version that works on equinox.<br clear="all"><div><br></div>-- <br><div dir="ltr">
<span><a href="http://www.liferay.com/web/raymond.auge/profile" target="_blank">Raymond Aug&eacute;</a>&nbsp;( <at> rotty3000)</span><div><span>Senior Software Architect</span></div>
<div>
<a href="http://www.liferay.com" target="_blank">Liferay, Inc.</a><span>&nbsp;( <at> Liferay)</span><div>
<div>
<div><br></div>
<p></p>
</div>
<span><span></span></span><div>
<p></p>
<p></p>
</div>
</div>
</div>
</div>
</div>
</div></div>
David M Williams | 26 Sep 02:05 2014
Picon

Re-spin of Eclipse 4.4.1 RC4a and Equinox (Luna SR1RC4a)

As I'm sure many heard, we rebuilt Eclipse and Equinox today, for Luna SR1. There were no changes to code, per se, just some metadata that created a "configuration unit" for Mac OSX incorrectly. These are the same bit's as what was in M20140925-0400 from this morning -- just renamed.

We are still on track to formally release Friday morning (around 10 AM, Eastern).

        Eclipse downloads:
        http://download.eclipse.org/eclipse/downloads/drops4/M-4.4.1RC4a-201409250400/

        Update existing (non-production) installs:
        http://download.eclipse.org/eclipse/updates/4.4milestones/

        Specific repository good for building against:
        http://download.eclipse.org/eclipse/updates/4.4milestones/M-4.4.1RC4a-201409250400/

        Equinox specific downloads:
        http://download.eclipse.org/equinox/drops/M-LunaSR1RC4a-201409250400/

Thanks,
<div>As I'm sure many heard, we rebuilt Eclipse
and Equinox today, for Luna SR1. There were no changes to code, per se,
just some metadata that created a "configuration unit" for Mac
OSX incorrectly. These are the same bit's as what was in M20140925-0400
from this morning -- just renamed. 
<br><br>We are still on track to formally release
Friday morning (around 10 AM, Eastern). 
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Eclipse
downloads:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/downloads/drops4/M-4.4.1RC4a-201409250400/">http://download.eclipse.org/eclipse/downloads/drops4/M-4.4.1RC4a-201409250400/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Update existing
(non-production) installs:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/updates/4.4milestones/">http://download.eclipse.org/eclipse/updates/4.4milestones/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Specific
repository good for building against:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/eclipse/updates/4.4milestones/M-4.4.1RC4a-201409250400/">http://download.eclipse.org/eclipse/updates/4.4milestones/M-4.4.1RC4a-201409250400/</a>
<br><br>&nbsp; &nbsp; &nbsp; &nbsp; Equinox
specific downloads:
<br>&nbsp; &nbsp; &nbsp; &nbsp; <a href="http://download.eclipse.org/equinox/drops/M-LunaSR1RC4a-201409250400/">http://download.eclipse.org/equinox/drops/M-LunaSR1RC4a-201409250400/</a>
<br><br>Thanks, 
<br>
</div>

Gmane