(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.
Related
I can't find any info on how to call a different java file from a different folder anywhere.
Heres a diagram of what I wanna do
So for example
If the java file was in the same folder you would do:
HUD.HEALTH
but what would you do if the java file was in a different folder.
In Java you normally work in one folder, the so-called source folder. In this folder the classes can be divided into packages, usually using a certain pattern, for example com.company.something. In this case, a class is applied via import. The keyword import and the package name in which the class is located are specified. If they are external resources, the classes are included as external resources (.jar files), nowadays build tools like gradle and maven are used for this. Once the dependencies are imported, they can be used as well.
If you have two local projects, and want to access a class from project B in project A, for example, you work with the IDE. In Eclipse I would simply go to ProjectB's Build Path settings and add ProjectA. I recommend Intellij as IDE, there you solve it as follows:
Steps in IDEA ( You won't need these below steps if you follow below mentioned best practices):
Right click on project and select open module settings
Go to dependencies tab
click plus sign and add the module you want to use.
Best practices:
Never use project class in another project, always create a nice interface and use that interface in other projects.
If possible use Dependency Injection to manage different projects and their dependencies (this internally uses interfaces to do this).
Use build tools like Gradle and Maven to manage build process.
I tried my best to get a multi-module Maven project synced with GitHub using EGit, but I've failed.
The structure of the project is like this:
parent (pom)
child-one (jar)
child-two (jar)
I tried this simple approach:
Completely blank copy of Eclipse JDT and an empty workspace
Create a new GitHub repository and initialize it with a README.md file
Clone that repository to Eclipse
Create the parent (pom) project
Create two children (jar) projects, add simple main classes, everything works at this point
Now comes the tricky part. Do I share just my parent project? Or children as well? Well, it seemed logical to me to share the parent only. However when I did, my build path went completely crazy and Eclipse could no longer find main classes. Then I restarted Eclipse. Issues persisted. Then I "disconnected" the project with the repository and logically EGit randomly deleted one of the children on the file system, and made the Eclipse project completely unusable (no classes would display, all structure was gone).
I previosly had an episode where EGit randomly deleted one of my repositories and that time it wasn't just a test, it was my actual latest changes to the codebase.
Is this plugging completely bugged out or am I missing something?
(I followed the basic tutorial on setting it all up, and have my SSH keys configured properly.)
What should I do to properly push a local Maven multi-module project to GitHub, and be able to clone it on a completely different PC out of nothing?
Actually it's 100% possible to do this!
Here's an even simpler approach than before:
Clone your repository
When creating a new Maven project, don't place it in the default Workspace location, place it in the *subdirectory** of the repository
Done! You can create as many sub-modules as you'd like, Eclipse has automatically detected your Git repository.
* the subdirectory is automatically created for you when you choose the default location, and it is named after your module. It's not automatically created when choosing a different location (which is a bit inconsistent, but makes sense). If you just choose your repo as your location, Eclipse/Maven will then generate all the top-level project files and directories (pom.xml, .project, src/, .settings, ...) in your repo's root directory - which might be what you wanted, but most likely isn't.
For a more complicated explanation of why it wasn't working, read on...
It's just a bit complicated and very unintuitive. Here's a picture of how it looks:
Steps I took (make sure to backup anything important):
Create a new repository on GitHub (with README)
Install Eclipse JDT (the "Java" download, with Maven and Egit preinstalled, but it would work in any Eclipse version I presume)
Clone the repository in Eclipse. At this time, there are no projects to import or anything, there's just the repository. To clone, go to Window -> Open perspective -> Other -> Git Repository Exploring
Create your projects in Eclipse using Maven. I first created one child and one parent. The parent has to have packaging type of pom. The child can have it as a jar and has to be a Maven module, not a project (but it's essentially the same thing). At this point I created a simple main class in this child module, and saved everything
Share your parent project to the repository you cloned before (right click on parent -> Team -> Share project -> Git -> select your repository). Now, things will start falling apart, but this is normal. Wait for Eclipse to finish. What happened is that Eclipse moved the project from the place you saved it previously (for me it was my workspace) to the git repository - and since the parent has the children inside it, it also moved the children repositories with it. However, it didn't update its definitions accordingly, so the child project is now just shown as an empty directory. You can commit now
Delete the missing child project (not the parent!)
Just import the projects again
Sadly, Eclipse does not really support what you are trying to achieve because it assumes the project hierarchy is single-level; while in your case the parent project contains the child projects as well. For details see this long bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 (at the end there are some nice summary comment about the status).
As workaround I can suggest two things:
Do not import your parent project into Eclipse.
Put your parent project as a simple project in the hierarchy, where child projects are referenced with hierarchic paths
The projects I am involved in mostly follow the second approach (see e.g. the EMF-IncQuery project, where the parent is stored in releng/org.eclipse.incquery.parent in http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/), but if your parent pom rarely changes, the first option could work well as well.
Note that all the trouble and distress discussed here is specific to using the 'sharing' features of Eclipse in which the code is directly checked in and out of the workspace from source control. You don't have to use those features -- all of this works perfectly, with no magic and no stress, if you do not.
If you do a plain old git (or svn (or whatever)) checkout outside your workspace, and then use Eclipse's feature of opening an existing project leaving its source outside the workspace, everything will be fine. You will still have VCS operations in the resource tree, you can still commit or merge from inside Eclipse if you like, and your multi-module-Maven project will simply work with no special incantations.
I have the following projects setup in Eclipse Indigo SR1:
Normal Java project (A) which includes package (P)
Plug-in project (B) which has a copy of the JAR that is exported from A and it then exports package P
Multiple other Plug-in projects (C...Z) which imports package P
What I want to do is get rid of the manual export and copy of the JAR from project A into project B. I do not want to convert this project to a plug-in project because the same project is used in a legacy application that does not use OSGi.
This is particularly annoying since when I update the JAR eclipse does not pickup the modified class files and all my breakpoints in there go crazy (a separate issue).
I thought I would be able to edit the project properties for B so that A was a "Required project" (Proeprties -> Java Build Path -> Projects), and since that essentially includes the source (at least I guess that is what the entry in .classpath is doing ) I figured I could then export package P from project B. However when I do this, eclipse just complains that plug-in project B does not contain package P.
I figured I could just link the source folders from A into B but that's not really what I want to do.
If a referenced project A is on the classpath then surely the plug-in project A should be able to export those packages, or am I wrong in this assumption?
What is the best way to achieve what I want?
Cheers,
Jason.
you should consider using maven as your build tool. the tool was built to automate exactly things you've described. Maven
You should convert your java project into a plugin project (an OSGi bundle) in this case. You can still use it both as a regular jar and as a plugin. When you convert it, make sure it creates the MANIFEST.MF. Just don't create an activator as that would require a dependency on org.eclipse.osgi, and don't add any other require-bundle dependencies.
An OSGi bundle is really just a jar (which is fine) with an OSGi MANIFEST.MF that provides information like what packages are exported, any dependencies, etc.
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.
Hello I am new to Eclipse (and I am a novice in Java): I am creating a project which should make use of some classes from another project. Do I have to export necessarily this last project as JAR file and add in my project? Are there other alternatives?
There are several alternatives:
If project A depends on project B, and both projects are in the same Eclipse workspace, you can just project B to project A's build path (project properties / build path / project). This has the nice advantage that it will (optionally) automatically pull in project B's JARs, plus updates to B will be used automatically by A, and you can debug into B's code (even using hot code replace).
If A and B are fairly separate, just make B into a JAR (or several ones), then add these to A's build path.
If you have the source of those class files you can just link that source
Or add the other project as a dependent project.
Or create a jar of those classes and add that in lib.