[jbosstools-issues] [JBoss JIRA] (JBIDE-12475) Split JBoss Tools into several functional groups of components for migration to Github

Nick Boldt (JIRA) jira-events at lists.jboss.org
Thu Sep 13 01:14:33 EDT 2012


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

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/plugins/org.jboss.tools.runtime.ui/pom.xml

                
      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/plugins/org.jboss.tools.runtime.ui/pom.xml

                  
> Split JBoss Tools into several functional groups of components for migration to Github
> --------------------------------------------------------------------------------------
>
>                 Key: JBIDE-12475
>                 URL: https://issues.jboss.org/browse/JBIDE-12475
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: Build/Releng
>    Affects Versions: 4.0.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.0.0.Beta1
>
>         Attachments: Components-Final .gliffy, Components-Final .png, git-decomposition-bigger.png, git-decomposition.png, git-decomposition1.png
>
>
> 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_Release_Candidates - "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
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbosstools-issues mailing list