I have been using the openNTF Domino API (ODA) for a while now and am very happy with it. In fact I am so happy that I want to use it with my own OSGi Plug-ins as dependencies, and I am having trouble with that.
The following is what is going on.
When I just start the plug in and do not use anything from ODA, everything is good. I can select my new library as required in Notes Designer and I can use my classes and all seems well.
The second thing I do is I go into the /META-INF/MANIFEST.MF and I mark org.openntf.domino as a dependency. From what i see, this is the correct plug in because it contains the ODA Document, View, Session etc. Classes that i want to make use of. If I should be using a different plug-in, please tell me.
I go into my class which extends the com.ibm.xsp.library.AbstractXspLibrary and I get a little stuck with the Library.getDependencies(). I am not really certain what to include here to mark my dependency on ODA. I have tried a few different strings, but in the end, I am not even sure if I need to mark it here as a dependency.
I have tried:
"org.openntf.domino"
"org.openntf.domino.xsp"
"org.openntf.domino.xsp.XspLibrary"
I think I tried a few other things but cannot exactly remember what.
The main issue is that I can no longer select my plug-in library in Notes Designer and I cannot use it(obviously). So my question is, how do I correctly add my dependency to other plug-ins installed separately? I will not only be using ODA, but also the ExtLibs.
I am very grateful for any help!
I know that "org.openntf.domino.xsp" depends on "org.openntf.domino.plugin", in the same way I think you want your library to depend on ODA. It also depends on Extension Library. Looking at that, my suggestion is to try:
On plugin.xml, Dependencies tab, add "org.openntf.domino.xsp". This tells it to look for that plugins already on the server, otherwise don't run, in which case I think tell http osgi diag com.myplugin would throw an error. org.openntf.domino.xsp is already dependent on org.openntf.domino.plugin, so that's the only plugin you need as a dependency.
I don't think you'll need to tick "Reexport this dependency". I think you'd do that if you didn't want to install the ODA plugin on the server itself as well. Also, I don't think you'll need to add any exported packages on the Runtime tab.
In getDependencies(), add "org.openntf.domino.xsp.XspLibrary". This loads the XspLibrary class when you load your XspLibrary.
Related
I'm a beginning programmer and I apologize if my questions is trivial but I haven't found a sufficient answer to my problem.
I have a git repository called "toolbox" with some utility classes that I frequently use in other projects. Until now, I have manually copied those class files from this project in other projects whenever I needed them.
This if of course not a good way of doing it. I frequently add new features and fixes in whatever project I'm currently working on to these files. It makes version management a nightmare.
What I'd like to to is to import the toolbox-classes directly into the IntelliJ-Project(s) (which is also on the same git as the toolbox repo) and whenever I make a change to those files in the toolbox-repo I want the other projects to be able to automatically pull those changes as well.
If possible I'd also like to be able to share my toolbox-repo easily with others who might need those classes. But that is not a requirement. I'd just be nice to be able to do so.
I tried to use git submodule. It included the entire toolbox-repo in the target-repo but unfortunately I wasn't able to use the utility classes. I asked someone more experienced and they told me that I need to define "SourceSet" in the gradle.build but I wasn't able to configure that due to my lack of knowledge.
How can I include/import/use my utility classes from my toolbox-repo within other projects?
Thanks for any advice.
We have a project which depends on Aspose Words' com.aspose:aspose-words:16.10.0:jdk16.
The POM for aspose-words declares no dependencies, but this turns out to be a lie. It actually uses jai-core, latest version of which is at javax.media:jai-core:1.1.3.
The POM for jai-core, though, also lies - it declares no dependencies, but actually depends on jai-codec, which is at com.sun.media:jai-codec:1.1.3.
Getting these projects to fix things seems impractical. JAI is basically a dead project and Maven Central have no idea who added that POM so there is nobody responsible for fixing the metadata. Aspose refuse to fix things without a test reproducing it, even if you can show them their own code doing it wrong, and even if they fixed it, they would then add their dependency on jai-core:1.1.3, which only fixes half the problem anyway.
If I look at our entire tree of dependencies, this is only one example of the problem. Others are lurking, masked out by other dependency chains coincidentally pulling in the missing dependency. In some cases, we have even reported POM issues to projects, only for them to say that the dependency "isn't real", despite their classes clearly referring to a class in the other library.
I can think of a few equally awkward options:
Create jai-core:1.1.3.1 and aspose-words:16.10.0.1 and fix their POMs to include the missing dependencies, but whoever updates them in the future will have to do the same thing. Plus, any other library I don't know about which happens to depend on jai-core would also have to be updated.
Add a dependency from our own project, even though it really isn't one.
Edit the POM for the versions which are there now to fix the problem directly, only caveat being that people might have cached the wrong one.
So I guess I have two related questions about this:
Is there no proper way to resolve this? It seems like any non-toy project would eventually hit this problem, so there not being an obviously correct way to deal with it is worrying.
Is there a way to stop incorrect dependency metadata getting into the artifact server in the first place? It's getting kind of out of hand, because other devs on the team are adding the dependencies without checking things properly, and then I'm left to clean up their error when something breaks a year later.
Tunaki has already given many good approaches. Let me add the following:
We had to deal with a lot of legacy jars which are some old or strange versions of already existing jars on MavenCentral. We gave them a special kind of version number (like 1.2.3-companyname) and created a POM for them that fitted our purposes. This is - more or less - your first "awkward option". This is what I would go for in your case; additionally, I would define the version in the dependencyManagement, so that Maven dependency mediation will not set it to some other version.
If a new version of your jar comes around, you can check if it still has the same problems (if they did a correct Maven build, they should have all dependencies inside the POM). If so, you need to fix it again.
I wouldn't change poms for already existing versions because it confuses people and may lead to inconsistency problems because Maven will not grab the new POM if an old version is already in the local repository. Adding the dependency to your own project is an option if you have very few projects to manage so that you still see what is going on (a proper comment on the dependencies in the POM could make it clearer).
JAI is optional for Aspose.Words for Java. Aspose.Words for Java uses JAI image encoders and decoders only if they available. And it will work okay without JAI.
The codecs complement standard java ImageIO encoders/decoders. The most notable addition is support of Tiff.
JAI (Java Advanced Imaging) is not usual library. First of all - it is native library. I.e. it has separate distributives for different platforms. It has also "portable" pure-java distributive, but if you want full power of JAI - you should stick to native option.
Another thing: usually you should run installation of JAI native distributive on the host system. I.e. it installed like desktop application, not like usual java library. Again, JAI codec acts not like usual library: if it installed on system - it will plug into ImageIO, irrelevant to classpath.
So, i don't know good way to install JAI using Maven - it is like using Maven to install Skype or any other desktop application. But it is IMHO, I am not great specialist on Maven:)
In eclipse I can add required plug-ins (Dependencies) within UI (see screenshot above). This leads to an entry in the manifest.mf file.
My question is: How can I do this programmatically?
I imagine something like myProject.getManifest().addRequiredPlugin(new PluginImport(...
I already used the Plug-In Selection Spy and copied the used code. The problem is, that internal classes are beeing used there and I don't want to use internal classes. There must be a better way. Thanks in advance.
I don't believe this is possible.
Eclipse uses the manifest to load your plug-in, and probably doesn't read it again after that's done, so editing it would have no effect (since your code doesn't run until after your plug-in is loaded). As such, I doubt an interface has been provided to do this.
What are you trying to accomplish? I don't know of any use cases where trying to do this would be a good idea.
Sorry for such question since it is more my duty to search for it, but I looked everywhere and didn't find answer for it.
Is it possible to get all apache commons components in one jar or there is no such archive?
No, we don't have a "all-of-commons" jar (nor should we). It'd be large, and the functionality would be a pretty bizarre mix. You could always (attempt) to create one yourself, but you might need to do some shading if there's any version mis-matching.
I highly doubt it. It makes no sense to combine such a broad array of functionality into a single jar. Most of the projects have nothing to do with one another and it is unlikely to require them all for a single application.
You can download the whole of spring in one hit. I have seen project "using" Spring, not as a container but as a way of including lots of libraries which can work together. i.e. no actual Spring class is used.
However I suggest you use a proper dependency management tool such as maven and you shouldn't need to download a jar yourself ever again. ;)
A good web site for finding dependencies is http://mvnrepository.com/ which have the XML you need to add to your pom.xml to get any version of most JAR you need.
I am very new to java and android development and to learn I am trying to start with an application to gather statistics and information like munin does. I am trying to be able to load "plugins" in my application. These plugins are already in the application but I don't want to have to invoke them all separately, but be able to iterate over them. I was trying to use serviceloader but could never get the META-INF/services into my apk. So I am wondering if it is possible to use serviceloader on android
Thanks
EDIT: I am asking about java.util.ServiceLoader, I think it should, but I can't figure out how to get my services folder into META-INF on the apk
There is an open bug report against this issue. See https://code.google.com/p/android/issues/detail?id=59658
The META-INF folder is deliberately excluded from the APK by ApkBuilder; the only comment in ApkBuilder.java is "we need to exclude some other folder (like /META-INF)" but there is no other explanation.
Even after adding META-INF with ant, you will still get in trouble if you want to use Proguard, which refuses to replace the content of META-INF/services/* files or rename them (that's another story, the author wants to keep Proguard agnostic).
However, people using maven may want to check https://github.com/pa314159/maven-android-plugin (the branch named "modified"), that tries to solve both issues. It is a fork from the original "android-maven-plugin" I modified one month ago for my own Android projects.
It also provides a patch for Proguard-4.7
Hope this helps, any feedback is welcome.
I've figured out a solution that may work for some situations. Instead of ServiceLoader, I'm using the org.openide.util.Lookup class / library that comes with NetBeans - it is a superset of ServiceLoader. It does not require NetBeans itself and seems to work ok with Eclipse. It is necessary to replace whatever ServiceLoader functionality you are using in your application with Lookup equivalents, and add the org-openide-util-lookup library. Then, you can just do something like this:
Lookup lookup = new ProxyLookup(Lookup.getDefault(),
Lookups.metaInfServices(myClass.getClassLoader(), "services/"));
And move your ServiceLoader files from META-INF/services/ to services/.
Note that, because of the ProxyLookup, this will continue to work on standard Java environments unchanged (i.e., in those cases it will continue to look in META-INF/services).
Here is a link to the documentation for the library: http://bits.netbeans.org/dev/javadoc/org-openide-util-lookup/org/openide/util/lookup/Lookups.html
UPDATE
After working with this for a couple of days, it seems to function well - I move between environments (standard Java and Android) and it works properly in each location. The primary downside is having to manually copy the files to the /services directory.
It is possible. You may want to check http://developer.android.com/reference/java/util/ServiceLoader.html
ServiceLoader is stuff from the Java language that is not really relevant on Android. I recommend not using it. If you just want to find a list of classes within your .apk to load, there are all kinds of ways to do this -- put in XMl file in res/xml that lists them, use reflection, annotations, etc.