Resolving giving different failures on restart

[Dan Gravell]

I'm getting a sinking feeling that resolving is as bad with Bndtools 3.x as 2.x. Fixing continual problems with resolving was why I have tried to upgrade, but so far it seems no better and this has cost me over a week of development time.

My current problem is that I get different failures on each restart of Eclipse, with nothing having changed. The current errors cycle between:

FileNotFoundException - Some file with SHA in the filename [sorry, don't have this one verbatim, hasn't happened for a while]

Or

Unable to resolve org.apache.commons.io version=1.4.0:

   missing requirement org.apache.commons.io; version=1.4.0

Or

NullPointerException

Resolving hasn't actually worked for about an hour now. It probably will at some point if I restart Eclipse enough times, but this is really becoming a time sink.

I'm not seeing anything in the console, nor in the Error Log.

Does anyone else have a special incantation when they get these errors? Or am I the only one?

Ah, just managed to get it work again. The only thing I did differently this time was when Eclipse restarted I clicked Resolve after the workspace was initialised (populating the bndrun file I'm trying to resolve) but before CPU usage dropped - normally I wait for it to drop.

Cross fingers...

Dan

[Dan Gravell]

Here's a nice new one. The whole reason I wanted to re-resolve was because I made a change to a bundle. So I made the change, deployed it, resolved and... the old bundle was still included, despite the fact that nothing depends on it - for some reason bndtools chose the older version.

So I put in a specific version for the bundle, tried to re-resolve and...

java.lang.IllegalStateException: What?!? The capability was not found associated with any key! That is not possible at this stage.

Love it.

[Tim Ward]

I too see this one from time to time, just got it again:

java.lang.IllegalStateException: What?!? The capability was not found
associated with any key! That is not possible at this stage.

Where does one go from here? What does it mean, why isn't there any
specific information (eg which capability is it talking about??) in the
error message, how do we diagnose, how do we fix?

--
Tim Ward

[Raymond Auge]

We know for sure there's a problem in the felix resolver still:

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

Tom Watson is working on a fix and once there's a new release of Felix resolver with that fix bnd will integrate it.

However, the issue can generally be worked around by pruning what you resolve against. This is the old "your repositories need better curation" argument.

However, rather than trying to resolve from eclipse all the time, why don't you try from the command line using gradle? It's much faster, and you can enable error logging with a "-e".

./gradlew <project>:resolve.<bndfilenamewithoutextension>

This way you can see if the error is consistent or different all the time.

There's other things you can do to... but start with that.

- Ray

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Raymond Auge]

On Fri, Dec 16, 2016 at 11:01 AM, Raymond Auge <raymon...@liferay.com> wrote:

./gradlew <project>:resolve.<bndfilenamewithoutextension>

./gradlew <project>:resolve.<BNDRUNfilenamewithoutextension>

i.e. if the project is `my.propject.app` and it contains a bndrun file called `runmyapp.bndrun`

use the gradle command:

./gradlew my.propject.app:resolve.runmyapp

- Ray

[Dan Gravell]

I have in the past successful debugged bndtools from a runtime workspace (or whatever it's called now in Eclipse). If that error message was consistently popping up we could find out that way.

The trouble is that if the error messages change on every resolve that becomes a bit more difficult to arrange in your head, as it were.

[Raymond Auge]

I'm not sure that your command line runbundles task will give you the option of ignoring your workspace repository. This is probably why you keep having interactions with the workspace projects instead of the released versions of those projects.

Secondly, it's very true that bndtools has something left to be desired particularly in the way of explaining exactly what some resolve failures mean, especially when the resolver more or less crashes and all you get is a single like NPE or AIOBE. I've discussed this with the team in the past but I feel we need more work here.

Sincerely,

- Ray

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Gravell]

Ray, can you add that first paragraph to the discussion: https://groups.google.com/forum/#!topic/bndtools-users/BqKxCfhohn8 ?

On Friday, December 16, 2016 at 4:15:14 PM UTC, Raymond Auge wrote:

I'm not sure that your command line runbundles task will give you the option of ignoring your workspace repository. This is probably why you keep having interactions with the workspace projects instead of the released versions of those projects.

Secondly, it's very true that bndtools has something left to be desired particularly in the way of explaining exactly what some resolve failures mean, especially when the resolver more or less crashes and all you get is a single like NPE or AIOBE. I've discussed this with the team in the past but I feel we need more work here.

Sincerely,

- Ray

On Fri, Dec 16, 2016 at 11:05 AM, Dan Gravell <d...@elstensoftware.com> wrote:

I have in the past successful debugged bndtools from a runtime workspace (or whatever it's called now in Eclipse). If that error message was consistently popping up we could find out that way.

The trouble is that if the error messages change on every resolve that becomes a bit more difficult to arrange in your head, as it were.

On Friday, December 16, 2016 at 4:00:04 PM UTC, Tim Ward wrote:

I too see this one from time to time, just got it again:

java.lang.IllegalStateException: What?!? The capability was not found
associated with any key! That is not possible at this stage.

Where does one go from here? What does it mean, why isn't there any
specific information (eg which capability is it talking about??) in the
error message, how do we diagnose, how do we fix?

--
Tim Ward

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dan Gravell]

Odd, I don't have a resolve task... when was that added? I'm on 3.3.0. Tried it qualified by project name and unqualified (executed within the project directory).

[Raymond Auge]

On Fri, Dec 16, 2016 at 11:28 AM, Dan Gravell <d...@elstensoftware.com> wrote:

Odd, I don't have a resolve task... when was that added? I'm on 3.3.0. Tried it qualified by project name and unqualified (executed within the project directory).

You're right, it's a 3.4.0 feature... https://github.com/bndtools/bnd/wiki/Changes-in-3.4.0

Sorry about that.

- Ray

 

On Friday, December 16, 2016 at 4:04:06 PM UTC, Raymond Auge wrote:

On Fri, Dec 16, 2016 at 11:01 AM, Raymond Auge <raymon...@liferay.com> wrote:

./gradlew <project>:resolve.<bndfilenamewithoutextension>

./gradlew <project>:resolve.<BNDRUNfilenamewithoutextension>

i.e. if the project is `my.propject.app` and it contains a bndrun file called `runmyapp.bndrun`

use the gradle command:

./gradlew my.propject.app:resolve.runmyapp

- Ray

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Gravell]

TBH I've broken everything going to 3.3 so moving to 3.4 won't hurt!

On Friday, December 16, 2016 at 4:34:35 PM UTC, Raymond Auge wrote:

On Fri, Dec 16, 2016 at 11:28 AM, Dan Gravell <d...@elstensoftware.com> wrote:

Odd, I don't have a resolve task... when was that added? I'm on 3.3.0. Tried it qualified by project name and unqualified (executed within the project directory).

You're right, it's a 3.4.0 feature... https://github.com/bndtools/bnd/wiki/Changes-in-3.4.0

Sorry about that.

- Ray

 

On Friday, December 16, 2016 at 4:04:06 PM UTC, Raymond Auge wrote:

On Fri, Dec 16, 2016 at 11:01 AM, Raymond Auge <raymon...@liferay.com> wrote:

./gradlew <project>:resolve.<bndfilenamewithoutextension>

./gradlew <project>:resolve.<BNDRUNfilenamewithoutextension>

i.e. if the project is `my.propject.app` and it contains a bndrun file called `runmyapp.bndrun`

use the gradle command:

./gradlew my.propject.app:resolve.runmyapp

- Ray

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dan Gravell]

I can't go to 3.4 because it's not released and I've been burned before on that...

Trying to "curate" my libraries right now. I noticed that I have been importing the "vanilla" org.apache.commons.io bundle, so maybe going to the SpringSource bundles might help. Done that, and that error message has gone away (might come back, who knows). Now I get:

Unable to resolve org.apache.felix.log version=1.0.1:

   missing requirement org.osgi.service.log; version=[1.3.0,1.4.0)

So I "curated my repository" and deleted org.apache.felix.log - there's no way I can see to tell what bundle is using it, so I thought it might provide a clue. Now it's just NPEs all the way.

Oh wait! No, I gave it twenty seconds while writing the last paragraph and now resolution works again...

Grabbing resolution results is precious because it gives the opportunity to see the "Reasons" for resolutions and perform more "curation" from there.

Assuming the resolutions that _work_ are trustworthy, maybe they aren't.

[Dan Gravell]

For a while it looked like by deleting a load of stuff it made it work better.

Unfortunately then I realised I need that load of stuff.

I'm trying to add one bundle back in. If it's not in the bndrun file it resolves. If it is in I get:

Unable to resolve org.apache.felix.log version=1.0.1:

   missing requirement org.osgi.service.log; version=1.3.0

org.apache.felix.log is actually available btw, it was resolved in the last successful resolution I made.

Anyway, the bundle that is causing the problem is pretty simple, it imports just

osgi.core;version=4.3.0,\

org.eclipse.jetty.osgi.boot;version=8.1

Both of which were also already resolved in the previous successful resolution.

I'll come back to it tomorrow I guess (another working day gone).

[Neil Bartlett]

Dan,

I’m truly sorry that you’re experiencing all these problems but I’m also quite surprised because it is completely at odds with my own experience. If it was as bad as you are describing then I would not tolerate it and would have worked to fix it.

It would really help us if you could provide bug reports when you hit problems. A stack trace for those NPEs for example.

Regards,

Neil

[Dan Gravell]

There are no stack traces - just java.lang.NullPointerException in the box. Nothing in the Error Log nor on stdout/err.

Don't be sorry. My last message was at the end of another long day and I was a bit grumpy. I run a software company that's supposed to be agile - taking so long to resolve issues with the build and configuration of our codebase is just a bit frustrating because we aren't improving our own product in this time.

Because of the complexities involved (the workspace, basically) I think the best way forward might be for a more white box approach, running with a runtime workbench to see what is going on. The trouble is [what appears to be] the whole non determinism of these issues!

Dan

[Milen Dyankov]

Dan, this is likely not going to help you much but just to share some experience. 

I realized the resolver in BndTools is very sensitive to what's in `cached.xml` and `generated` folder. As I'm using Maven to build my jars and then bndtools to test the resolution in eclipse (before letting bnd-export-maven-plugin do it), it behaves really weird. Sometimes it resolves, sometimes it doesn't. For example once I added unresolvable require-capability to one of the jar files to test if bndtools would fail as it was resolving things that should not resolve. Eventually it did but it continued to do so long after the require-capability was removed from the jar. For me the only somewhat reliable way to run the resolver is after 

 - deleting `generated` folder

 - deleting `cached.xml`

 - closing and reopening my `.bndrun` file in Eclipse

If I skip one of those, the result is unpredictable, sometimes it fails when it shouldn't, sometimes it resolves when it shouldn't. I didn't report that until now as I thought this is related to the fact I'm working with SNAPSHOT jars files which version  do not change on every build and perhaps bndtools caches them wrongly. 

Best,

Milen

 

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://about.me/milen

[Neil Bartlett]

On 20 Dec 2016, at 10:27, Dan Gravell <d...@elstensoftware.com> wrote:

There are no stack traces - just java.lang.NullPointerException in the box. Nothing in the Error Log nor on stdout/err.

Okay well that helps in itself… we need to make sure that if there are any exceptions in the resolution process, they are written fully either to the dialog or the Eclipse error log.

Incidentally we did find and help to fix an NPE occurring in the Felix Resolver code. The fix required pulling in a new release of the Resolver from Felix, which will be in Bndtools 3.4.0. I know that doesn’t help you right now, but it seems likely this is the same error.

Don't be sorry. My last message was at the end of another long day and I was a bit grumpy. I run a software company that's supposed to be agile - taking so long to resolve issues with the build and configuration of our codebase is just a bit frustrating because we aren't improving our own product in this time.

Because of the complexities involved (the workspace, basically) I think the best way forward might be for a more white box approach, running with a runtime workbench to see what is going on. The trouble is [what appears to be] the whole non determinism of these issues!

Yes that concerns me as well. The resolve process *should* be deterministic, i.e. given exactly the same input you should get exactly the same output. I can’t think why that wouldn’t be the case.

What does your repository config look like?

Neil

[Dan Gravell]

Neil, 

Because of the complexities involved (the workspace, basically) I think the best way forward might be for a more white box approach, running with a runtime workbench to see what is going on. The trouble is [what appears to be] the whole non determinism of these issues!

Yes that concerns me as well. The resolve process *should* be deterministic, i.e. given exactly the same input you should get exactly the same output. I can’t think why that wouldn’t be the case.

That's why I said "[what appears to be]" - I can't imagine it _is_ non-determinism, I guess something is changing. For example in my case above I added a bundle with two dependencies and I started getting errors about other bundles that aren't amongst that bundles' dependencies, including transitive.

 

What does your repository config look like?

Do you mean cnf/build.bnd? Here it is:

# Configure Repositories

-plugin.1.Central: \

aQute.bnd.deployer.repository.wrapper.Plugin; \

location = "${build}/cache/wrapper"; \

reindex = true, \

aQute.bnd.jpm.Repository; \

includeStaged = true; \

name = Central; \

location = ~/.bnd/shacache; \

index = ${build}/central.json

-plugin.2.Local: \

aQute.bnd.deployer.repository.LocalIndexedRepo; \

name = Local; \

pretty = true; \

local = ${build}/local

-plugin.3.Templates: \

aQute.bnd.deployer.repository.LocalIndexedRepo; \

name = Templates; \

pretty = true; \

local = ${build}/templates

-plugin.4.Release: \

aQute.bnd.deployer.repository.LocalIndexedRepo; \

name = Release; \

pretty = true; \

local = ${build}/release

-releaserepo: Release

-baselinerepo: Release

# JUnit

junit: org.apache.servicemix.bundles.junit; version=4.12

Thanks for your help,

Dan

[Dan Gravell]

Thanks. You mean the generated folder in the project that the bnd/bndrun file is in, right?

http://about.me/milen

[Milen Dyankov]

correct

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://about.me/milen

[Dan Gravell]

Neil,

On Tuesday, December 20, 2016 at 11:22:33 AM UTC, Neil Bartlett wrote:

On 20 Dec 2016, at 10:27, Dan Gravell <d...@elstensoftware.com> wrote:

There are no stack traces - just java.lang.NullPointerException in the box. Nothing in the Error Log nor on stdout/err.

Okay well that helps in itself… we need to make sure that if there are any exceptions in the resolution process, they are written fully either to the dialog or the Eclipse error log.

This occurs because generic Exceptions are caught in ResolveProcess.resolveRequired, rethrown as a ResolutionException which then just prints e.getLocalizedMessage() in ResolveOperation.run().

Since running the runtime workbench the errors have changed to ArrayIndexOutOfBoundsException, something to do with my system bundle fragment...

Dan

[Dan Gravell]

Hmmm... where does cached.xml normally appear? I can't see any in my workspace.

On Tuesday, December 20, 2016 at 11:16:06 AM UTC, Milen Dyankov wrote:

http://about.me/milen

[BJ Hargrave]

The exception reporting is much improved in 3.4. See https://github.com/bndtools/bnd/pull/1730

3.4 also include an updated Felix Resolver which I think will address the ArrayIndexOutOfBoundsException. There were also some fixes around fragment support made to the resolve process but I am not sure if that was for 3.3 or 3.4.

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Dan Gravell]

I removed the system bundle and I'm getting the same AIOOBE when resolving an Import-Package for sun.reflect. But I guess a resolution problem is expected - the point of the system bundle is to expose a number of sun. packages.

It's occurring here: 

Thread [Worker-22] (Suspended (exception ArrayIndexOutOfBoundsException))

ArrayList<E>.elementData(int) line: 418

ArrayList<E>.set(int, E) line: 446

ShadowList.replace(Capability, Capability) line: 81

Candidates.prepare() line: 915

ResolverImpl.getInitialCandidates(ResolverImpl$ResolveSession) line: 502

ResolverImpl.doResolve(ResolveSession) line: 387

ResolverImpl.resolve(ResolveContext, Executor) line: 375

ResolverImpl.resolve(ResolveContext) line: 329

BndResolver.resolve(ResolveContext) line: 29

ResolveProcess.resolveRequired(Processor, Project, Registry, Resolver, Collection<ResolutionCallback>, LogService) line: 75

ResolveProcess.resolveRequired(BndEditModel, Registry, Resolver, Collection<ResolutionCallback>, LogService) line: 55

ResolveOperation.run(IProgressMonitor) line: 65

ResolveJob.run(IProgressMonitor) line: 57

Worker.run() line: 54

We're trying to update a CapabilityImpl for sun.reflect in the ShadowList.unmodifiable (!) List, but the CapabilityImpl doesn't exist.

Dan

[Dan Gravell]

I think Milen might be onto something. Even when I remove the system bundles from run requirements they are involved in the resolvers getInitialCandidates phase. I'll try cleaning out what I can and restarting.

[BJ Hargrave]

There have been a number of improvements in this area since 3.3. You should set up a test eclipse with Bndtools 3.4 to see if that helps your issues. 

[Dan Gravell]

Has there been a change in parsing of bnd files? I'm getting a lot of markers on bnd files for pretty much all the projects:

Description Resource Path Location Type

Unexpected aQute.libg;version='[3.4.0,4.0.0)', biz.aQute.bndlib;version='[3.4.0,4.0.0)',bndtools.utils;version=project;packages=*,bndtools.api;version=latest, bndtools.core;version=latest, osgi.core;version=5.0.0,osgi.cmpn;version=5.0.0,org.eclipse.core.runtime,org.eclipse.core.contenttype,org.eclipse.jface,org.eclipse.jface.text,org.eclipse.core.resources,org.eclipse.equinox.common,org.eclipse.swt.cocoa.macosx.x86_64;packages=*,org.eclipse.swt,org.eclipse.text,org.eclipse.ui.workbench,org.eclipse.core.jobs,org.eclipse.equinox.registry,org.eclipse.jdt.core,org.eclipse.jdt.ui,org.eclipse.osgi,org.eclipse.core.commands,org.eclipse.ui.ide,org.eclipse.ui.forms,org.eclipse.ui.workbench.texteditor,org.eclipse.ui.editors,org.eclipse.ui.views,org.eclipse.debug.core,org.eclipse.debug.ui,org.eclipse.jdt.launching,org.eclipse.jdt.debug.ui,org.eclipse.jdt.junit,org.eclipse.team.core,org.eclipse.core.filesystem, org.eclipse.equinox.preferences,  error java.lang.NullPointerException, bnd.bnd /bndtools.release line 1 Bndtools Path Problem Marker

Unexpected junit;version=latest,hamcrest-core;version=latest,  error java.lang.NullPointerException, bnd.bnd /bndtools.release line 1 Bndtools Path Problem Marker

Unexpected junit;version=latest,hamcrest-core;version=latest,  error java.lang.NullPointerException, bnd.bnd /bndtools.release line 1 Bndtools Problem Marker

Will not build project bndtools.release until the compilation and/or path problems are fixed, output files are kept. bnd.bnd /bndtools.release line 1 Bndtools Problem Marker

Guess it's those NPEs that are the problem,... Nothing in the error log or stdout/err.

Dan

[BJ Hargrave]

Some release back, the bnd file parser was rewritten. You'll need to consult the change info to note the actual release. 

[Dan Gravell]

Thanks, my mistake. S'ok now, I posted before updating the wrapping bndtools release which is used to parse the bndtools projects in the workspace.

[Dan Gravell]

Working with head (I just did a git pull, assume that's right) I get the same thing:

I debugged it and it's the same stack trace as above, although now the error occurs when investigating the javax.activation capability, not sun.reflect.

Dan

[Raymond Auge]

Dan  you mention something that I would like clarified! These extra packages you need "from the system bundle". How are you configuring the framework to provide them?

Could you post:
1) list the packages you require from the JRE which are not typically exported by the system bundle
2) post your configuration of `-runsystempackages:`?

- Ray

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Raymond Auge]

Secondly, there was/is still a bug in the felix resolver which is not yet released:

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

I'm still encountering this in the HEAD of bnd/bndtools. So until Felix has a new resolver release we're still going to see this issue in the resolve process.

The only workarounds are:

1) be very sensitive to fragments in the repositories used to resolve. The slf4j/log4j bundles are a constant source of pain due to how these are designed using fragments and when you have multiple versions of those logging libraries in your dependencies it can really throw the resolution off due to the resolver issues with fragments.

2) specify in your -runrequires exactly the logging bundles you want and blacklist others that cause the resolution to fail.

Note the resolver issue may also result from other "fragment oriented" bundle assemblies. Try to avoid those right now. The reason that we've not seen this in places like enRoute and early bndtools project workflows, where this resolve process was pioneered, is because Peter and most of the seasoned OSGi experts involved have a huge (and totally reasonable) aversion to fragments.

However, as this technology gets applied to a wider audience and the "purity" of the bundles in question becomes more diluted we're suddenly seeing these fragment based scenarios popping up and causing the resolve process to barf because they are scenarios that would rarely (if ever) happen during runtime resolution process (having +4 versions of both hosts and fragments for them). However Tom Watson hit the exact issue at runtime recently on a large project and was motivated to find the root cause which had eluded us so far.

Sincerely,

- Ray

[Dan Gravell]

That bug looks like the problem I'm seeing, thanks!

In answer to your question:

These extra packages you need "from the system bundle". How are you configuring the framework to provide them?

Could you post:
1) list the packages you require from the JRE which are not typically exported by the system bundle
2) post your configuration of `-runsystempackages:`?

The answer is "any way that works"(I'm only slightly joking!)

The main way is to have a system bundle fragment. It exports:

EXPORT-PACKAGE: sun.nio.ch,\

 com.sun.image.codec.jpeg,\

 com.sun.management,\

 com.sun.medialib.mlib,\

 com.sun.org.apache.xpath.internal.jaxp,\

 com.sun.xml.internal.bind.v2,\

 sun.security.action,\

 sun.misc,\

 sun.reflect,\

 javax.swing,\

 sun.awt.image,\

 sun.awt.image.codec,\

 sun.security.action,\

 org.w3c.dom,\

 javax.xml.transform,\

 javax.xml.namespace,\

 javax.xml.bind,\

 com.apple.eio,\

 com.apple.eawt

And then I have imports for all the bundles that use the above. I believe this is as close to best practice as can be for this particular problem?

Interestingly, I also noticed what appears to be a regression in Felix 4 in that the system.bundle alias wasn't interpreted as being for org.apache.felix.framework (or whatever, that's from memory). Neil originally flagged this. For some reason it worked on my previous builds in bndtools 2.4...

Whether or not I should be trying with Felix 4 or 5.4 as the target platform I'm not sure, tried both, neither worked.

For some reason, and I can't remember why, I also have this in my bndrun file:

-runsystempackages: sun.misc,sun.nio,sun.nio.ch,sun.reflect,junit.framework,javax.servlet,javax.servlet.http,sun.reflect

I think it might have been from when I tried running the bndrun file, not merely resolving or building from it. I have tried commenting that out but still no dice. 

1) be very sensitive to fragments in the repositories used to resolve. The slf4j/log4j bundles are a constant source of pain due to how these are designed using fragments and when you have multiple versions of those logging libraries in your dependencies it can really throw the resolution off due to the resolver issues with fragments. 

Can you explain what you mean by "be sensitive"? I do use slf4j although that's not breaking right now, as far as I can see. It's the system bundle stuff (which is a fragment).

If it's FELIX-5450 causing the problem then how do I find the multiple hosts? I thought it would just be the system.bundle that's the host?

So I was out of the loop but how should I avoid fragments? I have used them as the basis for my own code too (for example contributing different native libraries). And what about system bundle fragments?

Dan

[Raymond Auge]

Oh my... ok.. I don't even think that the fragment bugs which Tom has worked on in recent months had considered the system bundle as the possible host, which might be an entirely new set of issues. To quote Tom: "Fragments are just horrible."

Rather than using a fragment for the system bundle to export extra packages couldn't you just configure the framework directly with those extra packages?

- Ray

--

You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Raymond Auge]

One more point, in order to make the resolution succeed (which you must in order to calculate the runbundles) while also not using a fragment for the system bundle, put all those packages on the -runsystempackages property so the resolver recognizes those as things which will be provided by the framework and allow bundles to resolve against those capabilities.

- Ray

[Dan Gravell]

I did this - removed the system bundle and added -runsystempackages

I get the same AIOOBE when looking at the hosts, and when sun.reflect is considered.

I then realised I have two host resources for felix-framework. That doesn't seem right. I guess this is the next thing to look at, but now I have to look after my daughter!

Dan

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Dan Gravell]

Looks like org.apache.felix.framework appears twice because once it is contributed as the host name in osgi.wiring.host as system.bundle, and once as org.apache.felix.framework. 

Not sure how to fix that (my system bundle fragments aren't in my bndrun file) so I'm going to park this now.

[Tim Ward]

So I've renamed some projects and packages, to fix some typos and
properly conform to our emerging naming scheme, and now bnd/bndtools
doesn't seem to build things properly.

I've been through and checked that files are in what look like the right
places, contents of .bnd files have all the right names, package names
are right, etc, and can't find anything wrong.

What else am I likely to have broken? Any other files I need to edit?
Any cached data I need to delete?

--
Tim Ward

[Greg Amerson]

It is a known issue: https://github.com/bndtools/bndtools/issues/1377

Try these steps:

- delete (but not the contents) all of your Eclipse projects

- manually verify for each of the project directories, that the directory names match the name of project in the .project file

- clean your workspace (gradlew clean and git clean -dfx)

- reimport all the projects into Eclipse using "File > Import > Existing projects..>"

- refresh repositories using "Bndtools > Refresh repositories"

See if that will clean things up.

--
Tim Ward

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Greg Amerson

Liferay Developer Tools

Liferay, Inc. www.liferay.com

[Tim Ward]

Thanks. Doing that (with gradlew.bat instead of gradle, and leaving out the git command) got me to the point where bndtools was giving error messages that made sense and helped me identify the one remaining error in a .bnd file.

However things don't seem to build any more on saving files - I seem to have to go round individual projects manually building them (right click on project, then Build Project), sometimes several times round in a loop, before all the red flags go away. At which point the code does actually run and work.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Tim Ward

[Tim Ward]

... which looks like it was just that somewhere in the middle of that process Project / Build Automatically had somehow managed to uncheck itself. So I don't really like saying things like this, but it all looks OK now.

-- 
Tim Ward

[Neil Bartlett]

The OSGi Framework implementation shouldn’t be appearing at all in the -runbundles list. This sounds like a bug, do you have any way to give us a reproducible example?

Thanks,

Neil

[Dan Gravell]

To be clear, it's not in the -runbundles list. I have chosen Felix 5.4.0 as the target framework. My subsequent email said:

Looks like org.apache.felix.framework appears twice because once it is contributed as the host name in osgi.wiring.host as system.bundle, and once as org.apache.felix.framework. 

I guess these are inserted by the resolver during the initial phase of the resolution. The bug occurs when hosts are discovered for fragments, and the framework appears twice under two different aliases.

Dan

[Raymond Auge]

Cc'ing Tom Watson regarding this last point. 

- Ray

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.