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 70875 - Set OpenIDE-Module-Java-Dependencies according to actual JDK, not source level
Summary: Set OpenIDE-Module-Java-Dependencies according to actual JDK, not source level
Status: RESOLVED WONTFIX
Alias: None
Product: apisupport
Classification: Unclassified
Component: Harness (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
: 71893 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-31 19:29 UTC by Jesse Glick
Modified: 2010-05-04 22:45 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Simplest but working approach (1.11 KB, patch)
2006-05-04 08:14 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-12-31 19:29:33 UTC
Perhaps the build harness (<jarwithmoduleattributes>) should automatically
insert OIDE-M-J-D in META-INF/MANIFEST.MF according to your selected JDK
(${java.specification.version} I suppose)? Would really force you to build
against a JDK no later than what you expected to run against.
Comment 1 tk_fhd_aui 2006-01-05 17:16:16 UTC
Would be a good idea I think. Also this should be used to add a j2se version to the generated jnlp 
descriptors, instead of the static 1.4+ in jnlp.xml.
Comment 2 Jesse Glick 2006-01-05 17:19:33 UTC
Good catch about jnlp.xml, thanks.
Comment 3 Jesse Glick 2006-01-12 00:18:23 UTC
Cf. also issue #70917 re. automatic versioning for module deps.
Comment 4 Jesse Glick 2006-01-26 18:12:43 UTC
*** Issue 71893 has been marked as a duplicate of this issue. ***
Comment 5 Jaroslav Tulach 2006-05-04 08:14:48 UTC
Created attachment 30230 [details]
Simplest but working approach
Comment 6 Jaroslav Tulach 2006-05-04 08:20:32 UTC
My recent experience with builds on release55 branch tells me that any help 
with java dependency is going to be useful. That is why I'd like to integrate 
some version of my patch which uses "javac.target" to identify the right 
version. Imho this is ok, as "javac.target" is in fact the lowest possible 
version of java runtime this module could possibly work with and it is better 
to put into manifest the lower bound than nothing. Especially if this can 
always be overriden - either by boosting javac.target or javac.source up or by 
directly specifying the whole attribute in the manifest file.
Comment 7 Jesse Glick 2006-05-04 15:49:41 UTC
Patch is indeed simple and better than nothing. I'm still guessing it would be
better to set it according to ${java.specification.version} from the selected
Java platform, however. For example, if you compile on JDK 5, even if using
-source 1.4, you cannot assure the module will really run on JDK 1.4 so it is
safest to make it be Java > 1.5. That would also align this enhancement with
issue #70917. So if you do commit the patch as is, please leave this open and
assign back to me, or open a fresh RFE for using the Java platform as a base.
Comment 8 Jaroslav Tulach 2006-05-04 16:25:18 UTC
Ok. All depends on whether we think defensively or positively. However I am 
afraid that with your solution we would not be able to have what we have 
currently in release55 - a compilation of 1.5 that ensures we run certain 
parts on 1.4. 

If you do not object, I'll commit this change and some test tomorrow, and 
reassign this issue back to you.
Comment 9 Jesse Glick 2006-05-04 17:21:02 UTC
"with your solution we would not be able to have what we have currently in
release55 - a compilation of 1.5 that ensures we run certain parts on 1.4" - not
sure what you mean. If a module is using 1.4 as a target platform then it should
get Java > 1.4. If just a part of a module is using 1.4 and the rest 1.5 - i.e.
the special case of core/bootstrap - well this is a special case where you would
want to put the attr directly in the manifest or otherwise modify the normal
build script logic.
Comment 10 Jaroslav Tulach 2006-05-05 07:26:16 UTC
Partially fixed by treating javac.target as lower bound for the Java > dep.

Checking in 
test/unit/src/org/netbeans/nbbuild/JarWithModuleAttributesTest.java;
/shared/data/ccvs/repository/nbbuild/test/unit/src/org/netbeans/nbbuild/JarWithModuleAttributesTest.java,v  
<--  JarWithModuleAttributesTest.java
initial revision: 1.1
done
Checking in antsrc/org/netbeans/nbbuild/JarWithModuleAttributes.java;
/shared/data/ccvs/repository/nbbuild/antsrc/org/netbeans/nbbuild/JarWithModuleAttributes.java,v  
<--  JarWithModuleAttributes.java
new revision: 1.10; previous revision: 1.9

The rest is up to Jesse, if he believes it is also needed.

Re. compilation of release55 - I am afraid that target platform is 1.5 for all 
modules, yet we want most of them to have Java > 1.4
Comment 11 Jesse Glick 2006-05-05 15:34:31 UTC
Re. compilation of release55 - it *should* be setting target platform to 1.4 for
the modules which we intend to run on 1.4. But this is another issue specific to
that release I guess.
Comment 12 Jesse Glick 2008-06-20 02:39:53 UTC
Refining priority and summary, since what we already have is decent.
Comment 13 Jesse Glick 2010-05-04 22:45:49 UTC
Do not seem to need anything more than javac.target-based configuration.