ShrinkWrapDeployer

[alrubinger]

Yo.

So I've had a working ShrinkWrapDeployer impl incubating for some time now:

http://http://anonsvn.jboss.org/repos/jbossas/projects/reloaded/trunk/vdf-bootstrap-minimal/src/main/java/org/jboss/reloaded/shrinkwrap

Time to extract this somewhere more appropriate.  How about:

http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/

...with new modules "deployers-shrinkwrap-spi" and "deployers-shrinkwrap-impl"?

S,

ALR

[alesj]

What would be the benefit of this?

[alrubinger]

MC bean enabling native deployment of ShrinkWrap archives.  Should be centralized because it'll be used in EmbeddedAS, Embedded EJB3, Arquillian, etc.

In a nutshell, this:

/**
 * Deployer for ShrinkWrap {@link Archive} types.  End-user
 * view to adapt archives directly into the Virtual Deployment
 * Framework.
 *
 * @author <a href="mailto:[e-mail]">ALR</a>
 * @version $Revision: $
 */
public interface ShrinkWrapDeployer
{
   //-------------------------------------------------------------------------------------||
   // Contracts --------------------------------------------------------------------------||
   //-------------------------------------------------------------------------------------||

   /**
    * Deploys the specified archives into the Virtual Deployment Framework
    * as an atomic operation.  
    * 
    * @param archives The archives to deploy
    * @throws IllegalArgumentException If the archives are not specified (null)
    * @throws DeploymentException If an error occurred in deployment
    */
   void deploy(Archive<?>... archives) throws IllegalArgumentException, DeploymentException;

   /**
    * Undeploys the specified archives from the Virtual Deployment Framework.  Each
    * archive must have been previously deployed in via this {@link ShrinkWrapDeployer}
    * instance, else it will be ignored and logged as a warning.
    * 
    * @param archives The archives to undeploy
    * @throws IllegalArgumentException If the archives are not specified
    * @throws DeploymentException If an error occurred during undeployment
    */
   void undeploy(Archive<?>... archives) throws IllegalArgumentException, DeploymentException;

}

S,

ALR

[alesj]

I still don't see why it should be part of deployers.

Why not make it a top level project in jbossas/projects?

[alrubinger]

It's an integration point between ShrinkWrap and deployers, so would be nice to tie it to the release cycle of these so we get refactorings as necessary during any API changes/updates looking forward.

The other option is that I'll make an extension project for it under the ShrinkWrap umbrella if you don't want to maintain this.

S,

ALR

[alrubinger]

And the reason I ask "Why in deployers?": Because it's essentially a MainDeployer extension.

S,

ALR

[alesj]

The other option is that I'll make an extension project for it under the ShrinkWrap umbrella if you don't want to maintain this.

It's not that I don't wanna maintain this, I just don't see why such completely independent spi (see your posted interface) needs to be in deployers.

Deployers api is not really gonna change much, and apart from obvious integrations - JMX - I'm not keen in keeping external integrations under Deployers umbrella -- conceptually wise.

[emuckenhuber]

However i guess you want to provide an interface for the whole deployment process. Since the deployers are "just" a part of that, this should not be in the deployers directly.

[wolfc]

Based on your own arguments:

Andrew Rubinger wrote:

It's an integration point between ShrinkWrap and deployers...

Andrew Rubinger wrote:

Because it's essentially a MainDeployer extension.

The ShrinkWrapDeployer should be above both Shrinkwrap and Deployers. It's part of neither.

(You don't want to create a dependency from Shrinkwrap to Deployers or vica versa.)

It should also not be part of Reloaded, although Reloaded might boot it up.

[alesj]

The ShrinkWrapDeployer should be above both Shrinkwrap and Deployers. It's part of neither.

(You don't want to create a dependency from Shrinkwrap to Deployers or vica versa.)

It should also not be part of Reloaded, although Reloaded might boot it up.

Akhhhm ... "Why not make it a top level project in jbossas/projects?" ;-)

[wolfc]

Because it should go into a git repo. :-)

And 'top-level' has a loaded meaning. ;-)

[jason.greene]

Can we start by talking about what it does more than just "deploys shrinkwrap archives?"

I assume the key capability it is trying to add to the deployer process is the ability to reuse application provided (already loaded) classes, with metadata pointing at them?

[jason.greene]

In other words, this smells like a "wrapper/facade"... What is it doing beyond the wrapping?

[alrubinger]

Jason Greene wrote:

Can we start by talking about what it does more than just "deploys shrinkwrap archives?"

Nope.  That's all it does.

Jason Greene wrote:

I assume the key capability it is trying to add to the deployer process is the ability to reuse application provided (already loaded) classes, with metadata pointing at them?

The ShrinkWrapDeployer has exactly the same function as MainDeployer, though it accepts different inputs (ShrinkWrap archive instead of VFS Deployment).  Classes are not "already loaded", instead they're defined just as they would be with a normal JAR deployment.  And because everything sits behind VFS, from the perspective of MainDeployer, the ShrinkWrap Deployment *is* a VFSDeployment.

The reason I proposed as part of the deployers project is because it's the same functionality as MainDeployer.  It does suck in a ShrinkWrap dependency.  So sure, I could spin it off into a component of Reloaded, but this is above Reloaded too.  Reloaded should bring together the MC and deployment mechanisms, not define them.

And as far as another top-level project, it's just more to maintain.  From my view, adding this support to jboss-deployers directly makes sense.  If we really don't want the extra dependency (for this one module) coming in, I'll make another home.

S,

ALR

[alrubinger]

Carlo de Wolf wrote:

Because it should go into a git repo. :-)

And 'top-level' has a loaded meaning. ;-)

I don't want to go to Git until supported by JBoss Community.   Already we have stuff floating around arbitrary repos and no clue where to find them.

S,

ALR