Community
Participate
Working Groups
-- Configuration Details -- Product: Eclipse 4.6.3.20170314-1500 (org.eclipse.epp.package.jee.product)Installed Features: org.eclipse.jdt 3.12.3.v20170301-0400 Versioning Plugin: org.eclipse.platform 4.6.3.v20170301-0400 Problem only appeared after loading the latest version as specified above. Overview Running the programs via the command line (java lib=xxx.jar) after exporting project to a jar file, results in the error: Code: [Select all] [Show/ hide] Exception in thread "main" java.lang.NoClassDefFoundError: jutils/Errs Details (sorry if this is not the right format, this is my first Bug report) Working in a Java Workspace, with 6 "Java Projects" that are exported into a single 'program' Some, but not all, of the "Java Projects" use specific and unique Jar files for classes provided either via GitHub or other repositories. In each of the projects that use them, I have added them into the project via the "Referenced Library" via the Build Path -> Configure Build Path... -> Java Build Path dialog box. Again, some, but not all, of the "Java Projects" use a set of Jar files with "common classes" that I have written. Mostly utilities to perform some action or hold data that is common across all of my projects. (My toolbox, if you will.) Initially, I also added these "common classes" to each project's "Referenced Library". The problem I ran into was that if I modified the 'common classes' I then had to update every project's "Referenced Library" with the new Jar File, Source file, and Java doc file. The solution to that was to place these jar files with the 'common classes' into a User Library. I then added the User Library to those projects that that used these 'common classes'. When there was a change to one of the 'common classes', simply updating the User Library changed the links for ALL of the java projects that referenced that User Library. Great Stuff!!! Everything worked fine on Jan 1, 2024 Now fast forward 3 months.... Due to a pending computer upgrade, I moved all of my source files from my local machine to a file server I set up. I access the files through a drive letter on my windows machine. Eclipse had a problem when I tried to "modify" the "Workspace" to point to the new locations, so I started fresh and created a new Workspace and pulled in the packages one by one and set up the libraries connections, etc. I did NOT reinstall Eclipse or move it. Making changes to the workspace projects works well, testing via the IDE also works..... Problem with Exporting All of my programs are run via command files on my machines, This allows me to schedule them at different times and frequencies, as will as run them mostly unattended. I do this by exporting the workspace to a Runnable JAR File, and then invoking them via the command files. I use the "Export,,, -> Runnable JAR File... -> Runnable JAR File Export" dialog box. I specify the Launch Configuration, the Destination File, and "Extract required libraries into the generated JAR" option. and press Finish. The JAR file is created with no errors and no warnings. However NOW the JAR file is actually smaller than than the ones created before moving the source files, despite the fact that I have added additional Source Files inside a number of the Java Projects. Running the programs via the command line results in the error: Code: [Select all] [Show/ hide] Exception in thread "main" java.lang.NoClassDefFoundError: jutils/Errs Where jutils/Errs is one of the main "common classes" defined in the jutils.jar file which is referenced in the User Library (Yes, I do have a "main" and everything worked fine before.) No amount of removing, re-adding, deleting and recreating the "User Library", cleaning, closing, reopening, the projects, seems to solve this problem. I can open the resulting JAR files (using WINRAR) and can clearly see these 'common classes' in the "old" JAR file (previous builds), but they are missing from the new JAR files. The only solution I have at this point is to add all the "Common Classes" back into the "Referenced Library" of each of the projects. This of course causes a maintenance issue when one of those are changed (which was originally solved by going to the User Library!) And while this workaround works, the exported JAR file is now almost 1.5 times as big as before!
