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 servlet file template (and possibly other templates) shall check if servlet-api jar classes are on classpath and if not, then add it. primarily an issue for maven based projects that don't have (and cannot have) app server bits on classpath and often don't even have an app server associated.
Changing to an enhancement request when we are ready for full maven support
please reevaluate, the maven support becomes part of standard distribution this week, therefore creating a servlet and get compilation error is a bug.
a P2 issue #153787 either depends on this one or is duplicate
I'm taking over servlet from scratch, so mkleint please give more detail (as much as possible) about where the change needs to occur. (We also may want to discuss offline.) Marking incomplete.
there needs to be some kind of procedure/api that will instruct the maven support that servlet-api (or other j2ee api) needs to be added on classpath at the moment of finishing the new file wizard for servlet and other j2ee templates. The primary actor here is the wizard iterator of the servlet template (or other templates) which need to identify the project that the file is being added to and act accordingly (make sure the project is compilable after the file template is created) An pre-existing solution to the problem is ClassPathExtender/ClassPathModifier api. + a generic solution, tested to work - servlet.jar is not a library and we need one according to the j2ee level (right?) Another approach could be to create a new api that would maven projects implement and the template iterator call. Something that would intstruct maven projects to add dependencies on classpath. eg. interface J2eeContainerEnhancer { void enhancej2eeEnvironment(<enumeration of technologies to support>); } we can chat about the solution offline via phone if you prefer.
According to mkleint, this is for 7.0. So changing target milestone.
Cc'ing also Milan and Trey. I think Milos's idea with J2eeContainerEnhancer is reasonable. This would be useful not only for the servlet wizard, but also in other cases: - Other wizards, such as JSP, Tag file, Taglib descriptor, Filter, WebApp Listener etc. - Web frameworks: when adding a web framework to a project, it is reasonable to add servlet/JSP API to the project classpath
The issue is related to most of the web wizard templates, including : - servlet - filter - servlet listener Some of them reqires servlet.jsp API (e.g. tag handler) Note some of the wizards are not even working due to missing servlet.api on classpath (e.g. Web Application listener wizards) Increasing priority to P2
*** Issue 153787 has been marked as a duplicate of this issue. ***
I also see the benefits of 3rd party modules to enhance the a projects classpath. However I do not see what the J2eeContainerEnhancer will provide over using the ClassPathExtender/ClassPathModifier. Well I do see one thing, the Enhancer would first check if the jar file is currently in the classpath before adding the jar to the classpath. But that sounds like how the ClassPathExtender/ClassPathModifier should work.
classpath modifier/extender requires all the jar files to be shipped with netbeans for all the j2ee versions. eg. 3 servlet-apis etc. The suggested api will work with symbolic token and will allow maven support to place the correct jars on the project's classpath.
Wouldn't be better to update the modifier/extender to handle these usecases? The reason I ask is that this requirement sounds like something that will be needed by most projects.
one of them is deprecated, the other one could be possibly used. I suggested a special api as the j2ee server specific jars are the only usecase now (together with maven projects) One thing I forgot to mention. On my side I need to learn that the jars are part of the j2ee server somehow as I need to prevent the jars to be part of the war file. That's done by defining a dependency scope of "provided".
mkleint and I spoke offline. The current plan--with the details still preliminary--is that he will add a new abstract class to the org.netbeans.spi.java.project.classpath package (in the java.project module) similar to the ProjectClassPathModifierImplementation class in that package. The new class will specify one or more methods whereby new resources can be added to the classpath, but instead of accepting a Library[] or URL[]/URI[], the methods will accept a String name or String[] of names representing the resources to be added. He will also write a new concrete class that extends this new abstract class; the concrete class will live in one of the maven modules. Also, he will write one or more methods for use by clients (such as the web.* modules) that accept a String name or String[] of names representing the resources to be added; he will likely add these to org.netbeans.api.java.project.classpath.ProjectClassPathModifier. Accordingly, I will make calls into the new client methods to add the servlet api and any related resources whenever the user adds a new servlet, servlet filter, or jsp to a maven project. We welcome any input on this plan, and, as previously mentioned, the details are preliminary. mkleint will begin this work in January or potentially February. mkleint, let me know if I got any of this wrong.
> I will make calls into the new client methods to add the servlet api and any related resources whenever the > user adds a new servlet, servlet filter, or jsp to a maven project. This is one case, but I believe that this API should also be used when creating a new Web-Maven project from scratch, so it works out of the box, even if I don't create the web components using NetBeans wizards.
In new web archetepes (J2EE 1.4 and java ee 5), proposed by mkleint, servlet api is there. I'd also add servlet.jsp API otherwise any simple JSP code will be error badged, e.g. : <% out.println("Hello World"); %>
reassigning to myself
Created attachment 75492 [details] suggested api change along with implementaion
I've added the new api to the j2ee.core.utilities module. it's advantage is that it's a friend api module (thus limits scope and eases the compatibility constraints) and is used by almost all j2ee modules already. it has only a few dependencies of it's own which is a plus too. I've added the api, implemented it for servlet-api and jsp-api apis in the maven modules and web.core module uses the api for servlet and taghandler file templates. please review
thanks for review, I will integrate shortly
http://hg.netbeans.org/main/rev/9f1dc4721536 mbohm, please proceed with evaluation of other templates and adding the boiler place code in teh template iterators. If you figure you need more than servlet-api and jsp-api, let me know
Integrated into 'main-golden', will be available in build *200901121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9f1dc4721536 User: Milos Kleint <mkleint@netbeans.org> Log: #150274 add a new friend contract between project type (maven) and the file generating codebase to notify the projecttype to add certain application server apis on project's classpath. implemented the interface in maven.j2ee and used it in web.core's Servlet and Taghandler file templates
prepare for replan
AFAIK, all wizards in web category, EJB category and persistence category were implemented to use this API. I consider this particular API issue completed. I also reported 2 tasks for SOAP and REST services wizards to implement this API: issue 161782 issue 161783