Hi John and others,
First, I am not against including WildFly in some form. But I vote for
the least possible set. jboss-javaee-7.0-with-all [1] is unnecessarily
broad. Hibernate anyone?
Second, the possibility to run in a non-WF-like container is still
somewhere in my consciousness. Importing wf BoM does not seem to be a
step in that direction.
[1]
http://central.maven.org/maven2/org/wildfly/bom/jboss-javaee-7.0-with-all...
Thanks,
Peter
On 02/16/2015 03:12 PM, John Mazzitelli wrote:
My bad - it has been my intention to never touch the parent pom (or
global maven stuff in general) anymore. I slipped up here. I was only
trying to keep everyone on the same version as the Wildfly container
we are embedding in (so, for example, the integration assembly will
work). Didn't think it would be a problem since we are all running in
Wildfly (at least, that is how the integration assembly that heiko
had me create is working). Not sure how we can ensure we all use all
the same versions as provided by the container we are in unless we
pull in the BOM, but perhaps there is another way. (BTW: this doesn't
pull in all those dependencies, it is just pulling in the dependency
definitions and individual projects pull in whatever deps they want
with the provided scope.
But if there is a better way to ensure we
keep on the same versions that the container provides, we can do
that.
> On 02/16/2015 02:37 PM, Peter Palaga wrote:
>> Hi John,
>>
>> was there any discussion (that I may have missed during my PTO)
>> around importing the jboss-javaee-7.0-with-all to parent? Could
>> you please justify the idea once again for me?
>>
>> I must say I'd veto the change if I was at work. Here is why:
>>
>> (1) Tying to WildFly only. The change might be understood like
>> this. I am not sure this was your intention, but please consider
>> that importing another similar BoM (say EAP BoM) in paralel would
>> in fact be extremely impractical, because of version conflicts.
>>
>> (2) Pulling in many artifacts we do not use, do not need, some of
>> them maybe being implicitly unwanted ones. But having them in
>> parent is actually legalizing them without any discussion. That
>> is especially dangerous.
>>
>> (3) "Political" dependence on WildFly. WildFly may do changes at
>> any time in their BoMs that may have bad consequences in
>> Hawkular.
>>
>> The bottom line is that it would be much better to avoid
>> situations this through discussing proposals prior to merging
>> them in master. I have proposed explicit parent contribution
>> rules in
https://github.com/hawkular/hawkular-parent-pom/pull/13
>> Feel free to comment on them.
>> _______________________________________________ hawkular-dev
>> mailing list hawkular-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
_______________________________________________ hawkular-dev mailing
list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev