There is also a concept of a contrib project which is used in Lucene. All the Non-core work is added as a separate contrib project.
The sub projects may need some changes to the core itself .That can be resolved on a case-by-case basis. This can act as an incubator for the feature . If it gains enough traction it can also become a subproject. --Noble On Thu, Jun 26, 2008 at 11:27 PM, Rick Hillegas <[EMAIL PROTECTED]> wrote: > Noble Paul നോബിള് नोब्ळ् wrote: >> >> Can there be a derby sub-project which can focus on a derby_lite for >> these kind of requirements? >> >> If by enabling a repackaging derby can grow it's userbase would it be >> nice? >> --Noble >> > > I think a subproject is a possibility. I don't know much about how Apache > subprojects work. My hope would be that contributions to Derby Lite would > also be contributions to Derby. So, for instance, if a Derby Lite user added > backward scanning of btrees, then it would be great if that work were > checked into Derby Classic so that someone working in the Derby SQL > interpreter could take advantage of it. > > Thanks, > -Rick >> >> On Thu, Jun 26, 2008 at 9:46 PM, Bryan Pendleton >> <[EMAIL PROTECTED]> wrote: >> >>>> >>>> be useful for applications which just need to put and get data by key >>>> value. These would be applications which don't need complex queries or >>>> SQL. >>>> >>> >>> Aren't there some pretty good packages for this already? E.g., BDB-JE, >>> JDBM, Perst, etc.? >>> >>> Speaking totally personally, I'd sure like to see Derby focus on the >>> things that make it special: >>> - complete and correct JDBC implementation >>> - complete and correct SQL implementation >>> - low footprint, zero-admin reliable multi-user DBMS >>> >>> thanks, >>> >>> bryan
