Although I am not working anymore with webobjects but with more recent technologies I was still the one who did the last updates on the wolips-project. And therefore here is my opinion about the discussion of work to be done on the wolips-plugin:
As you can see in the commit-history for my account "Wolfy42" (https://github.com/wocommunity/wolips/graphs/contributors) there was some annual necessary. The reason for that was that the wolips-plugin is based on the completely outdated eclipse e3-platform. Since around 2012 all new versions of eclipse are based on the e4-plaform. Eclipse knowns that not all plugins are actively maintained and the upgrade to the e4-platform can be a lot of work and therefore there are a lot of compatibility-layers which could be applied so that also old plugins are capable of running in new releases of the platform. That was the annual work I was doing in the wolips-project. But this compatibility-layer is also the reason why the plugin is rather slow and that it is possible that there is more annual work necessary. Every year there is a new version of eclipse with the possibility to break a lot of old plugins ... I think it would be relevant to break down the parts of wolips and consider which part should be maintained or updated. I think the major parts of the wolips-project are: * The Component-Editor with the Binding-Validation: I think this is the most relevant part and should be completely updated with a current HTML-Editor and it should be upgraded to the e4-platform. And the race-conditions in the binding-validator should be fixed. If you look at the amount of "synchronized"-keywords in the binding-validation-code it should be consider to rewrite it from scratch. The ruleset how the bindings have to be validator can still be reused * Hot-Code-Replacement (=automatic component-class-reloading) after changing the components. This is a very relevant part and should be automatically available without the need of third-party-technologies like JRebel * The EO-Modeler: This is still a relevant part when working with existing projects but there are other good database-domainmodel-modeling-tools out there. It should be considered if one of them should be extended to just generate the .plist-files and .java-files necessary. Maybe even the cayenne-modeler could help here because I consider cayenne to be a modern version of EOF * The EO-Reverse-Engineer-Tool: This should be completely ignored because no new project should be started with EOF. If someone still wants to use webobjects than at least the database-layer should be based on cayenne or JPA-Hibernate. * All the "wizards": The only wizard necessary is the one to generate new Components (all the .wod, .woo, .api and .java-files necessary). All other wizards are irrelevant * All the "refactorings": The only one relevant is the one to rename a component (=rename all the files/folder in one step). The other ones are not relevant. Although webobjects is long dead and not maintained for 12 years now there are still some great and maintained projects built with webobjects out there and therefore it is relevant to have a a good development-environment. Although sometimes I had the feeling that my eclipse was hating me it is still a good IDE. Best Regards, Wolfy ________________________________ Von: Paul Hoadley via Webobjects-dev <webobjects-dev@lists.apple.com> Gesendet: Freitag, 3. Juli 2020 11:33 An: Hugi Thordarson <h...@karlmenn.is> Cc: WebObjects-Dev <webobjects-dev@lists.apple.com> Betreff: Re: WOLips bugfixes and new features planning On 2 Jul 2020, at 20:25, Hugi Thordarson via Webobjects-dev <webobjects-dev@lists.apple.com<mailto:webobjects-dev@lists.apple.com>> wrote: Many of the issue reporters are still with us. I suggest announcing a short grace period where people can look at their own issues (and other issues, of course) and add the "keep" label to issues they want to keep. When that grace period expires, all unlabeled issues are closed. Worst case scenario: We have to re-open a closed issue. Most users probably get an e-mail notification when their issues are closed anyway so they can complain at that time :). I support this approach. Issues that aren't actionable for any of the reasons you describe should be closed. Regarding funding, I would be very willing to operate on some sort of a "per feature/issue" basis. I.e. I'd dedicate a fixed amount of money to the resolution of an issue. Perhaps that also solves the problem of prioritization? I'm guessing the issues most valuable to the community will end up being the ones with most funding attached to them. My preference would be prioritised list + pool of money → work on the list until the money runs out (just because it's simpler). But I'd participate in your system too if you want to run it. Regarding specific issues, there's one issue I'm *really* interested in: I've attempted to do WOLips development on some occasions but always gave up since I didn't get everything to work (the docs are kind of convoluted/outdated). Perhaps I'm just stupid, but if not; I believe we would benefit greatly from having a functional, up-to-date step-by-step guide for how to do development on WOLips. Teach a man to fish and all that :). This would be good. -- Paul Hoadley https://logicsquad.net/ https://www.linkedin.com/company/logic-squad/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
