[jbosstools-issues] [JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules

[Mickael Istria (JIRA)]

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

Mickael Istria commented on JBIDE-16220:
----------------------------------------

There are 2 approaches aggregating Eclipse stuff:
* Having such a repo using submodules to build all at once and creating the output repo. This approach is equivalent to the usage of map files, except that the mapping in stored in git metadata instead of explicit files. It's what is done by Platform build and WTP.
** The bad things:
*** developers don't care about the build because they still believe it is monolithic and don't understand it is modular.
*** Build takes ages, feedback loop is quite long, so people skip tests to save hours, so the quality of the output is very low (no test run is not something really acceptable)
** The good things:
*** You know everything build together so you see API issues as compile error
* Building git repos into p2 repos individually, and consume the output p2 repository to make an aggregate site. That's what we do, and it's also what's used by Eclipse Simultaneous Release.
** The good things:
*** We really act as a consumer and it keeps a better separation of concerns
*** it is more explicitly modular and people understand that they are responsible for the build of there stuff
** The bad things
*** There is more risk of inconsistencies in case of issues MANIFEST.MF (not enough constraints) and bad API practices. However, we can hope that unit-tests are a good way to notice such API changes,

If we can have both, it's nice, we might find some API issues a bit faster. But I definitely prefer the current approach for a production and teamwork POV, and I believe it's more important to have tests we can trust to find API issues as fast as a big build.
                
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
>                 Key: JBIDE-16220
>                 URL: https://issues.jboss.org/browse/JBIDE-16220
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 4.2.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.2.x
>
>         Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
>  "git submodule" started learning a new mode to integrate with the
>    tip of the remote branch (as opposed to integrating with the commit
>    recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.

--
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