Hi Tamás, Good to hear from you again :) I hope all is well over at Sonatype - I know I enjoy using Nexus with the ASF and at work - great job!
But I hear you - the biggest change that needs to occur is to get rid of the deep hierarchy you mention and definitely clean up the internals. And yes, any format I talk about (groovy, YAML, etc), would definitely be a default implementation of a pluggable interface so integrators like yourself could easily swap things. Did you have any ideas on how you the 'configuration source API' should function? I think you or Kalle (or both!) might have mentioned a proposed new architecture for the configuration components a few months ago - my memory is a little fuzzy on that at the moment. There is already the Configuration interface, which I thought was the 'configuration source' API you mention. Is there something else we could/should use? All comments welcome! - Les 2009/9/4 Tamás Cservenák <[email protected]>: > Well, I would object it :) > > I had a lot of trouble tampering with it in Nexus (yes, it was JSec > 0.9, i bet a lot of things changed since then). Major problem for me > back then was that configuration (the "ini" one) was processed/stored > in very deep class hierarchy, and I had to do a lot of trickery to > tamper with it. > > I would first extract the configuration into some form of > "configuration source API" (even a trivial one). So, in short, I would > not go "on direct path", but introduce some level of indirection, and > would leave to JSecurity consumer to decide where he want's to go. I > prefer Scala over Groovy ;) > > And finally, yes, the "reference implementation" for that API could be > done with Groovy, but you would not impose any lock-in for > integrators. All the "fancy" stuff (like circular path detection, > lifecycle) should be delegated to API implementors (and re-implemented > in the "default" Groovy one), since almost all environments (Spring, > J2EE, Pico, Guice, Plexus) do support those, but naturally, in vastly > different -- and usually incompatible -- ways. > > > ~t~ > > On Fri, Sep 4, 2009 at 8:02 PM, Les Hazlewood<[email protected]> wrote: >> What about using Groovy as the default configuration format? Then an >> end user would be building a real object graph and still has the >> ability to call whatever lifecycle methods they want. And, Groovy >> allows natural Domain Specific Languages if we want to leverage that. >> And our end-users would be able to easily understand it, with little >> or no learning curve. Finally, groovy syntax is really clean and easy >> to follow. >> >> And the only additional dependency would be the groovy .jar. >> >> I like it! Does anyone have any thoughts about using (or not using) Groovy? >> >> - Les >> >
