maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: scope management without losing granularity
Date Mon, 31 Oct 2011 18:56:30 GMT
On 31/10/2011 2:13 PM, Gustavo Pollitzer wrote:
> Ron,
> Thanks again for your clarifications. Now, I have more clear that the
> plugins are free to give the understanding they wish to the POM elements.
> Even the plugins supported by the maven project.
> Anyhow, based on what you say, I believe you didn't understand me. Perhaps
> because my bad English.
> *On Mon, Oct 31, 2011 at 11:24 AM, Ron Wheeler<
>>  wrote:
> *
>> *A plug-in that builds archives from artifacts created in other projects
>> will not care about scope since anything mentioned as a dependency or
>> included in the list of files to be included will be included.
>> The scope "provided" would be a stupid thing to say as a scope since you
>> could just leave it out of the list if you don't want it in the archive.
>> The scope "compile" is not instructive since you are not going to compile
>> anything.
>> I would expect the author of the plug-in to ignore scope altogether.*
> The scope 'provided' is not pointless. It permits to exclude from the EAR
> an artifact that is a dependency of many of the artifacts that are listed
> for inclusion in the assembly. It avoid the necessity to add a transitive
> dependency exclusion in every expressly included artifact that can depend
> on it.
> In fact, how to do this the proper way was the question that incited me to
> start this discussion. But that is clear for me now.
This would be a particularity of the plug-in and could be true.
It seems that what you are saying is that the assembly plug-in will 
expand all of the jars and remove certain classes from the jars that 
have been marked as excluded.

> *
> On Mon, Oct 31, 2011 at 11:24 AM, Ron Wheeler<
>>  wrote:
> *
>> *"Provided" only depends on deployment.
>> The fact that it is a "compile" or "provided" dependency at all means that
>> you need the artifact for the compile but when you specify a "provided"
>> dependency,  you are telling Maven that it will be provided at deployment
>> in some other way and you asking Maven NOT to stick it in the current
>> artifact.*
> Right. But note that also the "compile" scoped dependencies are not
> packaged along the artifact in many packaging types.
In the "standard" Maven plug-ins that build jars, it will cause them to 
be included.
> Anyway, that is what I am trying to say. This is the information supplied
> by the second aspect of the<scope>  element I mentioned. This aspect tells
> maven how the dependency will be provided.

> And because the person that
> creates an artifact POM (in opposition to an assembly POM) doesn't have to
> take care if his artifact and the dependencies it requires are going to be
> assembled together or how are they deployed, it should not be specified in
> the artifact's POM.
An interesting point.
If a JAR does not contain all of the dependencies that it needs, a 
person using that JAR must have some way to know what is missing and 
what version is required.
They will only find out at run-time that this jar depends on a missing 
dependency when the loader crashes.
The documentation of the utility will have to have big red sentences 
describing each of the missing dependencies.
This will make it much harder for the IDE to help the programmer. Now 
the IDE can detect version conflicts based on references in the POM and 
can let the developer resolve them.
> The artifact POM merely has to tell maven which dependencies are required
> by the release, which are required for testing, which of them are required
> during runtime only or compilation also, and which of them must be loaded
> by the same class loader than the artifact classes. In short, what it
> requires.
> On the other hand, the assembly POM provides the requirements and/or tells
> how they are provided.
> Therefore, the 'provided' option (and much more the 'system' option) must
> be removed from the<scope>  element. This information pertains to the
> assembly POM or whatever specifies how to deploy.

System is never used.

> I hope I was clearer this time.
I understand where the motivation for this idea comes from but am 
concerned that the problem that it creates is worse than the problem 
that it solves.

We used a much clearer way of solving this problem through aggregation 
jars that sorted out deployment once for each set of libraries and 
reduced the artifact POMs' <dependencies> to a few dependencies that 
were carefully managed centrally.


Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

View raw message