I think the feature pack plugins will avoid any enforced rules as they use the aether api
directly to resolve their dependencies. So it is possible for conflicting artifacts to be
resolved in a feature pack dependency chain.
----- Original Message -----
From: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>
To: "James Netherton" <jnethert(a)redhat.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Wednesday, 21 October, 2015 2:00:58 PM
Subject: Re: [wildfly-dev] Feature pack maven plugins question
If you would add maven-enforcer-plugin it would fail if you try to add
something like this.
We rely on it for this kind checking in WildFly build.
--
tomaz
On Wed, Oct 21, 2015 at 2:52 PM, James Netherton <jnethert(a)redhat.com>
wrote:
Hello everyone,
Consider the following.
Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>
Feature pack 'B' has a dependency on the WildFly 10 feature pack and also
on feature pack 'A'. E.g:
<dependencies>
<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
<artifact name="org.foo:feature-pack-A" />
</dependencies>
Leaving the sanity and validity of doing this aside, should the
feature-pack-build or server-provisioning-plugin be detecting this as an
error condition, given that you'll have overlapping and possibly
problematic non-overlapping file paths coming from the conflicting WildFly
versions?
At the moment the plugins allow this scenario.
Cheers,
James
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev