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.
Java Project Common API module should contain code which is more or less copy-pasted from J2SE project type to Java EE project types (Web, EJB, AppClient project types). This module should provide friend API for all the project types. The first phase includes SourceRoots, UpdateHelper and different *Query implementations, e.g. FileEncodingQuery. The next phase is focused on class path, but now it's still work in progress (because of shared libraries). I will attach javadoc and patch. I'm also going to push code related to class path but these packages are not public yet and of course another API review will be done for it after the changes are finalized. I can provide the whole hg bundle if needed.
Created attachment 56088 [details] proposed patch
Created attachment 56089 [details] javadoc
Created attachment 56230 [details] hg bundle (attaching after discussion with Tomas Zezula)
[JG01] Not sure if you care, but: UpdateHelper/Implementation do not look like they could be used to implement automatic selection of project.xml schema version according to XML validation the way ant.freeform does. For that to work you would need to have the Element of the proposed new XML content available when deciding which version to write out. [JG02] Some classes, for example ClassPathItem, have no Javadoc. [JG03] Delete the empty XML layer. BTW maybe I'm missing something, but diffstat (will attach) does not report much actual reduction in the total amount of code as a result of this patch. Might just be incorrect reporting.
Created attachment 56270 [details] Diff stat of patch
[JG01] In fact, you are right. In this step I just wanted to remove duplicity and create only one UpdateHelper. Moreover UpdateHelper should be integrated into AntProjectHelper and so there will be more work on it (see issue #122655). [JG02] Yes, I know that some classes don't have Javadoc - but all these classes should be in non-public packages. These classes are work in progress and will be probably more or less changed because of shared libraries. That's the main reason why I cannot remove duplicates in project's class path files. [JG03] Empty XML layer removed. Should I upload new hg bundle? Just this one change made. To diffstat: your diffstat belongs to the whole hg bundle - without class path related code the number is about 4600 lines "better". The reason why pushing this code as well is explained in the initial post. Thank you Jesse for your comments.
No need for a new bundle just because of JG03.
If there are no objections, I'll integrate tomorrow. Thanks.
I have no objections, all of them was solved during the design of the API. Please, integrate it.
It is refreshing to see so much removed code while the functionality removes the same. Y01 Imho SourceRoots shall not be an interface, but a final class (at least I do not see anyone directly implementing it). Making it a class will allow future extensions of its methods and potentially behaviour...
Y01 Yes, probably good idea - I will do it, not big change. Thanks for review.
Pushed to main.
By the way you neglected to include this issue number in any of the commit log messages that I could see, making it hard to find this issue. You might have missed some impls - at least EarSources.java looks like it could use this API.
*** Issue 63679 has been marked as a duplicate of this issue. ***
> By the way you neglected to include this issue number in any of the commit log messages that I could see, making it > hard to find this issue. Yes, that's true but - in which commit log should the issue number appear? It was quite many commits so - in the last one? In the merge commit? I was thinking about it but didn't see any correct solution - what's the right way how to do it? Thanks for any suggestion. > You might have missed some impls - at least EarSources.java looks like it could use this API. Yes, could be. There are many nearly copy pasted classes in our project types... :/ In fact I focused mainly on Web, EJB and AppClient project types because EAR project is quite a lot different. Thanks for catching it Jesse, I will look at EAR project soon.
You could I guess mention the issue # in the first commit adding the basic source files. There is no apichanges.xml for the module, which would normally be the place to put an initial entry "API added..." mentioning the issue. Since it's a friend API only, this is not so important though.
> You could I guess mention the issue # in the first commit adding the basic source files. I will try to do it next time (the problem here is that this issue was filed when I was nearly finished). > There is no apichanges.xml for the module... I can add it if needed.
*** Issue 126740 has been marked as a duplicate of this issue. ***