adopt Atomos #36
adopt Atomos #36
Conversation
Atomos also has the ability to use a header provider: Perhaps solstice can be a header provider. It could do one of the following:
|
…hat it can be used by Solstice and Atomos.
…nning, so let it fail gracefully.
|
Thanks @tjwatson for the HeaderProvider links. As I iterate over the bundles and call I know there's enough bundles to start a workbench without throwing any exceptions, so my goal for now is to make the OSGi headers happy until I can start a workbench. So I add a header provider which:
I apply this to every single bundle, but I get the exact same error. I know that the header provider is kind of working, because I print out the headers equo-ide/solstice/src/test/java/dev/equo/solstice/IdeMainTest.java Lines 113 to 118 in 28f9fa5 So it seems like the header provider is working in that it changes the headers that Atomos provides and removes |
|
I cloned the repository, but it is unclear to me how to run the IdeMainTest class |
|
Thanks very much for taking a look! I just pushed up a commit so that |
|
Also, you can do
|
|
I got: I updated the provider to this: But this still left me with lots of unresolved bundles. So I decided to simply remove all Import-Package and Require-Bundle headers: private static Optional<Map<String, String>> headerProvider(
String location, Map<String, String> existingHeaders) {
Map<String, String> copy = new LinkedHashMap<>(existingHeaders);
copy.remove(Constants.IMPORT_PACKAGE);
copy.remove(Constants.REQUIRE_BUNDLE);
return Optional.of(copy);
}But then I still had issues like you describe where the headers don't seem to take effect in the framework. Turns out there is an equinox cache holding onto the previous header values. For me this cache is located in `~/.gradle/caches/modules-2/files-2.1/org.eclipse.platform/org.eclipse.osgi/3.18.100/ with a hashed directory name. I removed all directories under here. Then the bundles "resolve" fine, but I get an NPE activating one: My guess is that this NPE is ultimately causing some issue for e4 to come up properly. |
|
Awesome, thanks for the Whenever a bundle has an Activator, or references a bundle with an Activator (via Import-Package or Require-Bundle), I think the headers are important because they determine the correct order to activate the bundles. Now that I know about the cache and how to wipe it, I'll experiment some more. In the long-term I hope there's a way to disable the cache... |
Then just make all the requirements have
If you want to disable the cache: Framework framework = atomos.newFramework(
Map.of(
"atomos.content.install", "false",
Constants.FRAMEWORK_STORAGE_CLEAN, Constants.FRAMEWORK_STORAGE_CLEAN_ONFIRSTINIT)
); |
|
Also if you want to control where the framework cache is located then set the |
… the bundles to match the Solstice activation order.
…nore that entry.
|
Making everything optional may be more simple than trying to ignore certain names: private static Optional<Map<String, String>> headerProvider(
String location, Map<String, String> existingHeaders) {
return new ModifiedHeaders(existingHeaders)
.removeAll(Constants.REQUIRE_CAPABILITY)
.makeOptional(Constants.REQUIRE_BUNDLE)
.makeOptional(Constants.IMPORT_PACKAGE)
.headers();
}
...
public ModifiedHeaders makeOptional(String header) {
String headerUnparsed = headers.get(header);
if (headerUnparsed == null) {
return this;
}
List<String> headerList = Solstice.parseManifestHeaderSimple(headerUnparsed);
headers.put(header, headerList.stream().map(h -> h + "; resolution:=optional").collect(Collectors.joining(",")));
return this;
}With that I ran into issues because the org.eclipse.equinox.supplemental bundle is getting pulled in from some dependency (I guess). So I filtered that out from install: for (AtomosContent content : atomos.getBootLayer().getAtomosContents()) {
// The resulting bundle will use a bundle location of
// "atomos:" + atomosContent.getAtomosLocation();
if (!"org.eclipse.equinox.supplement".equals(content.getSymbolicName())) {
bundles.add(content.install());
}
}But then I ran into this exception which I think will end up blocking you: When implementing this I was not sure what to do for the local URL. At this level the framework does not know what protocol sits behind the connected resource and I am not sure how we could fix that. |
|
You could open a bug against Equinox on this. I suppose the connect implementation in Equinox could ask for the resource with the connected class loader and then return that resource URL from |
|
Amazing! I've made a few tweaks
At this point, using The good news is that we're able to get all the way to L55 of this, so the context has some services populated equo-ide/solstice/src/main/java/dev/equo/solstice/IdeMainUi.java Lines 30 to 55 in 8b5c569 It is strange that equo-ide/solstice/src/main/java/dev/equo/solstice/SolsticeInit.java Lines 129 to 137 in 6dad35b By adding those lines, I can get the problem to switch back and forth between Any tips or tricks for how Atomos handles logging? |
I saw similar issues until I filtered out |
…cially, the Atomos mode has a working `UIEventTopic` which means that tabs can dock and undock.
…te our docs to reflect that. We still sort the classpath.
…eneration." This reverts commit 010ffff.
…g overriden by 'org.osgi.framework.storage'
Following up on the suggestions from #33 (thanks in particular to @tjwatson for the Atomos link).
If you run
IdeMainTestwithuseSolstice=true, you'll get a running Eclipse JDT but withUIEventTopicbroken.If you set
useSolstice=false, you'll get:this output
but the important part is that Atomos
org.eclipse.ui.ide.applicationsuccessfullyBundleContextstill doesn't have the service we need, so maybe it's actually not starting? We get error hereExpected exactly one application, got []equo-ide/solstice/src/main/java/dev/equo/solstice/IdeMainUi.java
Lines 31 to 37 in 8532388
I can dig in more later, but just wanted to share my first experience with Atomos.