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


On Thu, Mar 26, 2015 at 2:21 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:


On Thu, Mar 26, 2015 at 1:00 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:


On Thu, Mar 26, 2015 at 1:39 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
ok why no move out directly maven-parent-pom

instead of the che-parent containing maven-parent-pom and maven-depmgt-pom

why not having directly maven-parent and maven-depmgt repositories

  che-parent will contain one pom with plagin configuration and dependecies versions.

The top level maven parent pom shouldn't contain any version or few. It's like a "frozen pom" that doesn't change at each product released.
If you're talking about external dependencies (like plugin versions, etc) it's ok as it is the goal of this module. But it shouldn't reference any version produced by the che artifacts.
This is why top level parent is almost never updated. Its nature is designed by the fact that he's quite stable.
Ok. It means we need one more repository  
che-depmgt   for  maven-depmgt-pom

 


I think it doesn't slow the process to have these repositories out.
And then tagging parent is not linked to the tag of maven-depmgt-pom

For the proposed layout, it may be ok as long as client and server are in different maven modules as well.
We will have same modules set as we have now. This separation can be contributed later. 

And then I assume groupID should be mapped to the repository layout, correct ? and package name will follow as well ?
project        - gropup id and package name
che-parent - org.eclipse.che.parent
che-core  - org.eclipse.che.core
che-plugins - org.eclipse.che.plugin
 che-sdk   - org.eclipse.che.sdk
But we not sure is it fully compatible with convention 
https://wiki.eclipse.org/Development_Resources/HOWTO/The_Eclipse_Code_Namespace_Policy#Maven_Group_Ids

This document reference  Maven naming conventionwhich say 'That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId.eg. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting'
so it will be our case. (org.eclipse.che.core) for example
 

and about package naming ?
plugin-java will have org.eclipse.che.plugin.java.* package as well ? (as per https://wiki.eclipse.org/Development_Resources/HOWTO/The_Eclipse_Code_Namespace_Policy#Java_Package_Names )

Make sense for me. 


Florent

 






Florent




On Thu, Mar 26, 2015 at 12:14 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:

On Thu, Mar 26, 2015 at 8:41 AM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
Hi all,

I forget to say that maven-parent-pom must be a single repository

As all projects should use this pom as parent pom (and not maven-depmgt that can be seen like the bom import)

so why this one needs to be a single repository ?
Thats correct its single repository.
We saw it like this

1. che-parent
content of 
maven-parent-pom
maven-depmgt-pom
2. che-core - everything need to build plugins. 
----
commons
platform-api
platform-api-client-gwt
ide
vfs-impl
security
test-framework
3. che-plugins - all
plugin-java
plugin-editor-codemirror
plugin-editor-orion
plugin-php
plugin-git
plugin-datasource
plugin-angularjs
plugin-bower
plugin-gulp
plugin-grunt
plugin-npm
plugin-yeoman
plugin-cpp
plugin-ruby
plugin-go
plugin-python
plugin-tour
plugin-runner
4. che-assembly-sdk
plugin-sdk
assembly-sdk
 

As all projects should have this parent, we don't want to update the version of the parent too often (less changes). Usually parent pom are like updated once per year ;-)
And the main reason is that usually this pom is synchronized on central maven repository
It means that even if a newcomer has no eclipse/codenvy repositories, it will found this pom that will declare all repositories
With that, there is no need to put repositories on each pom.xml of projects as parent is declaring it.
Once again your proposal definitely make sense, and we will glad continue improving our maven usage experience. But not at once.
We want to provide eclipse Che proposal in reasonable time frame
 

Florent




On Wed, Mar 25, 2015 at 7:57 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
I think you misunderstood Roman. He talk only about his part of the job - release. 
But for me and for Vitaly as for developer, multi-repository approach in current state,
without new process technologies like BOM gives more disadvantaged than advantages.
We always rebuild, re-release, facing with long merging problem etc. The easiest way to solve it, is to put all repositories at one. 

But we see the final idea that you are trying to tell us. 
As compromise variant for initial contribution, which in future will allow as to use BOM and not release unchanged plugins, we propose 3d version of structure with 3 git repositories

1. che-core - everything need to build plugins. 
----
maven-parent-pom
maven-depmgt-pom
commons
platform-api
platform-api-client-gwt
ide
vfs-impl
test-framework
.....

2. che-plugins - all
plugin-java
plugin-editor-codemirror
plugin-editor-orion
plugin-php
plugin-git
plugin-datasource
plugin-angularjs
plugin-bower
plugin-gulp
plugin-grunt
plugin-npm
plugin-yeoman
plugin-cpp
plugin-ruby
plugin-go
plugin-python
plugin-tour
plugin-sdk
plugin-runner

3. che-assembly-sdk


Eventually after 1 before 2 we will have che-boms.
And all plugins will be able to use it. When we can work on the improvements with plugin building and running without rebuild-all. After that we can separate che-plugins into individual repositories.


WDYT?

On Wed, Mar 25, 2015 at 6:17 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
I don't get if multi repo approach is flexible, why we should let it go. I only see single repository that may be simpler for one person : the release manager. But well, we can improve the release tools !

If there are less dependencies, we do less tags/releases and then release are also quicker to do.
If there are more regression tests, the need to do bugfix version is decreased :)

And I live in the same world so I don't see what Eclipse Che environment would be different of any existing major project ? Why Eclipse Che would be an unique case ?

Developer of a plugin don't care about the release process of Eclipse Che. He only needs a version of the product to set in its pom.xml and launch maven that do the job.

And derivative work of Eclipse Che will have the same problems of 'multiple repositories'. (as it will not be included in this 'one single repository')
So taking directly the 'multiple repositories' approach will match all derivative work of Eclipse Che and then all people can centralize and use the same tools for assembly.
Then it will improve quality.






On Wed, Mar 25, 2015 at 5:01 PM, Roman Iuvshin <riuvshin@xxxxxxxxxxx> wrote:
Currently I'm doing release 3.8.0, and it's kind a nightmare, it is failed 4 times due to different reasons, and each time I have to recheck everything and restart release. If we are really going to do fast and stable releases single repo it's a requirement №1 for me.
Again we are agree that multi repo approach is more flexible but in our world, in our environment we have to start with some thing simple and predictable if we want release easily and frequently.

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


On Wed, Mar 25, 2015 at 5:31 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
It's still only 3 branches to release and it can be automated so I don't see problem. 3 branches is like nothing.
Ok Send this script to me and Roman we will use it next time we making bugfix. 

Look at the number of repositories on some legacy projects :




On Wed, Mar 25, 2015 at 4:24 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Florent +1 for multi repository approach.

Sergii  +1 for single
Vitaly  +1 for single
Roman +1 for single
Gennady +1 for single


>I'm also waiting for the example of '66 bugfixes' branch.
3.4.2 bugfix changes in platform-api,  plugin-java, ide
all 3 projects have  different versions + you need to release related project platfrom-api-gwt-client and sdk. 
For hosted version example should be much funnier

On Wed, Mar 25, 2015 at 5:21 PM, Tyler Jewell <tyler@xxxxxxxxxxx> wrote:
We should get the inputs of those that have to build extensions as well.

Can someone reach out to engineers at SAP, WSO2, gazibit, etc?

Tyler Jewell | CEO | tyler@​codenvy.​com | 9​78​.8​84​.53​55


On Wed, Mar 25, 2015 at 8:18 AM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
+1 for single

Vitaly Parfonov -- codenvy

On Wed, Mar 25, 2015 at 5:13 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
Please count only people that are voting on the list ;-) I didn't see yet Vitalii's vote on this thread mailing list.

Florent

On Wed, Mar 25, 2015 at 4:02 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Ok. 
Florent +1 for multi repository approach.

Sergii  +1 for single
Vitaly  +1 for single
Roman +1 for single

Any other votes?

On Wed, Mar 25, 2015 at 4:58 PM, Roman Iuvshin <riuvshin@xxxxxxxxxxx> wrote:
Totally agree with @Sergii, we are moving forward so fast and I believe that it is better to start with single repo approach. At this point we fully understand all nuances of those approaches and as for me It is reasonable "price" for simplicity which single repo way is offering us.
It also gives a lot of benefits not only for developers, for example we can reduce number of CI jobs which is nice, it will be really easy to maintain that, and so on.

On Wed, Mar 25, 2015 at 4:53 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
I'm saying that the 'single repository' is a false attempt to make simplicity for a beginner developer. You're targeting end problem while I'm targeting root cause.

Also I don't see any 66 branches bugfixes so give me a pointer.

Florent



On Wed, Mar 25, 2015 at 3:43 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
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



_______________________________________________
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



_______________________________________________
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



_______________________________________________
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