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/04 19:38:06 UTC
Reason why source-release artifact is not "attached"
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>.
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
>
>