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

[Michael Neale]

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 at gmail.com> 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 at codehaus.org> 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 at gmail.com>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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101027/45f8e722/attachment-0001.html