[jbosstools-issues] [JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-21012 at 11/4/15 11:08 AM:
--------------------------------------------------------------

To get value out of deploying JBT components' update sites to Nexus,

a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947

b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits

c) releng & QE need tools to audit when a component lead forgets to do (a) and (b)

d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS

[1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/index.html

-----

We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with:

* 4.3.0.Alpha1
* 4.3.0.Alpha2
* 4.3.0.Beta1
* 4.3.0.Beta2
* 4.3.0.CR1
* 4.3.0.Final/GA

we might use

* 4.3.011 (1 = Alpha, 11 = Alpha1)
* 4.3.012
* 4.3.051 (5 = Beta, 51 = Beta1)
* 4.3.052
* 4.3.091 (9 = CR/Final/GA)
* 4.3.092

then for 4.3.1 maintenance...

* 4.3.151 (51 = Beta1)
* 4.3.152 (52 = Beta2)
* 4.3.191 (91 = CR1)
* 4.3.192 (92 = CR2, if needed)

By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily.

So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351. 

Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1$\{BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field.




was (Author: nickboldt):
To get value out of deploying JBT components' update sites to Nexus,

a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947

b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits

c) releng & QE need tools to audit when a component lead forgets to do (a) and (b)

d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS

[1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/index.html

-----

We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with:

* 4.3.0.Alpha1
* 4.3.0.Alpha2
* 4.3.0.Beta1
* 4.3.0.Beta2
* 4.3.0.CR1
* 4.3.0.Final/GA

we might use

* 4.3.011 (1 = Alpha, 11 = Alpha1)
* 4.3.012
* 4.3.051 (5 = Beta, 51 = Beta1)
* 4.3.052
* 4.3.091 (9 = CR/Final/GA)
* 4.3.092

then for 4.3.1 maintenance...

* 4.3.151 (51 = Beta1)
* 4.3.152 (52 = Beta2)
* 4.3.191 (91 = CR1)
* 4.3.192 (92 = CR2, if needed)

By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily.

So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351. 

Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1${BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field.



> Why do we deploy JBT components to Nexus snapshots repo?
> --------------------------------------------------------
>
>                 Key: JBIDE-21012
>                 URL: https://issues.jboss.org/browse/JBIDE-21012
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build, updatesite
>    Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo.
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ?



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)