[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11524: ---------------------------------------- nightly is "every night", it is not what we have. If you don't like staging, what about snapshot or latest? What is confusing is having "nightly" for something that is not nightly, but that is run at least 3 times a day. I am also in favor of changing the URL. Nightly is very meaningless and when it comes to make things simpler, using accurate wording is one of the first things to work on. Ok, so what about "staging-composite" and "aggregate-snapshot" ? -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-11524: --------------------------------------------- The current names are way too long to be useful. its redundant to have "jbosstools-" in them and composite/aggregate is irrelevant IMO. It's good to know, but functionally it does not matter. nightly is for sure not staging - staging is something you use before going to a release. latest doesn't say anything about what it is. nightly at least has a clear signal its not the latest release nor is it something staged. I agree its not a perfect name, and even though snapshot is a bit "too much like maven" it's probably not the worst name to use. btw. to be clear if we did start doing this the nightly site would still need to be there for old builds to work AFAIK thus *snapshot* should be an additional place, possibly just a symbolic link for nightly ? -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-11524: --------------------------------------------- Snapshot is making sense but lets see what we end up with. about jbosstools-nightly-staging-composite then I'm not fully understanding why this is not just snapshot too ? Ah, one is each component the other is all merged, now I get it - sorry for being slow ;) snapshot-components snapshot-all maybe ? -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11524: ---------------------------------------- The idea is just to make things clearer to make the build easier to consume locally. I think most devs are not aware of this issue because they don't really use the build and snapshots update-sites because for them it is like black magic. But if we want developers to use it more and more in order to get better productivity and quality, having good names is at least as important as having good documentation. -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-11524: --------------------------------------------- note, I agree I don't think we should change these things blindly without actually considering what options it actually make sense to expose - right now I feel there are too many options or wrong options. What I would expect is that each branch (trunk, stable, 3.3.x, 3.4.x etc going forward) has the same commands to use. i.e. Default for dev should just be: mvn clean install Doing a release build: mvn clean install -Prelease Doing a build with some different sites: add -Pnightly or -Psnapshot for adding the latest built repo to the list of repos. The content of nightly/snapshot is then committed proper versioned parent pom's in the branches/trunk. -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11524: ------------------------------------ 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: 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) [?] 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). -- 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

[ 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). -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11524: ------------------------------------ That's one of the big reasons for rebuilding parent pom every time we build (rather than fetching from Nexus). Guarantees you've got the right source for the file rather than just "latest in Nexus" which might be wrong. Also minimizes churn in SVN every time we branch, because we don't have to commit changes to every root pom just so it can build against the correct branched version of the parent. As it is there's a ton of things to do to prepare a new branch: https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11524: ------------------------------------ Staging is not for intermediate snapshots. It's for assembling nightly snapshots into an aggregate nightly snapshot. http://en.wikipedia.org/wiki/Staging_area#In_data_warehouse Re: parent pom changes: https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12684741&... -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11524: ------------------------------------ Max, if you don't like the term "staging" as applied here to composite nightlies, why didn't you say something over a year ago when we started using it? Why is it confusing now, when it's been perfectly acceptable for the whole of the JBDS 4 cycle and now nearly all of the JBDS 5 cycle too? Would it make sense to change this for the JBDS 6 cycle, but leave things as is for 4.x and 5.x? -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11524: ---------------------------------------- I think that's my fault ;) I'm a kind of "naming integrist", so I'm the one to blame for this debate. But if nightly is confusing for me, and staging is confusing for Max, then it means these words are confusing to other people too and create some lack of understanding to them. So this debate is useful. the priority of this ticket is marked as minor. I agree on its a low-priority. Although we won't change it now, it is good to gather opinions and make a decision for these names ASAP. Finding good names is currently a background task. -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-11524: ------------------------------- Fix Version/s: 3.4.x (was: 3.3.0.CR1) -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11524: ---------------------------------------- And * jbosstools-continuous * jbosstools-snapshot * jbosstools-milestone * jbosstools-release ? -- 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

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11524: ------------------------------------ Assuming we are just talking about simplifying the profile names in the parent pom, then... I like this this simpler scheme. HOWEVER... a) How is continuous different from snapshot? Are you assuming the staging composite site is "continuous" as it changes every time a component is respun, whereas snapshot is when the JBT aggregate (nightly) is respun? b) where do we use milestone or release today? c) where does the notion of an "integration" site fit into this? --- Here are the repos we currently need to reference by some simpler name: * continuously evolving trunk composite site - http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk/ * aggregate unstable trunk snapshot site - http://download.jboss.org/jbosstools/updates/nightly/core/trunk/ * continuously evolving stable branch composite site - http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.0.... * aggregate stable branch snapshot site - http://download.jboss.org/jbosstools/updates/nightly/core/4.0.juno/ And going forward with the git migration (JBIDE-12475) we've talked about creating two more sites to facilitate cross-component integration: * developer-released integration builds in a composite site - http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.0.... * aggregate integration snapshot site - http://download.jboss.org/jbosstools/updates/nightly/core/4.0.juno_integr... So how would you name those 6 sites? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11524?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-11524: ------------------------------- Fix Version/s: LATER (was: 4.0.0.Alpha2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira