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

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/jt... > . >> >> 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

> > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development