Hi folks,
we've been discussing this long time ago, and now some users are finally
bugging me that they want to run OTDT and AJDT in the same eclipse
instance. At a first look both weaving mechanisms (built using the same
adaptor hooks) actually play well together, with minor hickups only,
but aft
Hi Martin,
thanks for your quick response. Meanwhile I've found some time for
experiments, which raised new questions :)
> The quick solution here would be to disable the caching service for
> equinox weaving. This can be done by stopping the bundle (or avoid to
> have it auto-started). If the ca
Hi,
I'm mildly interested in participating in this. Meaning, that if a
redesign of some sort happens, I'd like to help improve the support
for multiple different weavers.
best,
Stephan
---
>
>
> The Equinox Weaving project has gone rather dormant over the past
couple of
> relea
I was going to suggest --launcher.appendVmargs to avoid surprises [1],
but I can't find it in the docs. What happened?
best,
Stephan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=149994
On 05/08/2012 06:04 PM, Pascal Rapicault wrote:
See -vmargs on
http://help.eclipse.org/indigo/index.js
/show_bug.cgi?id=378868
best,
Stephan
On Tue, May 8, 2012 at 10:18 AM, Stephan Herrmann
wrote:
I was going to suggest --launcher.appendVmargs to avoid surprises [1],
but I can't find it in the docs. What happened?
best,
Stephan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=149994
On 05/08/20
on.exe -console --launcher.appendVmargs -Daprop=avalue
The original vmargs in the ini are there, but the additional property
is not being appended.
Ben
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=352235
On Tue, May 8, 2012 at 10:37 AM, Stephan Herrmann
wrote:
On 05/08/2012 06:25 PM, Ben Aberna
Hi Tom,
On 08/30/2012 02:55 PM, Thomas Watson wrote:
In short, yes I have been working on re-implementing the core framework ...
Will this affect any clients that use API not specified by OSGi?
Specifically, what about the adapter hooks? Will anything change here?
thanks,
Stephan
___
On 09/04/2012 03:47 PM, Thomas Watson wrote:
Yes, in my original post I stated this:
- all equinox framework extension hook implementations will need to
be migrated to new hooks.
Sorry I missed that.
It should not be difficult, but some migration will have to occur to run
on the new
May I join the party? :)
In https://bugs.eclipse.org/358290 we have a candidate interested
in helping to make the caching service capable to handle multiple
independent weavers.
Martin, could you please share your current implementation as a
common starting point for future experiments? Or shoul
Hi Martin,
On 04/23/2013 05:10 PM, Martin Lippert wrote:
The current work is going on in the twatson/container branch of the
rt.equinox.bundles repository. This is the place where we made the
changes to run that on top of the new framework implementation. And this
would be the place that I would
While playing with the new WeavingHook API [1], I wonder what's the
best way to ensure the service is registered ASAP during start-up.
Calling the service registry from my Activator obviously is
at the mercy of s.o. triggering the Activator to begin with.
Is the declarative way (MANIFEST.MF/Servi
I don't know about your exact situation but I know about the
difficulties of communicating between a javaagent and the rest
of the world.
I'm not sure if it is even possible to let regular classes "see"
the agent, given that the agent isn't actually on the classpath.
I believe you could get the co
On 05/02/2013 05:24 PM, Tomljenovic Marko (CDG-SMT/EMT1) wrote:
Thanks for the hint.
The problem is that I cannot change the agent code since it is the regular
jacoco java agent jar.
couldn't you wrap it / replace it with an agent of your own?
__
Hi,
today I tried the first Object Teams build against a Luna milestone,
and miserably failed at the attempt to implement
org.eclipse.osgi.baseadaptor.HookConfigurator
Looking back at the discussions about "new framework" and clients
migrating to the new WeavingHook etc. I can't find an announc
to the Luna framework.
Tom
Stephan Herrmann ---07/14/2013 11:44:07 AM---Hi, today I tried the first Object
Teams build against a Luna milestone,
From: Stephan Herrmann
To: equinox-dev@eclipse.org,
Date: 07/14/2013 11:44 AM
Subject:[equinox-dev] I'm unhooke
Hi,
In the old framework I could use the ClassLoaderDelegateHook
to make aspect classes visible to those base classes into which
I'm weaving calls to the aspect. This is necessary, because
only the aspect knows about its base, not vice versa.
For Luna with the new WeavingHook all I can see is
On 07/20/2013 09:43 PM, Richard S. Hall wrote:
On 7/20/13 10:46 , Stephan Herrmann wrote:
Hi,
In the old framework I could use the ClassLoaderDelegateHook
to make aspect classes visible to those base classes into which
I'm weaving calls to the aspect. This is necessary, because
only the a
Hi Tom,
Thinking more about this, I kind-of want both, see below :)
On 07/22/2013 02:59 PM, Thomas Watson wrote:
I see Richard Hall chimed in already. The important point to remember is that
your weaving hook introduced a real runtime
dependency. There are two main reasons the standard weavi
Hi Martin,
thanks for chiming in,
On 07/26/2013 11:42 AM, Martin Lippert wrote:
while re-working the aspectj weaving mechanics in Equinox Weaving a while ago
we discussed this (with the AspectJ team) and came to
the conclusion that aspects should be exported to be woven into other bundles.
Ot
On 07/26/2013 11:15 PM, Thomas Watson wrote:
> If OSGi would support Export-Class we could simply augment that declaration
> for our purposes :)
>
I think this was mentioned before, but not sure if I heard why it cannot be
useful for you. There are directives include/exclude
[1] that allow
On 07/27/2013 05:12 PM, Neil Bartlett wrote:
Quick experiments with Export-Package & include seem to indicate,
that from multiple exports of the same package only the last one survives.
What kind of experiments?
bundle Provider:
Export-Package: provider;include:="C1";my-attr="foo",
provider;
On 07/27/2013 05:48 PM, BJ Hargrave wrote:
You should also set mandatory:=my-attr on each export of provider so a hapless
importer does not import some random subset of your
package.
Makes sense, thanks.
But this whole thing seems like overkill. Why don't you simply export the whole
provide
On 07/27/2013 07:45 PM, Neil Bartlett wrote:
I think that the Export-Package header is unsuitable for this, but
you're not necessarily back at square one. You should probably look at
the generic Provide-Capability header instead.
I admit I hadn't looked into that, but after some playing around
Hi Uwe,
sounds like you're affected by the change from maven.test.skip to skipTests.
See http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09872.html
best,
Stephan
On 09/04/2014 09:45 AM, Stieber, Uwe wrote:
Hi,
I’ve submitted a simple change to gerrit (https://git.eclipse.org/r/32615) to
have you chased the chain of parent poms looking for a
definition of property skipTest *and/or* maven.test.skip?
Stephan
On 04/22/2015 07:06 PM, Raymond Auge wrote:
Does anyone here know how to make these tests work?
I can't for the life of me figure out how to get these tests to run for
org.
Hi,
I've observed, that JDT has problems working with class file
plus source attachment of org.osgi.framework.Bundle et al.
Reason: when compiling the attached sources we can't find
the annotation type org.osgi.annotation.versioning.ProviderType.
I see that Equinox has the corresponding jar in it
07/2015 02:43 PM, BJ Hargrave wrote:
> From: Stephan Herrmann
> I've observed, that JDT has problems working with class file
> plus source attachment of org.osgi.framework.Bundle et al.
> Reason: when compiling the attached sources we can't find
> the annotation type
This is not helping.
On 05/07/2015 05:21 PM, BJ Hargrave wrote:
> User has an arbitrary plugin project which obviously depends on o.e.osgi.
Well I would say that no one should depend upon org.eclipse.osgi. It is an
implementation of the OSGi core spec. If you are writing
bundles, then you are
I'm not responding to any of that religious anti-PDE flame war
which is totally inappropriate in this discussion.
On 05/08/2015 10:21 AM, BJ Hargrave wrote:
Well I suggest that (1) JDT not have a fatal error here since the goal is not
to generate a class file
Sounds like the obvious way to g
On 05/09/2015 08:50 AM, Tom Schindl wrote:
PDE can have compile time dependencies in its build.properties but naturally
build.properties is not part of the final jar
I see. So o.e.osgi has this in its build.properties:
jars.extra.classpath = osgi/osgi.annotation.jar
Brainstorming:
- would it
On 05/09/2015 09:05 PM, Neil Bartlett wrote:
I find *that* comment totally inappropriate.
Only one thing to add from my side:
Any opinions which I expressed in this thread, are the personal
opinions of me as an individual committer, nothing indicative
of the position of any group, team or compa
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 p
Hi Tom,
Thanks for your comprehensive answer.
Yes, we can easily agree that SynchronousLogListener is dangerous :)
More questions inline ...
On 05/16/2016 04:14 PM, Thomas Watson wrote:
Hi
The Eclipse Log API (org.eclipse.core.runtime.ILog) has the unfortunate
contract that log listeners reg
Nice trick this ping-pong-log-listener :)
For simple experiments I can directly see it working.
May re-exercise my original stress-test later,
thanks, Tom, much appreciated!
Stephan
On 05/16/2016 06:31 PM, Thomas Watson wrote:
> From: Stephan Herrmann
> Hi Tom,
>
> Tha
as part of the Platform release
cycle, after aggregation rather than from the equinox builds
themselves.
Stephan Herrmann has been doing that work and has written it up on the
mailing list[1], wiki[2] and did a blog post[3] about it.
However that does not answer your snapshot question, perha
Hi Andreas,
On 11.04.2017 15:03, Andreas Sewe wrote:
...but why does publishing to central use version ranges in Maven
dependencies on the first place?
I get that these are a more truthful translation of the original OSGi
manifests *but* AFAIK they not only suffer from the above problem but
als
On 11.04.2017 16:01, Cristiano Gavião wrote:
On 11/04/2017 09:42, Stephan Herrmann wrote:
One way around this, *might* be to publish / consume snapshots
only via repo.eclipse.org, not Maven Central.
In my vision, the better approach is to publish into maven central repository
only the
On 11.04.2017 18:11, Cristiano Gavião wrote:
Hello Stephan, hope I have understood your question...
Sorry, if I was unclear.
On 11/04/2017 11:26, Stephan Herrmann wrote:
In particular: if someone references a repo with
false
how exactly must a snapshot be marked in order to remain
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 be
consumed as automatic JPMS modules, because the algorithm
for names of automatic modules, fails to cut off the version
from jar file
e
at hand.
I'll bring the matter of Automatic-Module-Name to the table at cross-project.
Stephan
- Original message -
From: Stephan Herrmann
Sent by: equinox-dev-boun...@eclipse.org
To: equinox-dev@eclipse.org
Cc:
Subject: Re: [equinox-dev] Support for
has changed between Monday and Wednesday (yesterday) that could have caused
these bundles to be required for a headless test execution?
Stephan
On 25.04.2018 23:43, Stephan Herrmann wrote:
Hi,
JDT's gerrit job fails since
https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/801
the co
had successful gerrit builds on Monday.
IOW, after no relevant changes in tycho, jenkins, jdt could be identified,
this is simply the last remaining explanation that I can see.
And pulling in those bundles is for sure.
Stephan
Dani
From: Stephan Herrmann
To: eclipse-...@eclipse.org, Equi
42 matches
Mail list logo
