KEYCLOAK-5843 Add custom license processing plugin to avoid directory symlinks #4723
Conversation
|
You can't do a clean on this. If I do mvn clean in the /distribution directory, I will get: [ERROR] Plugin org.keycloak:keycloak-distribution-licenses-maven-plugin:3.4.1.Final-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.keycloak:keycloak-distribution-licenses-maven-plugin:jar:3.4.1.Final-SNAPSHOT in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced -> [Help 1] Looks like you need to make sure your license jar gets built first. BTW, don't tell anyone I'm doing work today. It's a holiday here in the US. :-) |
|
Thanks Stan. I can reproduce the issue when I delete the plugin from my local repo. keycloak-distribution-licenses-maven-plugin is configured to build, and it is in the reactor when building from the distribution directory. In fact, if you check your log, you'll see "Keycloak Licenses Processor Maven Plugin" right before the failure. However, in the I know I can explicitly tell maven not to load a plugin if I bind it to phase |
|
Ok, I think I found the issue. Maven was acting stupidly because I wasn't giving it enough information. It can't tell what the default phase of a plugin is without loading it, and the definition I wrote relied on the default phase. By specifying an explicit phase in the definition, maven can know immediately that that phase is not contained in the Also, it seems very difficult to activate a profile automatically on a certain lifecycle. The only way seems to be if there's a certain property or property/value combination that's unique to that lifecycle. |
… symlinks Symlinks are frequently unavailable on Windows (must be on NTFS and user must have SeCreateSymbolicLinkPrivilege). Removing the symlinks for licenses/common/ should enable the build to function mostly normally on Windows. The individual license files will be incorrect, but that shouldn't matter for local builds. Release builds are done on *nix. The plugin rolls several different plugin executions into one. The common files are distributed using a resource jar, used by and unpacked by the plugin.
|
So where are we on this? Do we have something ready for me to look at again? |
|
@ssilvert yes, it should now work for you if you try again, I force-pushed a new commit to replace the old one. |
|
Yep. Everything builds now. Ready for merge? |
|
I think it's ready to merge, yes. |
Symlinks are frequently unavailable on Windows (must be on NTFS and user must
have SeCreateSymbolicLinkPrivilege). Removing the symlinks for licenses/common/
should enable the build to function mostly normally on Windows. The individual
license files will be incorrect, but that shouldn't matter for local builds.
Release builds are done on *nix.
The plugin rolls several different plugin executions into one. The common files
are distributed using a resource jar, used by and unpacked by the plugin.