Re: [rules-dev] [vote] Module drools-atom in limbo

Yes - that is right - I forgot the name of it. So the stand alone module needs to stay - or is the source code being merged in with plugin codebase? On Wed, Oct 27, 2010 at 2:37 PM, Lucas Amador <lucazamador(a)gmail.com&gt;wrote: > Hi all, > drools-assistant is the module that I created to add refactoring support > in the eclipse plugin/guvnor. The last weekend I fixed the integration with > eclipse and they will be commited in the next days, maybe tomorrow :) > > Regards, > > Lucas > > On 26 October 2010 23:09, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > >> On 26/10/2010 22:57, Michael Anstis wrote: >> >> Hi Geoffrey, >> >> Being relatively new I can't comment on some of the specifics, but I >> question the following:- >> >> - drools-assistant >> - drools-atom >> - drools-clips (I believe Mark did this on a rainy weekend, but don't >> know if it's still supported). >> - drools-container >> - drools-doc\drools-docs (which is actively used?!? Do we need both?) >> - drools-rhq-plugin >> - drools-simulator >> - install >> - src >> >> I have thought for a long time I'd be good to have on the Wiki a summary >> of what each project represents and what package (JAR) they bundle into. >> >> You just volunteered yourself for your first task next november when you >> start ;) >> >> Mark >> >> >> Cheers, >> >> Mike >> >> On 26 October 2010 15:59, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt;wrote: >> >>> I am looking at cleaning up the build and moving to maven 3, to make it >>> faster, more reliable, etc. >>> I am also actively wondering if some modules or files aren't dead code. >>> First candidate is drools-atom: >>> >>> The module drools-atom is in limbo: >>> - It still exists >>> - It's not part of any build >>> - Does it still build? No >>> -- 'dependencies.dependency.version' is missing for >>> org.apache.cxf:cxf-rt-frontend-jaxrs:jar >>> - Does it still compile against the latest drools version? Idunno, but >>> since it's not part of the build, tomorrow's refactor might break it. >>> - Does anyone use it? If it doesn't build and it isn't released... no? >>> >>> I don't think that code is useful to anyone in this state. I do think >>> it's presence alone slightly complicates the drools sources. >>> >>> >>> What do we do with it? >>> - [A] remove the directory drools-atom from trunk (it's still retired in >>> in subversion) >>> - [B] leave it like it is now. It might be usefull to someone >>> - [C] add it to the build again, make it work >>> - [D] create a separate repository "drools-incubator" and move it there >>> >>> In my opinion: >>> +1 for [A] >>> -1 for [B]: either it builds or it's not in trunk >>> >>> >>> If we all agree that removing dead modules is a good idea, I 'll provide >>> a list of possible candidates next time. >>> >>> -- >>> With kind regards, >>> Geoffrey De Smet >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> >> _______________________________________________ >> rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev