I'm developing a JavaEE system with several applications which consists of many projects (EARs, EJBs, etc).
Whenever I change my runtime target of the Enterprise Server I have to reconfigure each project through Eclipse's wizards, and this takes forever.
For now I use a little script which updates the runtime target manually, although it says here:
The target runtime environment is specified in the org.eclipse.wst.common.project.facet.core.xml file in the project's .settings folder. You should not edit this file manually; instead, use the properties window as described in this topic.
Why am I changing the runtime target name?
1. I've upgraded the runtime target.
2. Another member of my team co the code from the SVN and he has a different name for the target runtime.
Is there a way to configure the projects to run with a default runtime target, which can be easily configured?
Possible workaround for 2: remove the org.eclipse.wst.common.project.facet.core.xml from SVN and put its name in the svn:ignore property.
Related
This is my first time using SVN or for that matter any version control. So, I've been able to check out a selenium project on my local machine. This source code was working fine on the other machine(my friend's), but on my machine it throws hundreds of errors such as "BeforeClass cannot be resolved to a type, Assert cannot be resolved to a type" etc.
I do know that this error could be because the required selenium jars may not have been setup in the build path. But, I can see all these selenium jars in the "lib" folder.
So, I want to understand if I need to reconfigure the build path. By the way, don't the project settings etc come by default as the same code works perfectly on other machine, which means the build path must have been configured there.
I know its a very basic question, but I assure you that I'm a naive coder.
Thanks for your help.
Note: I'm using Eclipse IDE
Eclipse's project configuration files (eg, .project, .classpath, .settings, etc) are designed to be checked in with the rest of the project. If done so, whenever the project is checked out to a workspace Eclipse will automatically use them to properly configure the project. Check that your friend checked in those files; if not, ask him to.
It looks like you did not add Eclipse project metadata files(.project,.classpath) & .settings folder to your source control system, so Eclipse doesn't know what your build path is or whether it is even a java project.
Go back to your other computer and look for the following files in your original project root...
.project
.classpath
.settings/*
Make sure all are present in Source Control System.
I am developing an Eclipse Java project and would like to use "variables" to point to required libraries (.jar files).
Setup:
Machine 1: Eclipse Juno, OS X, own laptop, libs under /mylibs
Machine 2: Eclipse Juno, Linux, shared machine, libs under /sharedlibs/some/complex/path
Source control: Mercurial
Example of libs I use:
"${libs_base}/junit.jar"
"${libs_base}/guava.jar"
"${libs_base}/logging/slf4j.jar"
How can I configure the project Build Path to use the same "variable" for the base directory for libraries, pointing to different locations on different machines, but still check in my project description to source control so that when I add a new library, provided I specify its location relative to the libs base, it is found on both machines?
I have found the help file but could use an example, maybe even a screenshot please?
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fcpathvars.htm
for instance, do I copy this model:
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Fconcepts-exttools.htm
inside "Java > Build Path > Classpath Variables" or elsewhere?
I have done a fair bit of "blind trial and error" already.. like stitching forms like "${env:VAR}" in there..
Oh, and I suppose I should mention that I don't know how to set these Eclipse variables based on environment variables considering that my systems' environment variables are set by Bash's .profile and I doubt Eclipse runs a shell to source that before...
/org.eclipse.jdt.core/org.eclipse.jdt.core.classpathVariable.my_libraries=$MY_SYS_ENV_VAR_LIBS
Of course, I use "Configure Build Path > Libraries > Add Variable" and then Extend from there, but still... an example would be worth a 1000 words.. (could it be that defining an Eclipse variable from which to Extend actual .jar references for inclusion in Build Paths just can't be based on a system environment variable, full stop?!)
PS: please don't ask me to just symlink things around, I am not a sysadmin on the shared machine..
From what I understand, extending a path variable would work perfectly for your case as you can define different base paths for each machine and reference libraries on subpaths based on that path. However if you are looking specifically to use environment variables you can try adding them to the build path this way:
Edit your launch configuration.
Go to the Classpath tab.
Click on User Entries and click the Advanced button.
To add a library based on a system environment variable, select Add
Variable String, and in the box type:
${env_var:libs_base}/logging/slf4j.jar. In this case
libs_base is your environment variable and logging/slf4j.jar is
the path to the jar in the subdirectory.
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.
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product
I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html