Look in jakarta-lucene-sandbox/projects/appex - I've commited Kelvin /
manfred's code there.
I couldn't find the tararchive class so I commented that out.
To build it you can use the interactive build with ./build.sh and see
the targets,
you can type ./build.sh docs to get teh docs
you can type ./build.sh compile to compile it...
or you can type ./build.sh mavendocs to get the docs as made by maven.
Due to limitations in maven the non-relative links don't render right so
the proposal and lucene link won't work. I'll see what I can do to
follow up with the maven guys on that. It works fine in the *docs*
build.
This format gives us a few advantages. ONe of which is that we can have
seperate xbuild.xml files under src/targets which can seperate out
functionality instead of having one monolithic build.xml.
A *cent* is basically an identified library that has a known repository
location... look in tools/cents/* for the ones that we're using
(forrest, maven, etc for documentation)
This uses some alpha and beta cents so you can't autodownload them if
you delete tools/cents/* -- once the next version of these cents are
officially *blessed* then you will be able to delete them and have them
autoupdate. This should happen soon.
I'll work on getting cents made for jdom and the rest of the
dependencies so that we don't have to store them in cvs.
In the comming weeks I hope to move classes out of the "search" package
and into src/java/org/apache/lucene/appex and create some basic specs
for particular concerns.
I think I'm sold on using avalon for much of these as I think a
component based architecture is the best idea and Avalon's documentation
is getting much better.
I realize this email may be a bit to terse to properly explain
everything.. Probably easiest to check it out and compile it, ask any
questions that aren't obvious.
If you have code that looks like it might fit into this then by all
means commit it. I prefer if we don't package it in
org.apache.lucene.** until its been refactored into an overall
framework.
I'll take a look at Otis's stuff and see if I can get that in here
tomorrow.
Sound good? Questions? comments? Thoughts?
Thanks,
-Andy
--
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
manfred's code there.
I couldn't find the tararchive class so I commented that out.
To build it you can use the interactive build with ./build.sh and see
the targets,
you can type ./build.sh docs to get teh docs
you can type ./build.sh compile to compile it...
or you can type ./build.sh mavendocs to get the docs as made by maven.
Due to limitations in maven the non-relative links don't render right so
the proposal and lucene link won't work. I'll see what I can do to
follow up with the maven guys on that. It works fine in the *docs*
build.
This format gives us a few advantages. ONe of which is that we can have
seperate xbuild.xml files under src/targets which can seperate out
functionality instead of having one monolithic build.xml.
A *cent* is basically an identified library that has a known repository
location... look in tools/cents/* for the ones that we're using
(forrest, maven, etc for documentation)
This uses some alpha and beta cents so you can't autodownload them if
you delete tools/cents/* -- once the next version of these cents are
officially *blessed* then you will be able to delete them and have them
autoupdate. This should happen soon.
I'll work on getting cents made for jdom and the rest of the
dependencies so that we don't have to store them in cvs.
In the comming weeks I hope to move classes out of the "search" package
and into src/java/org/apache/lucene/appex and create some basic specs
for particular concerns.
I think I'm sold on using avalon for much of these as I think a
component based architecture is the best idea and Avalon's documentation
is getting much better.
I realize this email may be a bit to terse to properly explain
everything.. Probably easiest to check it out and compile it, ask any
questions that aren't obvious.
If you have code that looks like it might fit into this then by all
means commit it. I prefer if we don't package it in
org.apache.lucene.** until its been refactored into an overall
framework.
I'll take a look at Otis's stuff and see if I can get that in here
tomorrow.
Sound good? Questions? comments? Thoughts?
Thanks,
-Andy
--
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
--
To unsubscribe, e-mail: <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>