Hi, For HSEARCH-459 I would like to move Search to a multi-module setup (similar to Validator). This way the archetype sources will actually always get compiled and are less likely to get outdated. I think we talked before about potential benefits of having a multi-module build for Search. Any objections if I go ahead with this? --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Of course it does not offer any additional functionality, but when deployed as archetype into the maven repo it allows to "bootstrap" a Search enabled maven project using the maven archetype plugin (http://maven.apache.org/plugins/maven-archetype-plugin). I agree in current setup the quickstart project gets a little into the way, but that is mainly because it uses a obsolete format/setup. Did you have ever problems with the quickstart module in Validator? That's how it would like like in Search as well. --Hardy On Fri, 12 Feb 2010 11:31:50 -0300, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Is the quickstart archetype really needed? > On my side, I always exclude it as it goes in my way. > > On 12 févr. 2010, at 15:25, Hardy Ferentschik wrote: > >> Hi, >> >> For HSEARCH-459 I would like to move Search to a multi-module setup >> (similar to Validator). >> This way the archetype sources will actually always get compiled and are >> less likely to get outdated. >> >> I think we talked before about potential benefits of having a multi-module >> build for Search. Any objections >> if I go ahead with this? >> >> --Hardy >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >

it's ok for me; the best benefit I expect is to split the testssuite and clean that, opening the doors to a performance&stress testsuite. Also the Solr "optional" dependencies should be actually mandatory if you use the analyzerdefs, so this could eventually be moved to a separate search module; that helps in dependecy management for users. Eventually other optional dependencies could follow - not sure the support for JPA won't be easy to split out but at least you would have options to do so if you wished. Similar story for other dependencies like JGroups backend, soon Infinispan DirectoryProvider, etc.. maybe even a contrib are for experimental backends and so on. I never had issues with the archetype? Eclipse ignores it. Sanne 2010/2/12 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > Is the quickstart archetype really needed? > On my side, I always exclude it as it goes in my way. > > On 12 févr. 2010, at 15:25, Hardy Ferentschik wrote: > >> Hi, >> >> For HSEARCH-459 I would like to move Search to a multi-module setup >> (similar to Validator). >> This way the archetype sources will actually always get compiled and are >> less likely to get outdated. >> >> I think we talked before about potential benefits of having a multi-module >> build for Search. Any objections >> if I go ahead with this? >> >> --Hardy >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

It seems to me that there are potential other benefits we could gain from a multi-module setup. Maybe Emmanuel should actually do it, since he loves maven so much ;-) On Fri, 12 Feb 2010 11:46:32 -0300, Sanne Grinovero <sanne.grinovero(a)gmail.com&gt; wrote: > it's ok for me; > the best benefit I expect is to split the testssuite and clean that, > opening the doors to a performance&stress testsuite. > > Also the Solr "optional" dependencies should be actually mandatory if > you use the analyzerdefs, so this could eventually be moved to a > separate search module; that helps in dependecy management for users. > Eventually other optional dependencies could follow - not sure the > support for JPA won't be easy to split out but at least you would have > options to do so if you wished. > Similar story for other dependencies like JGroups backend, soon > Infinispan DirectoryProvider, etc.. maybe even a contrib are for > experimental backends and so on. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

As much as I see the potential of gradle I don't want to be the one to push this forward right now. A multi-module setup is a minor change in this case. --Hardy On Fri, 12 Feb 2010 11:57:17 -0300, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > Might I suggest y'all look at gradle since this is something you re just > getting ready to start? > > On Fri, 2010-02-12 at 11:55 -0300, Hardy Ferentschik wrote: >> It seems to me that there are potential other benefits we could gain >> from >> a multi-module >> setup. >> >> Maybe Emmanuel should actually do it, since he loves maven so much ;-) >> >> On Fri, 12 Feb 2010 11:46:32 -0300, Sanne Grinovero >> <sanne.grinovero(a)gmail.com&gt; wrote: >> >> > it's ok for me; >> > the best benefit I expect is to split the testssuite and clean that, >> > opening the doors to a performance&stress testsuite. >> > >> > Also the Solr "optional" dependencies should be actually mandatory if >> > you use the analyzerdefs, so this could eventually be moved to a >> > separate search module; that helps in dependecy management for users. >> > Eventually other optional dependencies could follow - not sure the >> > support for JPA won't be easy to split out but at least you would have >> > options to do so if you wished. >> > Similar story for other dependencies like JGroups backend, soon >> > Infinispan DirectoryProvider, etc.. maybe even a contrib are for >> > experimental backends and so on. >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev