On Fri, Jan 21, 2011 at 11:13 AM, Andreas Andreou <[email protected]> wrote:
> On another note, i'm not sure why tapestry-upload needs a separate subproject > (one can manually exclude commons-fileupload) That's a good question... > As Howard said, it's probably not trivial to split core, esp. in so many > pieces > and indeed i too believe those where a lot! But that doesn't mean everything > new should reside in core either. I tested on my own skin to hack on core to remove, modify, change behavior of particular components within -core and failed, they're very tight (I'm talking about Bean* Grid* and similar). So I guess there are practical reasons. After that practical boundaries are fallen then it could be a value to separate components _but_ there should remain a library with the core components and that's would comprehend all typical form components at least. But the discussion on how to separate should come after some work on components. > Another issue about separate subprojects is separate releases (and > versions). As i > understand it, most devs are against this - but it also feels this > kills one of the > benefits of separate projects. Does anyone see any value in making this work? I would like to have separate release engineering for the various project within Tapestry. With dependency management in place it will make life easier even for new committer and/or new contributors. Bringing in some stupid example think the difference between git and svn as a source management. > How about building something like an appstore for components/projects? I don't dare to comment on this one it just seems a bit too early. My .02 euros -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
