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 (JIRA)" <de...@uima.apache.org> on 2011/01/18 13:23:44 UTC

[jira] Created: (UIMA-2008) Don't attach large distribution artifacts for uima-as builds, but sign them for releasing

Don't attach large distribution artifacts for uima-as builds, but sign them for releasing
-----------------------------------------------------------------------------------------

                 Key: UIMA-2008
                 URL: https://issues.apache.org/jira/browse/UIMA-2008
             Project: UIMA
          Issue Type: Improvement
          Components: Build, Packaging and Test
            Reporter: Marshall Schor
            Priority: Minor


The build process for distributions builds large binary assembly artifacts; the build process at the top level under profile apache-release builds large source-release.zip files.  These files, for the uima-as distribution, are made available after release on our download pages, and use the non-maven Apache distribution mirroring system.

These files probably should not be "attached" in the maven sense for uploading to maven central upon release; they will just waste space.  

Change the build so these are not "attached".   Find another way to get these unattached things "signed" (currently done in the deploy step).  One way is to use maven antrun plugin to do an ant exec of the gpg command on the artifact; there may be other ways.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (UIMA-2008) Don't attach large distribution artifacts for uima-as builds, but sign them for releasing

Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983891#action_12983891 ] 

Marshall Schor commented on UIMA-2008:
--------------------------------------

I think a simpler alternative is to override the deploy configuration for the uimaj-as-distr to skip deployment.  That way, the signatures and the checksums are automatically generated and installed into the local .m2, but don't go any further.

> Don't attach large distribution artifacts for uima-as builds, but sign them for releasing
> -----------------------------------------------------------------------------------------
>
>                 Key: UIMA-2008
>                 URL: https://issues.apache.org/jira/browse/UIMA-2008
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The build process for distributions builds large binary assembly artifacts; the build process at the top level under profile apache-release builds large source-release.zip files.  These files, for the uima-as distribution, are made available after release on our download pages, and use the non-maven Apache distribution mirroring system.
> These files probably should not be "attached" in the maven sense for uploading to maven central upon release; they will just waste space.  
> Change the build so these are not "attached".   Find another way to get these unattached things "signed" (currently done in the deploy step).  One way is to use maven antrun plugin to do an ant exec of the gpg command on the artifact; there may be other ways.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (UIMA-2008) Don't attach large distribution artifacts for uima-as builds, but sign them for releasing

Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984266#action_12984266 ] 

Marshall Schor commented on UIMA-2008:
--------------------------------------

I like how you generate also the vote.txt ! :-)  

So, it looks like maybe the best solution is:

1) override deploy to skip deploying, but leave the assembly artifacts "attached".  The common apache pom, in its apache-release profile, invokes gpg maven plugin which then signs all "attached" things.
2) use antrun to generate the checksums


> Don't attach large distribution artifacts for uima-as builds, but sign them for releasing
> -----------------------------------------------------------------------------------------
>
>                 Key: UIMA-2008
>                 URL: https://issues.apache.org/jira/browse/UIMA-2008
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The build process for distributions builds large binary assembly artifacts; the build process at the top level under profile apache-release builds large source-release.zip files.  These files, for the uima-as distribution, are made available after release on our download pages, and use the non-maven Apache distribution mirroring system.
> These files probably should not be "attached" in the maven sense for uploading to maven central upon release; they will just waste space.  
> Change the build so these are not "attached".   Find another way to get these unattached things "signed" (currently done in the deploy step).  One way is to use maven antrun plugin to do an ant exec of the gpg command on the artifact; there may be other ways.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Issue Comment Edited: (UIMA-2008) Don't attach large distribution artifacts for uima-as builds, but sign them for releasing

Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983891#action_12983891 ] 

Marshall Schor edited comment on UIMA-2008 at 1/19/11 4:51 PM:
---------------------------------------------------------------

I think a simpler alternative is to override the deploy configuration for the uimaj-as-distr to skip deployment.  That way, the signatures and the checksums are automatically generated and installed into the local .m2, but don't go any further.

Well, it turns out this doesn't put the checksums and the signatures into the local repo - their creation is also skipped.  So back to method #1.

      was (Author: schor):
    I think a simpler alternative is to override the deploy configuration for the uimaj-as-distr to skip deployment.  That way, the signatures and the checksums are automatically generated and installed into the local .m2, but don't go any further.
  
> Don't attach large distribution artifacts for uima-as builds, but sign them for releasing
> -----------------------------------------------------------------------------------------
>
>                 Key: UIMA-2008
>                 URL: https://issues.apache.org/jira/browse/UIMA-2008
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The build process for distributions builds large binary assembly artifacts; the build process at the top level under profile apache-release builds large source-release.zip files.  These files, for the uima-as distribution, are made available after release on our download pages, and use the non-maven Apache distribution mirroring system.
> These files probably should not be "attached" in the maven sense for uploading to maven central upon release; they will just waste space.  
> Change the build so these are not "attached".   Find another way to get these unattached things "signed" (currently done in the deploy step).  One way is to use maven antrun plugin to do an ant exec of the gpg command on the artifact; there may be other ways.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (UIMA-2008) Don't attach large distribution artifacts for uima-as builds, but sign them for releasing

Posted by "Jukka Zitting (JIRA)" <de...@uima.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983898#action_12983898 ] 

Jukka Zitting commented on UIMA-2008:
-------------------------------------

We do something like this also in Jackrabbit and PDFBox. See for example the apache-release profile configuration in http://svn.apache.org/repos/asf/pdfbox/trunk/pom.xml. There we solve the lack of MD5 and SHA1 signatures by using the <checksum> task with the antrun plugin.

> Don't attach large distribution artifacts for uima-as builds, but sign them for releasing
> -----------------------------------------------------------------------------------------
>
>                 Key: UIMA-2008
>                 URL: https://issues.apache.org/jira/browse/UIMA-2008
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Build, Packaging and Test
>            Reporter: Marshall Schor
>            Priority: Minor
>
> The build process for distributions builds large binary assembly artifacts; the build process at the top level under profile apache-release builds large source-release.zip files.  These files, for the uima-as distribution, are made available after release on our download pages, and use the non-maven Apache distribution mirroring system.
> These files probably should not be "attached" in the maven sense for uploading to maven central upon release; they will just waste space.  
> Change the build so these are not "attached".   Find another way to get these unattached things "signed" (currently done in the deploy step).  One way is to use maven antrun plugin to do an ant exec of the gpg command on the artifact; there may be other ways.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.