1 2 Previous Next 18 Replies Latest reply on Feb 24, 2010 9:49 AM by John Bailey

    EJBTHREE-2007: VFS Abstraction

    Andrew Rubinger Master

      https://jira.jboss.org/jira/browse/EJBTHREE-2007

       

      I've created a skeleton project to house our VFS abstraction:

       

      http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/components/vfs/trunk/

       

      Something I want is an Enforcer Plugin configuration which will fail the build if any org.jboss:jboss-vfs is available in "compile" scope; this is a runtime dependency which should be restricted to "provided".  I might take a stab at a custom rule:

       

      http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html

       

      Then we can adjust our dependencies to always bar VFS from coming in (right now it's declared in core and through jboss-metadata; see attached report).

       

      The actual task of splitting into an SPI and getting the extisting stuff into org.jboss.ejb3.vfs:vfs-impl-vfs2 shoudn't be too difficult from the looks of it, but I would like to see the Enforcer in place.

       

      Anyone think I'm being too strict?

       

      S,

      ALR

        • 2. Re: EJBTHREE-2007: VFS Abstraction
          jaikiran pai Master

          ALRubinger wrote:

           


          Something I want is an Enforcer Plugin configuration which will fail the build if any org.jboss:jboss-vfs is available in "compile" scope; this is a runtime dependency which should be restricted to "provided".


          I think with such a rule, we might run into trouble if that org.jboss:jboss-vfs is being pulled in transitively during compile scope from some other non-EJB3 module. Ex: core (depends on) --> some artifact (compile scope dependency on) --> org.jboss:jboss-vfs

          • 3. Re: EJBTHREE-2007: VFS Abstraction
            Andrew Rubinger Master

            jaikiran wrote:

             

            ALRubinger wrote:

             


            Something I want is an Enforcer Plugin configuration which will fail the build if any org.jboss:jboss-vfs is available in "compile" scope; this is a runtime dependency which should be restricted to "provided".


            I think with such a rule, we might run into trouble if that org.jboss:jboss-vfs is being pulled in transitively during compile scope from some other non-EJB3 module. Ex: core (depends on) --> some artifact (compile scope dependency on) --> org.jboss:jboss-vfs

            Good!  That way we can be ensured we're not depending upon VFS directly, no matter what comes in.  And it future-proofs us.

             

            I know I asked if anyone thinks I'm being too strict; I don't think I am.

             

            So we should set exclusions appropriately and ensure that we only have it in "provided"; available to runtimes.


            S,

            ALR

            • 4. Re: EJBTHREE-2007: VFS Abstraction
              jaikiran pai Master

              ALRubinger wrote:

               

              Good!  That way we can be ensured we're not depending upon VFS directly, no matter what comes in.  And it future-proofs us.

               

              I know I asked if anyone thinks I'm being too strict; I don't think I am.

               

              So we should set exclusions appropriately and ensure that we only have it in "provided"; available to runtimes.


              S,

              ALR

              I don't mind having this new enforcer rule, but eventually i suspect that we are going to end up with a lengthy (trial and error, ever changing) excludes list

              • 5. Re: EJBTHREE-2007: VFS Abstraction
                jaikiran pai Master

                jaikiran wrote:

                 

                I don't mind having this new enforcer rule, but eventually i suspect that we are going to end up with a lengthy (trial and error, ever changing) excludes list

                A bit OT - If Maven allowed a way to exclude an artifact irrespective of, from which artifact it get's pulled in transitively from, then instead of something like this:

                 

                <dependency>
                      <groupId>org.hibernate</groupId>
                      <artifactId>hibernate-annotations</artifactId>
                      <version>${version.org.hibernate}</version>
                      <!-- Exclude org.hibernate:hibernate which is banned in
                      favour of org.hibernate:hibernate-core -->
                      <exclusions>
                        <exclusion>
                            <groupId>org.hibernate</groupId>
                            <artifactId>hibernate</artifactId>
                        </exclusion>
                      </exclusions>
                    </dependency>
                
                    <dependency>
                      <groupId>org.hibernate</groupId>
                      <artifactId>hibernate-entitymanager</artifactId>
                      <version>${version.org.hibernate.hibernate-entitymanager}</version>
                      <!-- Exclude org.hibernate:hibernate which is banned in
                      favour of org.hibernate:hibernate-core -->
                      <exclusions>
                        <exclusion>
                            <groupId>org.hibernate</groupId>
                            <artifactId>hibernate</artifactId>
                        </exclusion>
                      </exclusions>
                    </dependency>
                

                 

                we could have just had:

                 

                      <exclusions>
                        <exclusion>
                            <groupId>org.hibernate</groupId>
                            <artifactId>hibernate</artifactId>
                            <!-- Instruct Maven to exclude this artifact from any dependency
                                 of this project which pulls this in -->
                            <include-transitive/>
                        </exclusion>
                      </exclusions>
                
                
                • 7. Re: EJBTHREE-2007: VFS Abstraction
                  Andrew Rubinger Master

                  I might move this to my new Git home in GitHub, but for now...

                   

                  http://anonsvn.jboss.org/repos/sandbox/alrubinger/maven-enforcer-rule-nocompiledep/trunk/nocompiledep/

                   

                  Will see if this does any good for us tomorrow.  Haven't tested it at all yet.

                   

                  S,

                  ALR

                  • 8. Re: EJBTHREE-2007: VFS Abstraction
                    Andrew Rubinger Master

                    Looks like it does the job.  I think I'll cut a release and see if it's too eager or breaks anything:

                     

                    [WARNING] Rule 2: org.jboss.maven.plugins.enforcer.rules.nocompiledep.NoCompileDependencyRule failed with message:
                    Prohibited dependency from compilation: Dependency {groupId=org.jboss, artifactId=jboss-vfs, version=2.0.0.CR1, type=jar}
                    [INFO] ------------------------------------------------------------------------
                    [ERROR] BUILD ERROR
                    [INFO] ------------------------------------------------------------------------
                    [INFO] Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.
                    

                     

                    S,

                    ALR

                    • 9. Re: EJBTHREE-2007: VFS Abstraction
                      Andrew Rubinger Master

                      To use this, apply the following patch to projects/ejb3/trunk/build:

                       

                      Index: pom.xml
                      ===================================================================
                      --- pom.xml    (revision 100755)
                      +++ pom.xml    (working copy)
                      @@ -186,8 +186,20 @@
                                   <requireMavenVersion>
                                     <version>[2.0.9,2.1)</version>
                                   </requireMavenVersion>
                      +            <noCompileDependencyRule implementation="org.jboss.maven.plugins.enforcer.rules.nocompiledep.NoCompileDependencyRule">
                      +              <excludes>
                      +                <exclude>org.jboss:jboss-vfs</exclude>
                      +              </excludes>
                      +            </noCompileDependencyRule>
                                 </rules>
                               </configuration>
                      +        <dependencies>
                      +          <dependency>
                      +            <groupId>org.jboss.maven.plugins.enforcer.rules</groupId>
                      +            <artifactId>nocompiledep</artifactId>
                      +            <version>1.0.0-alpha-1</version>
                      +          </dependency>
                      +        </dependencies>
                             </plugin>
                       
                             <plugin>
                      

                       

                      S,

                      ALR

                      • 10. Re: EJBTHREE-2007: VFS Abstraction
                        Andrew Rubinger Master

                        We'll see about getting the Enforcer rule upstream:

                         

                        http://jira.codehaus.org/browse/MENFORCER-90

                         

                        S,

                        ALR

                        • 11. Re: EJBTHREE-2007: VFS Abstraction
                          John Bailey Novice

                          Now that there is a reasonable option for making sure no VFS dependencies leak into the EJB3 projects, what is the plan moving forward?  There has been some initial discussion on the SPI Carlo started, but I am not if there is more to be had. 

                           

                          Questions I have are as follows:

                          1.  Are you waiting on me for anything?

                          2.  What is the timeframe to complete the VFS abstraction, and can it be done soon to help meet the VFS3 migration goals?

                          3.  Who will be responsible for the various pieces of work?

                          4.  The plan is to still use VFS for the test code, correct?

                          • 12. Re: EJBTHREE-2007: VFS Abstraction
                            John Bailey Novice

                            I flushed out the VFS3 impl to plug in directly to AS with the existing EJB3 core.  I am able to integrated EJB3 into a VFS3 enabled AS without updating any EJB3 projects.  So previous AS and EJB3 combos should function without update.

                             

                            I suggest we move forward with this temporary solution with no changes to EJB3 core.  Once we are comfortable the VFS3 integration in trunk is functional, we can move forward with a more robust abstraction layer and remove the 'org.jboss.virtual' interfaces.

                             

                            Thoughts?

                            • 13. Re: EJBTHREE-2007: VFS Abstraction
                              John Bailey Novice

                              I missed one reference to VirtualFileAdapter that will not allow a simplistic approach to work.

                               

                              The class org.jboss.injection.ServiceRefInjector creates a VirtualFileAdapter from the InjectionContainer:getRootFile.  In the case of VFS3 this will actually by the VirtualFileWrapper instance, which will not be compatible at runtime. 

                               

                              So we are going to have to account for this in some way.  What else uses InjectionContainer:getRootFile?  I am only seeing it used by the ServiceRefInjector, but I may be missing some references.  If this is the only use, we could have the InjectionContainer actually create the instance to the VirtualFileAdapter and keep it outside EJB3 core..

                               

                              Thoughts?

                              • 14. Re: EJBTHREE-2007: VFS Abstraction
                                Carlo de Wolf Master

                                It's ServiceRefInjector that's the actual splinter into ejb3-core. It's part of the WS SPI, not part of core.

                                I would say, rip it out. It should be easy to create a factory for it. But because of the wicked InjectionContainer we can't push it to WS itself and it needs to remain in our care.

                                1 2 Previous Next