I'm using proguard to obfuscate my code. My setup is I have 1 parent pom.xml and about 50 modules underneath. The problem is some of these jars are empty (I will implement those later), others contain only property files (kind of like spring-boot-starter jars) and some others are webjars (they only have css, js, and images) and the proguard maven plugin fails because proguard complains the source is empty:
[proguard] Error: The input doesn't contain any classes. Did you specify the proper '-injars' options?
Is there a setting in proguard to silently ignore those jars and not break the whole build? To me it sounds like this must be printed as a warning instead of throwing an error.
I've opened a pull-request for proguard here:
https://sourceforge.net/p/proguard/code/merge-requests/1/
Now we wait for it to be merged :)
This also happens when you input an empty directory, I just added a dummy class to the root package.
Related
What are the possible causes of a "java.lang.Error: Unresolved compilation problem"?
Additional information:
I have seen this after copying a set of updated JAR files from a build on top of the existing JARs and restarting the application. The JARs are built using a Maven build process.
I would expect to see LinkageErrors or ClassNotFound errors if interfaces changed. The above error hints at some lower level problem.
A clean rebuild and redeployment fixed the problem. Could this error indicate a corrupted JAR?
(rewritten 2015-07-28)
Summary: Eclipse had compiled some or all of the classes, and its compiler is more tolerant of errors.
Long explanation:
The default behavior of Eclipse when compiling code with errors in it, is to generate byte code throwing the exception you see, allowing the program to be run. This is possible as Eclipse uses its own built-in compiler, instead of javac from the JDK which Apache Maven uses, and which fails the compilation completely for errors. If you use Eclipse on a Maven project which you are also working with using the command line mvn command, this may happen.
The cure is to fix the errors and recompile, before running again.
The setting is marked with a red box in this screendump:
try to clean the eclipse project
you just try to clean maven by command
mvn clean
and after that following command
mvn eclipse:clean eclipse:eclipse
and rebuild your project....
Your compiled classes may need to be recompiled from the source with the new jars.
Try running "mvn clean" and then rebuild
The major part is correctly answered by Thorbjørn Ravn Andersen.
This answer tries to shed light on the remaining question: how could the class file with errors end up in the jar?
Each build (Maven & javac or Eclipse) signals in its specific way when it hits a compile error, and will refuse to create a Jar file from it (or at least prominently alert you). The most likely cause for silently getting class files with errors into a jar is by concurrent operation of Maven and Eclipse.
If you have Eclipse open while running a mvn build, you should disable Project > Build Automatically until mvn completes.
EDIT:
Let's try to split the riddle into three parts:
(1) What is the meaning of "java.lang.Error: Unresolved compilation
problem"
This has been explained by Thorbjørn Ravn Andersen. There is no doubt that Eclipse found an error at compile time.
(2) How can an eclipse-compiled class file end up in jar file created
by maven (assuming maven is not configured to used ecj for
compilation)?
This could happen either by invoking Maven with no or incomplete cleaning. Or, an automatic Eclipse build could react to changes in the filesystem (done by Maven) and re-compile a class, before Maven proceeds to collect class files into the jar (this is what I meant by "concurrent operation" in my original answer).
(3) How come there is a compile error, but mvn clean succeeds?
Again several possibilities: (a) compilers don't agree whether or not the source code is legal, or (b) Eclipse compiles with broken settings like incomplete classpath, wrong Java compliance etc. Either way a sequence of refresh and clean build in Eclipse should surface the problem.
I had this error when I used a launch configuration that had an invalid classpath. In my case, I had a project that initially used Maven and thus a launch configuration had a Maven classpath element in it. I had later changed the project to use Gradle and removed the Maven classpath from the project's classpath, but the launch configuration still used it. I got this error trying to run it. Cleaning and rebuilding the project did not resolve this error. Instead, edit the launch configuration, remove the project classpath element, then add the project back to the User Entries in the classpath.
I got this error multiple times and struggled to work out. Finally, I removed the run configuration and re-added the default entries. It worked beautifully.
Just try to include package name in eclipse in case if you forgot it
Import all packages before using it, EX: import java.util.Scanner before using Scanner class.
These improvements might work and it will not give Java: Unresolved compilation problem anymore.
Also make sure to check compiler compliance level and selected jdk version is same
As a weird case, I encountered such an exception where the exception message (unresolved compilation bla bla) was hardcoded inside of generated class' itself. Decompiling the class revealed this.
I had the same issue using the visual studio Code. The root cause was backup java file was left in the same directory.
Removed the backup java file
When the build failed, selected the Fix it, it cleaned up the cache and restarted the workSpace.
in IntelliJ (2016.2 and previous) we have our Groovy classes marked red with the error "class already exists".
I think we can exclude that the cause is the stub-generation, as this is deactivated.
Probably it's caused in our constellation: We have included our compiled groovy (and java) classes in a jar that is registered as dependency.
Dependency MyProduct.jar contains com.mycompany.MyGroovyClass
Our source contains com.mycompany.MyGroovyClass
The error disappears if the dependency is registered with Test-Scope, in all other scopes the error appears.
However, in our structure we kinda have to include the compiled classes in a compile scope, as we want to avoid that each developer needs to compile all classes (I know about the compile in background ability, but we have a constellation that prevents this from working).
We have no errors in com.mycompany.MyJavaClass which exists as well in source and in MyProduct.jar.
Any ideas on how we can solve this?
We've been suffering the same issue, it seems to be that IntelliJ registers the Java class, but also the Groovy class, and because of that it is showing that message (BTW, we are using a Maven Project).
So we ended up by going to the target folder -> right click -> Mark Directory As -> Excluded. Then, this setting will be saved on the IML file, and it won't happen again.
Hope it works for your as well!
Cheers
I'm using gmavenplus-plugin:1.5
After marking target/generated-sources/generated-sources/main as "Excluded", The error disappeared. I even did "invalidate cache and restart", It persists the setting. This is great. Intellij 2017.1.5
We have two ways to fix this issue
Exclude Stub Directory
target folder -> generated-sources -> groovy-stubs -> Right click main folder -> Mark Directory As -> Excluded
Remove generateStubs goal from gmaven plugin
Remove <goal>generateStubs</goal> from gmavenplus plugin
Make sure you Mark the src folder as Sources Root and do the same for the test folder
Then delete the target folder (most likely it's marked in yellow) and don't worry it won't delete any code from your project
If the issue persist, proceed to go to File -> Invalidate Cache/Restart
Having proguard issues since last update. (project and sdk, API 19)
First, com.android.dex.DexException: Multiple dex files define Lcom/google/gson/JsonSerializer;
OK, visiting bin/proguard and unjarring obfuscated.jar I do see com/google/gson/JsonSerializer declared there. Why? It should be in the lib only.
That is the crux of the question, why is Proguard copying in classes from the libs jars into ""?
And what is "" anyways? Progaurd fails saying the class is defined in gcm and "". What is ""? The class in only defined in libs/gcm.jar and nowhere else before I run the build.
Longer version, I add this to my proguard config:
-libraryjars libs(!gson-2.1.jar,!RSAMobileSDK-1.01.jar;)
Can't see it does anything. Following other questions and answers on StackOverflow, I edit the android build.xml.
I do this: (because it turns out the -libraryjars in the config file is not being passed throug)
-libraryjars ${project.target.classpath.value};libs/gson-2.1.jar
Still it says the file is multiply defined. If I could get proguard to ignore it then it would not be defined there. So, I try this in the build.xml:
Replace this:
-injars ${project.all.classes.value}
with this:
-injars bin\proguard\original.jar
What happens then?
It works!
So, why do I have to spefify these in the < proguard > element in the android build.xml, and how are I supposed to be able to do this with a config file?
-injars <b>bin\proguard\original.jar</b>
-libraryjars ${project.target.classpath.value}<b>;libs/gson-2.1.jar</b>
Don't specify additional input with -injars or -library jars in any configuration files; the build process already specifies these options for you. You'll only get lots of warnings about duplicate class files.
ProGuard indeed processes your own code together with the libraries. This is how it can significantly reduce the size of the application's code.
I’m trying to embed some JARs into single OSGi bundle using the feature of maven-bundle-plugin
The thing that worries me is that all packages of embedded JARs are put into the Import-Package header of the generated MANIFEST.MF.
If I specify explicitly to use only the packages I need, like in the following snippet:
Import-Package: org.osgi.framework
The build fails with BND error (unresolved references).
So, the question here is how can I build the bundle with embedded JARs with "Import-Package" header I need?
All the packages that are imported in your classes will be imported by bnd. Perhaps you do not want those packages imported because you know that at runtime you won't be needing them. If you cannot stop bnd from importing them, you can make them optional so that your bundle will still resolve even if they are not supplied by another bundle (at wire time). Try to add this:
<Import-Package>*;resolution:=optional<Import-Package>
To your maven bnd configuration in maven.
One possible reason why you are seeing "unexpected" packages in Import-Package header is the following:
A general good practice that supports collaboration model in OSGi is to import all packages that you export -- see this blog post by Peter Kriens for detailed explanation why. Bnd (and hence also maven-bundle-plugin) follows this practice by default and automatically imports all exported packages. Therefore you should first check your Export-Package header and make sure that you export only the packages you want.
Also if you want to export packages from the embedded dependencies then you should be careful to avoid duplication inside your bundle -- see section Embed-Dependency and Export-Package of the maven-bundle-plugin documentation.
You should use Bundle-ClassPath if you want to make classes available inside a bundle that contains JARs e.g.
Bundle-ClassPath: foo.jar,other.jar
Import-Package: org.osgi.framework,org.other.imported
You'll need to list the classes that foo.jar and other.jar import/use, but you won't need to list any of the packages in foo.jar or other.jar unless you're actually exporting them.
You can remove some packages from import-package scope when you embed a JAR into your bundle:
<Import-Package>![package_name9]<Import-Package>
inside pom.xml or if you use external *.bnd files:
Import-Package: ![package_name]
I currently have an existing plugin, which references a class from a required plugin. I have replaced this code with a reference to a class which is part of my fragment.
I am facing two issues.
If I import my fragment as a jar file, I am not able to see the changes I have made as the plugin running as an eclipse application results in a ClassNotFoundException
To overcome this, I link an additional source (of fragment) to the existing plugin project. However, the link uses an absolute path, and makes it unfit for deployment.
I want to be able to package the plugin with the code modification and be able to "depend" on my fragment code. Is there a way I can add my fragment as a dependency?
For example:
Plugin Project I am changing : org.eclipse.*.editor
it depends on org.eclipse.*.edit
I have a fragment mydomain.*.edit which has org.eclipse.*.edit as host plugin
I want org.eclipse.*.editor to pick up mydomain.*.edit
instead of org.eclipse.*.edit
ps: I have also tried packaging the jar file for the mydomain.*.edit in the plugins directory and try and pick it up from there, it doesnt show up on the list when I click add required plugins on the dependency tab on the plugin.xml file of the org.eclipse.*.editor
Please let me know if I am not clear enough, I will try and rephrase it.
Thanks in advance!
If I understand correctly what you want to do, I don't think that it's possible. You will have to try some other way.
Plugins have dependencies on other plugins. Fragments don't exist as separate runtime entities, but only as extensions of a plugin. So your plugin can only refer to the 'editor' plugin.
Classes provided by a fragment can't (and shouldn't) be accessed directly. They can be returned by the original plugin (A) if they are implementing an executable extension provided by plugin A.
If you refer to the fragment's code from another plugin (B), the classes will be loaded by plugin B's classloader and be different from the ones that are loaded by plugin A.
What is the purpose of your fragment? Do you want to get access to internal code in plugin A? Do you want to extend an eclipse editor?
If you want to extend functionality that the original plugin is not exposing as extensible, I think the only way is to write a plugin, extend the editor class from the original plugin, register it alongside the original one and use it instead.
[Edit] Maybe this link will explain better: Eclipse FAQ
Hope this helps,
Vlad
Thanks Vlad,
Your explanation was very helpful. Unlike the extension based architecture that is truly intended for fragments, I had to modify a certain component in the editor that was not exposed as part of the extension. This modification referred to an external project I created as an fragment but could have been a normal java project packaged a jar file that I could place in the classpath of the editor.
I was able to resolve the dependency issues by placing the jar file in class path, however when I export the plugins and related plugins as jar files and place it in the dropin directory, it does not install correctly. (Nor does placing the jar files in the plugins directory)
The eclipse editor that I am trying to modify uses the EMF project. I have kept the EMF project in the workspace inorder to resolve dependencies of the editor. However when I replace the EMF jar files bundled with eclipse with the one in the workspace, the files that I want to edit are not correctly recognized.
Is there another way of doing this?