[
https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi...
]
Nick Boldt edited comment on JBIDE-11524 at 4/16/12 10:13 AM:
--------------------------------------------------------------
Renaming stuff doesn't guarantee it won't still be seen as black magic. But
conceptually I agree we want to make this simpler.
So, I see a number of use cases:
{code}
a) build against local sources (mvn install -f build/pom.xml
-Pfoo-bootstrap)
b) build against binaries; upstream staging composite site (mvn install -Pstaging) [also
the mode that Jenkins needs for Core]
c) build against binaries; upstream nightly aggregate site (mvn install -Pnightly) [also
the mode that Jenkins needs for SOA]
d) build against binaries; upstream dev milestone agg site (mvn install)
[average user?]
e) build against binaries; upstream previous release (mvn install -Prelease) [?]
{code}
Are we assuming that there should be two modes for suffixes too? eg., for CI builds we use
the usual vTIMESTAMP-Hxxx-SUFFIX, but for releases we use something different?
I don't understand what you mean by "The content of nightly/snapshot is then
committed proper versioned parent pom's in the branches/trunk." Are you
suggesting that every time we spin a nightly aggregate we commit a change to the parent
pom in SVN?
As to the comment "each branch has the same commands to use", that's
currently true (I've even backported naming convention changes to the 3.2.x branch
from the 3.3.x one) but if you start creating new profiles and renaming variables,
you'll end up with a new set of commands in 3.3 vs. 3.2.x.
However, we could get to a point where -Pnightly if run in trunk would point at a
different set of upstream sites than -Pnightly from the latest stable branch (ie., after
branching for Beta3). In fact that's how things work today (though using longer
profile names).
To continue to achieve this "smart profile" functionality, however, we either
need to change all the root poms every time we branch to point a new version of the parent
pom in Nexus (eg., parent pom version 3.3.0.Beta1 vs. parent pom version 3.3.0.trunk), or
rebuild it locally every time as part of each job in Jenkins (as we do for 3.2.x and did
for 3.3.0.Beta1 & Beta2). This will ensure that the local version from the correct
branch is used instead of the problem we have now where BOTH trunk and the forthcoming
Beta3 branch COULD see the same version of the parent pom (0.0.4-SNAPSHOT) in nexus and
get the wrong variables (URLs, suffixes).
was (Author: nickboldt):
Renaming stuff doesn't guarantee it won't still be seen as black magic. But
conceptually I agree we want to make this simpler.
So, I see a number of use cases:
{code}
a) build against local sources (mvn install -f build/pom.xml -Pfoo-bootstrap)
b) build against binaries; upstream staging composite site (mvn install -Pstaging) [also
the mode that Jenkins needs for Core]
c) build against binaries; upstream nightly aggregate site (mvn install -Pnightly) [also
the mode that Jenkins needs for SOA]
d) build against binaries; upstream dev milestone agg site (mvn install)
[average user?]
e) build against binaries; upstream previous release (mvn install -Prelease) [?]
{code}
Are we assuming that there should be two modes for suffixes too? eg., for CI builds we use
the usual vTIMESTAMP-Hxxx-SUFFIX, but for releases we use something different?
I don't understand what you mean by "The content of nightly/snapshot is then
committed proper versioned parent pom's in the branches/trunk." Are you
suggesting that every time we spin a nightly aggregate we commit a change to the parent
pom in SVN?
As to the comment "each branch has the same commands to use", that's
currently true (I've even backported naming convention changes to the 3.2.x branch
from the 3.3.x one) but if you start creating new profiles and renaming variables,
you'll end up with a new set of commands in 3.3 vs. 3.2.x.
However, we could get to a point where -Pnightly if run in trunk would point at a
different set of upstream sites than -Pnightly from the latest stable branch (ie., after
branching for Beta3). In fact that's how things work today (though using longer
profile names).
To continue to achieve this "smart profile" functionality, however, we either
need to change all the root poms every time we branch to point a new version of the parent
pom in Nexus (eg., parent pom version 3.3.0.Beta1 vs. parent pom version 3.3.0.trunk), or
rebuild it locally every time as part of each job in Jenkins (as we do for 3.2.x and did
for 3.3.0.Beta1 & Beta2). This will ensure that the local version from the correct
branch is used instead of the problem we have now where BOTH trunk and the forthcoming
Beta3 branch COULD see the same version of the parent pom (0.0.4-SNAPSHOT) in nexus and
get the wrong variables (URLs, suffixes).
Rename jobs, sites, profiles, variables... to clearer names (remove
reference to nightly)
-----------------------------------------------------------------------------------------
Key: JBIDE-11524
URL:
https://issues.jboss.org/browse/JBIDE-11524
Project: Tools (JBoss Tools)
Issue Type: Enhancement
Components: Build/Releng
Reporter: Mickael Istria
Assignee: Nick Boldt
Priority: Minor
nightly is a very confusing name, that does not reflect at all what really happens.
We should prefer using "staging" in variable, profiles, jobs, url... to make it
clearer
For instance,
* jbosstools-nightly-staging-composite -> jbosstools-staging-composite
* jboostools-nightly -> jbosstools-staging-aggregate
--
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