On Thu, 2008-10-09 at 13:15 -0400, Ryan McKinley wrote: > >> > >> root > >> + tools > >> + docs (generated docs -- for everything?) > > > > For the core and core components (like dynamics) and our site. > > > > is there a distinction between "core components" and just > "components"?
Core components are the basic/default implementation of a couple of handler/protocols/... They can be reused in various use cases. May be would be better to call them common components. > My view would be that we have droids-core.jar, then a > jar for each 'component': droids-dynamics.jar, I agree to have a droids-core-dynamics.jar however this is for me not a component on its own. It is an dynamic extension of the core expressed as conf. http://ant.apache.org/ivy/history/latest-milestone/tutorial/conf.html > Perhaps we have some bundled jars for the most common distributions: > droids-all.jar (includes everything in one jar) Agree we need such a distribution containing core and common components. ... > > >> + solr > > > > IMO that has to be > > org.apache.solr or org.apache.lucene.solr > > > > Components should be named uniquely. Using package style naming seems > > the most appropriate. > > > > it seems a bit wordy to me. For clarity, I think a short unique name > is good. The problem is that this short names soon lead to conflicts. http://forrest.apache.org/pluginDocs/plugins_0_90/pluginInfrastructure.html#Naming+Conventions I think it always should be [organisation].[component-name] > Essentially anything in our depot would have the package > prefix "org.apache.droids" so I'm not sure I see the bennifit of > naming the folders under depot with a fully qualified name. For now that may be true however the core depot is one of many in the future. Let us be prepared for this situation. > > Additionally, I don't think Droids (or any other project) should write > code in a package other then its own name. Code related to solr > should go in: o.a.droids.solr NOT org.apache.solr.droids. You are mixing java package naming with the actual name of the plugin. However I agree about o.a.droids.solr. > What if > solr wants to include droids code in their distribution? Do they have > to worry about a name conflict? > > > >> > >> + dynamics > >> + src > >> + lib > >> ... (like the existing src/templates/component) > > > > I am not sure I see dynamics more within each component rather then on > > its own. I mean I expect e.g. a org.apache.solr.dynamic in the future. > > > > Each component *may* depend on the 'dynamics' component -- if so, then > it adds configs/loading specific to itself. > > But the 'dynamics' component is the one that contains all the common > code -- and the CLI you have... In ivy that is a config thing more then separating it into a component. I will see what I can come up with after finishing this slides. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
