You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2018/10/03 21:52:02 UTC
Found an approach that mostly works for asc signing and sha512
checksumming, for both deployed and buit-into-/target artifacts
I learned that the maven build mechanism sometimes can build things not in
target, that get deployed in your .m2 when "installing" or deploying. So we
have to check both destinations to see that things are being generated properly.
The approach so far involves "fixing" the checksum-signing plugin (see
https://github.com/nicoulaj/checksum-maven-plugin/issues/63 for details) and
using it in 2 ways.
way 1: with the goal "artifacts". Surprisingly, this fails to find (for the
uima-wide pom project) the main artifact that is, the pom. So to get that to
have the sha512 checksum we use
way 2: with the goal "files", specifying the artifact in the target, but
This needs a help to copy the pom.xml from the top level in the project, to
the target as "${project.build.finalName}.pom" (no trailing "xml") (at least for
the uima-wide pom build).
Other fixes: disabled the ant-based gpg and sha512 sigs, in favor of using the
gpg-plugin and the checksum signing plugin.
This didn't quite work, because the artifacts produced by the source-assembly,
for some reason (unknown - to be investigated) are not being "attached". Fixed
this by adding a step to attach the source release .zip (and if present the
source-release.jar - produced for java projects).
This may require waiting for the checksum-maven-plugin, and I still want to
investigate why the source-release isn't being attached.
-Marshall
Re: Reason why source-release artifact is not "attached"
Posted by Marshall Schor <ms...@schor.com>.
On even further investigation, I see maybe no change is needed.
Current design:
1) assembly for source-release runs at top level (of aggregate), and is
configured to *not attach*.
2) uima-wide parent-pom has an ant task in the apache-release profile, which
runs a gpg and sha checksumming for the source-release.
Because of this, I don't think there's a need to attach the source-release; I
won't change this.
-Marshall
On 10/13/2018 12:29 PM, Marshall Schor wrote:
> Turning off attaching the source-release has a bad effect: because it's not the
> "standard" "conventional" maven way, the maven-gpg-plugin doesn't gpg-sign this
> artifact. That plugin signs the main artifact, all attached artifacts, and the pom.
>
> Our maven use design already is blocking uploading to maven (via configuring the
> maven-deploy-plugin) all artifacts for the top level pom (for aggregate
> projects). And the maven-assembly-plugin execution that creates the
> source-release is set to only run at the top level.
>
> from the apache-wide pom 21:
> <execution>
> <id>source-release-assembly</id>
> <phase>package</phase>
> <goals>
> <goal>single</goal>
> </goals>
> <configuration>
> <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>
> from our uima-wide pom:
> <profile>
> <id>build distribution</id>
> <activation>
> <file><exists>src/main/assembly/bin.xml</exists></file>
> </activation>
> ...
> <!-- https://issues.apache.org/jira/browse/UIMA-2008 -->
> <!-- no maven deployment of this project's artifacts -->
> <!-- binary build artifact deployed from apache mirror system after
> release -->
> <plugin>
> <artifactId>maven-deploy-plugin</artifactId>
> <configuration>
> <skip>true</skip>
> </configuration>
> </plugin>
>
> So - we can achieve the result of UIMA-3247 without specifying that the assembly
> should not attach the result.
>
> This will, because of maven conventions :-) , allow the maven-gpg-plugin to
> sign it.
>
> The one downside is that for releasing non-aggregate projects (I don't think we
> have any, except I believe we did release one "add-on" as a single project),
> those releases will have deployed to maven the source-release.zip, which I think
> is not something to be concerned about.
>
> I plan to make this change in the uima-wide parent-pom 12.
>
> -Marshall
>
> On 10/4/2018 3:38 PM, Marshall Schor wrote:
>> It turns out this is on purpose, was configured that way by this Jira:
>> https://issues.apache.org/jira/browse/UIMA-3247
>>
>> The thinking was that this is an archival packaging of all the source, and is
>> part of the distribution, but shouldn't be part of maven's repo which is
>> designed for active use. So, we deploy things to maven repos like javadocs,
>> sources.jar, etc., which are useful for IDEs which can automatically pull the
>> source when debugging, etc.
>>
>> -Marshall
>>
>>
Re: Reason why source-release artifact is not "attached"
Posted by Marshall Schor <ms...@schor.com>.
Turning off attaching the source-release has a bad effect: because it's not the
"standard" "conventional" maven way, the maven-gpg-plugin doesn't gpg-sign this
artifact. That plugin signs the main artifact, all attached artifacts, and the pom.
Our maven use design already is blocking uploading to maven (via configuring the
maven-deploy-plugin) all artifacts for the top level pom (for aggregate
projects). And the maven-assembly-plugin execution that creates the
source-release is set to only run at the top level.
from the apache-wide pom 21:
<execution>
<id>source-release-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
from our uima-wide pom:
<profile>
<id>build distribution</id>
<activation>
<file><exists>src/main/assembly/bin.xml</exists></file>
</activation>
...
<!-- https://issues.apache.org/jira/browse/UIMA-2008 -->
<!-- no maven deployment of this project's artifacts -->
<!-- binary build artifact deployed from apache mirror system after
release -->
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
So - we can achieve the result of UIMA-3247 without specifying that the assembly
should not attach the result.
This will, because of maven conventions :-) , allow the maven-gpg-plugin to
sign it.
The one downside is that for releasing non-aggregate projects (I don't think we
have any, except I believe we did release one "add-on" as a single project),
those releases will have deployed to maven the source-release.zip, which I think
is not something to be concerned about.
I plan to make this change in the uima-wide parent-pom 12.
-Marshall
On 10/4/2018 3:38 PM, Marshall Schor wrote:
> It turns out this is on purpose, was configured that way by this Jira:
> https://issues.apache.org/jira/browse/UIMA-3247
>
> The thinking was that this is an archival packaging of all the source, and is
> part of the distribution, but shouldn't be part of maven's repo which is
> designed for active use. So, we deploy things to maven repos like javadocs,
> sources.jar, etc., which are useful for IDEs which can automatically pull the
> source when debugging, etc.
>
> -Marshall
>
>
Reason why source-release artifact is not "attached"
Posted by Marshall Schor <ms...@schor.com>.
It turns out this is on purpose, was configured that way by this Jira:
https://issues.apache.org/jira/browse/UIMA-3247
The thinking was that this is an archival packaging of all the source, and is
part of the distribution, but shouldn't be part of maven's repo which is
designed for active use. So, we deploy things to maven repos like javadocs,
sources.jar, etc., which are useful for IDEs which can automatically pull the
source when debugging, etc.
-Marshall