[jbosstools-dev] Proposed New Github Component Chunks for JBoss Tools 4.0

[Max Rydahl Andersen]

> The reason to have xulrunner out of jee component is it has been changed for a while, so I don't want build something over and over again.
> 
> I think we can have maven included in central component and runtime included in common when dependencies from seam and as are reversed.
> 
> +1 freemarker and forge to be in common.

Freemarker should just be built and released once - no further builds needed until someone has time to add/maintain features.

Forge - it is not obvious to me that Forge would stay "low" in the dependency cycle. It actually depends on m2e and others and probably more over time - how would that be handled ?

/max

> 
> that would give us 9 big chunks.
> 
> Denis
> 
> On 08/27/2012 11:35 AM, Nick Boldt wrote:
>> I've digested Denis' diagram so it aligns with what I proposed in terms of chunks (git repos) and tiers (collections of builds that must be done before the next collection can proceed).
>> 
>> My view includes 7 chunks and 4 tiers of builds, +0 through +3, starting with the "base" or "common" module (tests, common, and usage), all the way up to Central at the top as a +3.
>> 
>> Denis' view includes 13 chunks (git repos) and 7 tiers of builds.
>> 
>> See https://issues.jboss.org/browse/JBIDE-12475?focusedCommentId=12714042&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12714042 for details and discussion.
>> 
>> That's 6 more 'git clone' commands to run, and 3 more collections of builds, making our "release train" almost twice as long and seemingly twice as complex.
>> 
>> I'm not sure we gain much by removing things like Xulrunner into their own git repo when it's ONLY used by VPE. Similarly, OpenShift and WS use AS and have no downstream deps, so why not include them in that git repo so you only need to fetch a single repo to do any work on OpenShift, WS, AS, Archives or JMX?
>> 
>> We could simplify further by moving Forge into the Base repo. (Denis has Freemarker as a candidate to put in the Base chunk, but as it's only needed by Hibernatetools, why not keep it in there?)
>> 
>> Nick
>> 
>> On 08/24/2012 07:28 AM, André Dietisheim wrote:
>>> On 08/24/2012 02:56 AM, Denis Golovin wrote:
>>>> Below is the diagram I've got by analyzing dependencies it let reduce
>>>> amount of components to 13 without any changes to dependencies we have
>>>> now ( transitive dependencies aren't shown like openshift->common,
>>>> because openshift->as and as->common).
>>>> 
>>>> Opened questions:
>>>> * openshift in as component?
>>> 
>>> not sure if that makes sense feature-wise. AS aka sever adapter tooling
>>> is only an aspect of OpenShift.
>>> 
>>>> * forge and freemarker inside common?
>>>> 
>>>> If we would revert central and examples dependencies and let
>>>> interested components inject examples and certain functionality into
>>>> central (not sure if that possible) that would be logical to have them
>>>> in common component
>>>> 
>>>> That would reduce 13 to 9 counting forge, freemarker and openshift
>>>> consumed by bigger components.
>>>> 
>>>> 
>>>> # Current dependencies:
>>>> 
>>>> 
>>>> 
>>>> # final git modules dependencies
>>>> 
>>>> 
>>>> 
>>>> Denis
>>>> 
>>>> 
>>>> On 08/23/2012 12:00 PM, Nick Boldt wrote:
>>>>> 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_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."
>>>>> 
>>>>> If you have comments or suggestions regarding this migration plan,
>>>>> please post them here or in https://issues.jboss.org/browse/JBIDE-12475.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>> 
>>> 
>> 
> 
> 
>