Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 179584 - Autocompletion does not work in jsp files inside maven projects with type "bundle"
Autocompletion does not work in jsp files inside maven projects with type "bu...
Product: javaee
Classification: Unclassified
Component: JSP
Other Linux
: P3 with 3 votes (vote)
: 7.0.1
Assigned To: Martin Janicek
Depends on:
  Show dependency treegraph
Reported: 2010-01-16 12:07 UTC by benderamp
Modified: 2016-07-08 08:27 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT

Example mvn project to reproduce autocompletion issue (64.38 KB, application/zip)
2012-06-11 19:01 UTC, agallardo

Note You need to log in before you can comment on or make changes to this bug.
Description benderamp 2010-01-16 12:07:07 UTC
I understand that this is not something that might have been supposed to work, but some people try experiments to use OSGI on server side - for example here: and I had almost good success with netbeans+maven as IDE for such projects, but his issue is something that makes things much inconvenient.

1. Create new Maven Web Application projects
2. Open index.jsp file, put "<% %>" construction there and start to type something like "java.lang" and press "ctrl+tab" at some moment to make sure autocompletion works
2. Open pom.xml file and change project type from "war" to "bundle" (tag "packaging")
3. Close netbeans (this is important) and start again
4. Goto index.jst and see that autocompletion now is not working
5. Change projects type to "war" again - autocompletion still will not work until IDE would be restarted
Comment 1 Milos Kleint 2010-01-18 00:26:01 UTC
Reassigning to the j2ee component for evaluation.

this seems to be related to the packaging of the maven project (thus content of the project\s Lookup) but since it's working also without it (when not restarting the IDE) it might be worth looking into if it can work with bundles as well.
Comment 2 Petr Jiricka 2010-01-20 03:53:18 UTC
I guess the problem could be that for OSGi bundle Maven projects (unlike war Maven projects), the basic IDE infrastructure for doing "web stuff" (WebModuleProvider and friends) is not active, so the JSP editor does not have any context.

The potential fix could be to enable the "web stuff" also for bundle projects, but my question is this: is there a consensus/standard which says what a OSGi bundle web project should look like? I see the blog entry talks about a "web.jar" file, but the format of this file is rather non-standard and seems to be specific to this one particular blog entry. The war file has a set structure defined by a standard; in the OSGi space I am not aware of such a standard. I know that SpringSource allows deployment of OSGi webapps to their server - do they use the same format? Or a different one? I would think we need a generally accepted deployment format of OSGi webapps (which also translates to a source layout format), and then we can think about how to support such a structure in the source editor. Any pointers to more information about this space would be appreciated - thanks.
Comment 3 benderamp 2010-01-21 03:54:44 UTC
I have the following maven project structure:


It would be exactly the same both for bundle and war maven project - key directories are "src/main/java" which contains java source files and "src/main/webapp" which contains jsp file and all other web staff. The only key difference between bundle and war project is that bundle project does not contain web.xml file (which is located in another project), but actually this does not make sense in the scope of this bug (will try to explain below).

the produced bundle file:

So, files from webapp directory are taken from "src/main/webapp" and packaged to the bundle file just like normal resources, and for me this is enough to load them to tomcat-osgi environment (but again, the details are not important here).

The thing is that maven already handles project structure + output bundle generation correctly, so nothing new should be done in this area; also web standards are not affected here - generated bundle is normal OSGI bundle wich can be loaded to any OSGI environment - the fact that it can be loaded and executed on tomcat+osgi environment is secondary here.

Few notes: 

- having "src/main/webapp" directory is enough for netbeans to recognize it and put special "Web Pages" node in the project tree - exactly as contents of "src/main/java" are shown under "Source Packages".

- "src/main/webapp" is recognized as "Web Pages" in any type of project - web application, java project or java bundle project - just try to create this dir on filesystem inside new normal maven java project and "Web Pages" node would pop up in the project tree.

- try to create maven Web Application project, check that autocompletion works for jsp file under "Web Pages" node, then put jsp file to "Source Packages" node (near java files), and then check autocompletion again and see that it does not work. So that means that even inside normal Web Application project jsp autocompletion is enabled not for the whole project resources - only for ones which are located under "Web Pages" project node (in "src/main/webapp" dir on filesystem).

So, this all gives me a summary idea, that web development module can be loaded for any maven project which has "src/main/webapp" directory for resouces inside this directory without taking into account packaging type attribute stated in pom.xml. Such logick seems to be rather simple and straighforward, would cover all scenarious (both standard and such currently non-common as mine) and would not break any standards.
Comment 4 Tomasz Slota 2010-04-06 11:55:36 UTC
I think it will be tricky (if possible) to make our JSP parser work with projects without web.xml. This issue is technically similar to the problem of providing possibly complete editing support for JSP files that do not belong to any project.
Comment 5 benderamp 2010-04-06 14:36:08 UTC
I am not familiar with internal code mechanisms, but what I see is that with "war" project type autocompletion works even withot web.xml file present in the project - just changing nothing except "packaging" tag value from "bundle" to "war" enables jsp autocompletion (restarting ide/reopening the project is required), and vice versa - changing packaging from "war" to "bundle" switches autocompletion off.
Comment 6 Tomasz Slota 2010-04-06 14:55:19 UTC
you are right, please disregard my previous comment
Comment 7 fhopf 2011-03-29 18:17:18 UTC
I do have the same issues when using jsps in jar projects in NB 6.9.1. I understand that this is a rather special situation but I would really appreciate if this could be fixed.

Could anybody point me to the component that is responsible for activating the WebModuleProvider fuctionality? I guess it's quite hard to fix this without Netbeans knowledge but at least I could try.
Comment 8 David Konecny 2011-04-04 19:37:52 UTC
I hotfixed this by providing full web support in maven project's lookup not only for "war" packaging type but also for "bundle" packaging type if 'src/webapp' folder is presented. It does feel more like a hack than proper fix but I'm tempted to try this out and see how it works. I tested on the test case provided and it was OK.

Comment 9 Anton Chechel 2011-04-06 13:09:26 UTC
Davide, I can't find 0749b3ef017e changeset, was it in web-main trunk?
Comment 10 David Konecny 2011-04-06 22:44:09 UTC
(In reply to comment #9)
> Davide, I can't find 0749b3ef017e changeset, was it in web-main trunk?

Sorry, I will push it in next hour or so.
Comment 11 Quality Engineering 2011-04-07 08:43:26 UTC
Integrated into 'main-golden', will be available in build *201104070400* on (upload may still be in progress)
User: David Konecny <>
Log: #179584 - Autocompletion does not work in jsp files inside maven projects with type "bundle"
Comment 12 agallardo 2012-06-03 13:04:56 UTC
(In reply to comment #4)
> I think it will be tricky (if possible) to make our JSP parser work with
> projects without web.xml. This issue is technically similar to the problem of
> providing possibly complete editing support for JSP files that do not belong to
> any project.

I don't get why is this so tricky/impossible. Thinking naively, in a mvn project, it is very clear were the dependencies are, so it should be for the IDE quite straightforward, shouldn't it?
Comment 13 agallardo 2012-06-03 13:59:30 UTC
Autocompletion does not work in jsp files inside maven projects with type "war" but outside 'src/main'webapp.'

Providing JSP auto-completion only in src/main/webapp does not suffice. I'm aware of the maven recommended dir layout (, but:

1) in mvn, it is still possible to configure the webapp dir:


2) and there are cases were I don't even use the war plugin and still need to edit files outside the recommended 'src/main/webapp'.

In my real case, I'm creating a module for OpenCms (a content management system) by means of:

    mvn archetype:generate -DarchetypeCatalog=

This module has a particular directory hierarchy, where the jsps live inside '/src/main/opencms/...'. Changing the project type to war (originally was jar) and creating the '/src/main/webapp' dir, I could get jstl autocompletion. But unfortunately, I don't get autocompletion for other tlds in my dependencies.
Comment 14 Martin Janicek 2012-06-11 11:52:35 UTC
Could you attach simple project where I'll be able to see broken completion?
I've just tried following steps but everything works as I expected.

1. Create Maven web project
2. Create another source folder (e.g. /src/main/anotherwebapp/)
3. Create a JSP file inside
4. Using code completion in created file (JSP tags are available as well as HTML tags)
Comment 15 agallardo 2012-06-11 19:01:42 UTC
Created attachment 120690 [details]
Example mvn project to reproduce autocompletion issue

There is no auto-completion support under src/main/opencms.
Comment 16 agallardo 2012-06-11 19:02:39 UTC
Hi mjanicek,

thanks for taking the time to test it.

Following I have detailed how to reproduce this issue. My environment:

Product Version: NetBeans IDE 7.1.2 (Build 201204101705)
Java: 1.6.0_26; Java HotSpot(TM) 64-Bit Server VM 20.1-b02
System: Linux version 3.2.0-2-amd64 running on amd64; UTF-8; de_DE (nb)

(With a clean NetBeans 7.1.2 installation, after activating Java and JavaWeb + JEE.)

How to reproduce

(The archetype-catalog used for the bug report has been migrated to -DarchetypeArtifactId=opencms-module-archetype.)

1. Due to, you have to create the maven project from the command line:

   mvn -DarchetypeGroupId=at.infonova.opencms.archetypes -DarchetypeArtifactId=opencms-module-archetype -DarchetypeVersion=1.0.1 -DarchetypeRepository= -DgroupId=com.mycompany -DartifactId=mavenproject2 -Dversion=1.0-SNAPSHOT -Dpackage=com.mycompany.mavenproject2 -DprojectName=mymavenproject2 -Darchetype.interactive=false --batch-mode archetype:generate

2. Open the project with NetBeans

3. Edit the pom.xml to change "<packaging>" to "war"

4. Expand in projects "Other sources - opencms - system - modules - mavenproject2 - pages"

5. Right click in pages and create new JSP "newjsp.jsp" with default options

6. Add <%@taglib prefix="c" uri="" %> to the beginning of the page.

7. Dependencies -> Rigth-click -> Download declared dependencies

8. Try autocompletion for "<c:"

   *** It does not work *** ("No suggestions" displayed)

9. Check that "Dependencies -> opencms-core-8.0.0.jar [provided] /META-INF/opencms.tld" exists.

10. Add <%@taglib prefix="cms" uri="" %> to the beginning of the page.

11. Try autocompletion for "<cms:"

   *** It does not work *** ("No suggestions" displayed)

12. Create symlink to opencms:
   cd src/main
   ln -s opencms webapp

13. Reopen NetBeans

14. Open newjsp.jsp from within Web Pages

15. Try autocompletion for "<cms:"

    *** It works ***

16. Try autocompletion for "<c:"

    *** It works ***
Comment 17 Martin Janicek 2012-06-12 14:23:40 UTC
Thanks for the quick and comprehensive answer. I'll take a look at it as soon as possible..
Comment 18 Martin Balin 2016-07-07 08:55:48 UTC
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
Comment 19 agallardo 2016-07-08 08:27:11 UTC
Re-tested in NetBeans 8.1: I can confirm that this is not reproducible.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo