Message-ID: <606532532.42274.1371709402857.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_42273_1587106617.1371709402857" ------=_Part_42273_1587106617.1371709402857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In some cases - probably due to bad metadata on the repository - the dep= endency exclusion problem becomes so acute as to make it more productive to= simply disable transitive artifact resolution. Unless/until we can come up= with a strategy to clean up the metadata on the repository such that users= will have access to it immediately, and maintain a higher standard of qual= ity for this metadata (perhaps incorporating some sort of user comments/rat= ings in MRM per-artifact?), we will have some users who feel it would be mu= ch easier to build their projects without transitive artifact resolution.= p>
Currently, dependency exclusions are specified as affecting a single dep= endency's transitive closure. However, because of a bug in Maven, any exclu= sion will affect all of the project's dependencies - the w= hole artifact resolution process for that build, in other words.
There are some who feel that it would be simpler to change the exclusion= semantics (and syntax), such that excluding an artifact formally specifies= that you're excluding it globally from that build. This will effectively f= ormalize the process that's already in place (as I understand it), and woul= d lead to dependency exclusions being specified directly within a dependenc= yManagement section, for instance, rather than within a single dependency d= eclaration.
With the proposed changes to version conflict resolution, restricting th= e DependencyManagement section to only those dependencies specified directl= y in the POM inheritance hierarchy of the current project poses a subtle pr= oblem of consistency. That is, when the artifact version selected is not ne= cessarily the nearest, it creates a situation where the DependencyManagemen= t section clearly states one version/scope/etc. but another one is used bec= ause the dependency used is not the one that was declared directly within t= he POM.
There is a lot of confusion in the community (and even among Maven devel= opers!) about how the different scopes imply one another, and what use case= some of the more exotic scopes are meant to address. Compounding this, the= re are several pro/con arguments about whether certain scopes should be tra= nsitive. Also, it's become relatively clear that the system scope represent= s a design flaw in Maven 2.0. Finally, the scope vocabulary supported by Ma= ven is sometimes not adequate to capture the different classes of dependenc= ies used in the build process, and definitely cannot accommodate new depend= ency usages which might be encountered when using new build lifecycle mappi= ngs.
Some feel that the provided scope should be transitive. The argument is = that the top-level consumer should have control over what artifacts are exc= luded as provided (or for any reason, for that matter). Others would say th= at the provided scope annotates an artifact as always meant to be provided = by the platform, a fact that doesn't change when it's discovered transitive= ly.
The system scope almost seems to be a way of addressing a special case w= here provided scope + a specification-style dependency might be a better so= lution. The reason is that system-scoped dependencies are assumed to pre-ex= ist on the build machine, configured and maintained externally WRT the buil= d process. Things like the Javac compiler exist in different locations on d= ifferent JDK implementations (or not at all on some implementations), and t= herefore cannot be adequately captured as a dependency by something as conc= rete as a systemPath (the operative part of a system-scoped dependency).
I think most Maven developers agree that there must be some better solut= ion to this problem, which will accommodate situations like the above more = elegantly.
The static scoping vocabulary supported by Maven 2.0 cannot address all = of the various distinct use cases for dependencies in existing builds. For = example, the integration-test lifecycle phase has no accompanying dependenc= y scope, which means it must share some other scope with another phase - wh= ich may lead to classpath problems in one or more phases of the build. Sinc= e Maven 2.0 supports custom lifecycle mappings via the <packaging/> e= lement, this problem could literally explode in front of us. To extend the = previous example, this would become a major concern if functional, system, = or performance testing phases were added.
We also need a way to distinguish the dependencies that apply when resol= ved transitively via an attached artifact, rather than the main one. For ex= ample, while the server-side component of an EJB may need several dependenc= ies, the ejb-client aspect might only need one or two of those, just enough= to fulfill the needs of the EJB interfaces, and give the client the abilit= y to work with the data. However, when a dependency of type ejb-client is d= eclared in a project, the entire dependency set is resolved transitively.= p>
Dependency Scoping rules are hard-coded in Maven 2.0, which means we wil= l have to design and implement a componentized solution to accommodate new = scopes. Additionally, there is currently no way to specify a transitivity f= lag or list of project-global exclusions list, which means these solutions = will also need to be designed and implemented.
Taken with the proposed changes to DependencyManagement, these new behav= iors will almost certainly cause backward-compatibility problems, which is = not an option. Therefore, the real problem becomes how to support these sor= ts of enhancements while still supporting legacy (2.0) builds.