geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: [discuss]Web profile assemblies
Date Fri, 20 Aug 2010 16:46:02 GMT

Thanks Rick/Ivan/Jarek much for the comments so far.  I agree with
most of the comments.  I think these are what we agreed on -

1. keep extra spec jars instead of spending time to sort them out.
2. mina, yoko are needed.
3. pluto/portal are needed.
4. openejb: going to be hard to break down to ejb-lite.  don't worry
about it for now.
5. ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: not causing any
issue to have them in, leave them in for now.
6. javaee management/deployment are needed.
7. web services related are ok to remove.

 thus I think we need to decide the following:

1. whether we keep jaspi and javamail in web profile assembly?  I
personally would say no, but open to opinions.

2. tranql: i cannot think of a reason why these resource adapters are
needed for web profile... I can see geronimo-connector are needed but
not the RAs.   Maybe people who knows more about tranql could comment
on this?

Anything else I missed on this topic?



On Fri, Aug 20, 2010 at 11:30 AM, Jarek Gawor <> wrote:
> On Fri, Aug 20, 2010 at 10:09 AM, Lin Sun <> wrote:
>> Hi
>> I am checking at our web profile assemblies to ensure it met the
>> requirements for Java EE 6 web profile and prune the unnecessary
>> artifacts.   I've been mainly look at the tomcat7-javaee6-web and I
>> have some comments/questions:
>> felix core: i assume we'll always ship 2 osgi runtime?
> Yep, that's the plan.
>> connector (geronimo-connector, geronimo-connector-builder, connector
>> spec):  I think openejb uses connector, so we may have to keep it in.
>> java ee management 1.1:   Unchanged from Java EE 5.  I assume this is
>> provided by geronimo-management.  Not sure if we could remove this?
>> java ee deployment 1.2 related:  Unchanged from Java EE 5.   we may
>> have to keep it in, to keep existing deployment work.
>> geronimo-javamail: can we get rid of it?  think the answer is yes.
> Maybe. Might be nicer to include it.
>> geronimo-jaspi: can we get rid of it?  think the answer is yes.
> Maybe. Might be nicer to include it.
>> geronimo-webservices, geronimo-webservices-builder:  think we could
>> remove these.
> Yes, i think so.
>> geronimo-yoko, yoko: think we could remove these.
>> spec jars: we seems to include all specs in web profile assembly.
>> things that can be removed:  aspic, jaxr, jaxrpc, jaxws, dims, saaj,
>> ccpp?
> I don't think this is very important. A lot of specs have dependencies
> on each other. So this might be a mess to sort it all out. I think we
> should be able to include them all even though we don't provide all of
> that functionality. At runtime an user should see an error that a
> given provider is not found.
>> mina: think we could remove it... not sure which web profile function
>> it related to.
> It's not related to web profile. It used so one can remotely login to
> Karaf/Geronimo shell. So this should be totally ok.
>> ops4j, pax-loggin-api, pax-url-mvn, pax-url-wrap: think these are just
>> test dependencies that were put into the assembly incorrectly.
> Again, not related to web profile. And these are used at runtime. We
> need them. Expect maybe pax-url-wrap.
>> tranql: think we could remove it.
>> openejb: anything we could do so that we can just have the ejb-lite function?
>> pluto/portal: I assume these are needed for admin console so we need it.
> Right. Shouldn't matter for web profile.
> Jarek

View raw message