Hi, I've been on vacation so not sure how much have been said and done in this thread yet.
I just want to clearly state that my belief is that an IDE like Eclipse should not *prevent* users from doing things outside a spec or usecases if it can be avoided. It should merely provide a *warning* if relevant (or error if the users decide that he wants "strict" mode) Anything else is bound to be a straight jacket that prevents usage and adoption. So in short, J2EE 1.4 apps should be allowed to include EJB3 parts - its a common supported case by e.g. JBoss. And the spec does not say your are not allowed to do it, it is just not required by spec - not the same thing as it not being illegal. /max > Hi Kaloyan, > > Thank you for raising this issue. I agree we are inconsistent in parts, > and although we don't necessarily need to resolve all of the issues > immediately we should at least have a common definition of what is > 'correct' and may eventually be supported by WTP. > > Among the IBM committers we generally agree with #2, but have made an > interesting distinction: the schema used by a DD is only a bottom boundary > on the spec level of the EAR or module. As an example, a '1.4' EAR that > contains an EJB 3.0 module is really just an EE 5 EAR (or EE 6.0 or ...) > with an older DD. Likewise, EJB 3.0 annotations within an EJB module is an > indication that the EJB is at least EE 5/EJB 3.0, even if the DD still > points to the EJB 2.0 schema. > > If DD schemas and spec API usage are just a bottom boundary, it means that > there is nothing within the contents of an EAR or module that can > precisely determine its level. So how do we tell if it is valid for a user > to add an EJB 3.0 module to what currently looks like a 1.4 EAR? Was it > really an EE 5 EAR all along, do they want to uplevel the EAR, or is the > user simply making a mistake? > > The solution we came to is using facets. Facet versions allow the user to > tell us which spec level they expect an EAR/module to be at, and gives us > something to tool for and validate against. The versions are set on > project creation or on import based on what we initially find in the > modules. From there, the facet version of an EAR determines the maximum > spec level of modules that can be added or which servers it can be run on, > and validation can show errors for invalid modules or if the DD points to > a schema above the level of the facet. > > If you agree with the original distinction (that true EAR 1.4s can't hold > EJB 3 modules, but the schema used by the DD is only a bottom boundary on > the spec level), then I think you'll eventually come to the same > conclusion we have. Please feel free to let me know what you think and > others can chime in, or we can discuss on one of the WTP calls. > > Thanks, > Tim deBoer > [EMAIL PROTECTED] > > > > From: > "Raev, Kaloyan" <[EMAIL PROTECTED]> > To: > "General discussion of project-wide or architectural issues." > <wtp-dev@eclipse.org> > Date: > 06/26/2008 09:04 AM > Subject: > [wtp-dev] Mixing spec levels in EAR. Opinions? > > > > Hello, > > I want to bring up again an issue that was discussed some time ago in > Bugzilla. It is about mixing of spec levels of EAR and included modules. > There are two bugs related: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=220929 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=229893 > > Everybody agree that EAR with spec level X could include modules with > spec level X or lower. Example: EAR 5 can include EJB 2.1. > But there is no consensus of opinion on EAR with spec level X to include > modules with spec level higher than X. Example: EAR 1.4 to include EJB > 3.0. There are two contrary opinions: > 1. EAR 1.4 can include EJB 3.0 > 2. EAR 1.4 cannot include EJB 3.0. > > The supporters of opinion 1 says that it is not forbidden by the Java EE > spec. > The supporters of opinion 2 says that it is (at least indirectly) > forbidden by the spec. This is because the contract of the Java EE spec > says that a deployment module compliant with spec level X must always be > able to deploy on an application server compliant with spec level X. Now > let's look again at our example of EAR 1.4 including EJB 3.0. EAR 1.4 is > a J2EE 1.4 deployment module and it is guaranteed by the spec that it > will deploy on all J2EE 1.4 compliant servers. But if we try to deploy > it on an J2EE 1.4 compliant app server, that is not at the same time > Java EE 5 compliant, then our deployment will fail, because of the > included EJB 3.0 module (which is Java EE 5 spec level). > > At the moment there is an inconsistency in several dialogs in WTP > regarding this issue. For example the Java EE Module Dependencies > property page of an EAR 1.4 project filters Java EE 5 modules for > selection, while at the same time the project creation wizard allows a > EJB 3.0 project to be added to an existing EAR 1.4 project. > > I suggest that we discuss this problem and hope we will have an > agreement for WTP 3.0.1. I invite all application server vendors > represented in this mailing list to express their support for either > opinion 1 or opinion 2. > > Greetings, > Kaloyan Raev > Eclipse WTP Committer > <http://www.eclipse.org/webtools/people/person.php?name=raev> > Senior Developer > NW C JS TOOLS JEE (BG) > SAP Labs Bulgaria > T +359/2/9157-416 > mailto:[EMAIL PROTECTED] > www.sap.com > P Save a tree - please do not print this email unless you really need > to! > > _______________________________________________ > wtp-dev mailing list > wtp-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/wtp-dev > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev