Workaround:
Open the solder pom.xml and remove <module>logging</module>, it will grab the latest snapshot from the jboss repo of that shading jar.

This seems to be related to MSHADE-103.

The pom of the logging module contains a profile for the JBoss repositories that somehow doesn't get activated by default. Resolving the parent pom seems to work if I enable this profile manually.

$ mvn -Pjboss-public-repository install

The build works fine now.

I think I can bring some more light into this issue.

The shade plugin is configured to create a "dependency reduced pom.xml" which is a copy of the original pom but with all dependencies removed that have been shaded into the JAR. For some reason the "activation" part of the jboss-public-repository profile is missing in this new pom. So activating the profile via properties doesn't work. Even if I add "activeByDefault" it doesn't work as this also gets removed. So currently the only way to build the module is to manually activate the profile like described in my last post.

Another possible fix would be to move the repository declaration out of the profile directly to the pom. But this would also include the repositories in the distributed pom which isn't very nice I think.

@Christian Why use shaded jars in the first place?

Afaik, shaded jars bring nothing but trouble:

• If jar B shades jar A and both A and B end up in the same classpath (very likely in big projects that indirectly depend on A and B) and they are different versions (again likely), then the classes of the first jar on the classpath will be used at runtime (which is in practice means you don't know which one). Furthermore, the exceptions raised are unclear (NoSuchMethodError, ClassCastException: cannot cast Dog to Animal (but Dog does extend Animal), ...).
• the Red Hat guys that do RPM repackaging of our projects in http://www.jpackage.org/ absolute hate shaded jars as they can't deal with them
• OSGi doesn't like shaded jars.
• Once JDK 8 Jigsaw is out, we won't be able to shade any more anyway.

So instead of shading to create "dependency reduced pom.xml" and "shade the dependencies in the jar", can't the jar not shade those dependencies and simply depend on them in it's pom?

My personal thought on this is that shading is OK if you also relocate the classes (like Solder does it). This will lead to new package names that don't conflict with any others. In this case shading won't bring any trouble and has the advantage that libraries can existing in different versions concurrently because they have different package names.

@Christian I agree: most of the pain of shading goes away if you also relocate all the classes and all the resources. However, relocating resources is a PITA. I presume Solder doesn't have to deal with relocating any resources (yet?).

Can this be closed?

@Jason If you decide to keep the shading, yes it can be closed. But I personally would much rather see all shading go away Just reuse classes the normal way.

If you close it, that "-Pjboss-public-repository" trick should be noted somewhere that anyone's who's going to build solder from source would read.

Added the info about enabling the JBoss Nexus Repository to the readme.md file.

I don't think the shading will go away anytime soon, unless there's a pull request sent or something similar.