Adding an external JAR to Eclipse Application debug configuration - java

The issue is as follows:
I have a 3rd party Eclipse plug-in installed and running
The above Eclipse plug-in provides an "extension point" of sorts - a source for a class I can extend/rewrite and replace in the plug-in lib directory (I am not saying it's a great idea, but necessity makes us do things we are not proud of - in-house development has its quirks)
The idea here is to envelop any such change in an external JAR (created by us) so that any change in code wouldn't require us to restart Eclipse to "refresh" the "extension point" class during development.
Eventually, a plugin/bundle will be created and placed as a dependency on the original plugin - so that installing and using that plug-in would actually, you know, work.
Question is - can I somehow add what is basically an external JAR file to Eclipse Application debug/run configuration?
Normally, adding JAR to classpath tab would work for regular Java application debugging/running. Eclipse Application however, doesn't have that tab.
So far the efforts (failed, perhaps due to some stupid syntax error or whatnot) included:
Adding the JAR as a dependency to Bundle-ClassPath: of the plug-in as C:\test.jar
Adding the JAR to the system's CLASSPATH variable
None of that made any difference - the code in the "extension point" that refers to a class in the JAR file fails - exception that boils down to:
Caused by: java.lang.ClassNotFoundException: test.Test
at org.eclipse.osgi.internal.loader.BundleLoader.
findClassInternal(BundleLoader.java:506)
Any pointer/help/criticism would be greatly appreciated.
Update
Apparently putting the JAR in the lib directory of the plug-in and updating the MANIFEST file doesn't work (not that it would help me - since such a solution would require a "refresh", which I am trying to avoid in the first place), so I must be doing something fundamentally wrong.
Does that make any sense or did I miss something in one of those attempts?

I have included an external JAR file to my Eclipse application.....not to the debug/run configurations but to the application itself.
What we did was to wrap the plugin into it's own java project. We are using maven for our build, so the pom.xml lists the dependency as the .jar file (which we put into a lib directory in the project). The manifest.mf file exports the needed classes. My application plugins have a dependency on this project. When I debug/run the application in the workbench I just make sure that this library project is included.
I'm not sure this answers your question completely or not....but I hope it helps.

A first guess based on some assumptions:
You are developing an extension to an 3rd party extension point 'foo'. Your application is a Eclipse Application, that you start via a run configuration. You need to create a new plugin 'foo-extension' which implements the extension point. You have to add the new plugin as a plugin dependency to your application. This way it will be available in the project class path, as well as in the 'Plugin-Ins' tab of your run configuration. Select the new project and when you start your application the extension will be available with the latest change.

Related

How to remove duplicate jars from a gwt-application runtime config file

I am currently working towards upgrading our client side GWT setup, which we use when we deploy apps to google app engine. We also use DataNucleus's JDO on google app engine. The project is built using maven.
I have the following error below that occurs during runtime for my GWT app runconfig in legacy dev mode (the mode should not matter):
Plugin (Bundle) "org.datanucleus" is already registered. Ensure you
dont have multiple JAR versions of the same plugin in the classpath.
The URL
".../target/project/WEB-INF/lib/datanucleus-core-3.1.3.jar"
is already registered, and you are trying to register an identical
plugin located at URL
".../.m2/repository/org/datanucleus/datanucleus-core/3.1.3/datanucleus-core-3.1.3.jar."
at org.datanucleus.plugin.NonManagedPluginRegistry.registerBundle(NonManagedPluginRegistry.java:541)
I understand that this is a duplicate jar and I need to remove the duplicate. I am just at a loss for how to do it easily in my gwt app runtime configuration. What happens is that inside the runtime config, it uses the "default classpath". The default classpath includes the following:
Eclipse Project Name
(bunch of things like /src/main/java etc.)
/target/*
Maven Dependencies
There is the problem though. The datanucleus jar exists in the target/project/web-inf/lib folder and maven dependences. The maven build put the dependencies in the target folder, so the build is doing the right thing and the runtime config just has a duplicate pointer so to speak.
When I try to tweak the runtime config file, I do not have the ability to edit the "default classpath" included under the Classpath tab. It is an un-editable bundle in eclipse. The next thing I could do is remove that default classpath bundle, but then I have to manually add each jar to my runtime config by hand, which may take a couple hours.
Is there some sort of way to craft my own classpath that has everything from the default classpath less a folder or two and be picked up in the "Classpath" tab?
Is there a better way?

How to export Java app as runnable?

I created a Java project called TotalBeginner, and exported as a jar. I then reference it in a desktop app with a SWT GUI, called MyLibrary. I now want to be able to run MyLibrary outside of the Eclipse IDE (I am running Luna 4.4.0). In following the advice of other answers to questions on Stack Overflow, I export as Runnable JAR File. I pick "Package required libraries into generated JAR" - so if I understand correctly, referenced libraries like TotalBeginner.jar should be included in the MyLibrary.jar, correct? However, when I run it, it returns to the command prompt with absolutely nothing appearing to happen. Task Manager (Windows 7) shows no Javaw process. What am I missing? Thanks.
C:\Users\jimerman\>javaw -jar MyLibrary-app.jar
C:\Users\jimerman\>_
No errors, no dialogs.
I suspect in your JAR you only have classes of your own project (which is fine in fact) and you haven't put all dependent JARs in classpath (As it is complaining for unable to find org/eclipse/swt/events/DisposeListener)
It may be tedious to find out all dependent JARs and put it in classpath of java command manually.
Consider making use of build tools like Maven and Gradle, which will save you trouble in collecting dependencies, and there are plugins for them to help you to construct artifacts that makes execution easier.
For example by using Maven, what you need is to prepare a POM, put SWT (and other dependencies) as dependencies of your project.
Then by making use of shade, appassembler or assembly plugins, you can easily have a uber-jar that contains all dependencies, or have a zip files that all dependencies are put in a specific directory and you can easily execute using generated command.

Adding plain Java project as a classpath to an eclipse plugin

I have a plain Java project (not a plugin project) which I want to add to a classpath of a eclipse plugin which I am developing. But in web projects I can add that project as a build path and it works fine. But I tried same thing in eclipse plugin, I am able to compile successfully, but at run time I am getting java.lang.ClassNotFoundException.
I know OSGi quite well and I know how to add OSGi into an classpath (using export-packages) but what I want is to add Standard, non-osgi project into an classpath, so that I wont' get runtime errors. Is there anyway I can achieve this?
I can export project as a jar file or make it as a plugin project and it would work fine. But that's not my option currently because, still that API is in pre-alpha stage, and there would be lot of changes going on. So I am trying to avoid pain of exporting it as jar file everytime. Is there any option for me other than this?
I have a similar situation: I want non-OSGi Maven dependencies integrated into the classpath of my plugin. I succeeded with a roundabout solution, which I think is the best I could get.
I have a build step outside of Eclipse where I copy the class files of the dependency into the plugin's lib folder. The lib folder is specified in MANIFEST.MF as an entry in Bundle-ClassPath and (here comes the hack) as a source folder in build.properties. That was the only way to make the plugin work both when launched from within Eclipse and when exported.

Deploy Maven artifacts to <container>/shared/lib for Eclipse debugging?

I'm working with some very old, monolithic software that is basically a heavily customized JBoss deployment. Unfortunately, this means that JBoss can't be started from the "Servers" view in Eclipse, it must be started as a Windows service or via the command line. There are multiple WARs/EARs, but the WAR classloaders are rarely used and most of the actual class files are located in jboss/shared/lib as .jars.
We need a way to run a Maven build in Eclipse (via m2e) and deploy the class files in the resulting .jar to C:/product/jboss/shared/lib so that when we start JBoss, we can use Eclipse to debug (as a remote java application). Ideally, the artifact that Maven pushes will not overwrite the existing .jar file that was originally installed. For example, if the Maven project builds an artifact named myjar-1.0.0.jar, we need a way to deploy the classes inside of myjar-1.0.0.jar to C:/product/jboss/shared/lib/classes so that they are picked up by the classloader prior to C:/product/jboss/shared/lib/myjar-1.0.0.jar, which was installed with the product.
Currently, our (very hacky) solution is this:
Under the project configuration's Java Build Path > Source tab, we use the "symlink" functionality under Advanced to map the Default Output Directory (e.g. project/target/classes) to a class folder (e.g. C:/product/jboss/shared/lib/classFolder). This modifies the .project file, which is checked into source control.
We build the project normally with a m2e launcher (e.g. clean install).
Assuming the Maven build is successful, we run an Eclipse project build. This pushes the class files to C:/product/jboss/shared/lib/classFolder:
We restart JBoss. Since classFolders take precedence over jars, JBoss will load the classes in C:/product/jboss/shared/lib/classFolder, which are identical to the classes in our Eclipse workspace.
We attach to JBoss and debug the project as a remote java application.
Pros:
We're able to push our new classes to JBoss and test them without backing up the original jars and copy/pasting the new ones by hand (jar hell).
Cons:
We're compiling twice -- once with the maven-compiler-plugin, and
once with an Eclipse project build (Java Builder).
The symlink functionality is hit or miss in my experience. Sometimes we need to
do the refresh project/close project/build project dance to get it to
work.
Is there a better way to do this? I cannot force them to restructure the project so heavily that all deployables are container-agnostic WARs, but our developers need to be able to make changes and quickly test them without manually copy/pasting .jars.
How old is old?
Have you looked at the Cargo plugin?
http://cargo.codehaus.org/Quick+start
It can deploy to JBoss 3.x.
It has a Java API so you should be able to write something to extend it to do what you want.
Why are you trying to deploying classes instead of jar files?
You can still remote debug via Eclipse with jar files.
Worst case scenario - use Ant.
Maven is not designed for this kind of stuff, trying to force it to work will just cause you pain.
Once you have got Maven generated the right artifacts, work out what you would do manually and then script it via Ant.
I would try looking at the maven-dependency-plugin which has the possibility of copying artifacts to different location.
Please check your Deployment Assembly (project -> properties -> Deployment Assembly) and verify if your maven libs are there.

Eclipse debug-time classpath problem: How do you include a dependent project's output into a web project's runtime classpath?

So I started with a web services project (just a dynamic web project) that builds and debugs correctly from eclipse. We've pulled a chunk of common code out that we want to put into a shared library so now those classes are going into a separate jar project that the web project references.
On the web project, I did Project->Properties->Java Build Path->Projects->Add and added the jar project. And this correctly solved all the compile-time classpath problems and everything builds fine. But at runtime, when the tomcat server fires up, spring attempts to inject some of the classes contained in the jar file and I get a NoClassDefFoundError.
My .class and properties files and the contents of my META-INF directory are showing up in the ./build directory, but my WEB-INF/lib directory seems to be referenced in-place, and the jar dependency doesn't get copied in to it to show up as part of the Web App Library.
What is the magical incantation to tell eclipse that the other jar project needs to be available to tomcat at runtime? From our ant build script, we first just build the other project into WEB-INF/lib and everything works fine, but not for eclipse debugging.
I figured this out after spending some time on it. If you are in Eclipse Helios , go to properties > deployment assembly > add > project and select the dependent project you wish to add.
Java EE module dependencies would solve this problem.
You have already done the task of extracting your common classes into its own project, possibly because other projects depend on these classes. Either way, you'll have to ensure that this is a Utility project (appears under Java EE in the project wizards), and not just a plain Java project.
One that is done, you can proceed to add the Utility project to your build path (compile-time path) as you have figured out.
The additional (final) step is to establish a Java EE module dependency between your Dynamic Web project and the shared library, which causes the utility's classes to be placed in WEB-INF\lib during deployment, and even during export of the WAR. To do so, visit the dynamic web project's properties, and browse to the Java EE module dependencies. Ensure that your utility project is selected here. Redeploy/publish your application and you should be good to go.

Categories

Resources