bndtools | ARCHIVED : The contents of this repo | Code Editor library

I'm new to bndtools. I'd like to use testcontainers (https://www.testcontainers.org/) to test a osgi bundle which is supposed to connect to a MQTT broker. So I can test connect, connectionlost etc. strategies. I dont't understand how maven and bnd repositories work together, so until I understand, I don't use maven. Then I've tried to "import" testcontainers by adding it to build.bnd :

I am trying to use the Aspectj compiler ajc in a modular (OSGi setting). The standard way ajc seems to be used is to take aspects & java code and turn it into one a JAR with all classes and resources in the -inpath, -aspectpath, and -sourceroots.

I am trying to weave aspects an OSGi executable JAR from bnd. This executable jar contains a set of bundles that need to be woven. However, in a modular system, the boundary is quite important. For one, the manifest often contains highly relevant information to that bundle or one of the many extenders. Flattening all the classes into a big blog won't work.

I am therefore weaving each bundle separately. However, then the output is cluttered with the aspects. I'd like to import these to keep the aspect modules proper modules. However, using the annotation programming model, I notice that ajc is modifying the aspect modules, so I need to rewrite those as well. This is fine, but since I weave each bundle separately, I have the question if the weaving of the aspect could depend on what gets other modules woven? That is, does the modification of the annotated aspect depend on the classes that it is woven in?

The other issue is what happens to resources with the same name? Since my -inpath is only one JAR (the bundle), I notice I end up with the correct manifest (META-INF/MANIFEST.MF) in the output. However, if the -inpath consists of many bundles, what will the manifest be? Or any other resource that has the same path and thus overlaps?

Last issue is external dependencies. I understand acj wants to see the whole world and include this whole world into the output JAR. However, I must exclude external dependencies of a bundle. Is there a way to mark JARs as: use, but do not include. A bit like the maven 'provided' scope?

Summary:

• Does the modification of an @Aspect annotated class depend on the targets that is applied to?
• Can I compile the @Aspect annotated classes into separate JARs?
• How to handle the external dependencies that will be provided in the runtime and thus must be excluded from the output JAR.
• What are the rules around overlapping resource paths in the -inpath and -sourceroots?

UPDATE In the mean time I've made an implementation in Bndtools.

I'm trying to get bnd tools structure working (started with tutorial https://bndtools.org/tutorial.html)

Added use of javax.vecmath (as simple library as I could think of) in cnf/central.maven file

I am attempting to update an EMF/XCore project to newer versions to get around a versioning roadblock. Currently the repository that houses this project must target Gradle 4 and Bndtools 4.3 because of problems when targeting newer versions. I readily admit that a problem here is my lack of understanding of XText, XCore, and otherwise. Now I find myself on a machine without access to Java 8 which has forced an attempt to update the project settings if at all possible.

The last safe targets for this project were XText 2.16.0 and org.xtext.builder version 1.0.21. The examples I have been able to locate match the settings of this project for the most part.

So now, attempting to run in a Gradle 6.3 environment with OpenJDK 13 (if the Java version is the issue that can be changed)...

Notes

• Some changes are based on researching solutions to my build problem and some comments are added
• ${mavenURL} is currently pointing to Maven Central
• I added the compile platform() line based on XText's Release notes. It does not seem to help this issue, though
• I changed version numbers to match those found in the Maven BOM
• I have attempted various combinations of changing the org.xtext.builder version as well as targeting both EMF 2.21 and 2.20
• I have tried a lower XText version. 2.17.0 fails with a different issue

build.gradle: