[jboss-jira] [JBoss JIRA] (JBRULES-3470) publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central

Nick Boldt (JIRA) jira-events at lists.jboss.org
Tue Aug 28 13:33:15 EDT 2012


    [ https://issues.jboss.org/browse/JBRULES-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714348#comment-12714348 ] 

Nick Boldt edited comment on JBRULES-3470 at 8/28/12 1:33 PM:
--------------------------------------------------------------

Would it be possible to symlink your content in http://download.jboss.org/drools/release/5.4.0.Final/org.drools.updatesite/ from http://download.jboss.org/jbosstools/updates/stable/indigo/soa-tooling/droolsjbpm/5.4.0.Final/ ?

You can achieve this with some shell script at the end of your publishing job in Jenkins:

{code}
ECLIPSERELEASE=indigo
PROJECTNAME=droolsjbpm

SOURCESERVER=tools at filemgmt.jboss.org:/downloads_htdocs
SOURCEPATH=/drools/release

DESTINATION=tools at filemgmt.jboss.org:/downloads_htdocs/tools/updates/stable/${ECLIPSERELEASE}/soa-tooling

PROJECTVERSION=$(echo "ls *.Final" | sftp ${SOURCESERVER}${SOURCEPATH} 2>&1 | grep "\.\+Final" | grep -v sftp | sort | tail -1); PROJECTVERSION=${PROJECTVERSION%%/*}; echo ${PROJECTVERSION}

# if folder already exists, sftp will throw an error but should still be able to proceed
echo "mkdir ${PROJECTNAME}" | sftp ${DESTINATION}

# symlinking appears to only works with relative paths
echo "ln ../../../../../..${SOURCEPATH}/${PROJECTVERSION}/org.drools.updatesite ${PROJECTVERSION}" | sftp ${DESTINATION}/${PROJECTNAME}/

echo "Click here: http://download.jboss.org/jbosstools/updates/stable/${ECLIPSERELEASE}/soa-tooling/${PROJECTNAME}/${PROJECTVERSION}"
{code}

Alternatively, instead of symlink, could also fetch from one site & post to the other (uses twice as much disk space, however)
{code}
rsync -aPz --rsh=ssh --protocol=28 ${SOURCESERVER}${SOURCEPATH}/${PROJECTVERSION}/org.drools.updatesite/* /tmp/org.drools.updatesite-${PROJECTVERSION}
rsync -aPz --rsh=ssh --protocol=28 --delete /tmp/org.drools.updatesite-${PROJECTVERSION}/* ${DESTINATION}/${PROJECTNAME}/${PROJECTVERSION}/
# cleanup
rm -fr /tmp/org.drools.updatesite-${PROJECTVERSION}

echo "Click here: http://download.jboss.org/jbosstools/updates/stable/${ECLIPSERELEASE}/soa-tooling/${PROJECTNAME}/${PROJECTVERSION}"
{code}
                
      was (Author: nickboldt):
    Would it be possible to symlink your content in http://download.jboss.org/drools/release/5.4.0.Final/org.drools.updatesite/ from http://download.jboss.org/jbosstools/updates/stable/indigo/soa-tooling/droolsjbpm/5.4.0.Final/ ?

You can achieve this with some shell script at the end of your publishing job in Jenkins:

{code}
ECLIPSERELEASE=indigo
PROJECTNAME=droolsjbpm

SOURCESERVER=tools at filemgmt.jboss.org:/downloads_htdocs
SOURCEPATH=/drools/release

DESTINATION=tools at filemgmt.jboss.org:/downloads_htdocs/tools/updates/stable/${ECLIPSERELEASE}/soa-tooling

PROJECTVERSION=$(echo "ls *.Final" | sftp ${SOURCESERVER}${SOURCEPATH} 2>&1 | grep "\.\+Final" | grep -v sftp | sort | tail -1); PROJECTVERSION=${PROJECTVERSION%%/*}; echo ${PROJECTVERSION}

# if folder already exists, sftp will throw an error but should still be able to proceed
echo "mkdir ${PROJECTNAME}" | sftp ${DESTINATION}

# symlinking appears to only works with relative paths
echo "ln ../../../../../..${SOURCEPATH}/${PROJECTVERSION}/org.drools.updatesite ${PROJECTVERSION}" | sftp ${DESTINATION}/${PROJECTNAME}/

echo "Click here: http://download.jboss.org/jbosstools/updates/stable/${ECLIPSERELEASE}/soa-tooling/${PROJECTNAME}/${PROJECTVERSION}"
{code}

Alternatively, instead of symlink, could also fetch from one site & post to the other (uses twice as much disk space, however)
{code}
rsync -aPz --rsh=ssh --protocol=28 ${SOURCESERVER}${SOURCEPATH}/${PROJECTVERSION}/org.drools.updatesite/* /tmp/org.drools.updatesite-${PROJECTVERSION}
rsync -aPz --rsh=ssh --protocol=28 --delete /tmp/org.drools.updatesite-${PROJECTVERSION}/* ${DESTINATION}/${PROJECTNAME}/${PROJECTVERSION}/
# cleanup
rm -fr /tmp/org.drools.updatesite-${PROJECTVERSION}
{code}
                  
> publish org.drools.updatesite-*-assembly.zip contents to download.jboss.org so it can be used by end-users and linked from JBoss Central
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3470
>                 URL: https://issues.jboss.org/browse/JBRULES-3470
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-eclipse
>    Affects Versions: 5.3.1.Final, 5.4.0.CR1
>            Reporter: Nick Boldt
>            Assignee: Geoffrey De Smet
>             Fix For: 5.4.0.Final
>
>
> Currently the only ways to get drools/jbpm 5 plugins installed into Eclipse are to:
> a) download the org.drools.updatesite-*-assembly.zip zip from Nexus, or 
> b) unpack the droolsjbpm-tools-distribution-*.zip linked from http://www.jboss.org/drools/downloads, or
> c) use the nightly staging site for JBT  SOA Tooling http://download.jboss.org/jbosstools/updates/nightly/soa-tooling/trunk/
> d) use the nightly staging site for JBDS SOA Tooling http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_trunk.soa-tooling.updatesite/product-soa/
> Since the JBT site (c) is going away, and (a) and (b) are a relative pain in the butt, we need a new unpacked site, eg., under here:
> http://download.jboss.org/drools/updates/
> or
> http://download.jboss.org/drools/releases/
> ----
> For JBoss Tools, the convention we use is:
> http://download.jboss.org/jbosstools/updates/stable/ (releases)
> http://download.jboss.org/jbosstools/updates/development/ (milestones and candidate releases)
> http://download.jboss.org/jbosstools/updates/nightly/ (bleeding edge CI builds)
> http://download.jboss.org/jbosstools/updates/ (see this page for further discussion of the build types)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jboss-jira mailing list