avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: repository boostrapping
Date Tue, 04 Nov 2003 04:04:53 GMT

aok123@bellsouth.net wrote:

>>>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.


I've just committed an update to the repository/impl project - some 
jelly to generate the catalog descriptor.  After updating do a build and 
take a look in the target/classes directory for a file named 

>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.

I'm thinking we need to seperate out the bootstrap semantics intop a 
[project]/bootstrap subproject and use that as the generic pattern to 
trigger package catalog generation.  As far as API/SPI/IMP seperation is 
concerned - we could apply property naming conventions - e.g. 
artifact.spi.0 = whatever.


>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: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org


Stephen J. McConnell

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message