proguard module-info and jlink - java

Proguard does remove module-info in default.
keep 'class module-info'
Force proguard to keep the module-info class but it does not update the references inside to the obfuscated names, therefore jlink fails with
"Package x.y.z not found in module"
Is there a way how to keep module-info but let proguard update it so that it corresponds to the obfuscated package names ?

Related

classes folder in target in maven project directory structure

When working maven project , maven sometimes generate classes folder in target directory. Sometimes it doesn't(may be create and delete immediately) ?.
What are the cases when it happen and when it doesn't ?.
It depends on your project configuration. For general, the project packaging type will be one key factor. Like "pom" type or "bom" type, these types are just for describing a project meta like dependencies management, general plugin configurations and etc, which does not contain source code to do compiling. For jar package which contains source code, it will generate classes with compiling with default configuration of maven-compiler-plugin.
But for maven and its plugins, they are having many flexible ways to do configuration to change their abilities. For example, for compiling, you can even change your source code folder location and compilation location by using build-helper-maven-plugin. So this is still depending on your pom configurations.
For build-helper-maven-plugin, see https://www.mojohaus.org/build-helper-maven-plugin/usage.html for more details.

In Eclipse, what is the difference between modulepath and classpath?

In Eclipse, what is the difference between modulepath and classpath, and which one should I use to add a JAR file in the lib folder?
And why does the JRE System Library appear in modulepath?
The module system has mainly the following impact on the code:
A package can only be accessed from one module (Nested packages are treated as separate, so even though the package java.util is in the module java.base, the package java.util.logging can be in the module java.logging)
You can only access public fields and methods of code in exported packages of other modules. This is true even with reflection (i.e. java.lang.reflect.AccessibleObject.setAccessible(boolean) only works for code in the same module)
All code that is on the classpath lives together in the "unnamed" module.
All code on the modulepath lives in their own "named" modules.
You have to distinguish two cases:
If you don't add a module-info.java to your project, your project will be part of the unnamed module and can see all other code in the unnamed module, plus code in java.base and code in modules in java.se root module. Basically this means that w.r.t. code on the classpath, everything still works as in Java 8, so you should just put your dependencies on the classpath.
If you have a module-info.java in your project, your project will be in its own named module and can only see code in java.base and other named modules which are references using "requires"-clauses in the module-info.java. As named modules are only found via the module path, you should put your dependencies on the module path. This even works for jars created before Java 9, which will get a module name derived from the .jar file name (in which case they are called "automatic" module).
The JRE is always on the module-path, so that its internal code cannot be accessed even from code on the classpath.
There is one special case: If you have a module-info.java in your project and have test code in your project, you usually don't want to mention test dependencies like junit in the module-info.java. There are two solutions for this:
Create a dedicated test module. This has always been the convention for osgi-based projects. Disadvantage is that you can only use public API in your tests
The solution used by Maven: Put your test dependencies on the classpath. When compiling test code, Maven adds command line options that allow the code in the named module to read the unnamed module (which is not possible via the module-info.java).
In Eclipse Oxygen, the Maven solution was not possible, because it has no notion which code is test code, but this has been implemented in the upcoming Eclipse Photon (4.8) release, which will be out in June. You can already work with the (feature-complete) milestone builds from http://download.eclipse.org/eclipse/downloads/. In case you find any bugs, please report them at https://bugs.eclipse.org/bugs/.

Different jar file in classpath and buildpath in Eclipse

I added Lombok 1.12 jar file in classpath while I gave Lombok 1.16 jar file in libraries (while configuring build path in eclipse). Eclipse could not recognise some annotations of lombok like #Builder ( was giving compiler error).
(Also #Builder was included in the main Lombok package in version 1.12)
Later I corrected gave Lombok 1.16 jar file in classpath also. #Builder annotation gets recognised this time by eclipse. Everything works well now.
This means the classpath in vm gets compared with the build path and a check is performed whether binary file (lombok.jar) is same for the classpath and buildpath both. Is my assertion correct ? Pls correct me if I'm wrongly interpreting this.
build path is kind of a superset of class path,it holds class path,source code path and all resources that are dependent on project. If you have 2 different version of jars JVM will load the class from the jar which comes first in build path.This can be managed by editing (build path->configure build path->order of export). If the required class is not available in the first version it will check in 2nd version jar .if it doesn't find it at all then compilation error will be thrown
in eclipse if both jar is there in build path order them the one u want to refer give it priority order by making it to top-- Build path last tab or u can delink the lower version which u dont want to refer.

maven-exec-plugin not able to lookup un-compiled classes from src/main/java

I have a weird requirement where source is being generated by a jar based on the source in src/main/java. The final jar should bundle the files that are generated not the files that are in src/main/java.
Here's what I have done:
1. Added source in src/main/java
2. added maven-exec-plugin to invoke main-class from the jar added as dependency and passed required arguments.
3. added build-helper-maven-plugin to add the path to the generated sources to the maven sources.
4. added maven-jar-plugin to include and exclude the required classes.
Problem: When step#2 is executed the main class complains that its not able to find the class which is present in src/main/java. Is it a requirement to compile the class before it is used to dynamically create an instance...like Class.forname("package.Class")?
If maven-exec-plugin is execute after "compile" phase then there's no ClassNotFoundException but the problem with this is the generated source files do not get compiled before being bundled and I see files with ".java" extension being bundled in the generated jar.
Make your life simpler: use maven modules
root
|
+----> generator
|
+----> generated
Split your project into two modules, a generator module and a module with your generated code. That way, in each modules, you can embrace the standard maven lifecycle:
In the generator module, everything is completely normal.
The "generated" module referenced the "generator" module as a dependency with scope provided, and it executes the exec plugin in phase generate-sources, using the folder target/generated-sources/<your generator> as output folder. You probably need the buildhelper-maven-plugin to add the generated sources folder as source root also. Everything else works completely as usual.

eclipse library bundle - fails to export packages from some libraries

I've created a simple plugin project in eclipse 3.5 that just stores third-party libraries for the use by other bundles in an eclipse RCP application. Worked as expected: I edited the manifest, exported the required packages and added the libraries to the build path (project build path as well as manifest build path).
Some days later I added another jar to that project, did the same steps (exporting a package, adding the library to the build path(s)) but this time I can't import classes from that exported package in other bundles. The package was clearly selectable on the manifest editor but import statements in classes just taunt me with curly red lines. Importing classes from other packages exported by the bundles still works, only classes from the newly added lib remain invisible.
Has anyone has an idea what I might have missed? I'm pretty stuck and have no idea how to convince google to show me the solution to that ugly issue...
Check the following:
Make sure they are in the Build
Configuration -> Order and Export
area, and they are check for export.
Make sure you have the packages
exported in the manifest (PDE Tools
-> Open Manifest -> Runtime tab)
In the same place as above, make
sure the JAR files are in the
manifest classpath.
(as Al says
below), make sure the build
properties has your jars marked for
exclusion (though this is not likely
your issue as you are getting errors
compiling).
If all of this is done (and it's still not working), do a clean build an restart eclipse. Sometimes the Eclipse gets a little confused about this and a restart helps.
Check the build.properties to see if the bin.includes includes your newly added Jar. Without it, it won't be exported by the build process, and thus won't be able to use it in dependent bundles.

Categories