Replace class files before building maven

Question

I came across a very unique situation and I need advice: I am working on a project that depends on another project from my own company, and now I need to apply some changes to the dependency. The problem I have is that the source code from the dependencies was lost, so the only thing I have is the dependency on maven in the repository, with the corresponding jar file. In addition, some of the classes in the Jar file created using the JiBX parser that display some XSD files that I don’t have and the resulting classes are synthetic, and I did not find a decompiler that can handle them correctly.

The only thing that can be said is that the class I need to change can be decompiled correctly, so he went to the following:

• I decompiled the entire jar file and ended up with some classes (JiBx) with an empty or incorrectly implemented method.
• I commented on the body of the wrong methods to have stubs, applied the necessary changes to the correct classes, and recompiled.
• I took the old Jar file, opened it, and manually replaced the old class with the new one.

And the resulting Jar worked as expected.

Now my question is: can I do all this with Maven?

The idea is to put the JiBX class files as resources and save the stub equivalents as source files, and then enable maven:

• Compile everything as usual by placing all the compiled class files in the target folder
• Delete stub class files from the destination folder and replace them with old files with precompiled classes
• pack the jar.

Which approach would you recommend?

UPDATE

I will talk about more detailed information about the structure of the dependency project:

All classes are inside one package:

my.project.domain.JiBX__c_GeneratedObfuscatedClass1.java my.project.domain.JiBX__c_GeneratedObfuscatedClass2.java my.project.domain.JiBX__c_GeneratedObfuscatedClass3.java my.project.domain.CustomizableClass1.java my.project.domain.CustomizableClass2.java my.project.domain.CustomizableClass3.java 

JiBX classes are not imported properly as a dependency, and if I try to put any of the CustmizableClasses in the project source and let the JiBX members be dependent, the compiler reports missing methods.

I also tried using the Shade Plugin as suggested, but since I need to include the JiBX classes in the source path, I have to include the classes from the jar dependency in the JiBX class and compile CustomizableClasses, but skip the CustomizableClasses from jar dep and the compiled JiBX classes.

It looks like it might work, but I admit that I still haven't found a way to do this. Any hints would be greatly appreciated.

UPDATE 2 (PERMISSION)

I will explain how I finally dealt with this using the shadow plugin, as suggested, in case anyone else needs to do the same:

Finally, I created a project with decompiled classes inside the same package and left without comment methods that do not want to decompile.

In pom.xml, I added the following:

 <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>2.0</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <artifactSet> <includes> <include>${project.groupId}:${project.artifactId}</include> <include>TheDamnedProject:WithoutSources</include> </includes> </artifactSet> <filters> <filter> <artifact>TheDamnedProject:WithoutSources</artifact> <includes> <!-- These classes will be taken directly from dependency JAR --> <include>my/package/ClassWhichCouldNotBeDecompiled1.class</include> <include>my/package/ClassWhichCouldNotBeDecompiled2.class</include> <include>my/package/ClassWhichCouldNotBeDecompiled3.class</include> <include>my/package/ClassWhichCouldNotBeDecompiled4.class</include> </includes> </filter> <filter> <artifact>${project.groupId}:${project.artifactId}</artifact> <excludes> <!-- These classes will be overridden by the ones inside the JAR --> <exclude>my/package/ClassWhichCouldNotBeDecompiled1.class</exclude> <exclude>my/package/ClassWhichCouldNotBeDecompiled2.class</exclude> <exclude>my/package/ClassWhichCouldNotBeDecompiled3.class</exclude> <exclude>my/package/ClassWhichCouldNotBeDecompiled4.class</exclude> </excludes> </filter> </filters> </configuration> </execution> </executions> </plugin> </plugins> 

thanks!

Carles

Answer 1

Here is how I would do it:

• Create a new Maven project for this jar file with jar type packaging
• Include jar source file as dependency
• Add one decompiled .java file to src folder

This should lead you to the point where the .java file can be compiled, since other classes from the jar file are available.

You now have two Jar files: one original and one that should contain only one recompiled and modified class.

Adding both paths to your application class may work, but will depend on the order in the class path.

If you want to get one jar file, I recommend looking at the Maven Shade plugin ( http://maven.apache.org/plugins/maven-shade-plugin/ ), which will allow you to create a new Jar file with content from several sources. This will allow you to filter what is included in the new Jar file.

The Maven Shade plugin allows you to specify which classes from each artifact are included. It uses wildcards and includes / excludes tags for this, as described here: http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html

Once this Jar file is created, I will release it using the Maven Release plugin and then turn on this artifact downstream. This will allow you to update the fixed Jar when it is really necessary, perhaps this is not necessary for each assembly. But it depends on your usage pattern.

For the version number of the new Jar file, I recommend using the original version. Use the same groupId and artifactId , and then change the version number. If the original has 1.0.2 , your new patch file should be released as 1.0.2-1 to indicate that it is based on 1.0.2 sources. If you need to make additional changes, release it as 1.0.2-2 and so on. This will make it easier to understand on what basis your fixes are based, and the number of additional patches will enable you to distinguish between releases.