You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2003/11/07 09:54:23 UTC
Eclipse Plug-in
[On-list], as you (Stephen) recommended...
Hi,
Since I didn't hear from you (Stephen), probably sleeping, I went a bit ahead
on changing the package names after my own head.
The ServiceInfo, ComponentInfo, Compliance and Version interfaces has been
moved to o.a.a.repository
The RepositoryAgent, RepositoryRegistry, the associated listeners, events and
exceptions has been moved to o.a.a.repository.tools
The Eclipse plug-in view classes and interfaces has been moved to
o.a.a.ide.eclipse.
Hope this is better. Change again is not such a big deal, just shout.
I am now at the point of actually seeing something showing up in the Eclipse
managed RepositoryView. Expect to have it nailed down in a few hours (but
going out shortly, so somewhere tomorrow).
I have also been fooling around with the AssemblyEditor, so those trials will
also be part of the initial package, together with other sample code, not
much in use.
I will also try to add official support for adding RepositoryAgent types,
through standard Eclipse mechanism called Extension Point. If I can't figure
it out in 24 hours, it has to wait.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>Cool so are we all working on this in the sandbox repository project?
>
>BTW is there a difference between the concepts of a component registry and a
>component catalog? What do you guys think?
>
>I think so. To me the catalog lists the available software components and
>the registry is where a set of living instances of these (distributed)
>components are listed.
>
I agree with the distinction. Typically a registry is a place where
records are kept and in this context a registry can be consider as the
collection of records detailing the addresses of instances. A catalog
is a list or enumeration of something - if effect the result of a
selection relative to a criteria. In the above example "available
software components" we have [attribute] == "avaliable", and
[artifact-type] "software component".
More generally speaking, I would assume that a component catalog is view
of a component registry.
Cheers, Steve.
(who has just downloaded Eclipse in preparation)
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 13 November 2003 22:31, Gonzalo Diethelm wrote:
> This is amazing. For YEARS now I have used almost the exact same karma:
>
> "Make it RUN. Make it RIGHT. Make it FAST. Make it SMALL"
Small?? Why bother? You are in one of two positions when you start out;
1. Plenty of RAM, typically megabytes or hundreds of megabytes and size is not
a factor.
2. No RAM, typically in the kilobytes or 10ths of kilobytes range, in which
case "Make it Run" typically involves getting it to fit at all ;o)
> Glad to know I'm not alone in the universe... Regards,
I think you have near a religion called XP who is on the same track.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Eclipse Plug-in
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> > Cool so are we all working on this in the sandbox
> repository project?
>
> "Make it RUN. Make it RIGHT. Make it FAST."
>
> That is my contribution to software design principles.
> Once you have something that runs, it is easier to start
> working on getting it
> right, so.... My plan was to roll my own dirt simple way to deal with
> repositories, and then worry about how to use proper ones.
This is amazing. For YEARS now I have used almost the exact same karma:
"Make it RUN. Make it RIGHT. Make it FAST. Make it SMALL"
> Niclas
Glad to know I'm not alone in the universe... Regards,
--
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 08 November 2003 09:51, Alex Karasulu wrote:
> Cool so are we all working on this in the sandbox repository project?
"Make it RUN. Make it RIGHT. Make it FAST."
That is my contribution to software design principles.
Once you have something that runs, it is easier to start working on getting it
right, so.... My plan was to roll my own dirt simple way to deal with
repositories, and then worry about how to use proper ones.
But I'll get there.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Eclipse Plug-in
Posted by Alex Karasulu <ao...@bellsouth.net>.
Cool so are we all working on this in the sandbox repository project?
BTW is there a difference between the concepts of a component registry and a
component catalog? What do you guys think?
I think so. To me the catalog lists the available software components and
the registry is where a set of living instances of these (distributed)
components are listed.
> In the avalon-sandbox/repository are a couple of descriptors that Alex has
> been working on. We need to make sure that these thing are in sync.
> I've just
> updated the CVS with a api/spi slit (which Alex probably hasn't seen yet).
> >The RepositoryAgent, RepositoryRegistry, the associated listeners, events
> and
> >exceptions has been moved to o.a.a.repository.tools
I check after the next 100 emails but is this in the sandbox? And is the
Repository registry the way I outlined it above or are you referring to a
catalog?
I so excited to have you working on this stuff too from the build time
aspect as well Nick! It will cover more use cases as you say.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>[On-list], as you (Stephen) recommended...
>
>Hi,
>
>Since I didn't hear from you (Stephen), probably sleeping, I went a bit ahead
>on changing the package names after my own head.
>
>The ServiceInfo, ComponentInfo, Compliance and Version interfaces has been
>moved to o.a.a.repository
>
In the avalon-sandbox/repository are a couple of descriptors that Alex has
been working on. We need to make sure that these thing are in sync.
I've just
updated the CVS with a api/spi slit (which Alex probably hasn't seen yet).
>
>The RepositoryAgent, RepositoryRegistry, the associated listeners, events and
>exceptions has been moved to o.a.a.repository.tools
>
+1
Makes sense.
>
>
>The Eclipse plug-in view classes and interfaces has been moved to
>o.a.a.ide.eclipse.
>
>
>Hope this is better. Change again is not such a big deal, just shout.
>
This looks good!
Stephen.
>
>I am now at the point of actually seeing something showing up in the Eclipse
>managed RepositoryView. Expect to have it nailed down in a few hours (but
>going out shortly, so somewhere tomorrow).
>I have also been fooling around with the AssemblyEditor, so those trials will
>also be part of the initial package, together with other sample code, not
>much in use.
>
>I will also try to add official support for adding RepositoryAgent types,
>through standard Eclipse mechanism called Extension Point. If I can't figure
>it out in 24 hours, it has to wait.
>
>
>Niclas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 08 November 2003 08:45, Alex Karasulu wrote:
> What methods do you foresee needing? Perhaps I can add them into this
> interface and u can use an implementation of it. The first implementation
> will use properties file on the repo server to get meta data on artifacts.
Since I don't have commit rights (yet), you won't find my code in the CVS.
I had a look at the repository stuff in the sandbox, and perhaps I am not
capable of appreciating the effort to the full... :o(
My impression is that it is not very well abstracted and boiled down the the
bare essentials from the "use-case" point of view, and I feel that it is
looking too much towards a foreign repository (Maven I presume).
Here is the rough draft (Stephen, I have made quite a lot of changes since
yesterday, as my abstract is much clearer after some JDs);
First of all I have a very simple Resource defintion, extremely generic at the
moment. This is composed by the 4 interfaces below; ResourceInfo,
ReourceGroupInfo, Version and Compliance. (I am right now considering generic
Attributes on the resource as well, but have not put that in yet.)
I then have a RepositoryAgent interface, which knows how to communicate with a
particular repository type, to retrieve the resource metainfo and the
resource itself. One RepositoryAgent instance per actual repository.
Since the RepositoryAgent can be of different types (such as Maven, Niclas,
Alex, HyperDuper, etc) I need a factory class for each RepositoryAgent type,
simply called RepositoryAgentFactory.
The RepositoryAgentFactory is registered with the RepositoryTypeRegistry. For
each URN type, the implementation registers (somehow) with the
RepositoryTypeRegistry (now an interface, and would need to get instantiated
as well somehow).
A repository has (from my POV) the form like;
urn:[type]:[location]
for instance,
urn:plain-url:file:///opt/avalon/repository/
To use this, as client, you do
String urn = urn:plain-url:file:///opt/avalon/repository/;
RepositoryTypeRegistry reg = ... // Some way to find the registry.
RepositoryAgentFactory factory = reg.getRepositoryAgentFactory( urn );
RepositoryAgent agent = factory.create( urn );
// load root resource group ("").
ResourceInfo[] infos = agent.loadResourceInfo( "" );
for( int i=0 ; i < infos.length ; i++ )
{
String name = infos[i].getName();
String descr = infos[i].getDescription();
:
InputStream in = agent.openInputStream( infos[i] );
:
}
(It is arguable if the openInputStream() should be within the ResourceInfo
instead, but I think that by putting it in the agent, the ResourceInfo
implementation can possibly be very generic, and not re-implemented for each
repository type.)
And so on...
ResourceGroup is an interesting concept, that I have promoted to first class
citizens over the day. It is a type of Resource that can contains other
Resources. That means that
"MyComponent" is a ResourceGroup, where as
"MyComponent Ver 1.0.0" is a "leaf" Resource.
One could possibly even imagine that
"MyComponent-1.0.0.jar" is a ResourceGroup containing other resources
internally.
And I can also categorize my resources in any imaginable way.
To me this design looks pretty solid and well abstracted, and it should be
possible;
1. Provide implementations (RepositoryAgent + RepositoryAgentFactory) for just
about any remote or local repository or some form of library.
2. Specialize the functionality for more Avalon specific stuff on top of it.
Also, I have introduced listeners on RepositoryTypeRegistry,
RepositoryAgentFactory and RepositoryAgent, which are notified about any
changes loaded or detected. This will drive a UI, for instance, very well.
What do you think?
"This doesn't belong in Avalon!" - Yes, this has struck me too, but let's
iron it out here before we decide what to do with it.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Eclipse Plug-in
Posted by Alex Karasulu <ao...@bellsouth.net>.
Nick,
Have you looked at the ArtifactDatabase interface it sounds like we're after
a similar beast. Something to query for the catalog of components.
> initial attempt. I turned to a RepositoryView.
> ATM, my definition of a repository in this context is;
>
> A location where a RepositoryAgent (representative) can retrieve
> metainformation about components stored in such location. The
> RepositoryAgent
> also knows how to retrieve the component itself.
What about you get an artifact database from a repository or just use a
constructor and have extra methods to ask for the list of artifacts.
What methods do you foresee needing? Perhaps I can add them into this
interface and u can use an implementation of it. The first implementation
will use properties file on the repo server to get meta data on artifacts.
> The Eclipse Plugin is to support that you can install RepositoryAgent
> implementations, so basically any repository type can be browsed.
> For components that have Merlin Compliance, the UI will allow to be
> drag-n-dropped to a created merlin container, and manual or automatic
> dependency resolution can take place, but that is a bit further down the
> line.
That sounds so cool - I see myself using it already ;-).
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Eclipse Plug-in
Posted by Niclas Hedhman <ni...@hedhman.org>.
Gang,
SInce I was a bit of coward and wished to have some private feedbackback
first, before exposing my thinking to the world.
Here we go,
I am very much "use-case driven" in much approach to programming, always been.
I also always assumed everything can be done easily, if you just take really
small steps.
So, I want to get the Eclipse plug-in development going, and I was first
looking at an AssemblerEditor, but found that a bit over my head as an
initial attempt. I turned to a RepositoryView.
ATM, my definition of a repository in this context is;
A location where a RepositoryAgent (representative) can retrieve
metainformation about components stored in such location. The RepositoryAgent
also knows how to retrieve the component itself.
A component in this context is, any digital media that can be abstracted into
a single entity, with an Identification (globally unique), Name (smaller
human-readable form), Description, Compliance, Version.
Compliance is basically; Do you support X? yes/no, where X is any known
standard.
So much (to me) is fairly clear. I am still struggling a bit with the concept
of Dependency and Standard (exposure of service, interfaces or other
standards in the market place.), so at the moment I just assume the Avalon
model, Service Exposed and Dependence On Service, but expect to change that
in the near future, when I/we get a better understanding of the abstraction.
The Eclipse Plugin is to support that you can install RepositoryAgent
implementations, so basically any repository type can be browsed.
For components that have Merlin Compliance, the UI will allow to be
drag-n-dropped to a created merlin container, and manual or automatic
dependency resolution can take place, but that is a bit further down the
line.
Later on, we will see where the ship goes. Small steps!!!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org