9:59 a.m.
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
4:43 p.m.
I don't think it is used or needed. Can archive it off unless anyone says
otherwise.
On Wed, Oct 27, 2010 at 1:59 AM, Geoffrey De Smet
<ge0ffrey.spam(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
9:38 p.m.
Michael Neale wrote:
I don't think it is used or needed. Can archive it off unless
anyone
says otherwise.
Yes, its a dead code. We can safely remove it.
Jervis
On Wed, Oct 27, 2010 at 1:59 AM, Geoffrey De Smet
<ge0ffrey.spam(a)gmail.com <mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:32 a.m.
New subject: [result] Module drools-atom removed
Done, tnx :)
Op 28-10-10 04:38, Jervis Liu schreef:
Michael Neale wrote:
> I don't think it is used or needed. Can archive it off unless anyone
> says otherwise.
>
>
Yes, its a dead code. We can safely remove it.
Jervis
> On Wed, Oct 27, 2010 at 1:59 AM, Geoffrey De Smet
> <ge0ffrey.spam@gmail.com<mailto:ge0ffrey.spam@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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net<http://www.michaelneale.net>
> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
--
With kind regards,
Geoffrey De Smet
4:57 p.m.
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.
Cheers,
Mike
On 26 October 2010 15:59, Geoffrey De Smet <ge0ffrey.spam(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:05 p.m.
I will try and describe what I know (and perhaps a README would make more
sense?)
On Wed, Oct 27, 2010 at 8:57 AM, Michael Anstis <michael.anstis(a)gmail.com>wrote:
Hi Geoffrey,
Being relatively new I can't comment on some of the specifics, but I
question the following:-
- drools-assistant
Hmm... is this the refactoring support project? If so - not sure what
state it was
in. This was a google summer of code thing if I am not
mistaken.
- drools-atom
Can retire - was an atom-module for Guvnor for atompub support (what little
atom is
needed is now baked in anyway).
- drools-clips (I believe Mark did this on a rainy weekend, but don't
know if it's still supported).
HAhaha - I believe that started in a pub, and then mark did a furious
amount of
work - made it work in, what, 2007 (it is/was pretty cool
actually)? Last I looked at it, I added a little shell... but if its not
maintained at the moment up to all drools features - I still think it should
stay around - as it may matter to someone enough to get it up to date if it
isn't (help with people coming from jess for instance).
- drools-container
- drools-doc\drools-docs (which is actively used?!? Do we need both?)
- drools-rhq-plugin
I think Edson (?) did this - or Heiko Rupp? this is legitimate probably -
but
really should shift to the rhq-project.org repository - not live in
drools in my opinion.
-
- 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.
Cheers,
Mike
On 26 October 2010 15:59, Geoffrey De Smet <ge0ffrey.spam(a)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(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
9:09 p.m.
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
<mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@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
10:37 p.m.
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> 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>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
11 p.m.
Here is a starting point if anyone wants to keep busy:
http://community.jboss.org/wiki/Modules
Mark
On 27/10/2010 04:37, Lucas Amador 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
<mailto:mproctor@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(a)gmail.com <mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@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
1:54 a.m.
New subject: Modules description on the wiki or in the pom.xml description?
>> 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.
Imho, this summary is better put in the pom.xml's <description> entity,
instead of the wiki, because:
- easier to stay up to date (like javadocs)
- easier to find for most people (I doubt many even know about the wiki)
- used in repository search engines, such as
-- http://repository.jboss.org/nexus
-- http://www.mvnrepostory.com
Op 27-10-10 06:00, Mark Proctor schreef:
Here is a starting point if anyone wants to keep busy:
http://community.jboss.org/wiki/Modules
Mark
On 27/10/2010 04:37, Lucas Amador 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
> <mailto:mproctor@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(a)gmail.com <mailto:ge0ffrey.spam@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
2:59 p.m.
New subject: Modules description on the wiki or in the pom.xml description?
On 27/10/2010 07:54, Geoffrey De Smet wrote:
>>> 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.
Imho, this summary is better put in the pom.xml's<description> entity,
instead of the wiki, because:
- easier to stay up to date (like javadocs)
- easier to find for most people (I doubt many even know about the wiki)
- used in repository search engines, such as
-- http://repository.jboss.org/nexus
-- http://www.mvnrepostory.com
maybe one of those maven reports can be generated
and uploaded to the wiki.
Mark
Op 27-10-10 06:00, Mark Proctor schreef:
> Here is a starting point if anyone wants to keep busy:
> http://community.jboss.org/wiki/Modules
>
> Mark
> On 27/10/2010 04:37, Lucas Amador 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
>> <mailto:mproctor@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@gmail.com<mailto:ge0ffrey.spam@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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org<mailto:rules-dev@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
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
11:48 p.m.
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> 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> 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>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
12:42 a.m.
Ideally it should remain as a separated module, so it can be implemented in
guvnor and the plugin. But maybe it could be moved to a new folder together
with the other modules that aren't functional to drools itself.
On 27 October 2010 01:48, Michael Neale <michael.neale(a)gmail.com> wrote:
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>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> 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>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
1:35 a.m.
New subject: [vote] Module drools-assistent moved into drools-ide-common
If drools-assistent needs to be implemented in guvnor and the eclipse
plugin,
it should be added to drools-ide-common IIRC :)
Op 27-10-10 07:42, Lucas Amador schreef:
Ideally it should remain as a separated module, so it can be
implemented
in guvnor and the plugin. But maybe it could be moved to a new folder
together with the other modules that aren't functional to drools itself.
On 27 October 2010 01:48, Michael Neale <michael.neale(a)gmail.com
<mailto:michael.neale@gmail.com>> wrote:
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
<mailto:lucazamador@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(a)codehaus.org
<mailto:mproctor@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(a)gmail.com <mailto:ge0ffrey.spam@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(a)lists.jboss.org
> <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@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
--
With kind regards,
Geoffrey De Smet
5:41 p.m.
New subject: [vote] Module drools-assistent moved into drools-ide-common
agree - although "ide" in the name implies it is not for web tools ?
On Wed, Oct 27, 2010 at 5:35 PM, Geoffrey De Smet
<ge0ffrey.spam(a)gmail.com>wrote:
If drools-assistent needs to be implemented in guvnor and the
eclipse
plugin,
it should be added to drools-ide-common IIRC :)
Op 27-10-10 07:42, Lucas Amador schreef:
> Ideally it should remain as a separated module, so it can be implemented
> in guvnor and the plugin. But maybe it could be moved to a new folder
> together with the other modules that aren't functional to drools itself.
>
> On 27 October 2010 01:48, Michael Neale <michael.neale(a)gmail.com
> <mailto:michael.neale@gmail.com>> wrote:
>
> 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
> <mailto:lucazamador@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(a)codehaus.org
> <mailto:mproctor@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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)lists.jboss.org
>> <mailto:rules-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)lists.jboss.org <mailto:
rules-dev(a)lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net <http://www.michaelneale.net>
> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@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
--
With kind regards,
Geoffrey De Smet
_______________________________________________
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
7:56 p.m.
New subject: [vote] Module drools-assistent moved into drools-ide-common
Good idea, I agree.
On 27 October 2010 19:41, Michael Neale <michael.neale(a)gmail.com> wrote:
agree - although "ide" in the name implies it is not for
web tools ?
On Wed, Oct 27, 2010 at 5:35 PM, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com
> wrote:
> If drools-assistent needs to be implemented in guvnor and the eclipse
> plugin,
> it should be added to drools-ide-common IIRC :)
>
> Op 27-10-10 07:42, Lucas Amador schreef:
> > Ideally it should remain as a separated module, so it can be implemented
> > in guvnor and the plugin. But maybe it could be moved to a new folder
> > together with the other modules that aren't functional to drools itself.
> >
> > On 27 October 2010 01:48, Michael Neale <michael.neale(a)gmail.com
> > <mailto:michael.neale@gmail.com>> wrote:
> >
> > 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
> > <mailto:lucazamador@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(a)codehaus.org
> > <mailto:mproctor@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(a)gmail.com
<mailto:ge0ffrey.spam@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(a)lists.jboss.org
> >> <mailto:rules-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> rules-dev mailing list
> >> rules-dev(a)lists.jboss.org <mailto:
> rules-dev(a)lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org
> >
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> >
> > --
> > Michael D Neale
> > home: www.michaelneale.net <http://www.michaelneale.net>
> > blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev(a)lists.jboss.org <mailto:rules-dev@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
>
> --
> With kind regards,
> Geoffrey De Smet
>
> _______________________________________________
> 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
2:43 p.m.
No problem, I'll put comments in the pom files (at Geoffrey's suggestion).
How do I go about getting commit permissions on svn; or would you rather me
provide patches for now?
Geoffrey, would you rather me defer this until you've made your other maven
changes?
Cheers,
Mike
On 27 October 2010 03:09, Mark Proctor <mproctor(a)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(a)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(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
5139
days inactive
5141
days old
17 comments
6 participants
participants (6)
-
Geoffrey De Smet -
Jervis Liu -
Lucas Amador -
Mark Proctor -
Michael Anstis -
Michael Neale