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.
Karma configuration file path should be kept in project.properties instead only at private.properties. Not just it, but it should support relative path too. I would like to commit this configurations and keeping it just in private.properties file is not possible. I tried to copy the properties to project.properties file but they are not read from there. The Karma executable path should accept relative path too but could be kept at private.properties (be unique per developer). The same is true about watch files property. It will keep sane the configurations across workstations even when developers use Windows or Linuxes boxes.
I would like to highlight that using relative paths directly in the properties files works. The issue looks like to be only in the UI.
Again, paths are stored as relative ones; attach you project.properties and reopen this issue. Thanks.
Created attachment 146920 [details] Sample project This project has some on purpose issues. First thing, please just fix the Unit Tests and Config folder configuration, just selecting the folders test and config respectively, already create at project's root folder. When you save the configuration, you can see that private.properties file is update to the totally qualified paths for Karma configuration. project.properties file has no Karma configurations, and as described before, I understand why, but at least private.properties configuration should support relative paths. I hope now it is clear. Just let me know if you need any other information.
(In reply to Michel Graciano from comment #3) > When you save the configuration, you can see that > private.properties file is update to the totally qualified paths for Karma > configuration. And what is the problem here? File private.properties is for NetBeans only so it is totally OK that there are full paths here. > at least private.properties > configuration should support relative paths. Why?
IMHO the Karma configurations should be available to commit. I understand private.properties is not supposed to be that file, so as stated in the issue, some Karma configuration should be kept in project.properties. These 3 properties should be available at project.properties file: auxiliary.org-netbeans-modules-javascript-karma.autowatch auxiliary.org-netbeans-modules-javascript-karma.config auxiliary.org-netbeans-modules-javascript-karma.enabled Because it is supposed to be possible to have all these properties available to whole team. I don't want to keep this configurations in each workstation and have to configure it for each new developer we integrate to the team. I hope now it is clear what I needed in the first place :) One of the best things I advocate about NetBeans is the ability we have to keep as much information about the project committed as possible. It makes really easy to integrate new developers to the team, because everything is available out of the box, no additional (ou minimal) configuration is needed.
I have tested with an updated IDE version. Product Version: NetBeans IDE Dev (Build 20140422-549e28a599af) 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
If I understand correctly, the problem here is that the absolute paths are in your VCS, right? How have you created your repo, it wasn't using NetBeans, correct? ;) If you use NetBeans, you will find out that the whole "nbproject/private" directory is ignored and therefore it is not part of the repo. So, your problem can be easily solved - just remove nbproject/private directory from your VCS and you are done (each NetBeans instance will create it automatically once it is needed). If I am wrong, feel free to reopen this issue but please, provide *exact* steps to reproduse, e.g.: - create project - do this - do that - ... Thanks.
Everything is created using NetBeans. The project actually is a Maven Web Application but we want Frontend developers to use NetBeans too, but not the maven project, they use nodejs for it, so we want to have the HTML5 working up these project too. Basically what we need is to keep Karma configurations on VCS, and today it is impossible because private folder is ignored as expected. I have tried to include the properties auxiliary.org-netbeans-modules-javascript-karma.autowatch, auxiliary.org-netbeans-modules-javascript-karma.config, auxiliary.org-netbeans-modules-javascript-karma.enabled in project.properties file but it is ignored. The IDE just read from private.properties these properties. The issue here is that I need those properties available at project.properties too, as all other relevant properties. The steps to reproduce: 1. Create a HTML5 project 2. Configure Karma to be executed 3. Take a look at project.properties file, no karma properties there, so no karma properties in the VCS. BTW, those properties are the first ones I have seen in years with NetBeans that have UI and are stored just in private.properties file. I have tested it in 8.0 FCS and my local build, with the same result.
Well, this works as designed so it is not a bug. The idea behind it is easy: usually more developers work on the same project but not all developers work on all areas, so, e.g. for me, as a Java developer, Karma tests are not interesting and I really don't want to run them. Now, this scenario is supported. If we do what you ask for, this scenario will be impossible. Frankly, every developer needs to setup Karma *just once* so we are not going to implement this in the near future, sorry. Feel free to provide valid reasons why we should do it, but I have not read any so far, sorry... Thanks for reporting.
BTW we would need to add a checkbox "Store Karma properties for this PC only" or similar.
(In reply to Tomas Mysik from comment #9) > Well, this works as designed so it is not a bug. The idea behind it is easy: > usually more developers work on the same project but not all developers work > on all areas, so, e.g. for me, as a Java developer, Karma tests are not > interesting and I really don't want to run them. Now, this scenario is > supported. If we do what you ask for, this scenario will be impossible. First think I want to make clear, I am talking about HTML5 Application with Existing Sources project type. Well, I am sorry to say but this approach design has flaws and that is the point I have filed this issue. If this design does not support a simple team as ours here, so I can't imagine how it is for a bigger team. It is necessary to setup it for every HTML5 project which is frustrating. IMHO it is unacceptable. If I expand this rationale, I suppose you are going to refactor all Java projects and remove JUnit/TestNG tests configuration and test classpath just because not every developer are interested in that? I suppose not. IMO if you are opening a project and are not interested in tests right now, you just don't run it. What harm could it have if the default configuration are already defined? I can't see any. The point here is to make as simple as possible the team setup. If we follow your rationale, code formatting should be removed too, because a Java Developers just won't write code in this project? It just does not make sense to me. We have create here the HTML5 just for the frontend developers, and they are interested in JS tests. For Java Developers, we can use the Maven Java Web project, which have the Java and JS source files, but only Java tests configured. When we, Java developers, open the HTML5 project is because we are using the frontend developer 'hat' and are going to make maintenance in this code base, so tests are important. For me, the whole point about HTML5 project is support frontend developer, so we need to focus on them. The only option I think we really could keep as 'this PC only' is the karma executable, because it is different for Windows and Linux. I think there is no easy way to solve it, so I think when necessary, the developer will need to configure it. But I think your idea to have a option for this is really useful. > Frankly, every developer needs to setup Karma *just once* so we are not > going to implement this in the near future, sorry. Feel free to provide > valid reasons why we should do it, but I have not read any so far, sorry... > > Thanks for reporting. You are welcome. I hope the points stated before make you change your mind, because the approach taken here is totally in disagreement with the IDE move in the past years, where as much as possible configuration were moved to the project configuration, as code formatting, hints and so on. I won't change it to bug neither the priority, but I should argue that it is a P3 because it is not a minor usability flaw and 'result in a bad impression of Netbeans' usability' just to cite one point in the wiki page. (In reply to Tomas Mysik from comment #10) > BTW we would need to add a checkbox "Store Karma properties for this PC > only" or similar. I totally agree with it mainly for Karma executable, but could be applied for every Karma related property.
(In reply to Michel Graciano from comment #11) > It is > necessary to setup it for every HTML5 project which is frustrating. IMHO it > is unacceptable. > If I expand this rationale, I suppose you are going to > refactor all Java projects and remove JUnit/TestNG tests configuration and > test classpath just because not every developer are interested in that? No, why? This is something different. I already explained it before (server vs. client side tests). > What harm could it have if the > default configuration are already defined? I can't see any. Again, as I wrote - if you have more Karma configs (this can easily happen, see e.g. AngularJS sources), then changing a Karma config will mean a change in your sources (I mean in your VCS). Do you think it is OK? BTW there is no such thing (configuration) for Java/PHP/etc. tests. > The point here is to make as simple as possible the team setup. If we follow > your rationale, code formatting should be removed too, because a Java > Developers just won't write code in this project? No, formatting applies for all developers of the given project; Karma configuration does not. [the rest of your comment omitted, sorry - it is toooo long :] > I totally agree with it mainly for Karma executable, but could be applied > for every Karma related property. I will do it soon and it will be part of some Patch for NB 8.0 (unfortunately, it is too late for Patch 1). BTW do you have an idea for the label of the checkbox? Something like "Store properties only for the current PC" or the opposite "Share properties with other developers"? Thanks.
> > I totally agree with it mainly for Karma executable, but could be applied > > for every Karma related property. > > I will do it soon and it will be part of some Patch for NB 8.0 > (unfortunately, it is too late for Patch 1). BTW do you have an idea for the > label of the checkbox? Something like "Store properties only for the current > PC" or the opposite "Share properties with other developers"? > > Thanks. Hi Tomas, thanks for evaluating this again. I understand your point and I think we can assume that properties can be shared. I know that karma executable will be controversy but since we gonna have the option for the user choose to share it or not, it will work fine. If you permit, I vote for "Share Karma properties with other developers" or "Share this properties with other developers". I personally prefer this kind of thinking. Thanks in advance
BTW one problem with shared properties could _definitely_ be with the Karma executable path - on Windows, karma.cmd is used but on *nix, only karma exists.
Now, Karma path is not present in Project Properties anymore so we should reconsider this issue. @marfous: Martine, what do you think please? Do you think thatProject Properties of Karma should be private or public or should we let user decide? Thanks a lot.
(In reply to Tomas Mysik from comment #15) > Now, Karma path is not present in Project Properties anymore so we should > reconsider this issue. > > @marfous: Martine, what do you think please? Do you think thatProject > Properties of Karma should be private or public or should we let user decide? I wouldn't not do them public. There are properties which looks user specific - different browser or debug/not-debug mode. At least in multiuser setup it looks to me very reasonable to keep it private, otherwise developers would overwrite them each other.
Yes, I totally agree. So, closing again as INVALID. Thanks.