[ https://issues.jboss.org/browse/JBIDE-12475?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-12475: ------------------------------- Description: As part of the planned migration to git [0] it's been suggested that we combine some of the existing components into larger groups [1] so that it's more manageable in terms of checking out sources and tagging/branching [2]. Because 25 is a large number, and 1 is a small number, and we need some happy compromise. Here's my proposal for how to divide the JBT 4.0 sources into 7 github repos (chunks), comprising 4 tiers of dependency. This is akin to the +0, +1, +2, +3 labels assigned to projects within the annual Eclipse release trains [3], used to define delivery times based on dependencies between projects. {code:title=TIER 0: no upstream JBoss.org chunks} Base = tests + common + usage {code} == TIER 1: 1 upstream chunk, Base == AppServer = openshift + as + archives + jmx -> depends on Base Hibernate/Birt/Freemarker = hibernate + birt + freemarker -> depends on Base Visual Editing = vpe + xulrunner + gwt + struts + jsf + jst + cdi -> depends on Base Web Services = WS + Forge -> Depends on Base == TIER 2: 4 upstream chunks == Seam/Runtime = Seam + Runtime -> depends on Hib + Vis + AppServer + Base == TIER 3: 5 upstream chunks == Central/Examples/Maven/Portlet = central + examples + maven + portlet -> depends on Seam/Runtime + Hib + Vis + AppServer + Base I'm not thrilled with the names of the chunks, as something like "Central/Examples/Maven/Portlet" doesn't exactly roll off the tongue. If you have better names for the chunks, please suggest them. But regardless of name, I think the above separation of concerns, and the implied build sequence workflow makes a lot of sense. [0] http://tinyurl.com/git-migration-plan [1] http://ether-man.rhcloud.com/p/build.next [2] http://ether-man.rhcloud.com/p/jbosstools-2012-08-23 [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Milestones_and_Rel... - "These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3." was: As part of the planned migration to git [0] it's been suggested that we combine some of the existing components into larger groups [1] so that it's more manageable in terms of checking out sources and tagging/branching [2]. Because 25 is a large number, and 1 is a small number, and we need some happy compromise. Here's my proposal for how to divide the JBT 4.0 sources into 7 github repos (chunks), comprising 4 tiers of dependency. This is akin to the +0, +1, +2, +3 labels assigned to projects within the annual Eclipse release trains [3], used to define delivery times based on dependencies between projects. == TIER 0: no upstream JBoss.org chunks == Base = tests + common + usage == TIER 1: 1 upstream chunk, Base == AppServer = openshift + as + archives + jmx -> depends on Base Hibernate/Birt/Freemarker = hibernate + birt + freemarker -> depends on Base Visual Editing = vpe + xulrunner + gwt + struts + jsf + jst + cdi -> depends on Base Web Services = WS + Forge -> Depends on Base == TIER 2: 4 upstream chunks == Seam/Runtime = Seam + Runtime -> depends on Hib + Vis + AppServer + Base == TIER 3: 5 upstream chunks == Central/Examples/Maven/Portlet = central + examples + maven + portlet -> depends on Seam/Runtime + Hib + Vis + AppServer + Base I'm not thrilled with the names of the chunks, as something like "Central/Examples/Maven/Portlet" doesn't exactly roll off the tongue. If you have better names for the chunks, please suggest them. But regardless of name, I think the above separation of concerns, and the implied build sequence workflow makes a lot of sense. [0] http://tinyurl.com/git-migration-plan [1] http://ether-man.rhcloud.com/p/build.next [2] http://ether-man.rhcloud.com/p/jbosstools-2012-08-23 [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Milestones_and_Rel... - "These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3." -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ Per JBIDE-12447, Runtime component may in fact be able to move into the Base chunk instead of the Seam one; if that happens we could move Seam into the Central/Maven chunk and have 1 less git repo with which to contend. -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 8/27/12 2:12 PM: ------------------------------------------------------------- Denis' variation involves 13 chunks: !git-decomposition.png! [1] Common = tests + common + usage [1] Xulrunner = xulrunner [2] AppServer = as + archives + jmx -> depends on Common [2] Freemarker = freemarker -> depends on Common [2] Datatools = hibernate + birt -> depends on Common [2] GWT = gwt -> depends on Common [2] Web Services = WS -> depends on Common [2] Forge = Forge -> depends on Common [3] OpenShift = OpenShift -> depends on Common + AppServer [5] JEE = vpe + struts + jsf + jst + cdi + seam + portlet -> depends on Xulrunner + Common + AppServer + Datatools [6] Runtime = Runtime -> depends on Common + AppServer + Datatools + JEE + Xulrunner [7] Maven = maven -> depends on Runtime + JEE + Common + AppServer + Datatools + Xulrunner [9] Central = central + examples -> depends on Maven + Freemarker + Runtime + JEE + Common + AppServer + Datatools + Xulrunner was (Author: nickboldt): Denis' variation involves 10 chunks: !git-decomposition.png! -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 8/27/12 2:16 PM: ------------------------------------------------------------- Denis' variation involves 13 chunks: !git-decomposition.png! {code:title=TIER 0: no upstream JBoss.org chunks} Common = tests + common + usage Xulrunner = xulrunner {code} {code:title=TIER 1: 1 upstream chunk, Common or Xulrunner} AppServer = as + archives + jmx -> depends on Common Freemarker = freemarker -> depends on Common Datatools = hibernate + birt -> depends on Common GWT = gwt -> depends on Common Web Services = WS -> depends on Common Forge = Forge -> depends on Common {code} {code:title=TIER 2: 2 upstream chunks} OpenShift = OpenShift -> depends on Common + AppServer {code} {code:title=TIER 3: 5 upstream chunks} JEE = vpe + struts + jsf + jst + cdi + seam + portlet -> depends on Xulrunner + Common + AppServer + Datatools {code} {code:title=TIER 4: 6 upstream chunks} Runtime = Runtime -> depends on Common + AppServer + Datatools + JEE + Xulrunner {code} {code:title=TIER 5: 7 upstream chunks} Maven = maven -> depends on Runtime + JEE + Common + AppServer + Datatools + Xulrunner {code} {code:title=TIER 6: 9 upstream chunks} Central = central + examples -> depends on Maven + Freemarker + Runtime + JEE + Common + AppServer + Datatools + Xulrunner {code} was (Author: nickboldt): Denis' variation involves 13 chunks: !git-decomposition.png! {code:title=TIER 0: no upstream JBoss.org chunks} [1] Common = tests + common + usage [1] Xulrunner = xulrunner {code} {code:title=TIER 1: 1 upstream chunk, Common or Xulrunner} [2] AppServer = as + archives + jmx -> depends on Common [2] Freemarker = freemarker -> depends on Common [2] Datatools = hibernate + birt -> depends on Common [2] GWT = gwt -> depends on Common [2] Web Services = WS -> depends on Common [2] Forge = Forge -> depends on Common {code} {code:title=TIER 2: 2 upstream chunks} [3] OpenShift = OpenShift -> depends on Common + AppServer {code} {code:title=TIER 3: 5 upstream chunks} [5] JEE = vpe + struts + jsf + jst + cdi + seam + portlet -> depends on Xulrunner + Common + AppServer + Datatools {code} {code:title=TIER 4: 6 upstream chunks} [6] Runtime = Runtime -> depends on Common + AppServer + Datatools + JEE + Xulrunner {code} {code:title=TIER 5: 7 upstream chunks} [7] Maven = maven -> depends on Runtime + JEE + Common + AppServer + Datatools + Xulrunner {code} {code:title=TIER 6: 9 upstream chunks} [9] Central = central + examples -> depends on Maven + Freemarker + Runtime + JEE + Common + AppServer + Datatools + Xulrunner {code} -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-12475: ------------------------------- Description: As part of the planned migration to git [0] it's been suggested that we combine some of the existing components into larger groups [1] so that it's more manageable in terms of checking out sources and tagging/branching [2]. Because 25 is a large number, and 1 is a small number, and we need some happy compromise. Here's my proposal for how to divide the JBT 4.0 sources into 7 github repos (chunks), comprising 4 tiers of dependency. This is akin to the +0, +1, +2, +3 labels assigned to projects within the annual Eclipse release trains [3], used to define delivery times based on dependencies between projects. {code:title=TIER 0: no upstream JBoss.org chunks} Base = tests + common + usage {code} {code:title=TIER 1: 1 upstream chunk, Base} AppServer = openshift + as + archives + jmx + ws -> depends on Base Hibernate/Birt/Freemarker = hibernate + birt + freemarker -> depends on Base Visual Editing = vpe + xulrunner + gwt + struts + jsf + jst + cdi -> depends on Base Forge = forge -> Depends on Base {code} {code:title=TIER 2: 4 upstream chunks} Seam/Runtime = Seam + Runtime -> depends on Hib + Vis + AppServer + Base {code} {code:title=TIER 3: 5 upstream chunks} Central/Examples/Maven/Portlet = central + examples + maven + portlet -> depends on Seam/Runtime + Hib + Vis + AppServer + Base {code} I'm not thrilled with the names of the chunks, as something like "Central/Examples/Maven/Portlet" doesn't exactly roll off the tongue. If you have better names for the chunks, please suggest them. But regardless of name, I think the above separation of concerns, and the implied build sequence workflow makes a lot of sense. [0] http://tinyurl.com/git-migration-plan [1] http://ether-man.rhcloud.com/p/build.next [2] http://ether-man.rhcloud.com/p/jbosstools-2012-08-23 [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Milestones_and_Rel... - "These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3." was: As part of the planned migration to git [0] it's been suggested that we combine some of the existing components into larger groups [1] so that it's more manageable in terms of checking out sources and tagging/branching [2]. Because 25 is a large number, and 1 is a small number, and we need some happy compromise. Here's my proposal for how to divide the JBT 4.0 sources into 7 github repos (chunks), comprising 4 tiers of dependency. This is akin to the +0, +1, +2, +3 labels assigned to projects within the annual Eclipse release trains [3], used to define delivery times based on dependencies between projects. {code:title=TIER 0: no upstream JBoss.org chunks} Base = tests + common + usage {code} {code:title=TIER 1: 1 upstream chunk, Base} AppServer = openshift + as + archives + jmx -> depends on Base Hibernate/Birt/Freemarker = hibernate + birt + freemarker -> depends on Base Visual Editing = vpe + xulrunner + gwt + struts + jsf + jst + cdi -> depends on Base Web Services = WS + Forge -> Depends on Base {code} {code:title=TIER 2: 4 upstream chunks} Seam/Runtime = Seam + Runtime -> depends on Hib + Vis + AppServer + Base {code} {code:title=TIER 3: 5 upstream chunks} Central/Examples/Maven/Portlet = central + examples + maven + portlet -> depends on Seam/Runtime + Hib + Vis + AppServer + Base {code} I'm not thrilled with the names of the chunks, as something like "Central/Examples/Maven/Portlet" doesn't exactly roll off the tongue. If you have better names for the chunks, please suggest them. But regardless of name, I think the above separation of concerns, and the implied build sequence workflow makes a lot of sense. [0] http://tinyurl.com/git-migration-plan [1] http://ether-man.rhcloud.com/p/build.next [2] http://ether-man.rhcloud.com/p/jbosstools-2012-08-23 [3] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#Milestones_and_Rel... - "These delivery times are based on the dependencies between projects. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and +3 coming last (EPP). Projects themselves decide if they are +0, +1, +2, or +3." Note that in my previous statement of this issue, I had incorrectly omitted the dependency of WS on AS, so to alleviate that I've moved WS into the AppServer chunk. Forge now stands alone. -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-12475: ---------------------------------- Attachment: git-decomposition.png bigger-components.png -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-12475: --------------------------------------- one more iteration is !git-decomposition.png! New components releations !bigger-components.png! -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin edited comment on JBIDE-12475 at 8/27/12 6:21 PM: ---------------------------------------------------------------- one more iteration is !git-decomposition1.png! New components releations !bigger-components.png! was (Author: dgolovin): one more iteration is !git-decomposition.png! New components releations !bigger-components.png! -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin reassigned JBIDE-12475: ------------------------------------- Assignee: Denis Golovin (was: Nick Boldt) -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-12475: --------------------------------------- If I follow your explanation then: * 13-8 so-so * 9 nice * 6-7 is better * 2-5 even better * 1 is perfect Well, that is not true IMO. Problem is that we have much more components than developers and what I was trying to achieve is bigger components (group of related smaller ones) and number of components are close to number of people involved into project. I like first version with 13 chunks, when we would have (below list of components and component leads) common - ?? (probably should be group of people) javaee - Alexey forge - Koen hibernatetools - max central - Snjesana as - rob runtime - Snjezana maven - fred xulrunner - yahor freemarker - victor gwt - me ws - Brian/Xavier openshift - andre checkout process is even simpler with 13 components, because size you need to checkout is smaller. As for what you need to build jee component it is simple enough for all options. Just fetch component and build it, rest of dependencies comes from remote p2 repositories. If there is need in something new in common, open jira issue, submit pull request with new functionality with tests (or just wait for implementation), wait for new version of common is released, then release your component referenced to new version of common. It means most of the time you work only with single component source if you don't want to be involved into development of components you depend on. -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-12475: ---------------------------------- Attachment: git-decomposition-bigger.png updated new components diagram -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ If all 13 chunks are actively releasing changes / new features in the next year or so, one might argue that fewer chunks are needed because all the chunks (and their contained components) are releasing in lock-step -- as they have for the past few years. If however, some of the chunks are effectively "done" or "maintenance only", then having them separated out into their own repo (eg., Xulrunner) makes sense because it's code that no one has to bother checking out. Beyonf Xulrunner, are any other components in "maintenance only" mode? -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ Currently assuming we're going to implement repos like this: !https://issues.jboss.org/secure/attachment/12356381/12356381_git-decomposition.png! HOWEVER, we need to make two changes: * runtime no longer depends on seam and as * maven depends on examples, so examples can't be combined w/ central unless maven is also included in that repo. {code} [ERROR] Missing requirement: org.jboss.tools.maven.project.examples.feature.feature.group 1.4.0.qualifier requires 'org.jboss.tools.project.examples.feature.feature.group 1.2.0' but it could not be found {code} -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/1/12 8:31 AM: ------------------------------------------------------------ Currently assuming we're going to implement repos like this: !https://issues.jboss.org/secure/attachment/12356381/git-decomposition.png! HOWEVER, we need to make two changes: * runtime no longer depends on seam and as * maven depends on examples, so examples can't be combined w/ central unless maven is also included in that repo. Suggest we either have 1 repo with Central, Examples, Maven, or 2 repos so that each component can build + release separately {code} [ERROR] Missing requirement: org.jboss.tools.maven.project.examples.feature.feature.group 1.4.0.qualifier requires 'org.jboss.tools.project.examples.feature.feature.group 1.2.0' but it could not be found {code} was (Author: nickboldt): Currently assuming we're going to implement repos like this: !https://issues.jboss.org/secure/attachment/12356381/git-decomposition.png! HOWEVER, we need to make two changes: * runtime no longer depends on seam and as * maven depends on examples, so examples can't be combined w/ central unless maven is also included in that repo. {code} [ERROR] Missing requirement: org.jboss.tools.maven.project.examples.feature.feature.group 1.4.0.qualifier requires 'org.jboss.tools.project.examples.feature.feature.group 1.2.0' but it could not be found {code} -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/5/12 10:29 AM: ------------------------------------------------------------- Currently assuming we're going to implement repos like this: !git-decomposition.png! HOWEVER, we need to make two changes: * runtime no longer depends on seam and as * maven depends on examples, so examples can't be combined w/ central unless maven is also included in that repo. {code} [ERROR] Missing requirement: org.jboss.tools.maven.project.examples.feature.feature.group 1.4.0.qualifier requires 'org.jboss.tools.project.examples.feature.feature.group 1.2.0' but it could not be found {code} Suggest we either have 1 repo with Central, Examples, Maven, or 3 repos so that each component can build + release separately. That would put the github repo count up to 14. was (Author: nickboldt): Currently assuming we're going to implement repos like this: !https://issues.jboss.org/secure/attachment/12356381/git-decomposition.png! HOWEVER, we need to make two changes: * runtime no longer depends on seam and as * maven depends on examples, so examples can't be combined w/ central unless maven is also included in that repo. {code} [ERROR] Missing requirement: org.jboss.tools.maven.project.examples.feature.feature.group 1.4.0.qualifier requires 'org.jboss.tools.project.examples.feature.feature.group 1.2.0' but it could not be found {code} Suggest we either have 1 repo with Central, Examples, Maven, or 3 repos so that each component can build + release separately. That would put the github repo count up to 14. -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-12475: ---------------------------------- Attachment: Components-Final .png -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin updated JBIDE-12475: ---------------------------------- Attachment: Components-Final .png -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/5/12 4:31 PM: ------------------------------------------------------------ Components final diagram & [^Components-Final .gliffy] sourcefile is attached: !Components-Final .png! was (Author: dgolovin): Components final diagram & [^Components-Final%20.gliffy] sourcefile is attached: !Components-Final .png! -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/5/12 4:31 PM: ------------------------------------------------------------ Components final diagram & [^Components-Final%20.gliffy] sourcefile is attached: !Components-Final .png! was (Author: dgolovin): Components final diagram is attached: !Components-Final .png! -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/7/12 7:06 PM: ------------------------------------------------------------ First attempt at git migration: https://github.com/nickboldt/freemarker Seems that I got all the branches and history. Only problem I'm having is trying to merge origin/trunk into HEAD. Any suggestions? Next step... building in Jenkins from origin/trunk git instead of svn, and setting up change tracking: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... was (Author: nickboldt): First attempt at git migration: https://github.com/nickboldt/freemarker Seems that I got all the branches and history. Only problem I'm having is trying to merge origin/trunk into HEAD. Any suggestions? Next step... building in Jenkins from origin/trunk git instead of svn, and setting up change tracking. -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/7/12 7:12 PM: ------------------------------------------------------------ First attempt at git migration: https://github.com/nickboldt/freemarker Seems that I got all the important branches and recent history: {code} * master remotes/origin/HEAD -> origin/master remotes/origin/jbosstools-3.1.x remotes/origin/jbosstools-3.2.x remotes/origin/jbosstools-3.3.x remotes/origin/jbosstools-4.0.0.Alpha1 remotes/origin/master remotes/origin/trunk{code} Only problem I'm having is trying to merge origin/trunk into HEAD. Any suggestions? Also got it building in Jenkins from origin/trunk git instead of svn. Minor adjustments required to paths. https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... Appears to be pulling correct sources: http://download.jboss.org/jbosstools/builds/staging/jbosstools-4.0_trunk.... http://download.jboss.org/jbosstools/builds/staging/jbosstools-4.0_trunk.... was (Author: nickboldt): First attempt at git migration: https://github.com/nickboldt/freemarker Seems that I got all the branches and history. Only problem I'm having is trying to merge origin/trunk into HEAD. Any suggestions? Next step... building in Jenkins from origin/trunk git instead of svn, and setting up change tracking: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... http://download.jboss.org/jbosstools/builds/staging/jbosstools-4.0_trunk.... http://download.jboss.org/jbosstools/builds/staging/jbosstools-4.0_trunk.... -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- what commands did you execute to create this repo? I see the branches, but where are the tags showing what was actually released ? (I can see that our jbosstools svn mirror also dont seem to list tags, just branches...but it has many more branches than the one in your current repo ?) -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ * .project was put there to verify that web ui and egit were both in synch and happy from both sides. I will remove it. * I don't see the empty folders in the source mirror either: ** https://github.com/jbosstools/jbosstools-svn-mirror/tree/trunk/freemarker... /empty ** https://github.com/jbosstools/jbosstools-svn-mirror/tree/trunk/freemarker... /freemarker_ide So... we'd need to add .gitkeep to the source SVN, push that to github mirror, and then pull the changes to the fork. Right? * I filtered out everything but the branches for 3.1.x, 3.2.x, 3.3.x, and 4.0.0.Alpha1, along with trunk. Figured you didn't need tags too. Do you want tags too? * Process will be documented once we are clear on the output desired. I'll run through it again to pick up more tags and .gitkeep files. Are you OK with content being in trunk instead of HEAD? -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-12475: ---------------------------------------- Attachment: Components-Final .png -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/11/12 4:14 PM: ------------------------------------------------------------- Source does not include tags, either: https://github.com/jbosstools/jbosstools-svn-mirror/tags I can't invent tags, but I COULD go thru the repositories and tag after the fact if we really need that. Prefer to do it reactively if/when it's ever needed rather than in advance of a need that doesn't exist. Going forward, of course, we'd tag github repos. But do we really need the old ones to be reproduced as part of the migration? --- As to the process for migration, I've documented it as I went thru a _second_ migration - this time for forge - *https://github.com/nickboldt/forge* (The overall process is based on http://stackoverflow.com/questions/359424/detach-subdirectory-into-separa...). *Migration Guide* - https://gist.github.com/3701617 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... *How to use JBDS + EGit to work with JBT sources* - https://gist.github.com/3701624 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... was (Author: nickboldt): Source does not include tags, either: https://github.com/jbosstools/jbosstools-svn-mirror/tags I can't invent tags, but I COULD go thru the repositories and tag after the fact if we really need that. Prefer to do it reactively if/when it's ever needed rather than in advance of a need that doesn't exist. Going forward, of course, we'd tag github repos. But do we really need the old ones to be reproduced as part of the migration? --- As to the process for migration, I've documented it as I went thru a _second_ migration for forge - * https://github.com/nickboldt/forge * (The overall process is based on http://stackoverflow.com/questions/359424/detach-subdirectory-into-separa...). *Migration Guide* - https://gist.github.com/3701617 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... *How to use JBDS + EGit to work with JBT sources* - https://gist.github.com/3701624 or 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 For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/11/12 4:14 PM: ------------------------------------------------------------- Source does not include tags, either: https://github.com/jbosstools/jbosstools-svn-mirror/tags I can't invent tags, but I COULD go thru the repositories and tag after the fact if we really need that. Prefer to do it reactively if/when it's ever needed rather than in advance of a need that doesn't exist. Going forward, of course, we'd tag github repos. But do we really need the old ones to be reproduced as part of the migration? --- As to the process for migration, I've documented it as I went thru a _second_ migration - this time for forge - https://github.com/nickboldt/forge (The overall process is based on http://stackoverflow.com/questions/359424/detach-subdirectory-into-separa...). *Migration Guide* - https://gist.github.com/3701617 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... *How to use JBDS + EGit to work with JBT sources* - https://gist.github.com/3701624 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... was (Author: nickboldt): Source does not include tags, either: https://github.com/jbosstools/jbosstools-svn-mirror/tags I can't invent tags, but I COULD go thru the repositories and tag after the fact if we really need that. Prefer to do it reactively if/when it's ever needed rather than in advance of a need that doesn't exist. Going forward, of course, we'd tag github repos. But do we really need the old ones to be reproduced as part of the migration? --- As to the process for migration, I've documented it as I went thru a _second_ migration - this time for forge - *https://github.com/nickboldt/forge* (The overall process is based on http://stackoverflow.com/questions/359424/detach-subdirectory-into-separa...). *Migration Guide* - https://gist.github.com/3701617 or https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/2... *How to use JBDS + EGit to work with JBT sources* - https://gist.github.com/3701624 or 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 For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ After discussions today, tags/branches to keep are: {code} tags/jbosstools-3.0.3.GA [delete - history has changed too much] tags/jbosstools-3.1.1.GA [delete - history has changed too much] tags/jbosstools-3.2.2.Final tags/jbosstools-3.3.1.Final jbosstools-3.0.x [delete - history has changed too much] jbosstools-3.1.x [delete - history has changed too much] jbosstools-3.2.x jbosstools-3.3.x jbosstools-4.0.0.Alpha1 {code} And the following repos shown in the latest diagram will be renamed: {code} rename "common" group to "Base" rename "as" group to "Server" rename "datatools" to "Persistence" {code} All repos will be prefixed with "jbosstools-"; thus Freemarker and Forge will need to be re-done to add tags and be renamed. -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/12/12 12:50 PM: -------------------------------------------------------------- After discussions today, tags/branches to keep are: {code} - tags/jbosstools-3.0.3.GA [delete - history has changed too much] - tags/jbosstools-3.1.1.GA [delete - history has changed too much] - jbosstools-3.0.x [delete - history has changed too much] - jbosstools-3.1.x [delete - history has changed too much] + tags/jbosstools-3.2.2.Final + tags/jbosstools-3.3.1.Final + jbosstools-3.2.x + jbosstools-3.3.x + jbosstools-4.0.0.Alpha1 {code} And the following repos shown in the latest diagram will be renamed: {quote} rename "common" group to "Base" rename "as" group to "Server" rename "datatools" to "Persistence" {quote} All repos will be prefixed with "jbosstools-"; thus Freemarker and Forge will need to be re-done to add tags and be renamed. was (Author: nickboldt): After discussions today, tags/branches to keep are: {code} -tags/jbosstools-3.0.3.GA- [delete - history has changed too much] tags/jbosstools-3.1.1.GA [delete - history has changed too much] tags/jbosstools-3.2.2.Final tags/jbosstools-3.3.1.Final jbosstools-3.0.x [delete - history has changed too much] jbosstools-3.1.x [delete - history has changed too much] jbosstools-3.2.x jbosstools-3.3.x jbosstools-4.0.0.Alpha1 {code} And the following repos shown in the latest diagram will be renamed: {code} rename "common" group to "Base" rename "as" group to "Server" rename "datatools" to "Persistence" {code} All repos will be prefixed with "jbosstools-"; thus Freemarker and Forge will need to be re-done to add tags and be renamed. -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- jbosstools-build is currently one big garbage can IMO. needs a serious cleanup. -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ +1. We can start a new github repo for jbosstools-parent or jbosstools-build and into it introduce only the things we still need/use. Or perhaps have multiple modules? jbosstools-parent jbosstools-target-platform jbosstools-scripts ...? -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/13/12 1:09 AM: ------------------------------------------------------------- First attempt at doing a multi-component repo: https://github.com/nickboldt/jbosstools-Base_v2/ (includes common, tests, runtime, usage) Reason that the repo is so small in trunk (but still contains over 1Gb of .git/ folder) is that the whole repo came along for the ride in the other branches. Need to figure out how to filter the branches' content too. Similar problem here: https://github.com/nickboldt/forge/tree/jbosstools-3.2.x --- MEANWHILE, there's another problem - all the files in trunk contain no history except for the initial commit where I moved them into a subfolder. I had expected that git would retain history after a move, but apparently not: https://github.com/nickboldt/jbosstools-Base_v2/commits/trunk/runtime/plu... was (Author: nickboldt): First attempt at doing a multi-component repo: https://github.com/nickboldt/jbosstools-Base_v2/ (includes common, tests, runtime, usage) -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/13/12 1:14 AM: ------------------------------------------------------------- First attempt at doing a multi-component repo: https://github.com/nickboldt/jbosstools-Base/ (includes common, tests, runtime, usage) Reason that the repo is so small in trunk (but still contains over 1Gb of .git/ folder) is that the whole repo came along for the ride in the other branches. Compare: https://github.com/nickboldt/jbosstools-Base/tree/jbosstools-4.0.0.Alpha1 https://github.com/nickboldt/jbosstools-Base/tree/trunk Need to figure out how to filter the branches to remove unwanted content too. Similar problem here: https://github.com/nickboldt/forge/tree/jbosstools-3.2.x --- MEANWHILE, there's another problem - all the files in trunk contain no history except for the initial commit where I moved them into a subfolder. I had expected that git would retain history after a move, but apparently not: https://github.com/nickboldt/jbosstools-Base/commits/trunk/runtime/plugin... was (Author: nickboldt): First attempt at doing a multi-component repo: https://github.com/nickboldt/jbosstools-Base_v2/ (includes common, tests, runtime, usage) Reason that the repo is so small in trunk (but still contains over 1Gb of .git/ folder) is that the whole repo came along for the ride in the other branches. Compare: https://github.com/nickboldt/jbosstools-Base_v2/tree/jbosstools-4.0.0.Alpha1 https://github.com/nickboldt/jbosstools-Base_v2/tree/trunk Need to figure out how to filter the branches to remove unwanted content too. Similar problem here: https://github.com/nickboldt/forge/tree/jbosstools-3.2.x --- MEANWHILE, there's another problem - all the files in trunk contain no history except for the initial commit where I moved them into a subfolder. I had expected that git would retain history after a move, but apparently not: https://github.com/nickboldt/jbosstools-Base_v2/commits/trunk/runtime/plu... -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- thinking about this we need to keep the exact scripts we do for this since we'll be seeing commits in svn until the very last minute so we'll need to be able to rerun these again and again. You say runtime lost its history - how did you "move it" ? -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ [~maxandersen] Moved like this: {code} targetName="jbosstools-base" target="base" subdirs="common runtime tests usage" # space-separated list of child folders #git move then filter as if a single component mkdir ${target}; for d in ${subdirs}; do git mv ${d} ${target}/; done git commit -m "move ${subdirs} into ${target}" . # check in moved files # filter out all the subdirs we don't care about git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter ${target} -- --all {code} Root pom shouldn't have a variable there -- wrong set of quotes used to echo to file (using '' variables aren't expanded - need to use "" or omit). Fixed now in the repo and should work in the script [1] for subsequent runs. [1] 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 For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-12475?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-12475 at 9/14/12 12:07 AM: -------------------------------------------------------------- New forge component repo contains nothing in the 3.2.x branches and on disk is only 70M instead of 1.1G! https://github.com/nickboldt/jbosstools-forge/ New freemarker component repo is now only 2.3M: https://github.com/nickboldt/jbosstools-freemarker/ I've updated the script to take into account: * creation of target component folder if it doesn't exist on the specified branch (eg. forge was added in 3.3 so doesn't exist in 3.2.2.Final tag or 3.2.x branch) * incremental pushing (1 per branch), with +force * instructions for reverting a filter-branch (needs to be connected to an origin (remote server) to work) * cleaner README.md content * instructions for setting default branch in github (because the old 3.2 branch will be selected by default, as first alphabetic selection) was (Author: nickboldt): New forge component repo contains nothing in the 3.2.x branches and on disk is only 70M instead of 1.1G! https://github.com/nickboldt/jbosstools-forge I've updated the script to take into account: * creation of target component folder if it doesn't exist on the specified branch (eg. forge was added in 3.3 so doesn't exist in 3.2.2.Final tag or 3.2.x branch) * incremental pushing (1 per branch), with +force * instructions for reverting a filter-branch (needs to be connected to an origin (remote server) to work) * cleaner README.md content * instructions for setting default branch in github (because the old 3.2 branch will be selected by default, as first alphabetic selection) -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ BTW, the other approach, which iterates through all the folders in the svngit mirror clone we DO NOT WANT... {code} # $dd is a for-loop variable matching as, archives, birt, bpel, build, cdi, central, deltacloud, documentation, download.jboss.org, drools, ... git filter-branch --force --index-filter "git rm -r -f -q --cached --ignore-unmatch ${dd}/" --prune-empty HEAD {code} ... will take DAYS to process. Started it at 2012-09-13 4:45am and as of 2012-09-14 12:27am (about 20hrs later) it's managed to wipe the folders above and about half of drools. That only leaves 22.5 folders to go, or perhaps another 40hrs. Hugely impractical for the javaee, Persistence (datatools), and Server (as) multicomponent repos, if it's ~2.5days each to simply process the excess git history & artifacts. -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- eh - your filter-branch is running in a loop instead of doing it with a grep match like this: {git filter-branch --prune-empty --index-filter 'git ls-tree -r --name-only --full-tree $GIT_COMMIT | grep -v -E "^common/|^runtime/|^tests/|^usage/" | xargs -n 1 git rm --cached -r --ignore-unmatch ' -- --all} That prevents the loop and should be 10 times as fast compared to yours. Notice that the grep here has -v and -E allowing you to just specify the dirs you want to keep. But its still very slow. -- 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-12475?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-12475: --------------------------------------- I now successfully managed to delete the "common" dir in all the commits (all branches) using this command: {code}git filter-branch --force --index-filter "git rm -r -f -q --cached --ignore-unmatch common/site" --prune-empty -- --all{code} It took 6 hrs. Obviously running this in a for loop would take X-times that much time. So I wonder how fast it will be if I put everything in one git filter-branch command as Max suggests - I will try this over the weekend and will let you know :) It will be a more complex query so it will definitely be slower than 6hrs. But how much slower? Let's see. -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- history is used for figuring out when bugs occurred, why things didn't work this way before, finding bugs and being able to create patches easily - and simply to keep the source where it is instead of having to always go back and forth. We can also build out of git if we choose to but having that as a requirement would mean we would have to do even more work to set up this migration since we are changing the layout of the projects. Having history with us allow us to move 3.3.x/5.x builds off svn eventually. -- 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-12475?page=com.atlassian.jira.plugi... ] Martin Malina edited comment on JBIDE-12475 at 9/20/12 12:13 PM: ----------------------------------------------------------------- I saw Max mention git_fast_filter. So I gave it a try. It is really fast. I wanted to drop all the files except for paths containing .ui.bot. You can see my modified script here: https://gist.github.com/3756392 (See especially second half of step 3. - lines 75-107) The next step for me was to move all the plugins to one common location, e.g.: {code}mv bpel/tests/org.jboss.tools.bpel.ui.bot.test plugins/{code} The problem with git is that it doesn't handle this kind of moves very well - you cannot see the history in github ui for the moved files - see https://github.com/mmalina/jbosstools-integration-tests . From cli you can use "git log --follow" but it's still only heuristics (or so I hear). So the solution might that once I stripped all the unwanted files, I can now finally run git filter-branch, which will be much much faster with this new small repo, to really rewrite the tree. Or maybe this can be done with git_fast_filter, too, but I haven't checked yet. was (Author: mmalina): I saw Max mention git_fast_filter. So I gave it a try. It is really fast. I wanted to drop all the files except for paths containing .ui.bot. You can see my modified script here: https://gist.github.com/3756392 (See especially second half of step 3. - lines 75-107) The next step for me was to move all the plugins to one common location, e.g.: {code}mv bpel/tests/org.jboss.tools.bpel.ui.bot.test plugins/{code} The problem with git is that it doesn't handle this kind of moves very well - you cannot see the history in github ui for the moved files - see https://github.com/mmalina/jbosstools-integration-tests . From cli you can use "git log --follow" but it's still only heuristics (or so I hear). So the solution might that once I stripped all the unwanted files, I can now finally run git filter-branch, which will be much much faster with this new small repo, to really rewrite the tree. -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- Martin - ping me monday and we'll see if I can do this split in the migration scripts I got at https://github.com/maxandersen/jbosstools-gitmigration.git Denis et.al. any reason we dont want to move vpe into its own repository since separate team ? What does the struts/jsf dashed lined links to VPE mean ? -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-12475: ---------------------------------------- Attachment: max_suggestio.png -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- Suggestion for decoupled repos in !max_suggestio.png! WDYT? -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-12475: ---------------------------------------- Attachment: max_suggestio.png -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-12475: ---------------------------------------- Attachment: max_suggestio.png -- 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-12475?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-12475: --------------------------------------- Dashed means "optional". Latest version with birt and vpe out of its groups looks even better for me. -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12475: --------------------------------------------- what does "optional" mean here? that they can compile without VPE but need it at runtime or they dont need it at runtime at all ? birt I'm 100% convinced needs its own place - it needs to move forward or die off (its hibernate 3 specific currently) VPE being out is good too, but that leaves JST "hanging in the middle" - is it really worth the overhead ? should we put it together with xulrunner? fit in base better?) -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ I've added a bootstrap profile (and a deprecated bootstrap-svn profile) to the ws and openshift components' root poms in SVN. Now, instead of using {code} mvn clean install -f build/pom.xml -Pws-bootstrap,default {code} devs can use: {code} mvn clean install -f ws/pom.xml -Pbootstrap-svn,default {code} and when we migrate to git: {code} mvn clean install -f ws/pom.xml -Pbootstrap,default {code} Diff is here: https://source.jboss.org/changelog/JBossTools?cs=44069 This is a starting point for creating a shell/ant script that can fetch upstream github repos based on the bootstrap profile in a component's root pom. -- 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-12475?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12475: ------------------------------------ Shell script for fetching upstream repos basd on bootstrap profile: https://github.com/jbosstools/jbosstools-build/blob/master/scripts/checko... Also created a simple "get all the components" script here: https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... -- 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-12475?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen resolved JBIDE-12475. ----------------------------------------- Resolution: Done The bulk of the work is now done. http://github.com/jbosstools is open for business. -- 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