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.
The involved fully qualified names of the changes are: org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeAppProvider org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap (1) J2eeModuleProvider { File getEnterpriseResourceDir(); } * Reason for change: The original return type FileObject is not appropriate because now there are additional read-only user code in which case the directory does not need to exists and using FileObject would require unecessary directory creation. This is a week old API method and there is only one user code needed the signature change. (2) J2eeModuleProvider.ConfigSupport { public abstract void ensureResourceDefinedForEjb(String ejbname, String ejbtype); } Reason for adding: Dev modules need to explicit request for needed resource to be created if desirable and possible. The automatic DD bean event-drivent model for this service has timing problem; not all context information about the EJB are available at the time the event is fired. (3) SourceFileMap { public static final SourceFileMap findSourceMap(DeployableObject deployable); public abstract File getEnterpriseResourceDir() public abstract File[] getEnterpriseResourceDirs(); } Reason for adding: Plugin at deployment time needs to access to resource directories for automatically ensuring the resource are defined on server. DeployableObject from standard J2EE Deployment API, an existing dependency from J2eeServer.
Making P1 as part of the change is already integrated and if there is a problem it has to be resolved before release. According to api-changes mailing list there were three changes after branching release40: http://www.netbeans.org/servlets/ReadMsg?msgId=870008&listName=api-changes org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeAppProvider: method public org.openide.filesystems.FileObject org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider: method public org.openide.filesystems.FileObject org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() http://www.netbeans.org/servlets/ReadMsg?msgId=867308&listName=api-changes org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeAppProvider: method public final [Lorg.openide.filesystems.FileObject; org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getConfigurationFiles(boolean) org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider: method public final [Lorg.openide.filesystems.FileObject; org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getConfigurationFiles(boolean) http://www.netbeans.org/servlets/ReadMsg?msgId=870010&listName=api-changes org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeAppProvider: method public org.openide.filesystems.FileObject org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider: method public org.openide.filesystems.FileObject org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() Added Methods ------------- org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap: method public static final org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap.findSourceMap(javax.enterprise.deploy.model.DeployableObject) org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap: method public abstract java.io.File org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap.getEnterpriseResourceDir() org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap: method public abstract [Ljava.io.File; org.netbeans.modules.j2ee.deployment.common.api.SourceFileMap.getEnterpriseResourceDirs() org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeAppProvider: method public java.io.File org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider: method public java.io.File org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getEnterpriseResourceDirectory() org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider$ConfigSupport: method public abstract void org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider$ConfigSupport.ensureResourceDefinedForEjb(java.lang.String,java.lang.String) From what I can see, some of the changes are incompatible. It is question whether doing incompatible changes is really necessary, but as the j2eeserver is just friend api, it is probably up to you to decide whether or not you want to do them. However if you do api changes: 1. you need to increase the specification version of your module 2. you need to make a note in apichanges document (which you have to create, as the module is still missing it) 3. you should update the arch-usecases answer to describe what is the intendent use of your api and justify that the change is needed 4. you should have a test to verify that your functionality works 5. update all modules that use the new functionality to depend on new specification version of your module Moreover when doing an incompatible change, you should increase the major version of your module to j2eeserver/4 (necessary just once per release). Please fix the above described missing things and attach the diff here. PS: Info on versioning is available at http://openide.netbeans.org/versioning-policy.html
Probably getEnterpriseResourceDir() could return URL rather than File, unless you are positive it has to be a dir on disk (rather than e.g. a JAR folder). Generally we use FileObject when possible and URL (or perhaps URI) when we need to refer to a file/dir which might not currently exist.
Jarda, is this the change you said to be "incompatible": change #1 on J2eeModuleProvider from: FileObject getEnterpriseResourceDir(); to File getEnterpriseResourceDir(); If so, the fact is that method getEnterpriseResourceDir is added after release40 branched, so is this still consider incompatible? Jesse, Thanks for the hint on using URL. In this case the method returned value is meant for one location in project directory structure, so I think File is OK.
- I am attaching the manifest.mf increasing the spec number as well as the major version number as Jarda suggested. I actually saw that the in earlier changes SourceFileMap has one static method completely replaced. so the major version number is justified. - I also attaching a apichanges.xml. - I review arch answers, none of them are affected by these changes. - On unit test cases, I would like to waive. These changes are additional SPI and API methods with very thin buffering implementation code changes. The actual test cases should be on dev module who provide its service to and use the services from plugin, through the intermediation of j2eeserver.
Created attachment 19193 [details] manifest.mf diff
Created attachment 19194 [details] apichanges.xml for cmp and auto resouces support
Maybe you want to have more api categories in the apichanges.xml. As far as I remember Pavel told us that there are basically two (and maybe more) separate apis in the module. Tests can be waived. It is just friend api, anyway. Incompatible changes were reported by the tool, but in fact the only thing that matters is the difference to a release. If the changes are compatible with release40, then no increment in major number is needed.
- I am appending a new apichanges.xml with Yarda's suggested details. - I also, append new manifest.mf diff without major module version increment. The minor change in SourceFileMap is minor not expected be used by any plugins code yet.
Created attachment 19217 [details] new manifest.mf change w/o major version increment
Created attachment 19218 [details] apichanges.xml with finer API categories
Commited the latest recommendation on apichanges.xml and manifest.mf
v