I heavily use the Eclipse organize imports function but a major annoyance for me is its tendency to add some incredibly niche type from a dependency with the same name as a class from the JRE.
For example, when I declare Map map; and run "organize imports", Eclipse may add import net.some.dependency.of.my.dependency.i.never.use.Map instead of import java.util.Map and then valuable time is lost as I figure out why map.entrySet() does not work anymore.
Is there some way of imposing a priority system on imports? For example:
JRE classes
My own classes
my dependencies
dependencies of my dependencies (and so on for 5.,6., ...)
I use Eclipse Neon 4.6.0M7.
P.S.: My dependencies are managed with Maven 3.3.9, in case that makes a difference.
I don't know about support for priorities, but you could simply say you are not interested in some types or packages in the preference page Java / Appearance / Type filters. Types here are not shown in content assist.
E.g. I never develop in AWT or Swing, so I turn them off for the content assist as can be seen in the screenshot
I would take a close look at the Eclipse .classpath file in the project folder. If classpath entries are ordered in some way, maybe this ordering is also controllable in the IDE option dialogs.
See What's in an Eclipse .classpath/.project file?
Related
I have a code base scattered across tens of repositories.
I want to standardize names of packages and classes, but it's too tedious to do it by hand in IDE, since I need a dictionary based renaming across repositories.
Is there a way programmatically rename classes and packages across many repositories?
A similar thing for a different language: https://metacpan.org/pod/App::EditorTools
Eclipse, and just about every other major IDE, can do this rather trivially. Load the project into the IDE (most can read the project if it is built by maven or gradle, just by saying you want to 'import an existing maven java project' or some such, possibly after installation a maven and/or gradle plugin - if it's not a project built by such tools, then just import an existing java project and tell eclipse about where the source files live).
Then, right click the package, pick refactor/rename, rename it, and eclipse (or intellij, or any other major java IDE) will rename the directory, update the package statement in every source file inside it, and will update all imports or any other reference, and will even search for strings that contain that exact name in case you're doing weird reflective shenanigans and tell you that those probably also need to be updated.
It's not quite programmatic, but this sounds like it'll be much easier and faster than actually using e.g. ecj or writing an eclipse app that will run without a user interface to apply these refactor scripts.
The problem is, that this package and its children are not seen in the list of packages of "import". When I import all pde packages, org.eclipse.pde.internal somehow becomes usable anyway. But I don't see its sources. How can I manage this package?
Here are some rules from the Eclipse community that might help:
Package names should match plug-in names. If they don't strip from the right. The code you seek should be in the plug-in org.eclipse.pde.internal (doesn't exist). Strip internal and you get an existing plug-in.
OSGi allows to hide packages in plug-in X from other plugins. This feature isn't really used. You can still import the classes but Eclipse don't show them in code completion and you will get warnings. There is an option for the OSGi/bundle classloader to throw NoClassDefFoundError but that option is usually disabled. You can find the exports list in the MANIFEST.MF of the plug-in that you try to import from.
Most of the non-exported packages are in below a package internal, so this is a hint: Don't use this code. It's not part of the official API. It can change in the next version of Eclipse or the plug-in and nobody will care if your code breaks (unlike with the official API).
Of course, the world isn't that simple. Which is why using internal code is frowned upon but the classloader option is disabled (= Eclipse could enforce this behavior but they don't).
If you think some internal API would be great to use, file a bug report at https://bugs.eclipse.org/bugs/
The problem was solved by my colleague.
org.eclipse.pde.internal is in org.eclipse.pde.ui.
Eclipse 3.7.2 simply haven't the PDE sources. Appropriate directories in repository are empty. I downshifted to 3.7.0 and it is OK now.
I inherited a Java project in the form of an Eclipse project. After changing the Tomcat configuration (from v6 to v7), Subclipse prompted me to commit the following files:
.classpath
org.eclipse.core.prefs
org.eclipse.common.project.facet.core.refs
org.eclipse.common.project.facet.core.xml
Will commiting them help my team members or will it mess with their workspace?
What is the best practice approach to this?
Generally speaking, you should check-in (and commit after changes) everything that does contribute to the build AND is not re-generateable by re-building completely AND is workstation-specific. (The implications of this statement depend on your build process/procedure, which is intended.)
This implies you should exclude everything that is re-generated upon full build etc. so it is not checked in (and not offered for check-in).
As a general rule, you should avoid committing files that contain user preferences, and project details that that Eclipse and/or your plugins can regenerate.
But in some cases things are a bit murky. For instance, the .classpath file can be the primary source of the Eclipse build path; e.g. if you have JAR files in your project tree rather than using Maven. (With Maven, the m2eclipse plugin generates the .classpath file from the dependency information in the POM file, and hence the file should not be checked in.)
Also, some of the facet stuff is borderline. For instance, in projects with JSPs and Javascripts, I have found it essential to change the facet properties to disable broken validators. And there's a good case for treating those changes as part of the project rather than as personal preferences.
Separation of group / project preferences from personal preferences is one area where (IMO) Eclipse is seriously deficient.
It is better not to commit those files as paths/settings may differ on different workstations.
You may wanna use some build tool to overcome this. (eg. Maven)
As if any of the team members are not using eclipse (using some other ide) , those files have no meaning for them.
If everyone commits different IDE settings, imagine what kind of mess it can cause.
EDIT:
More explanation;
I have worked in teams that people used NetBeans, Eclipse, IDEA...for a really long time and it is not really an option for them to change the IDE. It will only affect the productivity of that person.
When people get used to their IDEs they learn shorcuts, they know where to look for some functions (refactor/generate getter setter/implement override required methods....) so if you force them to use some other IDE it will just make things harder for them and slower for the overall process. IMHO and from my experience having a flexible codebase is always good. I am an eclipse guy and probably would not want to work with any other IDE as I know lots of shorcuts which makes thing real quicker/easier for me and those shorcuts are different on different IDEs.
All IDE files can be regenerated automatical by the IDE itself probably in just a couple of clicks.
And my current project has 3 developers, each using different IDEs eclipse(me), NetBeans, IDEA without any problems. I dont want to see IDEA or NetBeans config files which makes no sense for eclipse when I check out the source from repo. Likewise for them as well.
Yes, though do make sure that paths are relative in the workspace rather than absolute paths. Having these files in the workspace allows members of your team to work in the same environment as you are. It also makes setting up a new development environment much easier: you just check it out of source control and in Eclipse use 'Import... > Existing Projects into Workspace'
As #adamdunne mentioned, these files can contain environment specific paths. However it if you are careful to make sure paths are relative within your workspace, by using variables and by not importing external jars, i.e., by only including jars from projects in the workspace, then you should be okay. In my workspace we check in those files and have had a lot less issues setting up dev. environments since.
I work in a project where we commit the .classpath file since it is very useful that all developers use the same :) If you only use dependencies inside your workspace, this file uses relative paths and thus should be same on all machines. Even if this file might not be necessary to build (with ant e.g.) it´s very convenient to synchronize it.
In contrast the org.eclipse.core.prefs stores (afaik) project-specific, but personal preferences of developers which I would not check in.
With the facets I didn´t work yet in a real project, so I can´t tell. But in general, I think it depends on the information in the file and on the way you work.
If you are unsure, just try it. If you get conflicts in these files all day this is a hint you may not be on the perfect way.
These files can be very useful to share configurations between developers. The alternative is to either use Maven (which is a huge task for an established project) or to have constantly-outdated step-by-step instructions and new developers taking half a day until they can even build the project.
However, you should take care to ensure that these configurations are portable, i.e. contain no local paths. This can be done via the use of relative paths within the workspace, eclipse path variables and user libraries.
What we've done is ignore these files, as they may mess up the workspace of others on the project.
Ignoring them also makes your project cleaner, which I always like.
These files can contain environment specific paths so I would suggest not checking them in. On my current project we use ant scripts to create the project and do the initial checkout of all our code.
I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.
Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.
As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.
There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.
There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...
I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.
Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.
I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.
I have been working on Eclipse recently. I am fairly new to java programming, so this question might seem novice to some.
I have been working on projects which have references to many other projects. So, when I create the project in my eclipse environment, it shows errors on many places, as I believe it is not able to pick-up all the jars for all the referenced projects automatically. I found out that all those referenced-jars of referenced projects are on my box in a savant_repository. In fact, my projects gets build and runs fine from my command-line environment, but eclipse throws errors. So, here's the question, is there a way I can always make all the projects that I create in eclipse IDE, look for referenced jars in that repository?, or do I need to explicitly add all the referenced jars one by one, which would definitely be painful.
In addition you can also:
create a 'User Library' (Java/Build Path/User Libraries) with all your class files and add it to every project you need it
modify your the (Installed) JRE Settings (Java/Installed JRE) for your used JRE Environment. just press edit and add your jars.
personally i would recommend the usage of 'User Libraries' or the already suggestet solution via variables.
Within Preferences have a close look to 'Java > Build Path'. You can define Classpath Variables and User Variables so that they point to / include your standard libraries. You will still have to add them to your projects but at least it can ease the pain.