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.

Bug 57069 - Cannot Create Class Library Project for J2EE
Summary: Cannot Create Class Library Project for J2EE
Status: REOPENED
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Pavel Buzek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-28 17:27 UTC by ssoong
Modified: 2017-03-08 16:50 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ssoong 2005-03-28 17:27:56 UTC
NB 200503271800
JDK 1.5.0

When I create a new project, I can specify it as a Class Library project.
However, a Class Library Project does not have handles to J2EE jars.

The project I am creating is a library of utilities for J2EE where java code 
contains imports like:
import javax.servlet.ServletContext;

Well, the Java compiler and auto code-checker/completion croaks on such import 
statements, because it cannot locate the J2EE library classes.

My solution would be to create my J2EE class library as a web app project. No, 
I don't want to do that. I don't want to create a war but a jar ( Make jar not 
war!).

Wouldn't it be weird and klugy if I created a web app project for the purpose 
of building a class library? How would we create a jar in a web app anyway?

On the other hand, I could look for servlet-api-2.4 in Tomcat and create a 
library reference to it. Is that the proper way to do it? Which means the way 
I build a class project and a web app project may not reference the same set 
of J2EE jars. Why should that the project manager spontaneously associate 
servlet-api jar for me in a web-app project but would not do it for me in a 
class lib project?

Could NB developers please resurrect the ability to associate J2EE jar handles 
in a non-web app project?
Comment 1 ssoong 2005-03-28 17:56:01 UTC
Servlet 2.4 should be a **spontaneously available library member just like 
JUnit, JSTL and Absolute Layout.

(** too many people misuse the word "automatic" in place of "spontaneous", but 
if the world has gone too far on its usage then yes, I do mean "automatically" 
available).
Comment 2 Tomas Zezula 2005-03-28 17:59:10 UTC
Reassigning to j2ee to evaluate. I don't know much about j2ee project.
Comment 3 ssoong 2005-03-28 19:19:05 UTC
Should this be a J2EE project issue? Isn't this is a class lib project issue 
requiring the J2EE jar files to be made visible as library members?


Anyway ....

I decided to define the Servlet 2.4 library myself.

1.
Since NB library defn dialog does not allow spaces in lib handle name I 
assigned the lib as:
Servlet-API-2.4 = jar:nbinst:///modules/autoload/servletapi24.jar.

2.
But NB unintelligently changed that to
Servlet-API-2.4 = 
jar:file:C:\documents*******\****\jar:nbinst:///modules/autoload/servletapi24.j
ar.
Never mind, I clicked okay.

3. Went into 
C:\Documents and Settings\******\.netbeans\dev\config\org-netbeans-api-project-
libraries\Libraries.
Editted Servlet-API-2.4.xml
and changed the path to
jar:nbinst:///modules/autoload/servletapi24.jar.

4.
I also managed to change the lib handle name to
Servlet API 2.4 resplendent with the full glory of two space chars not allowed 
by the library manager dialog. (What the authoritarians attempt to enforce 
there will always be members in the masses who would circumvent their rules. 
Viva!)

5.
I started IDE and compiler as well as Java editor did not complain,
 but code-completion feature would not work.

Therefore I had to edit Servlet-API-2.4.xml
and changed the path to
jar:nbinst:///modules/autoload/ext/servlet-api-2.4.jar.

Since jar:nbinst:///modules/autoload/servletapi24.jar is an envelope for 
containing both servlet-api-.2.4.jar and jsp-api-2.0.jar, now I would have to 
create another xml to define jsp api 2.0 (hrmmphhh!).

6.
I should write another bug report to direct item 5 to the java editor group 
about code-completion feature not recognising a jar envelope xml.

7.
Here's the xml for Servlet API 2.4:

?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE library PUBLIC "-//NetBeans//DTD Library Declaration 
1.0//EN" "http://www.netbeans.org/dtds/library-declaration-1_0.dtd">
<library version="1.0">
	<name>Servlet API 2.4</name>
	<type>j2se</type>
	<volume>
		<type>classpath</type>
		<resource>jar:nbinst:///modules/autoload/ext/servlet-api-
2.4.jar!/</resource>
	</volume>
	<volume>
		<type>src</type>
	</volume>
	<volume>
		<type>javadoc</type>
	</volume>
</library>

Comment 4 Pavel Buzek 2005-03-28 19:48:57 UTC
We could add servlet api and jsp api as libraries for use in J2SE projects, but
I have several concerns:

1. It will be confusing for users why these are not used for J2EE projects (of
course this is because j2ee projects get classpath defined by a plugin for
target j2ee server, but users may not understand). The number of users who will
need this will be much smaller then the number of users of j2ee projects. Maybe
this can be solved (explained in UI).

2. We can only do it for servlet and jsp apis, not all j2ee (legal issues, we
cannot bundle j2ee.jar).

3. I am not sure it is worth a UI change at this point, with all the docs, l10n,
etc. impact.

Several comments on how to define the servlet and jsp library manualy. 
First, you can add servet and jsp jar file to 1 library. Second, the javadoc
(the libraries also, btw) is available in the bundled tomcat. You can setup the
library in UI and should not need to change the xml manually but see what the
result should be:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE library PUBLIC "-//NetBeans//DTD Library Declaration 1.0//EN"
"http://www.netbeans.org/dtds/library-declaration-1_0.dtd">
<library version="1.0">
	<name>ServletAndJSP</name>
	<type>j2se</type>
	<volume>
		<type>classpath</type>
	
<resource>jar:file:/C:/nb_all/nbbuild/netbeans/enterprise1/modules/autoload/ext/jsp-api-2.0.jar!/</resource>
	
<resource>jar:file:/C:/nb_all/nbbuild/netbeans/enterprise1/modules/autoload/ext/servlet-api-2.4.jar!/</resource>
	</volume>
	<volume>
		<type>src</type>
	</volume>
	<volume>
		<type>javadoc</type>
	
<resource>jar:file:/C:/nb_all/nbbuild/netbeans/enterprise1/docs/j2eeri-1_4-doc-api.zip!/</resource>
	</volume>
</library>

If I add this to my project I have code completion.
Comment 5 ssoong 2005-03-29 20:39:32 UTC
How about the choice to create "web class library" project?
Comment 6 Pavel Buzek 2005-03-29 23:39:46 UTC
Definitely not for 4.1. Let's get back to this after 4.1.
Comment 7 Jiri Kopsa 2005-03-30 12:49:22 UTC
Re: Web Class Library 
This does not concern just Web Application libraries (i.e. JSP/Servlet API) but
the whole J2EE API.

We currently have a workaround for this, don't we? Add the required API as an
library to the Java Class Library project. Unfortunately this is a little harder
in 4.1 that it was 4.0, where we had the Servlet API defined as one of the
libraries. We replaced this with J2EE Platform (Server Manager) in 4.1.

In promo-F we might come with an ehnancement that would solve this issue as well
as the similar issue in free form projects. The user is supposed to add Servlet
API there as well.

What about switching this to an enhancement Pavle? This seems to me as not being
a defect - or freem form classpaths are also defects?
Comment 8 Pavel Buzek 2005-03-30 14:08:39 UTC
I think this was easier in 4.0 so I am ok with defect.
Comment 9 Pavel Buzek 2005-04-04 14:55:30 UTC
OK, I will change this to ENH, based on Jirka's suggestion and Jesse's opinion
(in issue 57329 Jesse goes even futrher by saying we do not want this at all....)
Comment 10 Martin Balin 2016-07-07 08:53:40 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 11 ShuffleBits 2017-03-08 16:50:26 UTC
Still present in Netbeans 8.2.
It is not possible to create a Java Library that references J2EE classes, without "faking" a, for example, tomcat jar file in.