On 6 Jun 2013, at 12:34, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
On 6 juin 2013, at 11:21, Pete Muir <pmuir(a)redhat.com> wrote:
> Hey Emmanuel,
>
> On 5 Jun 2013, at 19:25, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
>> The Hibernate Search enabled version of TicketMonster relies on
>> Hibernate Search 4.3 which itself has a dependency on Hibernate ORM
>> included in WildFly and JBoss EAP.
>>
>> My first approach was to ask the user to add the Hibernate Search JBoss
>> Module manually into their EAP / WildFly distribution and have it
>> referenced in jboss-deployment-structure.xml.
>> I also had to put Hibernate Search in my POM as provided because the BOM
>> references an older version of Hibernate Search.
>
> We should be targeting the version of HSearch that is in WFK. If the BOM is out of
date (highly possible), then please either send a pull to update it or ask Rafael to do
so. He or I can do a you a release very quickly once the change is in.
Spatial queries are part of 4.3 so if it makes it into WFK next we are good. At any rate
I can't use older versions without changing an interesting part of the demoing.
Gotcha. So for now, we'll need to keep this on the branch, and once WFK is updated, we
can update the BOM and merge this. Sound good?
>
>>
>> To avoid the manual step, I tried to list Hibernate Search explicitly in
>> the POM as regular scope and no longer use
>> jboss-deployment-structure.xml. But then I have to play with exclusions
>> which is not too nice either.
>>
>> Which approach is better suited for TicketMonster? And is there a better
>> way?
>
> Fix the HSearch POM so that it marks as optional or provided stuff that you are
excluding would be one way. If you don't want to do this, then another option would be
to produce a HSearch-for-WF pom as part of HSearch that does it.
>
> In general, it's better to not make the user fiddle with exclusions, and instead
do it in the framework itself.
Ok I'll discuss the options with the team.