[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
Mon Sep 10 12:06:33 EDT 2012


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

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/tests/org.jboss.tools.freemarker.ui.bot.test/resources/prj/org.jboss.tools.freemarker.testprj /empty
** https://github.com/jbosstools/jbosstools-svn-mirror/tree/trunk/freemarker/plugins/org.jboss.ide.eclipse.freemarker/src /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?

                
> 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