java eclipse build path options question - java

I have a question on Eclipse (I am using Helios).
When a project depends on various libraries, we add them to the classpath via the Build Path Dialog.
In the same dialog though, there is a tab for Projects (Required Projects on the build path).
It is not clear to me, when someone would add such a reference from one project to another.
I mean, if projectA needs functionality from projectB, then we can make a jar out of projectB and use it in projectA.
But when, would we add then, a reference from projectA to projectB, in order to need projectB in the build path of projectA?
Could someone please give an example?
Thank you!

Well, there are two reasons for depending on a project.
You can "click through" to the source code of the other project when its code is invoked.
If you're building and running the application in Eclipse for dev purposes, changes in the code will instantly be picked up.
Update: I thought of a third one, possibly even better than the first two. There is an "Order and Export" tab in the same screen, where you can select which elements of a project's classpath are exported. And what "exported" means here is exactly that if project B is configured to have project A as a dependency, then it will automatically add all the exported libraries from project A to its own classpath. So if project A has a lot of thrid party libraries, you don't have to manually add them to project B's classpath.

"Required Projects" allow you to state dependencies between projects without the need to build a jar each time you make a change to the project you depend upon.

One (for me nice, for others; perhaps, blasphemous) use of the "Project Dependancy" is when you have a seperate project for unit tests. Make the unit test project depend on the to-be-tested project. Of course, this is only nice if you are not a maven or hudson or blah, blah, blah user (like me). Not that blah, blah, blah are bad things.

Related

How to resolve requirement: Import-Package:

The scope of this question applies after you have created an RCP app in eclipse following Vogella's tutorial linked below. This assumes your feature, product, and father project are created. In this state the feature is delegated the task of building, therefore all dependencies need to be resolved in the feature build.properties file.
This question addresses when the missing dependency needs to be installed, i.e. is downloaded manually because the missing dependency is not on the class path. The class path determines what plugins are available in the feature/included-plugins tab. The plugins listed in the feature/included tab can be added as plugins for dependencies to your plugin. This list gets appended to your feature.xml file which gets linked to your build.properties file! See Solution below.
Eclipse nomenclature interchanges the ideas of plugins=dependencies and treats them the same. We know this by the names of the tabs.
The intent of this question is aimed at using existing Eclipse capability to develop an RCP application that uses objects from a third party plugin to create a custom workflow.
This error is thrown because my RCP app third party plugin requires this dependency which was not included in Eclipse ICE nor the plugin itself.
The first thing I tried was to install the plugin directly from the Eclipse Marketplace.
The string org.apache.commons.beanutils returned nothing so I went to apache and downloaded the plugin manually.
I then researched how to install a plugin in Eclipse manually.
I've learned not to simply drop the plugin into the Eclipse/dropins folder, which does nothing.
I've learned that this advice is lacking probably due to age of post.
I've learned when Maven is configured correctly, all the dependencies can automatically be resolved.
https://www.eclipse.org/forums/index.php/t/813199/
This says plugin dependencies are resolved by looking at four files.
"The plug-in definition, the product file, the run configurations and the target definition."
The plug-in definition I'm not sure what that is other than the plugin.xml file. The product file has been configured to launch the third party plugin. I've learned the run-configuration has a list of plugins and the third party plugin is not listed there.
I've learned that the target definition should be created in the parent project of your product project.
Create a target definition by highlighting your father project->Right click-> new-> Other-> Target Definition. During creation select "Use workspace configuration." The path to your downloaded plugin was added to this Location.
After the Target is created, Navigate to the content tab and select Manage Using: Features
This reduces the number of possible dependencies to only the ones needed to run.
You should now see the dependency checked in the list.
Creating the target resolved the other twenty or so dependency errors but the one under the title still throws an error.
I've learned that the product file is the file that calls the third party plugin in runtime.
The RCP app launches, but I cannot import the third party plugin in the bound classes created using this tutorial, to be used to obtain objects programmatically.
http://www.vogella.com/tutorials/EclipseRCP/article.html
I have a shell of a program running and just need to implement the classes for each window with the objects I can get from a third party plugin import.
Thanks,
(Solution)
Thanks Brian for resetting my thinking which led me to learn about Eclipse a little more to figure this out.
The main problem is an external .jar is identified as the missing Import-Package. Mine was org.apache.commons.beanutils. You must go to the parent website and download the library. In this case apache's website. There is probably a better way to do this by repo. I'm hoping I can export the product with all the required dependencies :p
I may be able to skip a step or two here, but these were my working steps.
Get .jar into Eclipse parent project. Right click the parent and select New->Folder->Name it Lib->Finish. Right click Lib->Import->File System->Navigate to .jar. Highlight the included .jars->Right Click->Build Path->Add to the Build Path.
Add the missing .jar to your Ant class path. Ant is used to build PDE apps using OSGi. See the Eclipse Help for an explanation. This will allow your missing jar to become visable in the feature project included-plugins tab.
Window->Preferences->Ant->Runtime->ClassPath Tab->Add jar->Navigate to missing jar
Create a target definition as described above in your parent project and add your missing .jar to the target and set your target active.
If target exists, In Locations widget window->Click Add->Directory->Navigate to missing .jar.->Next-> Verify plugins are recognized in window->Finish. Click Set as Target Platform in upper right corner.
Open feature.xml in your feature child project. ->Click Add->Navigate to your added plugin->Click Ok
Save All - Launch product
Now onto the next dependency!
Sounds like you're confusing an Eclipse plugin with a jar dependency for your project. it sounds like your project needs a jar (the beanutils jar from Apache) . Depending on if your project uses Maven or ant (or something else) the way to add it to your project varies. Try googling something like "adding a jar in eclipse for a X build" where X is the tool used for your build (ant, maven, etc). No matter what you use, the end goal will be for that jar to show up the java Build path->Libraries for your project in Eclipse.
it seems to me that u need a better understanding of how dependencies are managed in OSGI/eclipse, therefore i concur with BrianPipa.
beware: that subject is quite large and not easy to understand and is way too large to be explained here. but be not afraid, google is ur friend:
a few pointers on research topics:
the relation ship of bundle/plugin and jars
how is code contained in a plugin exported (aka make visible) to other plugins so they can use it AND what needs to be done so that the using plugin (ie. declare that usage-dependency)?
how are feature related to plugins?
how are products related to plugins and features?
what is a target platform ?
and how do i define it and what does it need to include ?
how do i set it ?

How can I add a short path in the build path of Eclipse?

I have already a project in Eclipse, a old project. So everything is already set up, but i don't know how can i add a folder named third_party, which contains some specific jars.
My goal is not to change the librairies of a project, but just to add one thing to fix all my dependency's problems.
Best Regards
I think you can't; you have to add JARs manually - but normally the "Add jars" dialog should allow you to select multiple JARs in one shot.
But what you can do is: define a project, that only contains your JAR files in the build path; and export all of them. Then you can make this project (maybe called "libraries" a pre-req for your other projects).
In other words: have one project that "collects" and exports all JARs that you need; then use that project in your other projects.
You could create a new User Library and add it to your project. that should take care of your dependency problem. You are not changing any libraries, but just adding the ones you need for the updates to the dependency issues.

How to separate subproject classpaths in Eclipse?

I know that there is a Git plugin for Eclipse ("Egit"), but I like to do Git stuff on the command line, and I like to code in Eclipse, so I want to keep them separate.
I cloned a Git repo (I don't think its important, but for good measure, it was https://github.com/spinscale/dropwizard-jobs.git). I then opened up Eclipse (Juno) and created a new Java project, and selected the root of the cloned repo as the base path to my project. Eclipse asked me if I wanted to associate the project with the Java facet, and I clicked 'OK'.
This project has a large dependency tree (if you like, check out its 4 POM files). I don't use Maven to build (I use Gradle) so I just ran a script that resolves the dependencies of these POMs into a directory, and then I created a lib directory in this Eclipse project and copied all the JARs into it. I then added all these JARs to the project's classpath.
I am now seeing 10 errors in the Problems view in Eclipse, and they're all similar errors:
The type ApplicationStartTestJob is already defined ApplicationStartTestJob.java /dropwizard-jobs/dropwizard-jobs-core/src/test/java/de/spinscale/dropwizard/jobs line 10 Java Problem
The type ApplicationStartTestJob is already defined ApplicationStartTestJob.java /dropwizard-jobs/dropwizard-jobs-guice/src/test/java/de/spinscale/dropwizard/jobs line 10 Java Problem
8 more all like this, etc.
Sure enough, when I expand the entire project, I see it has the following structure:
dropwizard-jobs/
dropwizard-jobs-core/
src/test/java/
de.spinscale.dropwizard.jobs
ApplicationStartTestJob.java
dropwizard-jobs-guice
src/test/java/
de.spinscale.dropwizard.jobs
ApplicationStartTestJob.java
dropwizard-jobs-spring
src/test/java/
de.spinscale.dropwizard.jobs
ApplicationStartTestJob.java
So it seems that the maintainers of this project like to rename their unit tests with the exact same package/class names, and for some reason, Eclipse sees them as all belonging inside the same package. To test this I renamed dropwizard-jobs-core/src/main/java/de.spinscale.dropwizard.jobs.ApplicationStartTest to something else, and did the same for dropwizard-jobs-guice/src/main/java/de.spinscale.dropwizard.jobs.ApplicationStartTest and sure enough, all the errors associated with ApplicationStartTest being already defined went away.
So my suspicion is confirmed: The intention of these subfolders (dropwizard-jobs-core, dropwizard-jobs-guice and dropwizard-jobs-spring) is that they are sub-projects with separate classpaths. Eclipse thinks all of these source folders are part of the same project, and so it is lumping all of their classes into the same classpath. Since each subproject uses the same unit test naming conventions (same package/class names for each subproject), Eclipse see multiple classes in the same package as having the same name.
OK, good! I figured out the problem. But what's the solution? Ideally I would be able to keep all of these inside the same project, but perhaps modify the .classpath file or do something similar that instruct Eclipse to keep the subprojects separated from a classpath perspective. Any ideas?
SImply download eclipse m2e plugin, then import the project(considering you have already checked-out at your workstation), and do spend sometime learning MAVEN commands. here you can find an pverview of maven parent project and modules. Maven parent pom vs modules pom
One possible solution would be to introduce maven, which allows to naturally define a parent project and sub-projects in a multi-module maven project.
You can actually test that configuration outside of Eclipse, and then use M2Eclipse in order to import parent and its dependencies, at the same time (as commented in this answer) in your Eclipse.
Actually, the M2Eclipse project itself has guice test project, which you can use as model for your own guive subproject, in the repo sonatype/m2eclipse-guice, with an adequate pom.xml.

How do I manage git submodule subprojects in Eclipse?

(In case it matters, these are Java Android projects)
Project A is a library project.
Project B depends on A. For ease of project management across the board for other people instead of just me, A is contained within B via a git submodule.
This means, if I want to make changes to both A and B, I will have the following:
Project A itself
Project B
B's submodule of A, let's call it A'. Same code, same project name, different location on disk.
Ideally I would like to be able to meet the following conditions:
Be able to modify A itself directly within Eclipse.
Be able to modify B and have it build, referencing A', all within Eclipse.
I don't really need A' as an imported project / no need to modify it, but I'd like it to automatically build its jar file and have that be referenced by B.
What I've tried:
Simply importing both A and A': Doesn't work, because Eclipse cannot import two projects with the same name. I can't simply change the name either because it's a submodule; would have to do that every git update, unacceptable.
Adding External Library reference to A', keeping it out of Eclipse entirely: actually not too bad of a solution, but requires at least one external build of it from the command line (using ant) before it will work...not the most convenient.
Doing a Source Link: Not the cleanest because A (and subsequently A') have multiple source folders within them, so I'd have to update each time I add or remove source folders within A. I'd rather just use the jar directly.
Is there a way to keep this all in Eclipse, or should I do something like #2 but with an added external build command to call ant on A'?
I have a similar situation. Import B as existing (android) project into eclipse after you git clone it. Make sure project A is initialized and updated (via git).
Now, do file->import existing project (android if A is an Android project) and go to where the submodule A project is inside of your project B and add it.
Now you have two separate projects in eclipse. You can change both projects, and it will all be under Project B, because that is where both projects are located.
Since this is specifically for Android, have you looked into Android libraries?
In my case I have a free (B) and a paid for (C) version of my app. Both share a common code base (A).
In eclipse I make A an Android library and both B and C use this library and all 3 are separate git repos. With this setup, changes I make in A are automatically available in B and C and I only need to maintain one code base for each project. No fancy build scripts/configs.
I think this sort of simplicity is what you were after? Apologies if I have misunderstood the question.
I'm not sure if i got your setup right:
Project A : src
+ /projecta.jar (binary of project A)
Project B : /src
+ /lib/Project A/src as submodule
+ /lib/projecta.jar (binary of project A)
..now you change A-A' and compile it, wanting to test it before pushing/commiting, right?
is it ok for you to just have the jar in B, or do you need the source within project B updated to A'?
first case:
have an ant file compile in project A and deploy it to B as well
that ant file is not part of project a, its just a local workaround
(its useful to have it in the ant view of eclipse)
Sketch:
<property name="projectb.libdir" value="..."/> set appropriate place in project B
<javac fromdir="./src" todir="./build" ...><fileset ... /></javac>
<jar /> from build to projecta.jar
<copy /> projecta.jar to projectb.libdir
Alternative is to create a .jardesc in eclipse, so you can run "create jar" on rightclick.
is that what you wanted to do?
Eclipse Mars Milestone 5 (4.5.0M5) has Multiproject-support. You only need to import "Existing Project" from Subfolder.
Just use a project build system to track your dependencies (that is what they are good for).
I would you suggest to use gradle (preferable IMHO but check which one fits better on your context) or maven, both can handle subprojects pretty well and can generate the eclipse configuration for you.

Understanding External Jars in Eclipse

So I'm fairly new to Java and especially Eclipse, so please excuse my ignorance. I took a project from a server and copied it locally to my machine. When I opened the workspace, I had many errors due to it not being able to find the jars. This makes sense because I don't have the same dir structure as the server I copied from. So if I copy the same external jar's to my machine and get it to compile into a jar and copy it back to the server, will it work? Or will it fail because now the external jar's are in a different place than it is expecting?
Also, down the road should I put the external jars into regular jars to avoid this problem?
You should be OK. Java is using what is called classpath to locate dependencies. The classpath may be different on the development machines, but as long as all the dependencies are on the classpath in the production everything should work.
To avoid issues with the synchronisation of directory structures the most common way is to use Maven - it will manage all the dependencies for you (but you have to manage the pom.xml - the Maven's project descriptor). A little clumsier way is to have the dependencies in the project, however you may end up with many projects having to include same jars, and then there will be version conflicts and so on.
For small projects you can manage dependencies yourself, however larger projects will need a more thought through strategy (like Maven).
In regard to the executable jars, make sure the Class-Path entry in <jarfile>:\META-INF\MANIFEST.MF is correct, e.g. where it references other jars, those jars are going to be there in the production. For example, assume we have ourjar.jar and assume this is a snippet from its MANIFEST.MF:
Class-Path: lib/myteamjar.jar
It will then be expected that a following directory structure is in place:
lib/myteamjar.jar
ourjar.jar
No, the location of the external jars does not mater. What you want to do is put the external jars on your classpath. How you do it depends on how you are running your java code. If you are running it from the CLI using the java command, it takes the classpath as an argument. If you want your code to build/run in Eclipse, you need to right click on your project, select "Build Path" > "Configure Build Path..." Use the "Add JARs..." button to add jars that are part of a project you have open and "Add External JARs..." to add jars that reside outside of the project. See specific documentation for your tool for more details about classpaths.
I would not recommend Maven to somebody who is fairly new to Java and Eclipse. I would forget about Eclipse, too.
You have a packaging and CLASSPATH issue. Focus on that.
What kind of project are you talking about? The answer you get will depend on what type of app you're creating. Is it an executable JAR? Then the right way to do it is to package everything into a ZIP file that's laid out exactly as the CLASSPATH in the JAR manifest expects.
If it's a web app, the right thing is a WAR file, with all the JARs your app needs in the WEB-INF/lib directory.
If you package things properly, you should end up with a single package that has everything laid out the right way. You should be able to deploy it to the server and make it all work.

Categories