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.
In order to find out how big amount of our users is using the Hudson integration, possibly Kenai and Hudson integration, please log some (anonymous) information about their setup. Things to log - how much hudson servers or jobs is observed. How many projects is directly associated to hudson server, the type of hudson associated project. More info at http://logger.netbeans.org/ or http://wiki.netbeans.org/UIGesturesCollector
Also, Usage Logging [1] should be added as well. [1] http://wiki.netbeans.org/UsageLoggingSpecification
According to UIGesturesCollector it is superseded by UsageLoggingSpecification. Do we really want to collect logs in both ways, or can we just use the apparently newer system?
Created attachment 114094 [details] proposed patch Patch for both types of statistics.
(In reply to comment #3) > Patch for both types of statistics. Also, Usage Logging wiki page [1] needs to be updated. [1] http://wiki.netbeans.org/UsageLoggingSpecification
Can use @Messages to define the bundle key, even if not using the generated method; at least keeps the key close to the source code. Cannot be fully type-safe without JDK 8 method handles I guess. I do not understand why we need both logUI and logUsage. UsageLoggingSpecification seems newer so why do we not use just logUsage?
logUsage is a fork of the original project. Initial fork is no longer maintained (for a while statistics.netbeans.org was the only source of info we had). I've heard that the group related to the original fork did yet another fork and tries to create new server for some reason (rather than joining efforts with statistics.netbeans.org). As original creator of the project I recommend everyone to stop supporting forks and donate to the statistics.netbeans.org as described here http://wiki.netbeans.org/UIGesturesCollector and here http://wiki.netbeans.org/HowToUseUIGesturesCollectorInYourApp Doing so will have one important benefit: The statistics.netbeans.org is essential for NetBeans QA, 99% available, accessible without intranet and running for more then five years. Contributing to this project guarantees your work will not be lost.
(In reply to comment #6) > logUsage is a fork of the original project. I don't think so since logUsage does a different thing; Honza can provide more information, of course. > Doing so will have one important benefit: The statistics.netbeans.org is > essential for NetBeans QA, 99% available, accessible without intranet and > running for more then five years. Contributing to this project guarantees your > work will not be lost. IMHO the only problem is that the output is different from what statistics customers expect. Again, Honza and Petr J can provide more information.
Created attachment 114147 [details] improved patch Using @Messages.
(In reply to comment #5) > Can use @Messages to define the bundle key, even if not using the generated > method; at least keeps the key close to the source code. Cannot be fully > type-safe without JDK 8 method handles I guess. Fixed.
Commit when ready - I guess you will wait for some more information about whether we should be sending to both loggers or just one. This needs to be mandated product-wide. Consider making UsageLogging into an API somewhere - it seems this utility has been copied a bunch of places.
(In reply to comment #10) > Commit when ready - I guess you will wait for some more information about > whether we should be sending to both loggers or just one. This needs to be > mandated product-wide. Well, who can/should do such decision? In fact, I tend to commit the patch as it is since we have this situation from NB 6.5, AFAIR. > Consider making UsageLogging into an API somewhere - it seems this utility has > been copied a bunch of places. IMHO we already have a good candidate: LoggingUtils in maven.j2ee. I guess it should be in the IDE cluster but not sure in which module, class - any ideas?
(In reply to comment #11) > Well, who can/should do such decision? Engineering managers I suppose. > I tend to commit the patch as it is since we have this situation from NB 6.5 OK with me. Can always be cleaned up later if necessary. > we already have a good candidate: LoggingUtils in maven.j2ee. I guess it > should be in the IDE cluster but not sure in which module, class - any ideas? Not sure. Might need to be in platform cluster. Could be filed as a separate API review.
Patch applied, Usage Logging wiki page updated as well. http://hg.netbeans.org/web-main/rev/2cb9d02fe3ce (In reply to comment #10) > Consider making UsageLogging into an API somewhere - it seems this utility has > been copied a bunch of places. Not sure where exactly this issue could be filed - if anyone has an idea, please, do so. Thanks.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/2cb9d02fe3ce User: Tomas Mysik <tmysik@netbeans.org> Log: #172913 - Log UI Gestures about Hudson usage