I agree with your point of view, I fiind it reasonable and could solve
my problem (and each other problem of the same kind).
Do you know if there is an improvement issue in Jira? If there is
none, can I open such an issue describing the desired solution in
general terms?
2013/7/30 Stephen Connoll
Yeah, I think that is probably something that will need to be addressed in
a future pom format... something along the line of dependency attributes or
markers that can then be used by specific plugins to pull out sections of
dependencies.
Scope should not be abused for what is really a marker ques
Correct. I don't want to duplicate the configuration twice, the first
time in my plugin and the second time in the section to
let Maven correctly compute the build plan.
2013/7/30 Stephen Connolly :
> On 30 July 2013 14:23, Francesco Mari wrote:
>
>> I missed to describe my use case. I will try
On 30 July 2013 14:23, Francesco Mari wrote:
> I missed to describe my use case. I will try to do it as detailed as I
> can, but it can be quite verbose.
>
> I have a project which is built by aggregating other artifacts with
> different roles: runtime OSGi bundles, plain content, testing OSGi
>
AFAIR In Maven 2.x it was possible to put anything in scopes and it was
very error prone because any unknown scope was silently transformed into
compile scope
In 3.x the choice was done to strictly check the scope with ones known by
Maven.
I agree that an API to declare new scope using extensions m
If you want a real life example which is very close to what I'm
talking about, you could take a look at [1], which is part of the
Launchpad Maven Plugin of the Apache Sling project.
[1]:
https://github.com/apache/sling/blob/trunk/tooling/maven/maven-launchpad-plugin/src/main/java/org/apache/sling
I missed to describe my use case. I will try to do it as detailed as I
can, but it can be quite verbose.
I have a project which is built by aggregating other artifacts with
different roles: runtime OSGi bundles, plain content, testing OSGi
bundles, integration testing modules. You can't build this
I find the lure of the custom scopes to be a siren's call.
There are maybe 2-3 "missing" scopes. all other needs are better addressed
with a different project structure in my view.
We have the separation between test and non-test... but test is an all or
nothing... need the symmetry between the n
Hi,
I was wondering why using custom dependency scopes issues a warning
when the POM model is validated. Why Maven just don't ignore dependecy
scopes he cannot understand?
I was thinking to treat dependency scopes in a different way. The only
logic I've found about dependency scopes is in [1] and
