Message-ID: <932917293.1137.1369213701978.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1136_933989004.1369213701977" ------=_Part_1136_933989004.1369213701977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Users have expressed the desire to turn off transitive dependencies and/= or filter out some dependencies obtained transitively. This design attempts= to allow the latter.
There is one contentious issue: should these filters be transitive?
Arguments in favour:
velocity requires jdbc for it's jdbc resource loader. If you are not usi= ng the resource loader, you don't need jdbc.
plexus-velocity depends on velocity - should it expose the jdbc resource= loader (and hence jdbc dep) to dependees, or should it hide that, and make= dependees introduce a velocity dep if they use the jdbc resource loader?= p>
jpox requires this for clob support. modello generates a jpox store but = does not use clobs, so that code will never be touched. Should all modello = dependees filter out ojdbc, or should modello-plugins-jpox filter it out?= p>
betwixt requires digester to do its parsing. In some instances, it also = requires beanutils. However, I recently changed some code in the m1 project= loading and realised the portion of betwixt I am using did not need beanut= ils at all. If mevenide was to depend on the m1 project loading, it would h= ave no knowledge of the use of betwixt - should it receive the beanutils de= p?
NOTE: This section was created in parallel to the above= modifications to the original page. Therefore, its structure may be at odd= s with the above content, and some of the arguments may be a bit redundant.= However, I'm leaving it as-is for now, since it expresses my own opinion o= n this issue inside a framework that I think will help others know where/ho= w to contribute theirs.
I'm creating this section simply as an area for each of us to weigh in o= n this issue, with the hopes that:
-we can avoid another multi-hour design session without resolution
-we can track this discussion over time, for the sake of documenting the re= asons for our eventual design decision
The main point of contention here (I think) is the behavior and location= of dependency-exclusion specifications. Specifically, can intermediary pro= jects specify dependency exclusions that will be effective for dependents o= f these projects, or must each project decide for itself which declared ups= tream dependencies it can safely live without?
My tendency was to think about these alternatives as the effects of two = goals of the repository which were at odds: enabling user productivity vs. = correctly specifying project information. From this perspective, it is corr= ect from a principles argument to say that subsequent dependents on a proje= ct shouldn't have the right to second-guess that project's release manager = regarding the project's dependencies. The viewpoint is in favor of making a= project's pom.xml the sole authority for that project, and assumes that al= l dependencies are required for all functionality in the project.
The other view rendered by this perspective is that release managers who= poorly specify their requirements compromise the net utility of maven as a= whole. It only takes some critical number of poorly specified projects to = push users away from maven and toward competitor products. This view is in = favor of limiting the effects of "bad" poms in an effort to make = users more productive (avoiding trial-and-error discovery of useless or blo= cker transitive dependencies) and to reduce the noise generated in the repo= sitory (as multitudes of poms are deployed containing the same exclusion). = This is the practical side of the debate.
This perspective is a polarizing one, since it pits the goal of usabilit= y against the goal of correctness and (wince) purity. However, I believe th= ere is an important third argument to be made, requiring a slight perspecti= ve shift. I believe that these two goals are not diametrically opposed. I'l= l explain, but first I want to lay some foundations.
First, what do we mean by usability? Since this is a build tool, and in = transitive dependency inclusion we're trying to read the implications of a = dependency set and "know what the user means" it is important tha= t we strive to provide the most accurate interpretation of the user's wishe= s. By and large, the user should be shielded from making elaborate and exce= ptional modifications to his POM; it should be literally only a couple of l= ines long (amplified by a couple of lines per dependency, obviously). In ke= eping with this, we have different scopes to allow users to specify, for ex= ample, that JUnit doesn't belong in his end assembly. This alleviates what = was an uncontrollable problem with the first implementation of transitive d= ependencies: severe bloat. Bloat is as important a problem to the end user = as dependency-closure specification once was.
Second, what do we mean by correctness of the repository? It means that = the POM for a project is a complete, comprehensive expression of what that = project provides, in what form, and what assumptions it makes in providing = it. In other words, it is supposed to say exactly what it does, and exactly= what it needs to do it. The build section is an exception here, in that it= is essentially specific build instructions about how the project's artifac= t has been provided. From a correctness standpoint, it seems logical to assume that only the development team and end users are quali= fied to make changes to this information. The development team, because the= y developed it, and should know better than anyone else; and the end user, = because even if they are wrong, their modifications will not affect others = (signified by the qualifier "end"). If the POM is an authoritativ= e provider of information, from where could others derive the authority to = override it?
To address this third viewpoint, I need an example. I chose jpox, for re= asons that will become apparent. The jpox-1.4 POM specifies a dependency on= Oracle's ojdbc jar, version 14. For clarity, this dependency can only be u= seful to those users who are using jpox functionality on Oracle, and probab= ly serves to allow jpox to use Oracle's blob implementations and such.
For the sake of argument, say I have a db-oriented project that uses jpo= x, but only for part of its functionality. The other part consists of code = that requires more performance. For this, I use jdbc core features like Pre= paredStatement and such. These are bundled with the JDK, so there is no iss= ue related to that functionality in and of itself. However, one implication= of this "other half" is that I have to construct SQL statements = using non-jpox code...and damn it, Oracle's just too hard! So, I don't support= it. It should be noted that this is not an application, m= erely a library. Since the project's functionality is cohesive, there is no= good reason for me to split the jpox-based parts from the jdbc-based parts= .
This is an interesting case, since it shows how the two previous viewpoi= nts can be made compatible. From a usability standpoint, including an impli= cit dependency on ojdbc is misleading and a nontrivial nuisance for my user= s. If they want to avoid bloat (ojdbc 14 is 1.4 megs - and I thought the '1= 4' was a version they'll have to add their own exclusions or else trim out the ora= cle stuff by hand. From a correctness standpoint, my project doesn't even s= upport oracle, so it's absolutely incorrect for me to export a transitive d= ependency on an oracle library (which may make it into their assemblies and= deployments). There is no possible way that they could use ojdbc.jar witho= ut causing problems with my library. Therefore, it should be possible for m= e to specify this anti-requirement in my POM to keep them from thinking the= y can use my project with Oracle based on the presence of this dependency. = Even though jpox has functionality that depends on ojdbc.jar, I do not. The= refore, I need to have the ability to specify, on behalf of my users, that = we will not depend on ojdbc.jar. In this case, absence of = such an ability is in clear violation of the correctness goal.
While it should be noted that I wholeheartedly agree with the critical m= ass argument - namely, that we are in a delicate position where we might st= art driving away users - I support propagated exclusions primarily to enabl= e the case above. I believe this illustrates that not all propagated exclus= ion is an abusive exploit of another project's position of power between an= other project and the end user. Since there is a valid use case - and I wou= ld argue, not an altogether exotic use case at that - I believe this is som= ething we should allow. All of our actions in making maven are subject to m= isuse, but just because I could specify a dependency on jd= k-1.0.1 doesn't mean that we should disallow users from specifying dependen= cies.------=_Part_1136_933989004.1369213701977--