Simon IJskes - QCG wrote:
On 08-11-12 13:40, Peter Firmstone wrote:
Yes, but lets play around with it in skunk. Dan's made some valid
Indeed Dan has made valid remarks, but i really dont like skunk. Tom
suggested sub projects once. I did not see any benefits at that time.
But i think it might be helpful right now.
We could use the subprojects as 'clients' to the core, and allow
requirements of these subprojects drive the modifications of the core.
We can decide whatever status a subproject will have, and we do not
make them heavyweight. Just an extra jar, an extra libs and an extra
src in a directory together.
I'm thinking about osgi, wan, internet, jmx transports etc. We treat
the sub projects as first class citizens, and do proper release
management on them. Just not that often.
Am i still thinking too grandiose Dan?
Gr. Simon
Ok, because it's small I think we can consider it, can you provide the
hooks to load different providers? The non default providers themselves
can be a subproject. We need to carefully consider security since we're
making it possible for downloaded code to resolve classes.
My SecurityManager and policy providers were developed in skunk, then
merged. URI changes were made in trunk, although this was a big change
semantically, the code footprint is small. For large changes to
foundation code we need skunk, not everything can be bolted on or
plugged in.
Cheers,
Peter.
