1 2 Previous Next 18 Replies Latest reply: May 10, 2010 2:48 PM by Andrew Rubinger RSS

    ShrinkWrapDeployer

    Andrew Rubinger Master

      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

        • 1. Re: ShrinkWrapDeployer
          Ales Justin Master

          What would be the benefit of this?

          • 2. Re: ShrinkWrapDeployer
            Andrew Rubinger Master

            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:andrew.rubinger@jboss.org">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

            • 3. Re: ShrinkWrapDeployer
              Ales Justin Master

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

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

              • 4. Re: ShrinkWrapDeployer
                Andrew Rubinger Master

                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

                • 5. Re: ShrinkWrapDeployer
                  Andrew Rubinger Master

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

                   

                  S,

                  ALR

                  • 6. Re: ShrinkWrapDeployer
                    Ales Justin Master

                    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.

                    • 7. Re: ShrinkWrapDeployer
                      Emanuel Muckenhuber Master

                      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.

                      • 8. Re: ShrinkWrapDeployer
                        Carlo de Wolf Master

                        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.

                        • 9. Re: ShrinkWrapDeployer
                          Ales Justin Master
                          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?" ;-)

                          • 10. Re: ShrinkWrapDeployer
                            Carlo de Wolf Master

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

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

                            • 11. Re: ShrinkWrapDeployer
                              Jason Greene Master

                              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?

                              • 12. Re: ShrinkWrapDeployer
                                Jason Greene Master

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

                                • 13. Re: ShrinkWrapDeployer
                                  Andrew Rubinger Master

                                  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

                                  • 14. Re: ShrinkWrapDeployer
                                    Andrew Rubinger Master

                                    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

                                    1 2 Previous Next