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

Denis Golovin (JIRA) jira-events at lists.jboss.org
Mon Aug 27 19:05:21 EDT 2012


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

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.
                
> 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.M1
>            Reporter: Nick Boldt
>            Assignee: Denis Golovin
>             Fix For: 4.0.0.M1
>
>         Attachments: 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jbosstools-issues mailing list