[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Building a custom artifact deployer
- From: Glyn Normington <gnormington@xxxxxxxxxx>
- Date: Fri, 9 Jul 2010 08:58:28 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: email@example.com
- Thread-index: Acsff5KEdfQJi+pSQw6Sxdxrxx5wxg==
- Thread-topic: [virgo-dev] Building a custom artifact deployer
Yes, InstallArtifactTreeFactory obeys the whiteboard pattern and the deployer will pick up any that are registered.
Your right that the ArtifactStorage interface needs promoting to an exported package to be usable by 3rd parties.
It would be good to collaborate on a toy example and then make that available as a Virgo sample. Compare .
Would you be interested in stripping down what you are doing into a toy and, with my and possibly others' help, getting that going with Virgo with a view to contributing it as a sample? (I guess the best way would be to create a small project on github that I could then directly access rather than sending zips around, but you can call the shots here.)
On 9 Jul 2010, at 15:21, Peter Gardfjäll wrote:
> as far as I can tell part of writing a custom artifact deployer for
> Virgo is to register an InstallArtifactTreeFactory in the OSGi service
> I assume that all such factories get picked up by the Virgo runtime.
> Am I right so far...?
> If that is indeed the correct approach, one apparent problem that
> strikes me is that the ArtifactStorage interface, which is a parameter
> of the InstallArtifactTreeFactory.constructInstallArtifactTree method,
> is internal to the org.eclipse.virgo.kernel.deployer bundle (that is,
> its package is not exported).
> This makes it impossible for me to write a bundle with a custom tree factory.
> Maybe some restructuring is required to simplify the development of
> additional deployers?
> What are your thoughts?
> best regards, Peter
> virgo-dev mailing list