11:04 a.m.
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
7:21 a.m.
Hey Thomas,
yes, boms ware modifed to have scope provided, as given the feedback on
forums lots of folks had problems with
bundling the API jars with their application, which resulted in lots of
deployment problems.
The testing on other hand results in problems you have, which are quite
easily fixed if you change the scope of dependency
when you are defining deps for your test modules.
Question is what is more common problem, one or another. It is hard to
choose what to cater to in this case.
I think that best thing do here is to update our quickstarts that reflect
how to work with newer boms.
Maybe someone else has better idea?
--
tomaz
On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont <tsegismo(a)redhat.com>
wrote:
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:06 a.m.
I was under the impression the best-practice "Maven-way" is to never specify
scope in BOMs (dependencyManagement) - let the importers of the BOM determine the scope of
the dependencies (to avoid the problems Thomas is reporting).
IMO, we should stick with the standard Maven best-practice and not provide a scope.
Anyone, therefore, importing BOMs should (usually) know they have to worry about providing
their scope since that's the normal operating procedure in Maven BOM usage.
This SO entry talks about this and the one response indicates problems with transitive
deps if you put scope in dependencyManagement (which sounds like the same reason why
WildFly has it - to specify "the most common" scope):
http://stackoverflow.com/questions/15221299/dependencymanagement-and-scope
I'm sure there are other reasons why not to do this. IMO, we should avoid the hassles
this is going to introduce - keep scope out of the BOM.
----- Original Message -----
Hey Thomas,
yes, boms ware modifed to have scope provided, as given the feedback on
forums lots of folks had problems with
bundling the API jars with their application, which resulted in lots of
deployment problems.
The testing on other hand results in problems you have, which are quite
easily fixed if you change the scope of dependency
when you are defining deps for your test modules.
Question is what is more common problem, one or another. It is hard to choose
what to cater to in this case.
I think that best thing do here is to update our quickstarts that reflect how
to work with newer boms.
Maybe someone else has better idea?
--
tomaz
On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont < tsegismo(a)redhat.com >
wrote:
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:57 a.m.
Just an update on this, as we discussed it with Thomas on IRC.
Result are fixed boms that ware just released with version of 9.0.0.Final
that is also in sync with just released WildFly 9.0.0.Final deps.
--
tomaz
On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont <tsegismo(a)redhat.com>
wrote:
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9 a.m.
Thank you very much Tomaž!
Le 03/07/2015 15:57, Tomaž Cerar a écrit :
Just an update on this, as we discussed it with Thomas on IRC.
Result are fixed boms that ware just released with version of 9.0.0.Final
that is also in sync with just released WildFly 9.0.0.Final deps.
--
tomaz
On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont <tsegismo(a)redhat.com
<mailto:tsegismo@redhat.com>> wrote:
Hi everyone,
While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed
that the Wildfly BOM now declares provided scope for some dependencies.
I guess the goal is to help users which forget to set the provided scope
in their POM to end up with all the libraries in their WAR.
On the other hand, if you use some libraries in your tests, then
dependency resolution can be broken. For example, if you add
org.jboss.resteasy::resteasy-client in test scope, your tests fail due
to a missing class from commons-io, because commons-io should be
resolved as a transitive dependency of
org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided,
instead of test.
Have you considered this use case? Are there other motivations than
helping Maven beginners?
Best regards,
Thomas
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3429
days inactive
3433
days old
4 comments
3 participants
participants (3)
-
John Mazzitelli -
Thomas Segismont -
Tomaž Cerar