Castle.Extensibility

[hammett]

I'm kicked off this project on my private repository, but I think it
needs to find its way to castle. Where should I add it, or should it
be its own repo?

Details here https://www.evernote.com/pub/hammett33/castle

--
Cheers,
hammett
http://hammett.castleproject.org/

[Markus Zywitza]

Is this something like MEF, or MEF-inspired?

-Markus

2011/12/19 hammett <ham...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[hammett]

Actually it is taking MEF to the next level, providing packaging, some
level of isolation. The goal is to enforce modularization of apps, the
same way OSGi was able to deliver for java.

A bundle is collection of assemblies/artifacts. It composes itself
using any "technology", but is activated through a
composablepart/definition
(http://msdn.microsoft.com/en-us/library/system.componentmodel.composition.primitives.composablepartdefinition.aspx)

A collection of bundles make up an app.

Eclipse is built this way, and more and more of java apps and servers
are going this direction.

[Mauricio Scheffer]

Sounds like a new project...

Also sounds a bit like Fubu Bottles. ( http://lostechies.com/josharnold/2011/09/05/modularity-via-bottles/ ) Haven't used it (nor OSGi) but it seems to have the same goals (packaging / modules). I could be wrong but I don't think it covers isolation though.

--

Mauricio

[Cristian Prieto]

You mean something like Mono.Addins?

Cristian Prieto

[hammett]

Not familiar with either, so I can't comment.

I'm reading this book and find it very useful:
http://my.safaribooksonline.com/book/software-engineering-and-development/ide/9780321561510

I'm writing this code out of need. I need a strong enforcement of
modularity and dependency management (architectural level). I believe
OSGi forces you to think on these terms, but there's nothing similar
in the .net space...

[Cristian Prieto]

With dependency management at architectural level you mean your "component" or "bundle" will publish dependency endpoints to another packages in and out? (publish what are you exposing and what dependencies you need)?

I'm a little confused, I'm not familiar at all with OSGi, need to read a little more about it...

Cristian Prieto

[Rafael Teixeira]

What you want looks a LOT like Mono.Addins, for me. 

Extension points in Mono.Addins are not tied to code (the main limitation of MEF in my P.O.V.), and dependencies are required to be explicitly put in the manifest. Packages are compressed folder trees, also.

So it does a lot more that MEF on the issues you stated, but is, I think, a lot simpler than OSGi (which I only glanced at conceptually, and perused on some Eclipse plugins unpacked folders).

I recommend you to study it, and maybe contribute there, before expending time on MEF++(Castle.Extensibility).

Rafael "Monoman" Teixeira
---------------------------------------
"The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'"
Isaac Asimov
US science fiction novelist & scholar (1920 - 1992)

[Sebastien Lambla]

What is in this that is not in OpenWrap? From a packaging side I would highly discourage anyone (and that included the fubu guys) from coming up with your own package/description/ditribution format. The way to compose an app from those is up to the implementer and is something we don't provide OOB just yet, but the way to package, publish, load and extend packages is all already in OW.

Anything I can do to avoid reinventing the wheel?

Seb

________________________________________
From: castle-pro...@googlegroups.com [castle-pro...@googlegroups.com] on behalf of hammett [ham...@gmail.com]
Sent: 20 December 2011 06:32
To: castle-pro...@googlegroups.com
Subject: Re: Castle.Extensibility

[Sebastien Lambla]

After reviewing the evernote stuff, this looks quite exactly like what openwrap and bottles+nuget are trying to achieve. You sure you want to create a third way?

________________________________________
From: castle-pro...@googlegroups.com [castle-pro...@googlegroups.com] on behalf of hammett [ham...@gmail.com]

Sent: 19 December 2011 19:44
To: castle-pro...@googlegroups.com
Subject: Castle.Extensibility

Details here https://www.evernote.com/pub/hammett33/castle

--

[hammett]

I'll publish the code and you guys can see if it's doing the same
thing. I'm particularly interested in the composition and isolation.
As someone mentioned, yes, I have to explicitly elect the
imports/exports to the external world. Any other import/export is
treated as internal (implementation detail) and therefore doesnt leak
to the whole composition. This way, I can have different _products_
with a set of dependencies (overlapping or not, with versioning
conflict) deployed on the same app domain. I can query the external
world for a presence of a service (product A) and if not found, do
remote calls.

I admit I didnt do my homework to see if something similar existed, though.

[hammett]

Here it goes
https://github.com/castleproject/Extensibility

[hammett]

Either the code doesnt communicate much or nobody changed their mind.
I've tasked myself on learning more about OW this weekend, and see
what is the overlap. In the meantime I need some functionality to get
some work done here, and will keep focusing on it.

Thanks

[Sebastien Lambla]

Sorry I've been travelling and have had no time. I'm happy to review over the holidays the code itself, but it'd be very helpful if you had an outline of needed features you're focusing on, to see what we can provide.

Some of the stuff you're looking at (meshing of package content, VPP et al) is not in the public builds of openwrap and I'd be more than happy to discuss them based on your needs (which are probably the same ones I have for openhttp), and prioritize them accordingly.

Seb

________________________________________
From: castle-pro...@googlegroups.com [castle-pro...@googlegroups.com] on behalf of hammett [ham...@gmail.com]

Sent: 21 December 2011 21:15

To: castle-pro...@googlegroups.com
Subject: Re: Castle.Extensibility

Either the code doesnt communicate much or nobody changed their mind.

[Cristian Prieto]

I've been busy preparing everything for xmas leave... I'll review the code in my way to home...

Cristian Prieto

[hammett]

This is what it supports today:

var container = HostingContainer("my/bundles", new AppLevelCatalog())

- The folder my/bundles will be inspected and any zip will be
extracted to /my/bundle/bundlename
- Each folder gets an isolated loading context (see )
- Each bundle may have IModulerStarter implementation, which will be invoked
- By default, a bundle "composer" is Mef based. A manifest.xml can
point to a different one.
- Another implemented composer is Windsor based
- BundleImport/BundleExport mark the contracts "exported" or
"imported" to the external world

I'm now about to add behavior capabilities (eg, a bundle can behave as
a MonoRail bundle, which implies that it's a source of controllers,
views and static content)