Bug 177194

There is no reason why the library does not have manifest.mf, at least I don't remember any.
Scheduling for Nb 6.9

There is a question on stack overflow about this...

http://stackoverflow.com/questions/2848642/how-to-setup-main-class-in-manifest-file-in-jar-produced-by-netbeans-project

I tried to do the following with a Java Library Project in 6.9

1. create an empty manifest.mf file at the project root.
2. add 'manifest.file=manifest.mf' in the project properties.

When I did a clean and build... The MANIFEST.MF file in the jar did not include a Main-Class entry...

it looks like bug 178796 and bug 182897 are variations on the same 'theme' as this one...

TomasZ: You may want to close the others as a dup of this...  If you do, you may want to raise the priority of this issue, too.

For apps (manifest+main.class) the J2SEProject does the copying of dependent libs and adds the Class-Path attribute into the manifest. This is unwanted for libs, see issue #180707. I didn't put it into 6.9 as I was afraid main class in library (causing Class-Path attribute to be added) as a dependent project.

Comments from Rob Conklin:
I am afraid this bug inspires a fairly substantial 'rant'....

There may be a patch or update for this that I haven't got.  But 6.9 should never have shipped with this bug in the first place.   This is an unbelievable lapse in quality control, IMHO.

I switched to Netbeans from Eclipse simply *because* of Netbeans configuration of Ant build to package project jar files into /lib subdirectory and fix the manifest to include the program jar's main class and reference to classpath pointing at /lib! 

I am almost ready now to switch *BACK* !

To break something like this really causes head-aches -- it's a nightmare in general to deal with classpath (note: dumping 'classpath entirely would be the biggest boon to Java development since the beginning, and would be a more significant improvement than anything that has appeared in platform evolution over decades -- it would restore millions of hours of programmer productivity to the free pool, and make Java a much more popular programming tool [not that it isn't already, but there's no reason to keep stupid features like classpath just because they don't completely alienate everyone enough to keep them from programming in Java -- it's close -- I hated it when I first encountered it, and I've never gotten any warmer in my feelings about it over the last 4-5 years of doing development full-time with Java!!!!

 ... the complexities of Java projects these days, with all the .xml files that  go into it.  Jesus, can someone focus on a *vast* simplification, such as simply having any .jar files in the same directory as the main  class or jar containing the main class automatically be searched for classes that the project may depend on (like .NET).   I suggest completely eliminating classpath from Java -- does anyone really enjoy dealing with this or find it really useful?  Better to have a simple mechanism like the cwd & to support something like a global cache library that can be used to add specific libraries that are critical for mulitple projects, (again, have a look at .NET, netgen, that sort of thing).

In the meantime, if it isn't fixed already, please fix this one, it's more than a 'defect' it's a disaster, highest priority bug, IMHO -- it's just incredible that this got broken.

The libraries copying was disabled due to j2ee server problems with non existent Class-Path reference.
In the NB 7.0 I've added Project/Properties/Packaging/Copy  Dependent Libraries which allows to turn it on. When you create a new project it's enabled for apps by default. For libraries you have to turn it on in customizer.

fixed jet-main 4c0bdd9bb167

Integrated into 'main-golden', will be available in build *201102030000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/4c0bdd9bb167
User: Tomas Zezula <tzezula@netbeans.org>
Log: #177194:[68cat] Java library projects do not package main class

Product Version: NetBeans IDE 7.1 (Build 201112071828)
Java: 1.6.0_29; Java HotSpot(TM) 64-Bit Server VM 20.4-b02-402
System: Mac OS X version 10.6.8 running on x86_64; MacRoman; en_US (nb)
User directory: /Users/Jeff/.netbeans/7.1
Cache directory: /Users/Jeff/.netbeans/7.1/var/cache

Well I am still having the same problem 
MANIFEST.MF no main class


So Read this above and tried it 
-------------------------------------------------------------------------------
http://stackoverflow.com/questions/2848642/how-to-setup-main-class-in-manifest-file-in-jar-produced-by-netbeans-project

I tried to do the following with a Java Library Project in 6.9

1. create an empty manifest.mf file at the project root.
2. add 'manifest.file=manifest.mf' in the project properties.
-------------------------------------------------------------------------------
Now I presume by project properties. that we mean
Right Click main Project - Choose Properties
In the Categories choose Actions
Bottom Right Set Properties
Add Button - Disabled
so could not do this as a work round

Would be glad to send my Project so you can check

This is still alive as I see, I am using the Netbeans 7.3 version and maven project still not working for me. the manifest class doesn't incluede the main class attribute deffinition.

In reply to comment #9:
Works in NB 7.4 for Ant project, please the java/project category are issues for Ant based project or generic infrastructure. The Maven issues belong to projects/maven. I know that it's a strange but it was set in this way.

For Ant based project in NB 7.4:
1) When library has a main class set the jar's manifest contains Main-Class attribute.
2) If you want the build to create the lib folder with dependences (as the Java Application does) go to Project's Properties/Packaging and enable "Copy Dependent Libraries"