Any idea for us about dependence conflict management.

[陈思淼 <ch...@gmail.com>]

we're in a big company's project, our project combine with other team's jar
dependences. To manage the dependence is a very hard work to do.for example,
our last accident is becourse of ice jar dependence override.
our project denpends on ice 3.1.0, but one of our partner group provide us a
jar which depends on ice 3.2.0.GBK, the ice 3.2.0.GBK is include into the
final ear package. but the 3.2 is redesign the TCP connection method from
long connect to short connect. after it deploy to the website.  our web
server fall down for 1 hour becourse of the connection flood.

My thoughts  is to write a plugin to analyze the pom dependence graph ,and
find all the conflicts in the graph. and we manage a list about conflict
resolve rule. for example when ice 3.1 and 3.2 conflicts, in that list, we
force the dependence to be 3.1, if there is conflict not in the list, the
build will fail.
Is this a feasibility way to resolve this problem? or threre is a better way
for me to do so .

Re: Any idea for us about dependence conflict management.

[陈思淼 <ch...@gmail.com>]

Great, I will do some research on your works.
Thank you again.
2008/9/26 Brett Porter <br...@gmail.com>

> You have a few alternatives here.
>
> * The dependency:tree goal shows the final resolution selection that
> can help track them.
> * In an IDE, you have apps such as this which can manage the versions:
> http://code.google.com/p/q4e/wiki/DependencyAnalysis
> * You can set the versions to be restrictive, eg [,3.1] will not allow
> versions > 3.1.
>
> Cheers,
> Brett
>
> 2008/9/24 陈思淼 <ch...@gmail.com>:
> > we're in a big company's project, our project combine with other team's
> jar
> > dependences. To manage the dependence is a very hard work to do.for
> example,
> > our last accident is becourse of ice jar dependence override.
> > our project denpends on ice 3.1.0, but one of our partner group provide
> us a
> > jar which depends on ice 3.2.0.GBK, the ice 3.2.0.GBK is include into the
> > final ear package. but the 3.2 is redesign the TCP connection method from
> > long connect to short connect. after it deploy to the website.  our web
> > server fall down for 1 hour becourse of the connection flood.
> >
> > My thoughts  is to write a plugin to analyze the pom dependence graph
> ,and
> > find all the conflicts in the graph. and we manage a list about conflict
> > resolve rule. for example when ice 3.1 and 3.2 conflicts, in that list,
> we
> > force the dependence to be 3.1, if there is conflict not in the list, the
> > build will fail.
> > Is this a feasibility way to resolve this problem? or threre is a better
> way
> > for me to do so .
> >
>
>
>
> --
> Brett Porter
> Blog: http://blogs.exist.com/bporter/
>

Re: Any idea for us about dependence conflict management.

[Brett Porter <br...@gmail.com>]

You have a few alternatives here.

* The dependency:tree goal shows the final resolution selection that
can help track them.
* In an IDE, you have apps such as this which can manage the versions:
http://code.google.com/p/q4e/wiki/DependencyAnalysis
* You can set the versions to be restrictive, eg [,3.1] will not allow
versions > 3.1.

Cheers,
Brett

2008/9/24 陈思淼 <ch...@gmail.com>:
> we're in a big company's project, our project combine with other team's jar
> dependences. To manage the dependence is a very hard work to do.for example,
> our last accident is becourse of ice jar dependence override.
> our project denpends on ice 3.1.0, but one of our partner group provide us a
> jar which depends on ice 3.2.0.GBK, the ice 3.2.0.GBK is include into the
> final ear package. but the 3.2 is redesign the TCP connection method from
> long connect to short connect. after it deploy to the website.  our web
> server fall down for 1 hour becourse of the connection flood.
>
> My thoughts  is to write a plugin to analyze the pom dependence graph ,and
> find all the conflicts in the graph. and we manage a list about conflict
> resolve rule. for example when ice 3.1 and 3.2 conflicts, in that list, we
> force the dependence to be 3.1, if there is conflict not in the list, the
> build will fail.
> Is this a feasibility way to resolve this problem? or threre is a better way
> for me to do so .
>



-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/