Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Bug 460944 - Dependency convergence
For #1
Me +0
Vitaly +0
Roman +1
Florent +1
UA Leads +0

I think it mean  "go" for this solution if we have no blocker here.

On Wed, Mar 4, 2015 at 12:46 PM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
Also notice that bringing dependencyManagement doesn't change the properties. So I don't any problem with current 'automation' as you'll update properties, not dependencymanagement section.



On Wed, Mar 4, 2015 at 11:39 AM, Roman Iuvshin <riuvshin@xxxxxxxxxxx> wrote:
+1 for #1, also we have some sort of automation based on current depmgt pom.

On Wed, Mar 4, 2015 at 10:57 AM, Vitalii Parfonov <vparfonov@xxxxxxxxxxx> wrote:
Agree with Sergii #1 good but doubt about size of parent pom

Vitaly Parfonov -- codenvy

On Wed, Mar 4, 2015 at 10:34 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:


On Wed, Mar 4, 2015 at 9:57 AM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
ok,
#1
first about dependencyManagement, I don't see where it will be hard to maintain. In fact, properties can stay and then the property is used inside the dependencyManagement. So, updating a current dependency will also result in updating the property. One gain is that we can remove one line per dependency in any child. (the version element of all dependencies) So me may also lower the length of any child pom.xml. And also, we're sure that people will not introduce a dependency with a different version. So no need to perform checks.
No problem with child pom. I have doubts with easiness of support of maven-dep mgt-pom with size of tens of megabytes

@Readers any votes on this part? @Roman @Vitaly P?



#2
Some people may want to use part of codenvy in their own projects. But using some codenvy artifacts as a dependency doesn't mean that we have to inherit from codenvy maven-depmgt-pom. So the problem that come to these projects are that they want to import a 'coherent' set of dependencies. For example if they import the sdk and platform-api artifacts, they want to be sure that they will match the correct set : not use for example platform api of sdk 3.6.0 while using sdk 3.7.0

So BOM is there for these projects. It defines all dependencies for a given set.

Project will import for example bom codenvy 3.7.0 and it will set all the versions for all artifacts that may correspond : including platform-api version, any plugin versions, etc

And when codenvy 3.8.0 is out, projects have only to update bom to 3.8.0 and all dependency versions are automatically set as well. (with consistency)

Regards,

Florent
Where in the line maven-parent-pom -> /maven-depmgt-pom ->ide-pom >plugin-*.pom BOM will be located?


On Wed, Mar 4, 2015 at 8:30 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:


On Wed, Mar 4, 2015 at 9:22 AM, Florent Benoit <fbenoit@xxxxxxxxxxx> wrote:
Hi Sergii,

Why not apply the standard maven dependencyManagement elements of pom.xml so that all subprojects inheriting from maven codenvy parent pom will have nothing to do, the dependency version being automatically set ? (so no need to run any profile, it's done automatically)
 
In theory you are right. In practice I have some doubts because if the do that we will have tremendously huge maven-depmgt-pom which will be probably hard to maintain. 
Any way I'm open to discuss that and if we will have quorum of experts who vote +1 for this. Then I will agree with that.
 
And also provide a bom (bill of materials) file for projects that don't want to inherit from a codenvy maven file but still want to get the correct versions.

These two options are two maven standards.
 
Not sure bom is related to this topic. Can you elaborate more on this topic. What we need to do and why, how it can be integrated with our development cycle? 


Regards,

Florent

On Wed, Mar 4, 2015 at 7:50 AM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
This time I want to discuss with you one of the requirements of enterprise and good sense is dependency convergence. In simple words: all dependencies and transitive dependencies should have same predictable version.

You can read more here 

To achive this goal I've added a maven  profile  dependency-convergence so you can test that you project is satisfy to this requirement.

Example:
 mvn clean install -Pdependency-convergence


Also we want to introduce a couple of requiroment for all subprojects related to codenvy and che.
1. All dependencies in subproject have to be declared from version taken from 
2. You should not declare dependencies version in subproject parent pom.
3. All subprojects should pass tests with  dependency-convergence maven profile
4. All plugin should not have version in subprojects and should take it from https://github.com/codenvy/maven-parent-pom
5. Subprojects should try to avoid usage of apache commons and use guava instead.
6.  After project  successfuly pass dependency-convergence maven profile it have to be enabled on jenkins.

A list of project that already pass  dependency-convergence maven profile you can find here https://bugs.eclipse.org/bugs/show_bug.cgi?id=460944.

Plz consider to fix 1-6 requirements as soon as you can.

Sergii Kabashniuk









Back to the top