estebanlm at gmail.com
Wed Nov 23 11:42:43 UTC 2011
I think we need to start deconstruct the "huge beast" it is VMMaker right now, and that means at first instance split the package in smaller parts.
No reason to have all plugins (newer, older, living, obsolete) in just one package.
But also, it would be good (IMHO) to have all plugin packages grouped in just one repository (same VMMaker repository) and easily installable with a ConfigurationOf... (now we have metacello, no reason to use hand made scripts)
If all agree in this, I can work a little on the split process (not right now, but in this weeks :) ).
El 23/11/2011, a las 6:00a.m., stephane ducasse escribió:
> for modular thinking.
> What is fun is to see the Klatt plugin still there.
> I'm sure that there are pluggin that could be removed too.
> On Nov 23, 2011, at 7:06 AM, Colin Putney wrote:
>> On Tue, Nov 22, 2011 at 7:00 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>>> (Note that the alternative would be to remove DSAPlugin from VMMaker
>>> and reference the copy in Cryptography, but the plugin does not seem
>>> to have changed in over a decade, so it's probably best to leave it
>>> where it is in VMMaker)
>> Why is it best to leave it in VMMaker? Do other parts of VMMaker have
>> hidden dependencies on DSAPlugin?
>> It's going to be inconvenient for the cryptography team to delete
>> their copy of the DSAPlugin and then maintain 3 plugins in their own
>> package, and 1 more in VMMaker. In fact, I'd like to see more plugins
>> being maintained and distributed independently of the VM. What's the
>> point of having a plugin architecture if plugins are tightly bound
>> into the VM anyway?
>> If there are issues with moving plugins out of VMMaker, let's figure
>> out what they are and fix them!
More information about the Vm-dev