This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Move project creation API into EJB API module | ||
|---|---|---|---|
| Product: | javaee | Reporter: | Pavel Buzek <pbuzek> |
| Component: | EAR | Assignee: | Pavel Buzek <pbuzek> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | blocker | CC: | abadea, dkonecny, pjiricka, wadechandler |
| Priority: | P3 | ||
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | Windows XP | ||
| Issue Type: | TASK | Exception Reporter: | |
if I undestand it correctly, this is an API between the default ant based ear project type and the respective j2ee module project type. how relevant is it to some 3rd party that wants to create a custom ear project representation? is it supposed to use this API? Will some UI functionality be unavailable if it doesn't? Is this undergoing an API review? Full or fast track? It doesn't have one of the API_REVIEW(_FAST)? keywords and no diff is attached. It would be easier to review and comment based on a diff. Anyway, the propsed change sound OK to me, only I don't like using j2ee/ejbapi for it. This module is already containing stuff it shouldn't, at least according to its name (for example the CAR API, the EAR API, project-related stuff like ServerResourceNode and J2eeProjectView). Woulnd't j2ee/utilities be a better choice? I would perhaps suggest the interfaces to be called XxxProjectGenerator and the method names to be createXxxProject() instead of just createXxx(). Is "war" instead of "web" project by intention, suggesting the project doesn't necessarily have to be a web project, but it produces a WAR file? Are we still planning to do this one? It is assigned to apireviews, but has no review keyword set. Also, this does not look like a defect (can't see any user visible problem), so I am changing to TASK. I forgot to add the review keyword. I will fix the problems and ask for the review again. This does not need to be done for 5.5. I agree this sounds like a strange place to put this. utilities also sounds better to me. It is always awkward to have to look around for things when developing and them be in non-intuitive places. Especially considering one is not required to access EJB to create WAR based projects if they do not intend to support full EAs for their project type and only support WA. What's the status of this? This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss |
EAR project needs to create and import j2ee module projects (currently war, ejb, car). There is an API in each of the j2ee module project implementations to create and import projects for that j2ee module type. This APIs creates tight coupling between nb modules that implement projects, so that for example w/o app client support the EAR projects cannot be enabled. There should be an API for project creation in a separate api module which could be used by EAR project and a corresponding SPI that would be implemented by war, ejb and car projects. I propose to put this API into j2ee\ejbapi. The API will be a public final class with methods for each project (ejb, car, war) type like this: createWarProject(...) importWarProejct(...) setWarPlatform(...) The parameters are slightly different for each project type (e.g. war needs lib folder). The parameter list will be the same as in current APIs in j2ee project modules. The SPI will consist of one interface per module type, for example: public interface WarProjectCreator { createWar(..); importWar(..); setWarPlatform(..); } Method signatures will match the API. An implementation of this interface will be placed into module layer in J2EE\ProjectGenerators folder and the API will use folder lookup to get an instance of it. If we expected multiple different implementations of this API for any module type we would have to let the caller select which implementation to use. For example in the EAR module wizard the user would have to select which web project module to create. This is currently not needed and it is not planned so I am proposing to design the API to only expect one implementation of project creator for each type (take the first one if there are multiple).