I have 3 C projects (prj_1, prj_2 and prj_3) in my workspace. prj_3 is referenced by prj_2 and prj_2 is referenced by prj_1.
For each project I have 4 build configurations as x86_win_debug, x86_win_release, x86_linux_debug and x86_linux_release.
The problem arises when I want to change the build configuration of prj_1 from one to another. I have to change the build configuration of the sub-projects (referenced projects) one by one manually. Is there any way to automate this process without using my own makefile? i.e. I change the build configuration of prj_1 to x86_win_debug and I want all the sub-projects be compiled with x86_win_debug configuration even if their last configurations are different then x86_win_debug. Is that possible?
This is possible with the "Project References" settings in the "Paths and Symbols" page of your project's properties. See also the related Eclipse help entry.
I have just tested this by deleting the associated build folder from the referenced project and building the dependent project.
Related
What is the best way to share project specific settings between multiple Eclipse projects?
I'm working with an application that is divided into several Eclipse projects. All of the Eclipse projects should use the same compiler settings. I could duplicate the settings in all the projects, but I'm looking for a way to avoid that.
The relevant settings are the ones that are saved in <PROJECT_LOC>/.settings, most importantly org.eclipse.jdt.core.prefs but also for example org.eclipse.jdt.ui.prefs. They are the ones that are set in Project Properties > Java Compiler, Java Code Style (and a few more places).
The solution must be version control friendly.
One possible solution use a linked resource, from org.eclipse.jdt.core.prefs or .settings of the projects to the same file, located in one of the projects. A similar solutions is to use soft file system links. I don't really like these solutions, it seems to me that they are hard to maintain, for example if the name of a project is changed.
I found this question which is different because it asks about sharing settings between developers, not between projects. (I must do both.)
How to share Eclipse project preferences between users?
I think it depends on how frequently you expect projects settings to change.
If not frequently, you shouldn't over-engineer your solution: just configure one project and copy settings to other projects, put everything under version control and you're done, except for having to perform this operation again every other year, or so.
If frequently, and if a lot of settings are involved, and if all (most) workspace projects should indeed use the same settings, then consider creating your own Oomph setup, that would include your settings as workspace settings. Then let all projects just use the workspace settings. (Of course a few projects could still deviate and use their own project settings, but once using project specific settings, changes to workspace settings will have no effect on that project).
BTW: Oomph includes capabilities to also specify once and for all: selection of plug-ins to install plus how to populate a workspace with projects from version control, and more. So I can only recommend this tool if you are really concerned about systematic configuration of working environments: create one setup - apply it automatically hundreds of times. And no, I'm not an author of Oomph, just a happy user.
Sharing your workspace setup using Project Sets
Your workspace setup may consist of several projects from one or more repositories. Once you have setup your workspace, you can share it with others by exporting a Team Project Set. A project set is a text file that contains a pointer to each of the projects contained in the project set.When a project set is imported, these pointers are used to fetch the projects from the repository.
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm
A long time afterwards I got an idea about how to solve this:
Set up a multi-module Maven project.
Configure the settings in the parent pom file.
Import the projects into Eclipse as Maven projects.
Disclaimer: I haven't actually tested this, so I don't know how well it's working...
I have two maven projects imported into Eclipse in the same workspace. Both have a class with the same name and package, but different implementations and in different locations in each project. Let's call this class com.namespace.Factory
Project A has Factory under its test folder, i.e: /src/test/java/com/namespace/Factory.java
Project B has Factory under its main source folder, i.e: /src/main/java/com/namespace/Factory.java
There is also a Project C which is dependent on both. Project C also uses Factory from Project B for some of its unit tests. Problem now is Eclipse can't compile Project C because it can't differentiate between the two Factory classes. If I build all projects in command line, they don't have issues.
You would think that Eclipse would ignore the Project A Factory class since it is in test.
I am using the m2e plugin. My current work around is to setup m2e to not resolve Project C's dependencies within the workspace. This forces it to download the jar that will not have test in it. However, this means I have a change in either A or B, I have to manually install A or B push the latest jar to the local repo, and update Project C's dependencies to pull down the latest jars.
Is there a way to exclude the Project A test folder from the build path in Project C so that I can continue resolving everything within the workspace? It feels like Eclipse is breaking something that is fundamental to maven projects.
I think you're just another user affected by the upstream bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=376616
To sum it up, the bug report discussion includes:
JDT implements just one buildpath per Eclipse project. This is very unlikely to change, since this was fundamental design choice and many APIs and implementation details rely on that.
Well, but that doesn't really answer your question I guess.
So I see multiple options here, depending on how much influence you might have on the projects:
either try to rename one of the classes => names would be unique
or if the classes contain basically the same functionality, play with dependencies between projects, or even create new one, that the other 2 would depend upon
that's pretty much what comes to my mind right now
Perhaps you can try this:
In project A's Properties dialog (get there by right clicking the project and then click Properties),
click Deployment Assembly on the left.
Eclipse will show all source folders.
Select the test folder (/test) and click Remove.
This issue is a variation on the one described here: Eclipse buildpath automatically taking all JARs of a internal directory
But instead of any local folder, I'd rather have a linked folder from another project be picked up automatically in the buildpath.
Basically, I have a main project in my workspace that holds directories lib, ext-lib that contain multiple jar files each. These jar files may be upgraded/removed or new ones added every few days.
I also have many other projects in the workspace that relay on the exact same (up-to-date) jars from my main project.
My goal is that as I modify the jars in these two folders in my main project, to have them as linked folders in all other projects and have those linked projects dynamically picked up as part of the buildpath of all those projects.
Any suggestion on how to do that in eclipse would be highly appreciated.
Unfortunately, the "dynamic directory" plugins people mention can not work with "linked" folders :(
Sincerely,
Guy
I would suggest creating a USER LIBRARY in eclipse and then using that in all of your eclipse projects.
Try going into preferences Java -> Build Path -> User Libraries and creating a new user library with all your jars. Then use this everywhere you need these jars.
See this page for more details.
Also, this page explains creating a user library in a bit more detail. There is also a use-case there which seems a bit more aligned to what you had in mind:
6.2.1. Linked Library Project
A useful hybrid strategy is to configure a user library that is also available as a linked folder in your Eclipse workspace. Follow these steps:
1.
Create a simple project in your workspace. Unlike Java projects, a simple project has no Java build path configuration in its properties. Use the command File > New > Project > Simple Project.
2.
Uncheck the option to use a default project location within the workspace folder and enter the path for your \eclipse-contrib\libraries folder (see Figure 6-8).
creating a parent project with only a pom.xml, and lots of sub projects such as:
my-web
my-core
my-backoffice
etc. is easy, and the sonotype eclipse plugin does most of the work.
However, getting one project to know about the source in the other project seems to be hard. E.g. when you are debugging the my-web project, and step into my-core, eclipse doesnt know where to get the source.
Looking in the Java Build Path in eclipse, the maven plugin has added my-core as a folder under "Web App Libraries". I.e. its not using the my-core-0.0.1.SNAPSHOT.jar or similar, its using the raw java files. Great!
But how to tell maven to tell eclipse to look for the source in the same place?
Im not really sure where to start. Im guessing its possible to get maven to put the source in a special jar using the maven-soure-plugin, but this will usually be out of sync with the actual java files which the web project seems to be using directly.
A quick and dirty solution is to manually Edit the Java Build Path for each project, and add my-core and other dependant projects in the "Projects" tab. Is this best practice? Any other suggestions?
A quick and dirty solution is to
manually Edit the Java Build Path for
each project, and add my-core and
other dependant projects in the
"Projects" tab.
If this doesn't happen automatically you have a configuration problem.
My Guess would be that you have a version mismatch between the pom dependencies and the actual project versions. Or your projects have an unusual name template (m2eclipse resolves projects by their artifactId AFAIK)
Either way, what always helps is in your Debug configuration (Run > Debug Configurations ...) select the Source tab and just Add... the selected projects.
I have an Xcode app project with available configurations "Foo", "Bar", and "Baz". This project is dependent on a static library with configurations "Debug" and "Release".
Xcode4 is building products from the app project into a "Foo-iphoneos" directory, and products from the library project into a "Release-iphoneos" directory.
What is the best practice for having these two projects share the same build products directory?
You can add the following path to library search paths for any non-standard configuration:
"$(BUILT_PRODUCTS_DIR)/../Release-$(PLATFORM_NAME)"
This works for me with xcode 4.6. I'm not sure if there is a way to control which configuration will get built for the dependent sibling projects, but for my purposes Release was what I wanted.
One solution is that if your dependent projects have the same configuration names as the main project (i.e. Foo, Bar, Baz), then Xcode will match them up and build using the same configuration.
So, if you wanted a debug build instead of a release build, you could duplicate the Debug configuration and call it Foo. If you do not really need both, you could rename the configuration instead of duplicating it, but with example names like Foo, I am not sure what would make sense for your situation.
However, the title mentions Xcode 4. The technique described above is what I used to do in Xcode 3; I haven't figured out how to manage these configurations yet in Xcode 4. I'm trying to figure that out now.
Update: To manage configurations in Xcode 4, you can click on the name of your project or dependent project towards the top of the project navigator (where all your files/folders are listed on the left side). In the main window, select Info (the other tab is Build Settings). You will then see the Configuration section where you can add/delete/rename your configurations.
I have found that if your target and dependencies' configurations don't match then the dependencies will be built with the Release configuration.
I couldn't find a way to customize that.