I want to keep the copy of my eclipse and spring tool suite in a shared path so that anybody can run the application logged in from their machine and use the common workspace settings.
However, except me when anyone else tries to run eclipse/STS they are getting the below error. I thought it is because of the .eclipse settings file is loaded from the C:/users/user-id/.eclipse. Apart from this the JDK, JRE etc.. are also configured in the shared path.
So even after relocating this settings file also to the shared path, I am facing the same error. Can some one help me to fix this?
below is the configuration folder
Well, first of all, I don't recommend you do this. You're better off sharing code in a central git repository than doing it this way.
However, the following SO thread talks about this: Change location where eclipse create .eclipse, .p2, and other folders .
Related
I deployed an Eclipse product and it works great in my computer, in order to everybody in my network could use it I left it in a shared directory, at first nobody but me could run it then I noticed that in the application.ini file there are some arguments that are pointing to libraries that are in my computer, I fixed it copying these libraries at the root folder of the aplication and changing this arguments in the file and it worked but with errors, those error are because the config.ini file has the variable osgi.framework pointing to the eclipse directory that I have in my computer then again I tried to copy these libraries to the application's root folder but it can't launch the application because it is not reading that osgi.framework variable.
Currently is something like this:
osgi.framework=file\:/D\:/personal/Apps/eclipse-jee-mars-M2-win32/eclipse/configuration/org.eclipse.osgi/312/data/1012924256/plugins/org.eclipse.osgi_3.10.100.v20140909-1314.jar
I tried to change it after I moved those libraries to the application folder to something like:
osgi.framework=file\:/\\shareddirectory\/application/plugins/org.eclipse.osgi_3.10.100.v20140909-1314.jar
But it doesn't work.
There is a correct way to make an eclipse product usable from shared directory or a least making portable? there is totally another way to do this?
Thanks
Try putting #user.home in your products .ini file.
Something like:
-configuration
#user.home/<datadir>/config
-data
#user.home/<datadir>/workspace
Check out the Eclipse multi-user installs manual page. It might have solutions to your problem.
I am using GeneXus Evolution 2 for my project. While I was developing, I got the following error:
HTTPステータス 500 -java.lang.NoSuchMethodError:com.genexus.ModelContext.server2webcli(Ljava/util/Date;)Ljava/util/Date;
I don't know what it is and how to solve this. Any ideas?
A NoSuchMethodError usually indicates that a method (declaration) was there when you compiled the code, but the implementation is missing when you're running it. In most cases, the reason for this is that you had one version of the respective library's JAR file on your class path when compiling, and another, incompatible one when running.
A more detailed answer would require a more detailed question...;-)
Supposing you're using Tomcat as servlet container, look at {Tomcat_Home}/webapps/MyApp/WEB-INF/lib, where MyApp is your app name. There will be a gxclassR.jar file that should match with the version of your Genexus installation. To test if you have the right one:
Assure that there is not other similar lib, like gxclassD.jar, in the same folder. If there is, delete it.
Go to the environment target folder where you're working (from the Genexus DE Menu "Tools -> Explore Target Environment Directory") and look for the gxclassR.zip file. Copy to the WEB-INF/lib folder, rename it to gxclassR.jar replacing actual gxclassR.zip file.
Restart tomcat application to assure that the new gxclassR.jar is being used.
If your object keep failing, then the problem may be the .class associated to your genexus object. Maybe isn't correctly generated/compiled. So, to fix this:
Force the building of the genexus object. For this, try the Build with this only option associated to the object. Activate the Force option for this action, accessing to "Tools -> Options -> Build -> Build with this Only"
Once forced the build, go once again to the environment target folder and look for the .class file/s associated to the object. Usually the name of the file/s matches the name of the object. Look the modification date and confirm that is recently.
Copy this .class files to WEB-INF\classes folder inside your webapp folder.
I think this is good enough info to fix your problem. If not, detail your error a little bit more.
It may also be that the method you are calling does not exist, or exists with different parameters, either by quantity or by type.
Check the date and size of the file gxclassR.zip that is on your web folder inside your KB (Tools -> Explore Target Environment Directory), and compare it with the one used by your web application (folder WEB-INF/lib). If they don't match, replace the one in your web application with the one in your KB.
If you are unsure about it, and would rather GX handle it, delete all the .ver files in your web folder and force a build. That should synchronize all the files to the proper version.
I am using Tomcat 6.x and Eclipse J2EE Kepler. For reasons mentioned in my other question, I sometimes need to delete the Tomcat from the Servers list and re-add it.
The weird thing is: after I re-add the server, two configuration files server.xml and context.xml revert to a previous state! let's call it S. I cannot really tell what S is - it definitely is a state I once had, but it lacks some newer changes. For this reason my webapp does not work and I have to revert these two files in the workspace/Servers folder.
I'd love to fix this by updating S. However, I am unable to find the source of S, where Eclipse takes it from - I tried fulltext-searching my computer for files that look like the server.xml and context.xml, but to no avail. Specifically, I updated these two files in the conf/ folder of my Tomcat installation, but it did not help.
Where could Eclipse be keeping S? In some weird DB in the workspace metadata? Could it be using the local history?...
Thanks for any insights!
If you are working on Eclipse then there should be a folder called Servers in your workspace. When you start your server for the first time, it copies over the tomcat conf files into this eclipse project. So no matter if you change your actual context.xml from outside, eclipse will override it with what is stored in the 'Servers' folder.
If you still need the eclipse to take control of your tomcat installation directory, you need to primarily update this file from within the eclipse.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I noticed that "sometimes" the resources i put into a source folder in my Eclipse project will not be copied to the output folder ("bin") immediately.
E.g. i change a properties file using the eclipse editor and save... and "bin" still has the old version.
Does anyone know what exactly triggers the copying (and how i can trigger that from a plugin)?
I thought it happened automatically when a resource changes.
-- EDIT --
To clarify what i meant by triggering it from a plugin: I have a plugin that depends on up to date resources in the output folder, but apparently the resources are outdated when my plugin is called. And that's why i need to better understand what happens and how i can force it when i need to.
If you don't add the resource through eclipse (but for instance through the windows explorer), eclipse wont notice some changes until you refresh your project/folder. (right click in the packater explorer for instance).
After it notices the change it will copy it to the output folder when you build (often this is done automatically upon changes)
This is a Bug in almost all Eclipse versions, it happens without any reason. My eclipse 3.5.2 and 3.6.2 both meet this problem in someday. In my case, I need to copy modified .clj clojure source files to classes directory for immediate effection in a web app, now I have to set /src before /classes in CLASSPATH of web appserver startup script, It's solve my problem temporarily.
As #Thirler said, if you don't add the resource through Eclipse, it may not notice the files until you refresh your project. However, if the Refresh/Clean doesn't work (in my case, it didn't), you have to add the files to the folder structure IN ECLIPSE.
Just drag the file from the folder where it is in the file system using Finder/Windows Explorer, drop it into the same folder in Eclipse's Project Explorer (Eclipse will ask for overwriting, just say yes) and Voila!
EDIT:
An easier way is to just navigate into the folder using Project Explorer and then Refresh (F5).
As far as I know it happens when you build the project. You don't need a plug-in, you just need to tell eclipse to do a build of the project.
There is an Eclipse setting Java > Compiler > Building > Output folder > Filtered resources.
For unknown reasons, this was set to *.launch,*.testsuite,*.deploy,*.location,*.execution,*.datapool,*.artifact,*.html,*.svg in my workspace (while the default seems to be just *.launch). This was the reason, why my Eclipse constantly refused to copy a classpath resource index.html.
Late response, but I just stumbled over this question but non of the answers helped me to convince Eclipse to do its job.
This happened to me when I imported an Eclipse project as a whole, including both src and bin directories. The fix is to Clean the project: Project -> Clean... -> select your project and press Clean. This should re-build the project and properly locate the resources needed.