No problem, I'll put comments in the pom files (at
Geoffrey's suggestion).
tnx, please do it under the <name> element always (usually
about the 8th line or so).
How do I go about getting commit permissions on svn; or would you
rather me provide patches for now?
IIRC, send your username which works on www.jboss.org for you
(create one if you don't have one) to mark,
he knows who to poke for commit rights :)
Geoffrey, would you rather me defer this until you've made your
other maven changes?
No need, subversion can merge stuff.
Only problem is, do you have an idea what to write in those
descriptions?
I mean, I have no idea what to write in drools-grid ("Drools in the
cloud" doesn't really suffice I believe).
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.