I use the google plugin for eclipse with GWT and Appengine libraries. Every so often I upgrade one of the libraries, which currently involves:
I install the update somewhere on my HD
I add the update as an alternative SDK in eclipse, with a generic name
I update the project settings to point to the new generic name
I commit the changed settings files (which do NOT include the upgraded library) to our source control
The problem here are in unfortunate steps 5-7:
5 Everyone else's builds stop working past the change,
6 I go from machine to machine, repeating steps 1 and 2, and
7 I think for the nth time, "I should really find a way to automate this."
I'm here for the elusive step 8: Actually automating this. I want to include the SDK in my source control, so when I switch between versions or set up shop on a new machine, the relevant SDKs are automatically installed and downloaded. I don't want to have to configure eclipse settings at all. In my ideal situation, I am willing to install Eclipse and the GPE on each machine, but after that I just want to clone my repository and go.
I've tried doing this by removing the GWT library from my build settings, copying the entire GWT installation folder into the root of my project, and adding gwt-user.jar and gwt-dev.jar to the build path from there. This almost works, but eclipse complains that it can't find gwt-servlet.jar (even though it exists precisely where it claims to be looking for it!). There also seem to be other magical settings I don't understand.
Finally, the question: If this is the right track, what settings do I need to manually control? If this is the wrong track, what's the right one?
+1 good question. This may or may not answer your question, but I can share with you what I do. I also work with GAE and GWT.
I just include the SDK .tar/.zip files in my repository, remove the version numbers from the filename, and update it when I want to move to a new version. If that version migration fails, I can easily revert to the old SDKs. I also use GXT and a bunch of other GWT extensions, so my problem is even worse than yours. I don't use eclipse for GAE nor GWT, so I can't relate to the problems you are having there. If you don't want to have to configure eclipse every time, then don't use eclipse.
Disclaimer: I hate eclipse.
Related
I am trying to get started with Eclipse SCADA and import the projects from their git repository.
I have cloned the following projects:
org.eclipse.scada.external
org.eclipse.scada.utils
org.eclipse.scada.base
org.eclipse.scada.protocols
org.eclipse.scada.core
org.eclipse.scada.releng
For each project I did mvn verify in the parent folder and imported the projects in Eclipse. I also changed target platform. However, I still seem to have problems with their dependencies.
Any help would really be appreciated.
Actually the Eclipse SCADA java projects are not developed with "Maven first". So you should disregard maven completely while in the IDE. The maven build is basically only used to build the project unattended.
The issue with the target platform is more complex. We were a bit sloppy in providing a always working target platform (and it is actually difficult to keep them up to date, since the versions of the bundles are fix).
I made a target platform file for the current version, you can find it here: https://gist.github.com/CptMauli/ec6eda37734f0108510f
To make it work properly please download a classic eclipse put it somewhere and create an environment variable ECLIPSE_432_HOME which points to it. Alternatively you can just change the first entry in the target file and point it directly to it.
The reason behind it is, if you would use your own eclipse installation, it is possible that bundles installed there conflict with bundles provided in the target platform or from your workspace. This is actually mostly not even a problem when compiling, but as soon as you start a client or a server, Eclipse will complain about duplicated bundles.
If you have any more questions please go to our mailing list: https://dev.eclipse.org/mailman/listinfo/scada-dev
or our google group: https://groups.google.com/forum/#!forum/openscada
or write to me directly at juergen dot rose at ibh-systems dot com
Is the file .settings/org.eclipse.jdt.core.prefs part of the project or is it part of my personal eclipse configuration?
Should I add it to version control?
Yes, you should. If this file is not under version control, then you cannot create reproducable builds of the same project, because it is no longer self contained, but depends on your specific Eclipse installation and its settings.
If you import this project into another workspace (on your or any other machine), it may behave completely different, as the compiler compliance settings, the compiler warnings configuration and a lot of other stuff is suddenly missing or different. Chances are high that such a project suddenly shows warnings/errors in the new workspace, while it was completely fine before.
Note: This all also requires that you actually configure all Java related settings in the Project properties. Never use the Java compiler settings under Window -> Preferences if you want to have self contained projects.
Just to give a concrete example: If you have configured your projects compiler compliance level to Java 6, because you are using Java 6 specific features (like Override annotations on interfaces), then the project will create a lot of compile errors on other peoples machines. This is because the default compiler compliance level in every Eclipse workspace is Java 1.5, and in Java 1.5 that Override annotation is simply not allowed.
This doesn't have anything to do with whether you are developing closed source or open source, as indicated in the other answer.
Contrary to #nitind's opinion, no. You should not put any IDE-specific settings under version control. Except you are developing IDE features or plugins.
In case you really have mandatory team-wide IDE settings, putting them under version control would be a good idea, but IMO having mandatory team-wide settings is not a good idea in itself.
For all other cases, shared IDE settings are bad for portable builds, even with the same IDE, and useless at best for users of other IDEs.
EDIT: I should differentiate, depending on the target group of your project. If you are developing a closed source product in a team that works with eclipse, then keeping these preferences under version control is helpful and a good idea. If you are developing a library, closed or open source, or an open source project, I consider ignoring the preferences more appropriate and polite.
EDIT2: I'm afraid #Bananenweizen is misunderstanding what I am trying to say.
I know that these settings are the eclipse compiler settings. They are still IDE-specific in the sense that they won't have any effect in Netbeans or IntelliJ as they won't have any impact on ant or maven builds from the command line.
Yes, leaving these setting out of version control can bring you many red wavy lines in eclipse on a different machine. It won't, if it's a maven project with a set source level by the way, I'm not sure about ant.
Eclipse is not building the projects by itself - it builds them with ant if it's an eclispe or an ant project, or with maven if it's a maven project. Both ant and maven have specific settings for the source version that do not depend on IDEs.
And this is where these settings ought to be - in the build file. And the build file should be under source control. The exceptions I mentioned earlier still apply.
EDIT 2020.03.15 #howlger informed me that the usability of these formerly eclipse-exclusive files has improved. They can be used in VSCode and maybe IntelliJ. This improves their chances of being useful across IDEs and may change your decision towards sharing them.
IMO, the files are mixing concerns. While I support source level and code formatting as being part of the build, I consider issue highlighting rules, save actions and similar concerns to be out-of-scope. If possible, I separate those, sharing the former by putting them into the build definition, but not the latter.
Here is the problem with putting it under version control....
If you import and open a project, Eclipse insists when IProject.open(...) is called on touching the file in the .settings folder... and this is before you can register the team provider on the IProject object. That means validateEdit won't fire and you get annoying errors whether you click "yes" or "no" on the popup asking "do you want to make it writeable?" That's all well and good for optimistic file-locking providers, but no so great for the "pessimistic" ones. For us this is just been yet another eclipse annoyance.
If it's up to me, there is no way I'd put these in source control.
The answer is "yes" and here you find the motivation for it and the proper way to do it: watch the talk "Committing IDE meta files: misconceptions, misunderstandings, and solutions." or look at the corresponding slides from EclipseCon Europe 2015 by Aurélien Pupier #apupier (Senior Software Engineer, Eclipse specialist).
I think it is quite normal to have more than one binary in a project. However, with Eclipse CDT I don't know how to set up the IDE to get things done.
I know I can create several projects - one per binary. And I know I can set the dependencies per project. However, I cannot regard them as one project in Eclipse. If I'd like to share the code with a version control system (like svn), each developer has to import the projects separately.
What I miss is something like the Solution (sln file) in Visual Studio. Should I create a single project and create the make files by myself?
I haven't tried it out yet, but there is this 'project set' which can be ex- and imported. Is this the solution? Can this be put into version control?
My goal it to put everything under version control, not only subprojects. I cannot imagine that CDT makes only sense for single-binary applications.
How can I work properly?
I am quite sure CDT doesn't support sub-projects, which leaves you pretty much with:
one workspace per "set of projects"
one project per binary (like you mention in your question)
project dependencies (like you mention in your question)
In term of version control, that means:
submodules (Git),
subrepos (Mercurial) or
external (SVN)
for each project needing a shared library project.
In short, that means putting under version control various components (set of files), with one referencing specific version of others (that list of specific versions of other components is called a "configuration", based on a component-based approach development)
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.
After searching around I see that eclipse 3.4/3.5 now allow you to use their 'dropin' folder to manually install plugins.
This works well in a situation where you have already downloaded the feature and plugin files, however in cases where you use the Software Updates feature to simply point to a URL and download a plugin, you don't appear to have control over what folder the plugin is installed into.
Is it possible to force plugins to be installed to an arbitrary dropin folder, or otherwise export a plugin to a location so that it can be shared with other people's eclipse installations?
I'd prefer not to have to comb through the plugin info and manually determine which plugin jars to copy into a dropin folder :P
Thanks
I think the answer in this thread and the mentioned blog post of Michael Scharf can be useful for you, although the procedure is not as simple as it should be :(
The new p2 system in 3.4 is supposed to have a feature called bundle pooling that allows for shared plugins. However, I haven't used it, so I'm not sure about the particulars. I hope this at least points you in the right direction.
When using 3.4.1 you can still enable the "old" update manager in Preferences/ General/ Capabilities. Then you can use the extension points again. But it has been removed in 3.4.2 completely.
You have to remove P2 to get the old update manager.
Note: The P2 team managed to broke everything backward compatible. This tricks does not work with 3.5.