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
I think you are proposing to much new things in the same time.
Which we are not ready to accept in our technological life cycle in very short period of time.
I prefer to stay on our initial approach with single repository for initial Che contribution.

On Wed, Mar 25, 2015 at 4:06 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:

On Wed, Mar 25, 2015 at 2:23 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:


On Wed, Mar 25, 2015 at 2:13 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
 Hello Roman,

I think I will include usecases and what I think is simplicity for the developer.

So first scenario (or community scenario): Plugin developer
A user wants to develop a plugin for Eclipse Che. First, it shouldn't have to download or clone the source of Eclipse Che. (it's like when developing a webapp, you're not downloading Tomcat sources or Wildfly or TomEE to begin)
So what is required in maven world for something easy for the developer of the plugin : having a maven archetype for creating a plugin + BOM (so that all dependencies are set for him)
Also it needs to include a maven-plugin in the plugin-lifecycle : or better set packaging to 'eclipse-che-plugin'. Then the eclipse-che plugin is launching the assembly with the plugin inside.

to sumup : I create my plugin with an archetype and I use 'mvn eclipse:che start' for example and voila I've my custom IDE including my plugin

I should also be able to create my plugin using online Eclipse Che (like proposed by codenvy.com) so I do all stuff remotely without installing something on my computer.

In this usecase, we've seen that we don't need to clone the sources of Eclipse Che.
 
I'm afraid that we are releasing so frequently that developers with such approach can be far behind of the mainstream


I just have to update the version of Eclipse Che in my plugin (bom) to 3.7.0
<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.eclipseche.bom</groupId>
                <artifactId>che-sdk</artifactId>
                <version>3.7.0</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>


 

 


another scenario: Eclipse Che developer

in that case, we may be either developing a plugin (so we can use the first usecase) or the API/server side.
 
we can't because user have to have master source code unless they are developing for some old version 

Sources come with transitive maven dependencies and can be shown automatically.
 

So for server side, we should only have to clone platform-api component and then we could run this project that will provide server side components.
 
The tricky part is: server side can be not only platform-api, and version of necessary component can be tricky to find, especially if it not master   


Well either it's provided by the platform(or a transitive dependency) or it's my plugin part (BTW, I could list in my plugin all 'server' dependencies required)


 


We should do also like we do for other subprojects. We can specify the remote host when using a client component.
So for example I could run a local IDE using any remote server 
so in the case of the runner panel, I could only launch my local che (IDE) with ./che.sh --remote http://multi-runner-instance.com

So if there are 5 developers that need to use a new API as consumers, these 5 persons could work without the need to recompile the server API implementation, they could just use it remotely.

So in that case we don't need also to clone all repositories in order to work and we have something very simple.
I think your  explanation how to run project without rebuild everything will be much harder than
1. rebuild all with mvn clean install
2.  run ./path_to_che/che.sh run

it's simpler as I only have to do : mvn clean install in my plugin codebase (eclipse che plugin can be called automatically in the lifecycle and then start the local assembly as well)
So I do not require script (so it's portable across Linux/Windows)


 

For mature programmers I agree with you, it can be faster, but for newcomer way to test changes should be simple as possible

It's simple : mvn clean install in my plugin codebase

 

 


In my two usecases, mave artifacts are also provided by Nexus instance so I don't need a all-in-one repository


about your #2 point
you think that plugin should be all gathered to an external assembly while I think that each plugin could be run directly from it's location. In my case I just have to specify the dependency (bom) of my Eclipse Che version for which I need to work. 
Also I don't see problem in automation because releasing a new assembly can be automated.
In master yes.  but if you have 66 bugfixes branches with different versions it become not so trivial. 

As long as it is automated I don't see the problem, either the automation work or it doesn't work but I never hear robot complaining.
ha ha . Ask Roman about how is he happy when he making bugfix release in 66 branches.


 

About your point #3 I think it's because development process is too complex as you are still rebuilding the whole stuff (and then one or multiple repository is not changing much) while I say that we may work by only using and recompiling a subpart of the projects. (Decoupling client and server or using different remote from local che IDE)




Florent





On Wed, Mar 25, 2015 at 12:07 PM, Roman Iuvshin <riuvshin@xxxxxxxxxxx> wrote:
Hello,

1) I think SDK contributor should be able to just checkout some tag with everything related easily, otherwise contributor should manage a lot of projects, use workarounds like cbuild scripts.

2) we are tagging everything even if it's not changed because we have some automation on that it allows us to do frequent releases, I agree that it's overhead but it's a big price for being able have release automation. Btw it can be a nightmare if number of plugins will be more than 100, for now it's ~25. Also if we will have everything as single project we will don't need anymore maintain our release automation, and it will allow us to have a job on CI for release, which can be scheduled or launched by any allowed person, which is very important if release team will not be able to work.

3) In fact our devs spends a lot of time on that, for example new runner panel was developed in more than 15 projects in the same time, and it's not that easy to do development this way. Also it is not a trivial task to merge all those projects in master, I think it can be much easier with single project approach.


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



_______________________________________________
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