You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@depot.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2004/03/17 14:25:51 UTC
[VOTE] Naming stuff with fance names... not
Fancy names are sometimes catchy, and help identify the project, unless
there are too many of them. Usually a project should have only one fancy
name, but we have two: 'depot' and 'ruper'.
Hence, why not make a single logo for 'Depot', and simply name the
artifacts "versioner" and "updater"?
Hence it would be
Depot versioner
Depot updater
(or Depot Version and Depot Update)
I think this would improve the clarity for outsiders and make the site,
docs, and code more understandable. In any case, we need to do it now,
before a first milestone release.
WDOT?
From me, +1 (please specify if you prefer the -er ending)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
[Results] Re: [VOTE] Naming stuff with fance names... not
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
...
> Hence it would be
>
> Depot versioner
> Depot updater
>
> (or Depot Version and Depot Update)
...
>
> From me, +1 (please specify if you prefer the -er ending)
We have 3 +1s, and the decision of naming without the ending desinence.
Hence it's oficially:
Depot Version
Depot Update
I will take care myself of changing the package names later today, and
putting up a single logo for depot (temporary, not necessarily the final
one).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] Naming stuff with fance names... not
Posted by Nick Chalko <ni...@chalko.com>.
Markus M. May wrote:
>+1 for
>Depot Version and Depot Update (without er)
>
>
>
+1 with or with out the (er)
Re: News from the Avalon front?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote:
> On Thursday 18 March 2004 20:28, Nicola Ken Barozzi wrote:
>
>
>>If Avalon Repository decides to use Depot, after the 2.0 release of
>>Avalon Repository we can start using depot as a backend, and
>>contextually exit incubation. What we still lack a bit is community, but
>>if Avalon uses Depot we should be ok with it.
>
> Another drastic consideration would be (don't faint) to make Avalon home of
> Depot. Just a suggestion... :o)
That's the best way to make Depot fail :-P
Don't get me wrong, I love Avalon, and have been the Avalon chair in
probably the most difficult time for Avalon. But I know that Avalon is
not well understood by many other projects, and an Avalon repo project
would not be used by others IMHO.
Besides, it's not in the scope of Avalon, and Avalon really needs to
focus on containers and leave all the rest to others. We know what
happened to Avalon when it wanted to do all. -sigh-
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: News from the Avalon front?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 18 March 2004 20:28, Nicola Ken Barozzi wrote:
> If Avalon Repository decides to use Depot, after the 2.0 release of
> Avalon Repository we can start using depot as a backend, and
> contextually exit incubation. What we still lack a bit is community, but
> if Avalon uses Depot we should be ok with it.
Another drastic consideration would be (don't faint) to make Avalon home of
Depot. Just a suggestion... :o)
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
Re: News from the Avalon front?
Posted by Stephen McConnell <mc...@apache.org>.
Markus M. May wrote:
> Hello,
> so you are storing a .meta file for each component and in this file you
> basically describe the dependencies and some other stuff like the used
> factory and the criterias used to initialize the factory?
Just to be clear (because component is a loaded work in Avalon) - within
Avalon (and other Apache projects) - the Avalon Repository package is
typically use this to load "systems" as opposed to "components". For
example, the Avalon Logging system provides a container side logging
management api and uses the Avalon Repository to load the implementation
(e.g. Log4J, LogKit, etc.). Dig down deeper inside something like the
LogKit implementation for Avalon Logging and you will see several
examples of log target loading using Avalon Repository (for example an
SMTP log target includes javamail in its classloader description).
In each case - the system implementation that is loaded has an
associated .meta file that describes its classloading requirements and
factory management criteria.
> Right now we are just storing the dependencies for each project
> (component?) in an xml-file. Is the Meta-file just a .properties file or
> could it be a .xml-file as well?
Currently the implementation is exclusively based on properties. But
this is largely a result of the collaboration between Avalon and the
Directory Project in getting a small and efficient bootstrap system in
place. The Avalon Repository bootstrap is a 64k (or there abouts) jar
file with no XML dependencies - which actually uses itself to load a
repository implementation. The repository implementation could provide
a lot more - such as XML based "system" descriptors - but for the moment
its doing this using properties (but I also think that XML descriptors
is the way to go).
> Like I said, we are storing the dependencies in an .xml-file and also we
> are using a kind of directory structure for the definition of the
> domain, etc. Basically right now we are supporting two kinds of
> repositories
> 1) Maven-like repos (ibiblio.com)
> 2) Flat file structure (local, ...)
Under the avalon repo stuff we don't have anything in the flat file
space - but - there are are couple of related things. Inside the Avalon
Composition framework (the real component meta model) there is a bunch
of stuff dealing with classloader management that fully supports Sun's
optional extensions spec - and this is all XML based (ie. XML into
management object model). Longer term - I would like to see this
content m oved down to the repository package.
> Here is the question, if Apache Repository decides on a different
> structure. It is clear that we need probably more meta-data and that we
> should use therefor another .meta file. This is not decided yet, but we
> are pretty open on this one. Right now, nearly no information from the
> project/component (like dependencies) are stored on the server. This
> information is only stored in the project specific file basically on the
> client (like maven does).
>
> I definitly like the idea of Avalon Repository concerning the Factory
> loading as well as the classloading stuff.
Going beyond here is something I'm interesting in gaging. Irrespective
of individual opinions about Avalon - there is immutable interest in
moving forward with back-office component technology - things like
service registration and discovery (think intelligent server side
repository technology). This is intrinsically linked to the Avalon
Repository development.
Is there an existing back-office strategy for depot? Is there interest
in this area?
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
Re: News from the Avalon front?
Posted by "Markus M. May" <mm...@gmx.net>.
Hello,
so you are storing a .meta file for each component and in this file you
basically describe the dependencies and some other stuff like the used
factory and the criterias used to initialize the factory?
Right now we are just storing the dependencies for each project
(component?) in an xml-file. Is the Meta-file just a .properties file or
could it be a .xml-file as well?
Like I said, we are storing the dependencies in an .xml-file and also we
are using a kind of directory structure for the definition of the
domain, etc. Basically right now we are supporting two kinds of
repositories
1) Maven-like repos (ibiblio.com)
2) Flat file structure (local, ...)
Here is the question, if Apache Repository decides on a different
structure. It is clear that we need probably more meta-data and that we
should use therefor another .meta file. This is not decided yet, but we
are pretty open on this one. Right now, nearly no information from the
project/component (like dependencies) are stored on the server. This
information is only stored in the project specific file basically on the
client (like maven does).
I definitly like the idea of Avalon Repository concerning the Factory
loading as well as the classloading stuff.
R,
Markus
J Aaron Farr wrote:
> Hello Nicola.
>
> Stephen may have some other points to add, but I wanted to chime in. :)
>
> Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
>>> - automated factory and criteria management (maybe)
>>
>>please expand on this
>
>
> The Avalon-Repository project provides an API for not only loading repository
> artifacts and creating a classloader, but also a Factory API for easily building
> an object/application from the loaded resources. I'm not sure how familiar you
> are with the details, but it's actually pretty simple:
>
> avalon-repository specifies a ".meta" file that sits along side a regular
> artifact (jar file). The meta-file specifies a few things, perhaps most
> importantly is the list of other resources required for building the
> classloader. An example is at:
>
> http://www.ibiblio.org/maven/avalon-logging/jars/avalon-logkit-impl-1.0-SNAPSHOT.jar.meta
>
> Notice this line:
>
> avalon.artifact.factory = org.apache.avalon.logging.logkit.DefaultLoggingFactory
>
> This DefaultLoggingFactory implements a Factory interface defined by the
> avalon-repository API, and allows a user to load the Logging resource by doing
> something like:
>
> File cache = new File( "local-repository" );
> InitialContext context = new DefaultInitialContext( cache );
>
> String spec =
> "artifact:avalon-logging/avalon-logkit?version=1.0-SNAPSHOT"
> Artifact artifact =
> Artifact.createArtifact( spec );
>
> Builder builder = m_context.newBuilder( artifact );
> Factory factory = builder.getFactory();
> Map criteria = factory.createDefaultCriteria();
>
> String key = "avalon.logging.configuration";
> File file = new File( "logging.xml" );
> criteria.put( key, file );
>
> LoggingManager manager =
> (LoggingManager) factory.create( criteria );
>
> The criteria is just a java.util.Map that allows repository clients to pass
> parameters to the factory.
>
> So avalon-repository not only loads the artifacts, but it also allows for object
> initialization using the Factory pattern. I don't know if you knew all of this
> already, but perhaps it gives the rest of the depot/repository crew a better
> understanding of our project.
>
>
>
>>>>I think it's time to merge efforts :-)
>>>
>>>Yep.
>
>
> +1
>
> ---
> jaaron <http://jadetower.org>
>
>
Re: News from the Avalon front?
Posted by J Aaron Farr <fa...@apache.org>.
Hello Nicola.
Stephen may have some other points to add, but I wanted to chime in. :)
Quoting Nicola Ken Barozzi <ni...@apache.org>:
>
> > - automated factory and criteria management (maybe)
>
> please expand on this
The Avalon-Repository project provides an API for not only loading repository
artifacts and creating a classloader, but also a Factory API for easily building
an object/application from the loaded resources. I'm not sure how familiar you
are with the details, but it's actually pretty simple:
avalon-repository specifies a ".meta" file that sits along side a regular
artifact (jar file). The meta-file specifies a few things, perhaps most
importantly is the list of other resources required for building the
classloader. An example is at:
http://www.ibiblio.org/maven/avalon-logging/jars/avalon-logkit-impl-1.0-SNAPSHOT.jar.meta
Notice this line:
avalon.artifact.factory = org.apache.avalon.logging.logkit.DefaultLoggingFactory
This DefaultLoggingFactory implements a Factory interface defined by the
avalon-repository API, and allows a user to load the Logging resource by doing
something like:
File cache = new File( "local-repository" );
InitialContext context = new DefaultInitialContext( cache );
String spec =
"artifact:avalon-logging/avalon-logkit?version=1.0-SNAPSHOT"
Artifact artifact =
Artifact.createArtifact( spec );
Builder builder = m_context.newBuilder( artifact );
Factory factory = builder.getFactory();
Map criteria = factory.createDefaultCriteria();
String key = "avalon.logging.configuration";
File file = new File( "logging.xml" );
criteria.put( key, file );
LoggingManager manager =
(LoggingManager) factory.create( criteria );
The criteria is just a java.util.Map that allows repository clients to pass
parameters to the factory.
So avalon-repository not only loads the artifacts, but it also allows for object
initialization using the Factory pattern. I don't know if you knew all of this
already, but perhaps it gives the rest of the depot/repository crew a better
understanding of our project.
> >> I think it's time to merge efforts :-)
> >
> > Yep.
+1
---
jaaron <http://jadetower.org>
Re: News from the Avalon front?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
...
> The content is not Avalon Specific - so, yes, in principal we could
> think about moving the entire project here. The current release is a
> 1.2. The CVS HEAD is targeting a 2.0 release to coincide with a Merlin
> 3.3 release that will be coming up soon.
>
> If we move Avalon Repository here - there are some questions:
>
> 1. Its the functionality it provides considered to be within
> the scope of this project - in particular:
>
> - artifact caching (yes)
+1
> - classloader building (maybe)
IMHO yes as classloading is artifact loading, and we manage artifacts
(in this case inside the VM)
> - automated factory and criteria management (maybe)
please expand on this
> - repository tools (yes)
+1
> Basically the repository package is a fundamental building
> blocks that is used across a bunch of avalon systems.
...
> Concerning the Avalon road map for the repository package
> there are two main items on the agenda. Firstly the extension
> of the factory metadata to include dependent systems (i.e. have
> the repository implementation handle the preloading of dependent
> systems which in turn are used in the parameterization of
> factories).
>
> Secondly - thee is the issues concerning the management of java
> optional jar extensions. This is currently handled internally
> within the merlin container - however - the correct solution is
> to move optional extension loading out of merlin and into the
> repository classloader builder.
Sorry but I don't get the above. I'm not accustomed to most of the
terminology used above, could you please clarify?
> 2. how to manage flexibility
>
> As described above - the Avalon Repository platform is intrinsic
> element of several avalon facilities. On one hand we don't want
> to break existing avalon content but on the other hand locking
> Depot down on a particular API does not sound like fun! So perhaps
> the right approach is for Avalon to finalize 2.0 and get this out
> in line with the Merlin 3.3 release, and from there we either:
>
> (a) bite the bullet and move it over here and start
> pulling things together ASAP
>
> (b) progressively replace implementation content with
> Depot content lading to the ultimate transfer of
> the entire repository package at a later date
I think that (b) is the best thing to do. Going in small reversible
steps seems slower but favors stability.
> 3. exiting incubator
>
> Impressions and time line for exiting incubation are IMO an
> important aspect here. So long as Depot is under incubation then
> we have a catch 22 - Avalon cannot use incubated content in its
> releases. There are a number of ways we can deal with this but
> they all smell like procedural workarounds. Clearing this off
> the agenda would eliminate the main stumbling block that I see.
If Avalon Repository decides to use Depot, after the 2.0 release of
Avalon Repository we can start using depot as a backend, and
contextually exit incubation. What we still lack a bit is community, but
if Avalon uses Depot we should be ok with it.
>> I see a big duplication of functionality that can be brought in Depot.
>> We have an artifact called version that does advanced version
>> resolution. One AKA Ruper and now named Updater that gets artifacts
>> from a repository (local or remote) using version and it's resolution
>> system.
>
> I'm digging into version and update now to get a better idea of where
> things fit/etc.
Good :-)
Things are in no way set in stone, so changes can be easily made. The
idea is that he packages are as focused as possible. So the Avalon
Repository extra parts would be additional packages giving extra
functionality on top of the other packages.
>> I think it's time to merge efforts :-)
>
> Yep.
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: News from the Avalon front?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
> ...
>
>> Big picture news from the Avalon front is a decision to move to a
>> single specification, single container, single architecture. As part
>> of that picture the Avalon Repository package is an important
>> sub-system. What remains open or at least foggy is where the overlap
>> is between the work here and the activities in Avalon.
>>
>> My assumptions:
>>
>> 1. A lot of the internal low-level code in the Avalon Repository
>> package could be replaced by content from this project.
>
>
> Good.
>
>> 2. Higher level functions such as classloader construction and
>> factory management should probably stay in Avalon.
>
>
> Why? If they are Avalon specific, I agree, if not, and part of it surely
> is indipendent, there is no reason why they cannot move here under their
> own subsystem.
The content is not Avalon Specific - so, yes, in principal we could
think about moving the entire project here. The current release is a
1.2. The CVS HEAD is targeting a 2.0 release to coincide with a Merlin
3.3 release that will be coming up soon.
If we move Avalon Repository here - there are some questions:
1. Its the functionality it provides considered to be within
the scope of this project - in particular:
- artifact caching (yes)
- classloader building (maybe)
- automated factory and criteria management (maybe)
- repository tools (yes)
Basically the repository package is a fundamental building
blocks that is used across a bunch of avalon systems. It
provides the bootstrapping framework for merlin (i.e. the
core of the repository package builds a classloader and
instantiates a full repository package impl handler, which
in turn is used to build a classloader, instantiate and
parameterize a factory for merlin, which in turn uses the
repository to load and instantiate logging systems, container
runtime environments, etc., etc.
Concerning the Avalon road map for the repository package
there are two main items on the agenda. Firstly the extension
of the factory metadata to include dependent systems (i.e. have
the repository implementation handle the preloading of dependent
systems which in turn are used in the parameterization of
factories).
Secondly - thee is the issues concerning the management of java
optional jar extensions. This is currently handled internally
within the merlin container - however - the correct solution is
to move optional extension loading out of merlin and into the
repository classloader builder.
2. how to manage flexibility
As described above - the Avalon Repository platform is intrinsic
element of several avalon facilities. On one hand we don't want
to break existing avalon content but on the other hand locking
Depot down on a particular API does not sound like fun! So perhaps
the right approach is for Avalon to finalize 2.0 and get this out
in line with the Merlin 3.3 release, and from there we either:
(a) bite the bullet and move it over here and start
pulling things together ASAP
(b) progressively replace implementation content with
Depot content lading to the ultimate transfer of
the entire repository package at a later date
3. exiting incubator
Impressions and time line for exiting incubation are IMO an
important aspect here. So long as Depot is under incubation then
we have a catch 22 - Avalon cannot use incubated content in its
releases. There are a number of ways we can deal with this but
they all smell like procedural workarounds. Clearing this off
the agenda would eliminate the main stumbling block that I see.
> I see a big duplication of functionality that can be brought in Depot.
> We have an artifact called version that does advanced version
> resolution. One AKA Ruper and now named Updater that gets artifacts from
> a repository (local or remote) using version and it's resolution system.
I'm digging into version and update now to get a better idea of where
things fit/etc.
> I think it's time to merge efforts :-)
Yep.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
Re: News from the Avalon front?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
...
> Big picture news from the Avalon front is a decision to move to a single
> specification, single container, single architecture. As part of that
> picture the Avalon Repository package is an important sub-system. What
> remains open or at least foggy is where the overlap is between the work
> here and the activities in Avalon.
>
> My assumptions:
>
> 1. A lot of the internal low-level code in the Avalon Repository
> package could be replaced by content from this project.
Good.
> 2. Higher level functions such as classloader construction and
> factory management should probably stay in Avalon.
Why? If they are Avalon specific, I agree, if not, and part of it surely
is indipendent, there is no reason why they cannot move here under their
own subsystem.
> 3. Open question - when do you guys think you will be exiting
> incubation (Avalon Repository is a released product).
Quite soon. If Avalon starts using Depot and puts stuff here, it will
certainly help in exiting as it will increase the community.
> 4. What thoughts do you guys have?
I would really want to see all Repository implementation efforts unite
here.
http://avalon.apache.org/repository/
I see a big duplication of functionality that can be brought in Depot.
We have an artifact called version that does advanced version
resolution. One AKA Ruper and now named Updater that gets artifacts from
a repository (local or remote) using version and it's resolution system.
I think it's time to merge efforts :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: News from the Avalon front?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>> Markus M. May wrote:
>>
>>> +1 for
>>> Depot Version and Depot Update (without er)
>>
>>
>> +1 for the above.
>
>
> Hi Stephen! Any news from the Avalon front?
Hi Niclas:
Big picture news from the Avalon front is a decision to move to a single
specification, single container, single architecture. As part of that
picture the Avalon Repository package is an important sub-system. What
remains open or at least foggy is where the overlap is between the work
here and the activities in Avalon.
My assumptions:
1. A lot of the internal low-level code in the Avalon Repository
package could be replaced by content from this project.
2. Higher level functions such as classloader construction and
factory management should probably stay in Avalon.
3. Open question - when do you guys think you will be exiting
incubation (Avalon Repository is a released product).
4. What thoughts do you guys have?
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
News from the Avalon front? (was Re: [VOTE] Naming stuff with fance
names... not)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
> Markus M. May wrote:
>
>> +1 for
>> Depot Version and Depot Update (without er)
>
> +1 for the above.
Hi Stephen! Any news from the Avalon front?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [VOTE] Naming stuff with fance names... not
Posted by Stephen McConnell <mc...@apache.org>.
Markus M. May wrote:
> +1 for
> Depot Version and Depot Update (without er)
+1 for the above.
Stephen
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
Re: [VOTE] Naming stuff with fance names... not
Posted by "Markus M. May" <mm...@gmx.net>.
+1 for
Depot Version and Depot Update (without er)
Marcus
>
> Fancy names are sometimes catchy, and help identify the project, unless
> there are too many of them. Usually a project should have only one fancy
> name, but we have two: 'depot' and 'ruper'.
>
> Hence, why not make a single logo for 'Depot', and simply name the
> artifacts "versioner" and "updater"?
>
> Hence it would be
>
> Depot versioner
> Depot updater
>
> (or Depot Version and Depot Update)
>
> I think this would improve the clarity for outsiders and make the site,
> docs, and code more understandable. In any case, we need to do it now,
> before a first milestone release.
>
> WDOT?
>
> From me, +1 (please specify if you prefer the -er ending)
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>