[jboss-dev] AS Embedded and The Full AS Dependency Set

[Paul Gier]

Andrew Lee Rubinger wrote:
> 
> 
> Carlo de Wolf wrote:
>> Andrew Lee Rubinger wrote:
>>> With Branch_5_x starting off the newer jboss-bootstrap, I've been 
>>> prototyping a bit with an Embedded launcher for AS.  Goals are:
>>>
>>> * User defines one dependency upon org.jboss.embedded:someArtifact
>>> * Entire AS dependency set (==all JARs used in the runtime) are 
>>> brought in and are available for use in tests and upon the runtime 
>>> test classpath
>>>
>>> The key here is that the AS dependency set wholly ends up on the 
>>> application ClassLoader.  Later on child>parent delegation takes 
>>> place and the app CL is the defining CL for everything (except 
>>> webapps or other things which define explicit scoping).
>>>
>>> What I need is a mechanism to bring in the AS dependency tree in one 
>>> fell swoop.  Most of this is accomplished by:
>>>
>>> org.jboss.jbossas:jboss-as-build (All AS modules and *most* 3rdparty 
>>> deps)
>>>
>>> But that doesn't account for everything.  I also need to explicitly 
>>> define, at a minimum:
>>>
>>> org.jboss.jbossas:jboss-as-management:jsr77
>>> jboss.web:jsp-api
>>> jboss.web:el-api
>> This is because jboss.web:jbossweb doesn't define any dependencies.
>>> ...probably more stuff I haven't yet discovered.
>> I know JBossTS doesn't have a proper pom as well. See 
>> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/jta-profile/pom.xml?view=markup 
>> .
>>>
>>> I'd be much cleaner if AS itself could provide one POM artifact which 
>>> held all deps.  Then Embedded could bring in this one dependency and 
>>> get everything else transitively.  Embedded versions then become tied 
>>> to AS releases.
>>>
>>> Can we add this?  Is there a better way that occurs to anyone?
>> I think it's more related to having proper poms for sub-projects.
>> Let's go on a case-by-case. If necessary we can always define virtual 
>> projects which do have a proper pom, tying the artifacts together.
> 
> I like this approach.  Virtual POMs become the stopgap, and we can 
> request each individual project to export their dependencies used by the 
> AS runtime.
> 
> Paul, where can we put virtual POMs, assuming we go this route?
> 
> S,
> ALR
> 

By virtual POMs do you mean define your own POM for a given sub project that 
includes a dependency on the sub project plus other dependencies that are needed?

I'm not sure where is the best place to put that.  Maybe subdirectories/modules 
under the thirdparty directory?  Once I refactor the testsuite, then we won't 
need all the downloaded files in the thirdparty directory anymore.

>>
>> Carlo
>>>
>>> BTW I've got a series of docs in progress for the Wiki soon, but have 
>>> preferred to do proof-of-concept before posting it.  I'll ping back 
>>> here when there's docs and source to comb through.
>>>
>>> * Alternative Boot Method *
>>>
>>> There is another way to boot AS, which is to be selective about the 
>>> classes allowed upon the application ClassLoader.  This is the 
>>> current solution taken by AS Main, and the specialized assembly which 
>>> cherry-picks eligible classes is provided by run.jar.
>>>
>>> This gives us another Embedded mode which uses a similar assembly on 
>>> the application ClassLoader, and then the rest of the classes are 
>>> brought in via the standard jboss-cl models as we normally do.
>>>
>>> The drawback to this approach is that the user is not able to 
>>> reference classes such as the MC Kernel because this imposes invalid 
>>> parent>child ClassLoader delegation resulting in NCDFE.  So it's, at 
>>> the moment, good for little more than starting and shutting down AS.
>>>
>>> S,
>>> ALR
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>