Feature Wish for GIT and Maven SubModule Support on whole GitHub Org or User


#1

Hi there!

I have created a GitHub Org on Agilhard-OSS · GitHub with few open-source subprojects that partly depend on each other and tried to enable DepShield on the whole agilhard-oss organisation.

After I did that I got issues in each subproject from DepShield that the subproject would not build.

I had somehow hoped that when enabled for the whole GitHub org DepShield would somehow recognize the subproject dependencies and build all subprojects in one DepShield run in the correct order enabling the DepShield checking to find the maven artifacts of one subproject X while building subproject Y, which depends on it, in its local Maven Repository.

But it at least currently does not seem to do that so when building one subproject all its dependencies must already be published on maven central or similar and can not be other subprojects of the GitHub org or user currently being checked by DepShield.

Concrete example: my subproject jzlib builds on it’s own but subproject jsch uses that jzlib as a maven dependency and thus got an issue filed by DepShield.

Also I have a parent git+maven module on GitHub - agilhard-oss/agilhard-oss: agilhard-oss parent GIT Module which uses the git submodule feature which also did not build when being checked by DepShield. The parent module references and uses all the other subprojects on the GitHub org.

For that git parent module the feature wish for the DepShield build would be that it would recognize that there is a .gitmodules file present and that it therefor has to do a “git submodule init; git submodule update” before doing a “mvn clean install” or better that when cloning the project in the first place DepShield would have used “git clone --recursive” to get the whole source code.

Kind regards,
Bernd Eilers


#2

Hi Bernd,

Thanks again for reaching out to us and thank you for the suggestion about the git modules.

For clarification, while DepShield does clone projects locally, it does not currently do a ‘mvn clean install’ on them but rather a ‘mvn dependency:tree’. Therefore, any internally defined artifacts are not built and are not resolvable by DepShield, as you point out, unless they are published and available on maven central. Sorry for the confusion there. But we are considering how best to handle these situations.

Thank you.

Russ Jackson
Sonatype