EJBTHREE-2007: VFS Abstraction

[alrubinger]

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

[alrubinger]

Forgot the report.

[jaikiran]

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

[alrubinger]

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

[jaikiran]

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

[jaikiran]

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>

[alrubinger]

Agree; put some pressure here:

http://docs.codehaus.org/display/MAVENUSER/Global+exclusion+of+artifacts

S,

ALR

[alrubinger]

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

[alrubinger]

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

[alrubinger]

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

[alrubinger]

We'll see about getting the Enforcer rule upstream:

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

S,

ALR

[johnbailey]

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?

[johnbailey]

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?

[johnbailey]

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?

[wolfc]

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.