Re: [virgo-dev] Jboss Migrating to Virgo

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

That is the exact issue that I ran into also.

To work around I created a fragment to attach to deployer bundle.  But that is not best approach.
I would actually liked to have a fully self contained bundle with artifact/bridge/deployer/transformer specific to a type to deploy.
Currently this is split between org.eclipse.virgo.kernel.artifact and org.eclipse.virgo.kernel.deployer bot par/plan/bundle/config.

Some other classes that were internal and I wanted to use (from dmServer days):

1. ArtifactStorage - became public in virgo
2. ArtifactStorageFactory - still private.

I still have to go back and figure out why I wanted to use ArtifactStorageFactory.

Regards,

Dmitry

 
2010/11/16 Peter Gardfjäll <peter.gardfjell@xxxxxxxxx>
>
> Hi all,
>
> I started on a similar effort some time ago (that is, writing a custom
> deployer) but I ran into the following issue:
>
>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=320721
>
> I believe that resolving this issue is a prerequisite for being able
> to provide custom deployers.
> The bug report includes a minimalistic Eclipse plug-in development
> project which shows what interfaces to implement and services to
> publish to the OSGi registry for a custom deployer. The only problem
> is that the approach doesn't work due to the deployment pipeline
> making too many assumptions about the InstallArtifact.
>
> There is one quick-and-dirty fix (promote AbstractInstallArtifact to
> the public API) and a more elegant solution that would require a lot
> more effort (essentially redesigning parts of the deployment
> pipeline).
>
> Another related issue:
>  https://bugs.eclipse.org/bugs/show_bug.cgi?id=315867
>
> best regards, Peter
>
>
>
> On Tue, Nov 16, 2010 at 4:59 PM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
> > On 16 Nov 2010, at 15:13, Dmitry Sklyut wrote:
> >
> > There are few other things you have to be aware of:
> >
> > 1. org.eclipse.virgo.repository.AftifactBridge
> > 2.org.eclipse.virgo.kernel.install.artifact.InstallArtifact
> >
> > #1 is used to read deployed artifact and generate descriptors for pipeline to consume.  #2 encapsulate lifecycle logic for a specific type of an installed artifact.
> >
> > One correction.
> >
> > Actually #1 is used by the Virgo repository to determine the (type, name, version) identity of an artifact found while scanning the repository. Lin will need to implement this to make the repository recognize EARs.
> >
> > org.eclipse.virgo.kernel.install.artifact.ArtifactIdentityDeterminer is the interface for determining the identity of an artifact which is being deployed. Lin will need to implement this so EARs can be deployed, e.g. by dropping in the pickup directory.
> >
> >
> > I have been trying to find the time to write up something concreate on custom deployed artifacts for months now, but work and life gets in the way :)
> >
> > I know the feeling.
> >
> >
> > If you are interested in participating on working on a prototype, I can throw together an initial implementation on github and we can collaborate on implementation.
> > There are a lot of edge cases that might be specific to your deployment structure that would be missed without your input.  For example start order of artifacts.
> >
> > This is a great suggestion and would allow us to identify and answer the remaining questions about adding an artifact type.
> >
> > Regards,
> > Glyn
> > _______________________________________________
> > virgo-dev mailing list
> > virgo-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/virgo-dev
> >
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev