On Wed, 2008-10-08 at 21:50 -0400, Ryan McKinley wrote: > I'm trying to figure out what the layout is/should be. I'm new to > ivy, so bear with me.
LABS-189 there you can find the commit history about this issue. I have not really used ivy in conjunction with multiple projects yet but I am making steady progress. ;) I will use the word "component" synonym to plugin in the rest of the mail. I created so far a "seed" infrastructure for components but it is not 100% connected with the build logic. You can have a first look in using the new "droids" command. After setting $DROIDS_HOME and adding $DROIDS_HOME/bin to your $PATH. You can seed a component like follow: cd $DROIDS_HOME/depot droids seed -> Now there is a guided creation process. It ask you a couple of question about your component and create it then in the depot folder. I need to finish my slides for apachecon which is ATM the hold up for me to finish with hooking up the build process for a fresh seed. > Looks like we have: > > <configurations> > <conf name="core"/> > <conf name="dynamics" extends="core" visibility="public" > description="dynamic support"/> > <conf name="plugins" extends="dynamics" visibility="public" > description="plugins support"/> > <conf name="robots" extends="dynamics" visibility="public" > description="plugins support"/> > <conf name="test" extends="core" visibility="private" > description="for testing our framework"/> > </configurations> > > this implies plugins and robots extend dynamics. Yeah but I am not 100 % convinced about this since it is actually an extension to the core. I mean close to every component can/will provide dynamic support. It is just a xml file in the end. I am not sure if keeping them in a separate jar brings any benefit. I think the conf should look for the core and as well any component like: <configurations> <conf name="core"/> <conf name="dynamics" extends="core" visibility="public" description="dynamic support"/> <conf name="test" extends="core" visibility="private" description="for testing our framework"/> </configurations> So one is able to resolve dependencies for dynamic mode (BTW I hope to have a chat with the Felix guys on the apachecon for osgi support), plain core and testing. > If I understand 'dynamics' correctly, it is just a bunch of utilities > to help loading from spring. It also includes a command line > interface to start droids. Dynamics is nothing more then another > plugin. See above, I do not share full hearted this view. > About tests... I think each set of code should manage its own tests. > > Perhaps it makes more sense for our layout to look like this: > > root > + tools > + docs (generated docs -- for everything?) For the core and core components (like dynamics) and our site. Each component will need to provide its own set of documentation. > + core > + lib (logging and not much else) Not sure about moving the lib dir into core, what are the benefits? > + src > + java > + test > + plugins droids/branch/LABS-144/depot/ I used the name depot (as suggested by you in another mail) for any kind of component. I like the association of both names to the real life. In a "depot" you can find "components" that you use to build your droid (robot). > + 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. > + src > + lib > ... (like the existing src/templates/component) exactly. > + tika > + src > + lib > ... (like the existing src/templates/component) > + 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. > + myCustomCrawler (hello crawler) > + src > + lib > ... (like the existing src/templates/component) > > > Rather then "plugins" maybe we call them "contrib" or "extensions", > "ext"? I think I like "contrib" I think we should stick to depot as name for the component repository > > Each contrib would manage its own dependancies -- it could depend on > 'core' and other contribs. Yes. > > Note, in this structure, there is no special 'robots' 'examples' or > 'test' source tree. Everything would be a contrib. The test tree is as now, each component has to provide its own test cases. > I could make these changes to our branch, but doubt I could do it > without breaking the scripts... I am concentrating on this ATM but as stated above I am busy to finish my slides for apacheCon. BTW would be great to meet there. Hang in there I may be close to finish. 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]
