Re: WOLips bugfixes and new features planning
Re: WOLips bugfixes and new features planning
- Subject: Re: WOLips bugfixes and new features planning
- From: Maik Musall via Webobjects-dev <email@hidden>
- Date: Wed, 18 Nov 2020 10:02:44 +0100
Hi everyone,
we’ve had a long period of procrastinating about how to prioritize issues and
the way to proceed, so I’m making a proposal here and need your feedback on it.
It seems to me that Wolfy’s input in the email from July cited below is the
best starting point, because all other lists of things we have are much less
coherent/complete/up to date [1][2][3]. From that, I’d say that the component
editor with binding validation, it’s upgrade to the e4 platform, and bugfixes
in that is prio 1, and everything else is up to be voted upon.
We need a sample application complex enough that most of the relevant parts of
WOLips is touched when working on it, so that the plugin developer has an
actual piece of code to test WOLips on. It should be something using most of
the components and EOF. Who volunteers to identify one and prepare it for this
task?
Then we need to collect the actual money from everyone who agreed to
contribute, which so far were: Selbstdenker AG (the company I work at), Hugi
Þórðarson, Henrique Prange, Paul Hoadley, Philippe Rabier, Mark Morris, Markus
Stoll, Theodore Petrosky, Michael Kondratov, Martino Limido, and Miguel Angel
Torres Avila. From all of you (and obviously everyone else who decides to
participate in this) I need an email (public or private) mentioning the amount
you are willing to spend, a VAT number (if applicable), and optionally a note
explaining on which part of this effort it is to be spent. We will then send
back an invoice with that amount which you can pay, and have the plugin
developer start working on it. Payments will be possible via SEPA transaction
or PayPal. We will then pay the developer from that money.
I’m hoping that with those notes attached to the money we’ll already have some
priorities that we can assign to the remaining topics. If most of the money
comes in without appropriation and enough of that is left after completing prio
1, we can somehow vote on it. Either way I’ll update you here about how things
are proceeding.
If some money is left over after this is finished, we can pay it back to the
contributors, invest it into new features or other improvements, save it for
future fixes and adaptations, or whatever else we come up with.
What do you think?
Maik
[1] github.com/wocommunity/wolips/issues
[2] wiki.wocommunity.org/pages/viewpage.action?pageId=43155458
[3] Google Docs Tabelle (1Vny…I2M)
> Am 07.07.2020 um 21:47 schrieb Wolfgang Hartmann via Webobjects-dev
> <email@hidden>:
>
> 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 <email@hidden>
> Gesendet: Freitag, 3. Juli 2020 11:33
> An: Hugi Thordarson <email@hidden>
> Cc: WebObjects-Dev <email@hidden>
> Betreff: Re: WOLips bugfixes and new features planning
>
> On 2 Jul 2020, at 20:25, Hugi Thordarson via Webobjects-dev
> <email@hidden> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden