On 22/07/2020 21:20, JamO Luhrsen wrote:

https://jenkins.opendaylight.org/releng/job/ovsdb-maven-verify-sodium-mvn35-openjdk8/276/



One clue I have is that if I downgrade mdsal from version 4.0.16 to
4.0.15 the build
will pass.

Looking for ideas because I've run out :)

nite@nitebug : ~/odl/ovsdb on $ mvnDebug clean install -rf :library

then attaching Eclipse debugger, breaking on IllegalArgumentException
being thrown ends up with a stack trace which points to:

META-INF/versions/15/org/bouncycastle/jcajce/provider/asymmetric/edec/KeyFactorySpi$X448.class

... which is why I just hate blueprint-maven-plugin with a passion. Why
in the world does it need to scan the entire dependency path?!

This can, of course, be fixed locally by adding following configuration:

<includeArtifacts>
<includeArtifact>org.opendaylight.ovsdb:.</includeArtifact>
</includeArtifacts>

given what we are doing, this should have been placed into each and
every instance of the plugin across all projects, in the form of:

<includeArtifacts>

<includeArtifact>${project.groupId}:${project.artifactId}</includeArtifact>
</includeArtifacts>

so that generation considers *only* the artifact being built, but alas
whoever introduce this magnificent piece of engineering did not care to
read the documentation properly.

At any rate, this is not biting Mg/Al because those release trains have
an upgraded XBean override, i.e. it needs to be backported, just as in
here: https://git.opendaylight.org/gerrit/c/odlparent/+/91566

Bye,
Robert

On 7/22/20 3:10 PM, Robert Varga wrote:

On 22/07/2020 21:20, JamO Luhrsen wrote:

https://jenkins.opendaylight.org/releng/job/ovsdb-maven-verify-sodium-mvn35-openjdk8/276/



One clue I have is that if I downgrade mdsal from version 4.0.16 to
4.0.15 the build
will pass.

Looking for ideas because I've run out :)

nite@nitebug : ~/odl/ovsdb on $ mvnDebug clean install -rf :library

then attaching Eclipse debugger, breaking on IllegalArgumentException
being thrown ends up with a stack trace which points to:

META-INF/versions/15/org/bouncycastle/jcajce/provider/asymmetric/edec/KeyFactorySpi$X448.class

... which is why I just hate blueprint-maven-plugin with a passion. Why
in the world does it need to scan the entire dependency path?!

Geez... told you I was way in over my head :)  Thanks for figuring it out.

This can, of course, be fixed locally by adding following configuration:

<includeArtifacts>
<includeArtifact>org.opendaylight.ovsdb:.</includeArtifact>
</includeArtifacts>

given what we are doing, this should have been placed into each and
every instance of the plugin across all projects, in the form of:

<includeArtifacts>

<includeArtifact>${project.groupId}:${project.artifactId}</includeArtifact>
</includeArtifacts>

so that generation considers *only* the artifact being built, but alas
whoever introduce this magnificent piece of engineering did not care to
read the documentation properly.

At any rate, this is not biting Mg/Al because those release trains have
an upgraded XBean override, i.e. it needs to be backported, just as in
here: https://git.opendaylight.org/gerrit/c/odlparent/+/91566

Didn't totally follow the right thing to do here? Should I go search and
destroy all projects to replace with the ${project.groupdId}:${project.artifactId}
trick or are you saying we need to backport odlparent/+/91566 so that
sodium-sr4 will have it?


Thanks,
JamO

Bye,
Robert

On 23/07/2020 01:53, JamO Luhrsen wrote:

On 7/22/20 3:10 PM, Robert Varga wrote:

This can, of course, be fixed locally by adding following configuration:

           <includeArtifacts>
             <includeArtifact>org.opendaylight.ovsdb:.</includeArtifact>
           </includeArtifacts>

given what we are doing, this should have been placed into each and
every instance of the plugin across all projects, in the form of:

           <includeArtifacts>

<includeArtifact>${project.groupId}:${project.artifactId}</includeArtifact>

           </includeArtifacts>

so that generation considers *only* the artifact being built, but alas
whoever introduce this magnificent piece of engineering did not care to
read the documentation properly.

At any rate, this is not biting Mg/Al because those release trains have
an upgraded XBean override, i.e. it needs to be backported, just as in
here: https://git.opendaylight.org/gerrit/c/odlparent/+/91566

Didn't totally follow the right thing to do here? Should I go search and
destroy all projects to replace with the
${project.groupdId}:${project.artifactId}
trick or are you saying we need to backport odlparent/+/91566 so that
sodium-sr4 will have it?

Ah, sorry. Either fix will do. The odlparent backport is being pushed out.

It might be worthwhile to do the includeArtifacts on master at some
point also, as it could cut down on build time:

22:33:28 [INFO] --- blueprint-maven-plugin:1.10.0:blueprint-generate (default) @ aclservice-impl ---
22:33:31 [INFO] Package org.opendaylight.netvirt will be scanned
22:33:37 [INFO] Generating blueprint to /w/workspace/netvirt-maven-merge-aluminium/aclservice/impl/target/generated-sources/blueprint/OSGI-INF/blueprint/autowire.xml

(that's latest netvirt/Al, there are 12 executions of the plugin
averaging 5 seconds each).

Regards,
Robert