On 30/10/2011 5:56 PM, Gustavo Pollitzer wrote:
Thank you a lot for your time. Your really illuminated my brain. My mistake
was to try to make the EAR module of my project in such a way that other
artifacts can depend on it. But that is no the purpose of EAR modules.
Right.
So, there is no risk to append, after the dependencies intended to add
content to the EAR, some dependencies to artifacts that are already
dependencies of the before dependencies just to override its scope to
'provided'. The maven-ear-plugin takes advantage of the maven dependency
management, but uses it for a very different purpose: to make an archive
and not an artifact to which other artifacts can depend upon. So the
maven terms has a different meaning in POMs intended to be an artifact to
which others can depend upon than in POMs intended to build assemblies.
That could be but that is the plug-in author's choice.
The assembly plug-in or the shade plug-in can use a separate file to
determine what to include in the archive.
Nevertheless, there is something that makes noise in my brain. It would be
better if the two kinds of dependencies; the ones intended to add content
to the EAR, let's call them 'content' dependencies, and the ones intended
to override the scope of the dependencies of the 'content' dependencies;
would be clearly distinguishable by means of the maven language instead
of comments.
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.
I think that the source of this trouble is the low cohesion of the<scope>
element. It tries to specify two aspects of an artifact with a single
value. Two aspects that should be independent of each other and that should
be determined in different circumstances.
- The first aspect is the classification of the dependency as
required during runtime only or during compilation also. This aspect
depends only and exclusively on the source code of the artifact for which
we are specifying the dependencies. It does not depend in any way on the
deployment.
Not true.
"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.
- And the second aspect tells the packager plugin if it has to add the
dependency to the archive or not. This aspect has nothing to do with the
source code, but only with the deployment. The creator of the artifact
should not necessarily know the way his artifact and their dependencies
will be deployed, and therefore, this aspect should not be specified by
him, but by responsible of the deployment trough some kind of descriptor.
In our case, the EAR module POM.
This depends on who wrote the plug-in and what they decided to use as
instructions.
This has nothing to do with Maven since anyone can put whatever logic
they want in their plug-in.
If the plug-in has its own place to list files and artifacts that it
want to manipulate, that will work.
If the author wants to look at the <dependencies> to identify artifacts
to process, that will work.
Don't mix up plug-ins with Maven and be careful about generalizing the
behaviour of plug-ins.
The author has a lot of freedom about how to build a plug-in.
There is a big difference between the core Maven plug-ins that compile
and build artifacts and plug-ins that do assemblies of archives.
You are right that their understanding of <dependencies> are very different.
I hope that this helps.
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]
