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.
The use of nb-configuration.xml cab cause problems within the IDE that can take time to resolve if the said file is forgotten. i.e. I just spent some time trying to figure out why NB 8 would not recognise that the projects had been switched to JDK8. I have a parent POM with the following properties: <version-java-target>1.8</version-java-target> <netbeans.hint.jdkPlatform>JDK_1.8</netbeans.hint.jdkPlatform> I should note I start NB with JDK7, and use JDK8 as a secondary JDK. The problem here was that the super pom was correctly setting the JDK version, though the child projects had their own nb-configuration.xml files which had <netbeans.hint.jdkPlatform>JDK_1.7</netbeans.hint.jdkPlatform> causing an invalid override as it should never be specified in a child POM. Deleting all nb-configuration.xml files and reloading projects has solved the problem. Product Version: NetBeans IDE Dev (Build 201401260001) Java: 1.7.0_40; Java HotSpot(TM) 64-Bit Server VM 24.0-b56 Runtime: Java(TM) SE Runtime Environment 1.7.0_40-b43 System: Mac OS X version 10.9.1 running on x86_64; UTF-8; en_AU (nb) User directory: /Users/bryan/Library/Application Support/NetBeans/dev Cache directory: /Users/bryan/Library/Caches/NetBeans/dev
there's 2 distinct concepts/rules here at play. 1. we use nb-configuration.xml by default as there's a large portion of people that doesn't like IDE specific entries in the pom file. 2. the other rule is that a customizer for a project will only affect the given project only. Even if we stop doing 1., you would end up in the same situation as the child project property overrides the parent definition in the pom. I admit it would be somewhat more clear given that effective pom would show you the origin of the effective value but still.. And changing the customizer to allow edits that potencially change tens of projects decreases the usability of the UI. Our current approach so far was keep it simple and predictable in the UI but allow advanced customizations for those who know and dare.
Thanks Milos The main reason for my argument is that NB did the wrong thing. In maven child projects should not use a different java version to their parent project. i.e. I just changed my project to JDK8, however NB did not update the child projects to reflect this, maybe because they weren't open, I do not know. Opening the configuration for these child projects would reveal they had JDK8 configured, so it could not be changed. And rightly so, because they were actually referencing the parent like they should have. It was those rogue nb-configuration.xml files hanging about that were hiding the fact they were telling the IDE that the child projects should use a different JDK, when their maven plugin told otherwise. As an example do the following: parent + pom.xml - Configured to use `maven-compiler-plugin' = 1.8. - Contains property for `netbeans.hint.jdkPlatform' = JDK_1.8. + child + pom.xml - No configuration present to represent any JDK, refer to super pom. + nb-settings.xml - configured to use JDK7 In the above you will find that the nb-settings.xml for child project should be ignored, since the parent should override it. Being IDE generated many users might not understand what's going on, and find it hard to figure out why the IDE keeps telling them they can't use language features when they change to a newer JDK. Avoiding nb-configuration.xml would solve this where possible.
(In reply to brettryan from comment #2) > Thanks Milos > > The main reason for my argument is that NB did the wrong thing. In maven > child projects should not use a different java version to their parent > project. i.e. I just changed my project to JDK8, however NB did not update > the child projects to reflect this, maybe because they weren't open, I do > not know. No, it was because all UI edits by default affect just the current project. If the pom.xml file is being edited, then inheritance can come into play. A bit related to issue 214121, but so far we haven't introduced inheritance to any of the netbeans files, basically because it adds up complexity and slows down execution. > > As an example do the following: > > parent > + pom.xml > - Configured to use `maven-compiler-plugin' = 1.8. > - Contains property for `netbeans.hint.jdkPlatform' = JDK_1.8. > + child > + pom.xml > - No configuration present to represent any JDK, refer to super pom. > + nb-settings.xml > - configured to use JDK7 > > In the above you will find that the nb-settings.xml for child project should > be ignored, since the parent should override it. No, actually it's the other way around. Closer definition wins. We've added the nb-configuration.xml file into play but it's the same with pom.xml. Eg. imagine that we would edit pom.xml only. your child project would still reference JDK7 because that's what the property in child project would hold. > > Being IDE generated many users might not understand what's going on, and > find it hard to figure out why the IDE keeps telling them they can't use > language features when they change to a newer JDK. > > Avoiding nb-configuration.xml would solve this where possible. as I pointed out above it would not solve the problem, might only make debugging easier, but in general once you let people edit individual projects (in a large multiproject) there's no way for the IDE to know 1. where to write changes 2. when to forbid editing The IDE handles each project as an individual unit, missing the big context, but that's IMHO ok. People know the big context.
But in maven, you can't have a different JDK in a child project to it's parent, that would imply half way through the build maven could magically change the JDK per child project. That's why I say, if the JDK is set in the parent, it should be ignored in all child projects.
(In reply to brettryan from comment #4) > But in maven, you can't have a different JDK in a child project to it's > parent, that would imply half way through the build maven could magically > change the JDK per child project. That's why I say, if the JDK is set in the > parent, it should be ignored in all child projects. well, you can. We assume each project (pom.xml) to be independently buildable. aslo please note that the child->parent relationship doesn't always mean source->source locations, but sometimes source->repository (with released parent versions) and both can keep changing. In general I don't see the current behaviour changing any time soon. it's a pattern that's been working for a while without much complaints, could be suboptimal for jdk settings but it's better to keep the behaviour consistent IMHO.
Then it must be a bug in Netbeans. Steps to reproduce: 1. Create a parent project with pom.xml configured for JDK 8 source 1.8 2. Create a child project with JDK 7 set in nb-configuration.xml but source in pom.xml to 1.8 3. Open project configuration for child project, it will report JDK of JDK8, source 1.8. This is what prompted me to open this in the first place. As everywhere in the IDE it was telling me the project was for 1.8, yet the source editor would not allow me to write lambda expressions, telling me that the source level was 1.7.
I'm not able to reproduce. I guess I'm doing something wrong. Can you attach a sample project demonstrating the problem? One possible culprit is that changes done in parent pom are not immediately visible in child projects and manual "Reload POM" action execution might be required. We don't listen on parent project changes and keep the old module until something changes with the current project pom.