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.
Created attachment 149898 [details] The initial dependency fix sketch The client HTML project is about to be reused in other contexts, for example in node.js case and it would be great if we could open any node.js projects out of the box. One way to achieve that is by (auto)generating the essential meta-data in nbproject behind the scene. The other way is to remove the direct dependency on Ant support and make the communication with the disk & co. pluggable. This issue has been created to investigate "pluggability" possibility.
Whether or not the proposed removal of Ant dependency makes sense should be subject to design discussion, so I am adding API reviewers on CC, in case they want to participate. Of course Tomáš M., as a maintainer of the module, needs to be comfortable with my proposal at first place. What the diff does? It removes dependency on ant support and then it recreates all the necessary classes in the "indirect" package in the module. It of course needs to change imports in all the classes. The next step, in my opinion, is to implement the "indirect" classes to delegate to real Ant implementation. Then the module should behave the same as now, while giving us a chance to experiment with different storage options than Ant one. I'd like to discuss my proposal and if it seems to make sense, create a branch where we could polish its rough edges before final review.
Adding Tomas to CC, I guess he could be interested in this issue. Thanks.
TM01: The "indirect" package should be in its own module so other project types (e.g. PHP) can use it as well. This can be done later, I guess.
Let's have an inception meeting on Tue, Oct 21, 1pm. Everyone is welcomed to come or call in (ask me for a phone number). Prague meets in Giza.
I've created branch http://hg.netbeans.org/web-main/rev/5b04064f7ac3 in web-main, so Tomáš M. can watch my changes easily.
Thanks Jardo.
This is the diff of my changes as of today: http://hg.netbeans.org/web-main/rev/2a6a2ee8b695 All the dependencies to Ant (except one from UI) has been moved into *.ant package. The rest of the module communicates with this package via *.indirect interfaces. I can create new project, Run it, open its properites, etc. I will find out how to run UI commit validation for the clientside project and check its results later today. To recap the great plan (having HTML functionality without dependency on Ant) and steps how to get there: 1. concentrate Ant related functionality to a single place. Use indirection to access it. Keep the naming as close as possible. 2a6a2ee8b695 is basically it. 2. Verify the changes are sane, merge into main and start refactorings. We don't want the indirect interfaces to keep names of the old Ant onces. We may want to simplify the set of interfaces a bit. Doing such changes on a branch would clash with changes in main development line. So do the renames, moves, etc. in main development line. 3. Create a branch to investigate possibility of storing the project information in alternative formats like package.json. Improve the *.indirect interfaces where necessary. Review. 4. Address TM01: e.g. turn the *.indirect interfaces into an API that other project types can use as well and get rid of Ant dependency too.
TM02: Just curious - would it be possible for new HTML5 projects switch to another "backend" (e.g. package.json) without breaking the existing ones (Ant-based)?
TZ01: Goal is to abstract java.api.common QuerySupport into project.common and use it in php, web, js & etc. TZ02: When bridging between PropertyEval <-> PropertyEval don't create too many new instances. TM03: Search for string "nbproject" in sources. TZ03: Keep UpdateHelper in mind and eliminate it in the new API Integrate #1 and #2 as soon as possible (after all unit & qa tests are passing and qa verification). Integration of #3 and #4 is for post 8.1 release. Approved.
I am open to help with #3, #4 in NB 9.0.
Created attachment 150023 [details] Resut of qa-functional test run on default branch (without my changes)! Result of $ cd web.clientproject $ ant clean test on a default branch is attached. It seems to have five failures and one error. Can somebody responsible for the UI validation comment on the state of the test run? Is it correct to get these errors? I am running on Linux Kubuntu, 14.04, JDK1.7.0_67-b01. Should I use some different configuration?
You can ignore that. The XHRDebuggerTest is not being run right now because this feature does not work on JDK7 (embedded browser from JDK7 does not support XHR breakpoints). The RefreshTest and InspectionTest have random failures (the main reason they are being executed twice a day...). The problem is that communication with embedded browser is a bit fuzzy, based on JavaScript events so it sometimes fails.
Created attachment 150026 [details] Version of the web.clientproject from the RemoveAntDep247927 branch (changeset 9198bdbc9a90) for testing
Thank you Jardo, I'll give it a try today and let you know.
So far so good but due to other P1 issue I haven't tested everything yet. I'll finish it on Monday morning.
The nbm seems to be fine. I've tried creating/running projects, project actions, Less/Sass compilation, JS testing, Grunt, NPM, Bower etc. and I haven't found any issues.
OK. I merge now into ergonomics.
Integrated into 'main-silver', will be available in build *201410290913* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/5ce936688863 User: Jaroslav Tulach <jtulach@netbeans.org> Log: Merging in #247927 work from RemoveAntDep247927 as it has been tested by vriha@netbeans.org and seems to be stable enough.
TM04: I guess that ProjectUtils needs to be tested as well, especially getAuxiliaryConfiguration() and getPreferences() methods. Thanks.
(In reply to Tomas Mysik from comment #19) > TM04: I guess that ProjectUtils needs to be tested as well, especially > getAuxiliaryConfiguration() and getPreferences() methods. Just to clarify, this applies to point #3 (see comment c#7). In other words, alternative storage needs to support key-value as well as XML storage.
> Integrate #1 and #2 as soon as possible (after all unit & qa tests are > passing and qa verification). Name polishing (e.g. #2) done in: https://hg.netbeans.org/web-main/rev/603ad267c9f1 > Integration of #3 and #4 is for post 8.1 > release. Closing the issue. Subsequent work will happen on a branch and be tracked independently.
Integrated into 'main-silver', will be available in build *201411130002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/6572641ba9de User: Jaroslav Tulach <jtulach@netbeans.org> Log: #247927: No need for the event class
Integrated into 'main-silver', will be available in build *201411140002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/6572641ba9de User: Jaroslav Tulach <jtulach@netbeans.org> Log: #247927: No need for the event class