Community
Participate
Working Groups
So far, I put all my JAR files separately in the project's "Java Build Path" and this worked. No I would like to use "Add Class Folder..." instead to become independent on the JAR file names. But it doesn't work: I removed all my custom *.jar references from the Java Build Path's "Libraries" and instead added the folder containing all these *.jar files via "Add Class Folder". No matter if i "refresh" , "clean" the project, restart Eclipse, ... the project now has many "ClassNotFound" errors (Problems view: "... cannot be resolved ..."). It seems all third party JARs are missing that exist in the lib/ directory that I reference. I got my project only back compiling when adding all the JARs again ...
btw: "Add External Class Folder..." also does not work.
Please note that a "class folder" is expected to contain .class files, not .jar files.
Bummer! So how can I setup a folder containing *.jar files?
(In reply to M H from comment #3) > Bummer! So how can I setup a folder containing *.jar files? Most projects having more than a couple of jar dependencies use a build tool like maven, gradle, PDE ..., which then provide all dependencies with just one container entry on the classpath. If you feel that a semi-manual approach (no build tool but bulk-handling of jars) is a relevant feature for Eclipse, we could discuss this as an enhancement request. If you plan to work on this (with a little help from us) such request would even have good chances to materialize, otherwise please don't hold your breath, as I don't expect that many people will need it.
I would find it a very basic feature for an IDE to support a directory of libraries to include instead of setting each single file for this - which also leads to problems if a new version of such a library has different files and or names of files if a new version is released. However, we use Apache IvyDE (Ivy) for depenedency management and I noticed that Eclipse (Apache IvyDE Plugin) supports this partly, e.g. Project > Java Build Path > Libraries > Ivy but has its own (refersh) problems (or does not include all JARs that are in Ivy.xml). We also have lots of ANT targets that we use for most "deployment packaging" and work flawlessly - including the Ivy related parts. So all non-Eclipse tasks we have in ANT targets work flawlessly - incl. Ivy. But the standard daily coding requires the Eclipse internal compiler to build automatically the code instead of double clicking the ANT target for each compile cycle. For this reason, it would be very helpful to be able to state a directory of JARs instead of adding each single JAR file.
So one user (out of how many millions?) thinks the valuable. I don't argue against, just question the size of the user base that thinks similarly. Two (non-exclusive) options moving forward: - Perhaps you could produce evidence that indeed a large number of users is affected by this - You contribute this feature - if you go this way, let's please first discuss the details, before investing real development efforts. FWIW, here's an old answer from a related thread on SO: https://stackoverflow.com/a/12266998/4611488 S.o. even announced a plugin providing this feature: https://stackoverflow.com/a/12267103/4611488 Maybe you should just help those folks to maintain that plugin, if it serves your purpose.
Too bad, you write such an answer. Years ago, when I started using Eclipse I already missed this feature and many others, too. It's like in our office: no one complains (officially) but everyone is angry about that not having a feature. If I had the time to work myself into Eclipse code, I would try to contribute, but from my last Eclipse reports I noticed that some "very easy" features are "very hard" to implement in Eclipse because of the suboptimal architecture. I learned about the "Add Library" function in the Java Build Path Libraries dialog which might make things easier. But you also have to add each custom JAR in this custom library anyway (when you create a "User Library"). So, can you at least cvhange this bug report to a "request for enhancement" report, please?
(In reply to M H from comment #7) > Too bad, you write such an answer. Years ago, when I started using Eclipse I > already missed this feature and many others, too. It's like in our office: > no one complains (officially) but everyone is angry about that not having a > feature. No offense implied, but a handful of JDT developers can impossibly implement all wishes of each in those millions of users. It's about prioritization. > If I had the time to work myself into Eclipse code, I would try to > contribute, but from my last Eclipse reports I noticed that some "very easy" > features are "very hard" to implement in Eclipse because of the suboptimal > architecture. Please don't confuse inherent complexity due to richness of features with a bad architecture. Or do you have specific proposals how the architecture of JDT could be improved, still? Also note that I googled for you an existing plug-in which you could certainly use as a starting point. The only issue here: if you start with code from undocumented provenance than this cannot be contributed to Eclipse (for legal reasons), but hey, having this as a separate plug-in makes perfect sense to me. Yes, the architecture of Eclipse allows to implement this outside of JDT. How is that? :) > So, can you at least cvhange this bug report to a "request for enhancement" > report, please? Well that obviously required to rephrase the title as well, since the original complaint is still invalid. Now, if this bug gets a lot of attention and lots of votes, maybe some contributor will consider it worthwhile to work on it, maybe...
I just wanted to remark that this usefull feature to state the classpath with a wildcard myLibs/*.jar is something that was wished since the start of Java (I started coding in Java since the first beta release ...) and even Sub long ignored this request although it is so useful. So I was disappointed the a modern IDE like Eclipse still does not support this. However, I contributed some code to misc open source libraries and apps and got disappointed because all of them got broken with new releases. So writing an own plugin is always something that can break on each new release and you always have to work on this and find out what has changed. For this reason, I ask for supporting this in the code Eclipse Java part. Thanks for changing the title and importance!
(In reply to M H from comment #9) > However, I contributed some code to misc open source libraries and apps and > got disappointed because all of them got broken with new releases. So > writing an own plugin is always something that can break on each new release > and you always have to work on this and find out what has changed. In close to 20 years of existence JDT is about as conservative in its API policy as you could possibly imagine. When programming only against public API (which should be fully sufficient here), your general worries should not be relevant in our case :) In the end it's up to you if you wait or do (or convince some third contributor) ...
