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 69015 - funny behaviour for MANIFEST.MF
Summary: funny behaviour for MANIFEST.MF
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2005-11-20 23:32 UTC by _ alexlamsl
Modified: 2011-08-31 14:06 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ alexlamsl 2005-11-20 23:32:05 UTC
In a java project, which comes without the file MANIFEST.MF in the project 
directory, I set the value of "main.class" and build my file. Then I tried to 
run the compiled project from the jar file and got the error "Cannot find main 

I add an empty MANIFEST.MF into the project directory, set the "manifest.file" 
in build.xml, and the compiled jar file now have Main Class specified in its 
embeded MANIFEST.MF!

The problem comes from the fact that in build-impl.xml:

    <target name="-do-init" depends="-pre-init,-init-private,-init-user,-init-
        <available file="${manifest.file}" property="manifest.available"/>
        <condition property="manifest.available+main.class">
                <isset property="manifest.available"/>
                <isset property="main.class"/>
                    <equals arg1="${main.class}" arg2="" trim="true"/>

and I'm not quite sure why this is set to behave in such a way.
Comment 1 Jan Chalupa 2005-11-21 06:19:41 UTC
So, what is the expected (not so funny?) behavior?
Comment 2 _ alexlamsl 2005-11-21 10:18:34 UTC
shouldn't the main class be set in MANIFEST.MF regardless of whether an empty 
version of the file exists in the project directory?
Comment 3 Jan Chalupa 2005-11-21 10:45:53 UTC
Why? If you're creating a project from existing sources that don't include
MANIFEST.MF, there is probably some reason why it's missing. Would you expect
the IDE to create it for you and set the Main-Class attribute?

Sorry, this is not a P1 defect. In fact, I am not conviced it's a defect at all.
Comment 4 _ alexlamsl 2005-11-21 11:01:47 UTC
So why am I setting a Main Class in my project if that is not my Main Class in 
the packaged JAR?

Well if creating an empty MANIFEST.MF file for any new projects is a suggested 
fix, I would accept that personally - since this behaviour feels counter-
intuitive and I didn't get any help from the Help in the IDE!
Comment 5 Jan Chalupa 2005-11-21 11:13:19 UTC
Re "if creating an empty MANIFEST.MF file for any new projects is a suggested 

If you're creating a project from scratch, then the IDE creates a new
MANIFEST.MF for you, of course. If you're creating a project from existing
sources, how can it decide the missing MANIFEST.MF is not an intention?

Re "why am I setting a Main Class in my project if that is not my Main Class in 
the packaged JAR?"

I assume you're well aware that the Main Class setting is also used when
running/debugging the project in the IDE, so it's a useful property to set, even
if MANIFEST.MF is missing.
Comment 6 _ alexlamsl 2005-11-21 11:20:22 UTC
ah, now I see the point:

1) The project was created as a Class Library.

2) Later on, (after having a few classes) I have decided that it should just 
be an Application instead; so I created a "Java Main Class" to the project, 
and set it as the project main class.

obviously in this case MANIFEST.MF would be missing. I'm wondering though, so 
what is the proper way to get round this problem in the first place?
Comment 7 Jan Chalupa 2005-11-21 11:57:16 UTC
Hmm, we could possibly generate a warning when building the project jar (for the
first time). E.g.:

"You're building an application JAR without the file. Do you want
the IDE to create it for you? Yes/No".

Or (simpler), the warning could be printed in the build process output "Building
application JAR without the file."

This would need to be specified. Not for 5.0.