> >So you intend to have maven generate the build descriptor for the jar (used to > >calculate the URL of the properties file artifact to get from repo) and the > >properties file with the dependencies to be put up on the repo? > > > >I'm getting confused. If we can generate the property file with dependency URLs > >then what's so bad for us to just bundle the properties file into the jar and use > >it as a jar resource rather than a repostory artifact? Why have the extra > >properties file generated by the build stored separately on the repo from the jar > >that the same build generated? > > > > The spi project does not know what version the impl is at and this > information is not available in the SPI POM.
Oh yeah right! > The only place that this > info is available is in the impl POM. All we have to do is generate the > list of deopendent artifacts to a dependency descriptor file and add the > impl artifact address to the list, then name the file based on the spi > version that we can get from the impl POM dependency info. Right I see the impl drives the spi/api versions used and so it must generate the dependency descriptor file with the urls to all dependencies and the impl jar. I know I repeaded what you said but I'm kinda thinking out loud again. > The *massive* plus is that we enable auto-updating - because we can > apply the same pattern to the kernel boostrap. What if there are multiple implementation projects? Is that even a possibility? Probably a stupid question. Another question is where are the defaults stored for the configuration which will probably be very implementaiton specific? Yes store that as a separate properties file for defaults discovery within the implementation - you agree? I definately see the auto-updating functionality. You change the implementation and it generates another descriptor. When you bootstrap using the api/spi you pull down the right build descriptor version and use that to download jars, load classes and so on. A nice ClassLoading infrastructure is starting to emerge here. If we only had a utility framework to make the process of bootstrapping this way generic. Here's what some of those components might be: - Utilities to load the build descriptor - Utilities to download the dependency descriptor - Utilities to download the dependency jars and impl jar using the dep desc - A ClassLoaderFactory that uses these utilties to build the required ClassLoader. In these bootstrap situations we have a super interface as a window into making calls against a default implementation within another ClassLoader. Some of the examples to date are Repository and Kernel. It follows good design principals to have a factory object for these objects which takes some sort of configuration to build the object. The factory can also provide a default configuration for making the call to create an instance. This is what happens in the Repository example. Now if we presume a convention we might be able to standardize the process. It is always good form to have factories with a default constructor. We can then create a framework where a default factory (specified as a property) is instantiated and returned. The entire process can take place in one step. Object FactoryLoader.load() ; |--> Load build descriptor properties from within the [A|S]PI jar |--> Download the impl dependency descriptor using build descriptor props |--> Use dependency descriptor urls to download dependent jars |--> Build the ClassLoader |--> Load and newInstance the default factory implementation using ClassLoader |--> Return the factory instance The API user would then cast the returned Object using the interface for the factory implementation. Then the factory would be used to get the configuration defaults. Finally the defaults are overriden by the user and the call to create the object is made. This works nicely: we get the auto-update functionality you mentioned and we have a tight common bootstraping classloading framework. The default factory used manages configuration parameter defaults discovery and provides the hooks to get the configuration information. Calls to get the config bean and the object creation all happen within the safty of separate class loaders. Next we should think about API/SPI/IMPL usage nesting and the nesting it mirrors with ClassLoaders. I need to think about this some more. Alex P.S. BTW if we kept the POM dependency structure in a distributed directory (also a repo) then queries about POMs would make life much easier for us. Again we fall into that interesting triangle between maven, merlin and eve ;-). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
