Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Eclipse Che Maven and Git structure
Florent, ideologically I am *totally* with you, I am a fan of modularity and hate the idea to "release everything each time", so do every developer here who ever think about it.

But, in practice I am afraid we will *have to* leave "repository per-module model" according the reasons pointed by Sergey and Roman, which are:
- clear rules for community
- unpredictable big amount of modules
- frequent releases cycle 

Really sad for me too...

Gennady Azarenkov - CTO @ codenvy.com


On Wed, Mar 25, 2015 at 11:31 AM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
  Hello,

#1 : well it's not fully true. Importing project with 150+modules (and searching which is the right module to look at) is no more trivial than importing the correct project

#2 releasing often doesn't mean to tag everything each time: it means that API has been broken. So it means that if everything needs to be tagged, there was a modularity problem. Previous version of the API should be still kept for existing clients.

#3 Again changes on API should always keep backward compliance (or as it may be difficult, to provide versioning). So even a major change won't impact current clients. Clients picking up API versions for which they are designed.
Testing is easy : if API has all unit tests OK, it can be pushed with a new API version into production.
for clients: they're not impacted until they upgrade their API version.

So lifecycle should be totally decoupled thus I think trying to merge all the stuff into one repository is not moving for a better world. It's like coming back in 80's.

Regards,
Florent

On Wed, Mar 25, 2015 at 10:06 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Hi

First topic: git repository structure.
1. Single repository
2. Multiple repositories

First of all I must admit that if we are talkin for our internal developing we are ok with both solution.
But since project grows and we involving more and more peoples some issue with multiple repositories become harder and harder.
For example: 
1. It's much easier to explain for new contributor how to build and run  product from any tag or snapshot 
when it is in one repository than in multiple.
2. Since we releasing very frequently we are releasing everything even if some plugin has no changes at all. 
3. When we develop some big feature which require changes in several project, bulding, testing and contribution
   become to not trivial task.

In the same time we are rejecting multiple repository approach. 
The basic idea is to hold minimal starting version (SDK and everything related to it) in one repository.
Everything else will be in separate repositories grouped by feature with individual (not depending to SDK) lifecycle.



About maven groupID.
@Dmitry can you confirm that we MUST use org.eclipse.che as groupID?  Can it be something like this org.eclipse.che.plugin for some cases?

Sergii Kabashniuk


On Tue, Mar 24, 2015 at 2:18 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
Hi,

looking at eclipse git web interface [1] to browse existing Eclipse projects I can see that we can keep the multiple git repositories approach
And not to have only code in a single repository. We can see that many projects are using the multiple repositories approach.
Virgo has for example many repositories. [2]

As we may have different lifecycle it should be better to split in different git repositories (like we have now)

In general we don't have to make new release of code that hasn't been updated. For example if all plugins are based on an API and that API is not changing, there is no need to tag/build a new version of these plugins.

So in the first approach, even code that has not been changed will need to be tag again and then deploy on maven repositories, etc for nothing.

So I was thinking that modularity is also ensured by using separated git repositories.

BTW I also think that the maven groupID and the package should be related and all CHE plugins should have same prefix for their package name. (maybe a different topic)


Florent

On Tue, Mar 24, 2015 at 12:26 PM, Dmitry Kuleshov <dkuleshov@xxxxxxxxxxx> wrote:

Hi,

The initial contribution is fast approaching so I think it is a good time to update Eclipse Che maven and git structure policy. Actually there are several options unless someone will propose more. 

Maven structure:

Each Eclipse Che component (project) has its own POM file which inherits parent POM file. Parent POM file defines all high level configuration.

  1. We group modules by their nature:

    Git Repository
    ↳

    commons ← module grouping
    ↳
    commons-env ← module
    ↳
    src ← module sources
    pom.xml ← module pom
    commons-schedule ← module
    ...
    pom.xml ← module grouping pom
    plugin-java ← module grouping
    ↳
    java-ant-tools ← module
    java-builder-ant ← module
    ...
    pom.xml ← module grouping pom
    ...
    pom.xml ← parent pom

  2. We keep all modules in a root folder:
    Git Repository
    ↳
    commons-env ← module
    ↳
    src ← module sources
    pom.xml ← module pom
    commons-schedule ← module
    ...
    java-ant-tools ← module
    java-builder-ant ← module
    ...
    pom.xml ← parent pom

GitHub structure:

  1. Each Eclipse Che module has its own Git repository (as it is right now)
  2. All Eclipse Che modules restructured:
    1. All SDK assembly related components are stored in a single repository (SDK, all SDK plugins, etc.), the components themselves will be git repository submodules
    2. All custom assemblies are stored in a separate repositories (along with all needed components and plugins)

My thoughts: 

I prefer 1st option for Maven structure and 2nd option for GitHub structure. I was guided by the following considerations: 

  • Though keeping all modules in one place seems to be more maven friendly way the other variant should provide less complexity during addition of a new submodules, simplifies the hierarchy understanding.
  • Keeping all related components in a single repository will significantly ease tagging and release process in general.

Does anyone have anything to add or to comment?

With regards,
Dmitry


_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev



_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev



_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev



_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev


Back to the top