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
Some news related to this topic


We are going to introduce several requirements to our dependency usage

Enforecer rules
1. DependencyConvergence - This rule requires that dependency version numbers converge. If a project has two dependencies, A and B, both depending on the same artifact, C, this rule will fail the build if A depends on a different version of C then the version of C depended on by B. See more https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

2. requireDepMgmt - Enforces that dependency management is used for a declared dependency. See more https://github.com/ceilfors/enforcer-rules/wiki/requireDepMgmt

3. bannedDependencies- enforces that excluded dependencies aren't included.  We will have a list of undesired dependencies https://github.com/codenvy/maven-parent-pom/compare/ECL-460944#diff-600376dffeb79835ede4a0b285078036R1320

One more improvement related to dependencies that we want to add is  how we using  declaration.
In simple words: all used dependencies have to be declared explicitly and unused dependencies is not allowed. 
See more https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html


You can take a look here https://github.com/codenvy/maven-parent-pom/compare/ECL-460944#diff-600376dffeb79835ede4a0b285078036R1320 how it will be implemented using maven

Platform-api adopted to this rules 
https://github.com/codenvy/platform-api/compare/ECL-460944


About when and how we will have it in master.
Since adopting this rules takes some time and since we are going to reorganize a bit our source code because of migration to eclipse 
we will start mass adoption of this rules after migration.


On Fri, Mar 13, 2015 at 11:52 PM, Sergii Kabashniuk <skabashnyuk@xxxxxxxxxxx> wrote:
Thinking

On Fri, Mar 13, 2015 at 11:36 PM, TAN Sun Seng David <sun.tan@xxxxxxxxx> wrote:
Hi all,
what about #2 ?

Le 05/03/2015 17:08, Sergii Kabashniuk a écrit :
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