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<
[email protected]> 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<
[email protected]> 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
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
