My system contains four jars. One jar contains Mixedcode(applet called from javascript). The jar containing the mixed code accesses other jars also. I added the attribute Trusted-Library : true and Permissions: all-permissions in manifest.mf(I'm using Java7 update25) of the jar containing the mixed code. All the jars are self-signed. Now the problem is I'm still getting the mixed code warning, which Oracle introduced in Java 7 update21.
Should i add the attributes in manifest.mf file of other jars also ?
My observations are:
After adding Trusted-Library : true and Permissions: all-permissions in all jars(doesn't matter whether they are signed or unsigned) it works fine. All the jars are loaded.
But why do i need to add these particular attributes in all the jars(Some of jars are third party jars)?
According to definition of Mixedcode and usage of the attribute Trusted-Library: true it should allow other jars once it is updated in Manifest.mf file of jar containing the applet.
Related
I am working on two projects in Eclipse.
Project A depends on some jar files that come with the project, and those jar files have been added to the “Libraries” tab in Project A's “Java Build Path” property in Eclipse.
Project B depends on Project A, as well as directly using some classes in some of those jar files in Project A's build path.
I had assumed that adding Project A to Project B's Java Build Class would also add the jars already in Project A's build path, but that appears not to be the case.
Do I have to manually add those jars to Project B's build class, or am I overlooking a setting? If so, why is that a useful standard behaviour?
You have to manually add the jars to project B's classpath.
Adding a project dependency means project A depends on the compiled output of project B. Project B's output (its compiled .class files) doesn't contain the .jar files it depends on.
Why is this? I don't know the rationale of the eclipse authors, but my guess is that they want to keep the classpath as simple and verbose as possible. Things can get confusing if you have multiple versions of the same library on the classpath.
In vanilla java you can provide directory names for the classpath. When loading a class, the JVM will search these directories in order. Eclipse encourages a stricter approach where each jar is specified manually. Note that you can add multiple jars at once, so it's trivial to add all of project B's jars to project A's classpath.
Just recently started using Eclipse and ran into an issue with exporting the plugin I'm working on. I tried to search but so far no luck - but if the answer is already here I'd be grateful if someone can point me to it.
I'm writing a n OSGi/Equinox plugin with Eclipse. The plugin is for a 3rd party system, which allows extensions: basically all jars placed in the application's plugin folder are automatically loaded into the application at startup. I have managed to put together my plugin, it's loading fine and it works.
The issue is that I rely on another plugin which is placed beside mine in the plugins folder. For obvious reasons I do not want to package that plugin into my plugin jar file. I have tried to add the dependency as an external archive, but this breaks the export: when I try to export my plugin project ant complains about missing dependencies and types. (If I actually include the other jar file in my plugin everything works, but obviously this is less then ideal.)
So: how do I set up my plugin project dependency, that it's a) an external dependency and b) doesn't need to be specified with a path or a variable - i.e. how do I tell my exporter to "don't worry, it will be there right beside you"?
Edit: Apparently there's an important detail I didn't mention. The external jar file I depend on is not an OSGi plugin, just a regular jar file with some classes in it. To the 3rd party system it seems all the same (all are under the plugins folder, all are loaded into the application), but for Eclipse the distinction seems important.
If you reference the other plug-in as a dependency in your plug-in's MANIFEST.MF the export should work without errors. The plug-in should be listed in the Require-Bundle list in the MANIFEST.MF.
You can do this in the MANIFEST.MF editor by adding to the 'Required Plug-ins' list on the 'Dependencies' tab of the editor.
Note: When referencing other plug-ins you must always use this method. Do not try adding the plug-in jar to the Java build path or anything like that.
If the jar you want to use is not an Eclipse plug-in you must should include it as part of the plug-in and list the jar in the Bundle-Classpath in the MANIFEST.MF. If you cannot do this you can reference an external jar in the Bundle-Classpath using something like:
Bundle-Classpath: .,external:$LIB_LOCATION$/lib.jar
. is the normal entry in for the plug-in code. external:$LIB_LOCATION$/lib.jar looks for lib.jar in a location defined by the environment variable LIB_LOCATION. This method can be difficult to get right.
In the end the solution to my specific problem was to add the external jar file as an Extra Classpath Entry on the build properties tab (this translated to a "jars.extra.classpath = .jar" entry in the build.properties file). I have also added the jar file to the project itself - after adding the extra class path entry that got changed into an external dependency automatically.
With these two changes I was able to successfully export my plugin, which didn't contain the external jar file, but was able to reference it when loaded into the 3rd party system.
My entities objects are scattered in multiple jars.
In jar A I have a base class name MyBase which is annotated with #MappedSuperclass.
In jar B there is an entity class which derives from MyBase.
The problem is that because the weaving is done in the context of the jar file (I'm using the maven plugin) the base class (MyBase) isn't instrumented (although it should).
If I move the derived class from jar B to A then the weaving process will handle the base as well.
Since I'm working on a large project it is critical for me to develop in a modular way.
Doesn't EclipseLink support such methodology?
The only way I found to override this limitation is to add a temporary entity class to the jar where the #MappedSuperclass base class is defined and remove it after the weaving procedure.
Sad, but true ;-)
I'm not sure on the maven plugin, but you should be able to use the static weaver on both jars, you will need to call it twice to weave both, and will need both jars on the weavers classpath for both calls.
Alternatively you can specify the jar containing your superclass as inpath - as explained here and here:
Managing multiple projects
Building AspectJ source code requires two distinct phases; compiling
the source in .java and .aj files to generate .class files, and then
applying the aspects to the generated .class files. This second phase,
known as weaving, is the key difference between AspectJ and Java
compilers. The Java compilation process is controlled by the classpath
setting, which makes types available for resolution by the compiler.
The same classpath setting is used by the AspectJ compilation process
and it is configured in exactly the same way in Eclipse. However, this
setting is not sufficient to control both the compilation and weaving
steps in all situations. This is why there are two extra settings
available for AspectJ projects.
First, there is the inpath setting. Anything specified here will be
made available to the weaver and so any aspects that apply will be
woven in. Entries can be added to a project's inpath by right-clicking
on the project, selecting Properties, then going to the AspectJ InPath
section. Entries can be either JAR files or directories (class
folders), such as the bin directory of another project. Anything on
the inpath is sent to the project's output, after potentially being
woven with aspects.
The second additional setting is the aspectpath. Whereas the inpath
controls the list of things that get woven, the aspectpath controls
what is woven into that list. In other words, any aspects specified on
the aspectpath are made available to the weaving process, just as if
they were present in source form in the project. This setting is
controlled from the AspectJ Aspect Path property page and can contain
either JAR files or directories.
An output JAR setting is also present in the AspectJ section of each
project's property page. This setting causes the compiler to output
class files directly to a JAR file, instead of to the project's output
folder.
Drove me crazy just like you - hope this helps. ;)
I'm creating a JAR file in Eclipse and for some reason classes are missing. The classes that are not included are referenced in other JAR files included on my build path. What doesn't make sense is that the behavior is not consistent. Some classes on the build path get included while others do not. Any ideas?
The step I take to create my JAR file, is to export all the source folders.
JAR files are libraries, and that means - thinking object oriented:
If the classes are referenced in other JAR that included in your build, so they have to be part of the included JAR files and not part on your new JAR.
That's the whole idea of a library - If I understand your question right.
If your JAR uses those external classes, so you have to include those classes's JAR files in your project.
I hope I understood you correctly.
When I need to distribute something for internal use, I use the Maven assembly plugin: it allows you to create jars with dependencies. This is very useful if you only want to pass around one single jar: http://maven.apache.org/plugins/maven-assembly-plugin/usage.html
I have a workspace with nearly fifty web projects in it. In an effort to streamline classpath entries, I have created a user library variable and added all required jars to it. Next, I removed the individual classpath (build) entries from each of the fifty projects and replaced them with my single user library variable. Everything was going great until I deployed one of my projects from Eclipse to Tomcat and discovered the list of jars on the user library variable were not being copied to the WEB-INF/lib folder.
Does anyone know of a way to specify that these libraries get copied to the deployment source? I experimented with the Java EE Module Dependency tab, but the jars were not copied even after selecting the name of the user library set.
Try FatJar
From my experience, Eclipse is not good at packaging all external Jars for you, but FatJar will do the trick.