[JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:26 PM:
--------------------------------------------------------------
Pros:
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
Cons:
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in {WORKSPACE}, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
was (Author: nickboldt):
Pros:
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
Cons:
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in ${WORKSPACE}, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
> Key: JBIDE-13316
> URL: https://issues.jboss.org/browse/JBIDE-13316
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:26 PM:
--------------------------------------------------------------
Pros:
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
Cons:
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
was (Author: nickboldt):
Pros:
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
Cons:
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in {WORKSPACE}, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
> Key: JBIDE-13316
> URL: https://issues.jboss.org/browse/JBIDE-13316
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:26 PM:
--------------------------------------------------------------
*Pros:*
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
*Cons:*
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
was (Author: nickboldt):
Pros:
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
Cons:
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
> Key: JBIDE-13316
> URL: https://issues.jboss.org/browse/JBIDE-13316
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:27 PM:
--------------------------------------------------------------
*Option 1*
*If in same repo*, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
*Option 2*
*If in different branches*, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
was (Author: nickboldt):
*Pros:*
If in same repo, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
*Cons:*
If in different branches, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
> Key: JBIDE-13316
> URL: https://issues.jboss.org/browse/JBIDE-13316
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13316) Improve versioning for TP using standard Maven way
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13316?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-13316 at 12/17/12 3:27 PM:
--------------------------------------------------------------
*{color:red}If in same repo{color}*, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
*{color:red}If in different branches{color}*, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
---
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
was (Author: nickboldt):
*Option 1*
*If in same repo*, can build both locally at the same time and compare the output results locally - eg., how are the list of IUs (and versions) different?
Could have 1 job to build both TPs; both folders would simply be checked out and build in series.
*Option 2*
*If in different branches*, have to copy local repo TWICE in order to be able to diff resolved target platform sites (target/ folder). Switching branches might cause resolved TP to be trashed?
More complicated to build / bootstrap the TPs locally.
Could have 1 job to build both TPs; would need to ensure branches were checked out to different folders in WORKSPACE, just as local dev would need to do. Could then build in series.
I personally don't like "tp-" as a prefix, as it's vague. Why not "target-" or "target-platform-" ?
Also not really keen to change stuff that works in the Juno stream. Why wouldn't we refactor/fix/improve this for Kepler, then MAYBE backport changes to 6.0.1/6.0.2 if needed? This issue is targeted for Kepler (4.1.0.Alpha1) but you're making changes that affect the 6.x stream. *:confused:*
> Improve versioning for TP using standard Maven way
> --------------------------------------------------
>
> Key: JBIDE-13316
> URL: https://issues.jboss.org/browse/JBIDE-13316
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: target-platform
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> Currently, we deal with explicit versions in folder names that make it confusing to understand how target-platforms are versioned.
> Instead, we should use usual Maven way and Git branches: one Git branch for each version of TPs.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13308) Remove cascading
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13308?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13308:
------------------------------------
Just be aware that by unlinking jobs, the Build Pipeline plugin is no longer a useful option for us. Without upstream/downstream jobs, there's no pipeline. (The upstream/downstream columns in our views will also become useless.
http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Trunk/por...
I would argue that we still want:
{quote}
change to (parent) --> triggers rebuild of target platforms
change to central/maven/examples --> triggers JBT aggregate
change to JBT target platform --> triggers matching JBDS target platform
change to (JBT aggregate or JBDS target platform) --> triggers JBDS
change to (Base or Server) --> triggers JBT webtools aggregate
change to JBT aggregate --> triggers JBT coretests aggregate
{quote}
> Remove cascading
> ----------------
>
> Key: JBIDE-13308
> URL: https://issues.jboss.org/browse/JBIDE-13308
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: Build/Releng
> Reporter: Mickael Istria
> Assignee: Nick Boldt
> Fix For: 4.1.0.Alpha1
>
>
> Unlink job by disabling cascading/blocked by upstream. That will make us able to het faster feedback and consume/depend on less Jenkins resources.
--
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
13 years, 4 months
[JBoss JIRA] (JBIDE-13307) Set up the "All JBoss Tools" build+test
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13307?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13307:
------------------------------------
AFAICT the Build Pipeline Plugin is simply a view -- it doesn't do anything in terms of sequencing or triggering builds. It just shows you how you have your jobs interconnected (via other plugins/job config), and which build #s were used within a given flow. I admit seeing which build # triggered which downstream build # is handy, but you can find that information other ways (admittedly w/ more clicks). So +1 for single-view usability.
It also adds the option to block and wait for a manually triggered build, eg., if you wanted to script the workflow that every successful JBDS build would wait for user input before publishing to production server. That might be handy for pushing bits to QE via a job instead of a semi-manual workflow; OTOH, do we want builds being pushed to QE via a single button? or via a gatekeeper? +0 for this feature.
-----
I'm also not convinced that we should be building all the source in a single operation (with tests!) because some jobs already take 4hrs+; combining them all into a single one could take >8hrs and could also be more failure prone due to memory overload or git checkout failure. If 1 build in 15 fails because of Jenkins snafu (memory, bandwidth, nfs, http://, git://), the other 15 might succeed and it's only a 30 min job that needs to be kicked again. If the ALL-IN-ONE-UBER-BUILD fails, you need to wait another 8hrs for a respin. Having lived through JBDS 4, I never want to be beholden to a process that takes so long and could potentially fail in so many time-wasting ways.
So, -100 for the effort required to set this up, since it will duplicate what we'd have w/ the 15 component jobs, probably be more failure-prone, and produce something we wouldn't want to publish anyway.
> Set up the "All JBoss Tools" build+test
> ---------------------------------------
>
> Key: JBIDE-13307
> URL: https://issues.jboss.org/browse/JBIDE-13307
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: Build/Releng
> Reporter: Mickael Istria
> Fix For: 4.1.0.Alpha1
>
>
> This job would take all JBoss Tools and build everything at once. It can be used to ensure everything builds together.
--
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
13 years, 4 months