On Fri, Jan 16, 2009 at 1:04 PM, ant elder <[email protected]> wrote:
> > > On Fri, Jan 16, 2009 at 12:28 PM, Simon Laws <[email protected]>wrote: > >> snip.... >> >>> >>> Yes that what the current compact distribution does, its in 1.x right now >>> as there's few extensions going in 2.x but there should be no problems with >>> doing it there too. >>> >>> ...ant >>> >>> I looked at the compact distro in 1.x and the distro projects in 2.x and >> this is what I found: >> >> Key >> Plain text = common between the two >> [] = different between the two >> * = my opinion >> >> A set of maven modules which define dependencies for features >> [in /modules or /distribution] >> * I prefer /distribution as the feature modules are not providing any >> new function > > > There's pros and cons, where they are right now enables a facility i've not > mentioned yet but the where they go is not big deal at the end of the day. > > >> >> Samples depend on only the feature modules that they require >> >> An "all" distribution that ships all features >> >> [separate distributions that ship individual features] >> * I don't mind having them if people want to support them. > > > The problem with doing that is it adds some significant complexity, from > things like the download page, to things like the documentation for samples > and how to use etc. > As I say below I don't think we need to decide for M1. I would assert that we need to be able to have samples depend on separate feature distributions, modules call then what you will. Doesn't mean we need to ship them but does mean they need to exist. As in my first point I think this is a common feature of both approaches as they are currently implemented. > > > >> >> * I suggest though in this first instance (M1) we just ship the "all" >> distro and we can see how we get on with that. This is still build from the >> separate feature modules. >> > > Yes i agree with just shipping an "all" distro for now. I'd like to leave > the "how its built" till this discussion has progressed a little further > though. > > >> >> [separate tuscany jars vs feature jars] >> * I don't particularly like the feature jars as it's another step to go >> wrong. In particular it uses the shade(?) plugin and you have to configure >> transformers. > > > I'm puzzeled that you consider that as "another step to go wrong" but don't > mind having multiple different distributions or building distributions out > of each other, both of which seem to add much more complexity, restrictions, > and points of failure to me :) > To me it looks like a step in the process that we don't necessarily need. In the context of this point my measure of complexity is how many places I have to specify things. I agree that there are also complexities in distributing more that one distribution package but I don't see that that's particularly related to this point. > > > >> >> [Launcher vs manually specified classpath comes into this] >> * Manual classpath is easier with feature jars. Can we use a >> different approach to support the manual classpath? Manifest jars for each >> feature? > > > I think we need to make a bit more progress on the "Tuscany runtime > launching" thread before that can be answered. > Agreed > > > >> >> >> [structured libraries directory] >> * I like this. It gives some sense of order to the distro lib directory. >> >> > Me too. Comparing the distros we've had in the past and the different > varrieties being talked about now i think a structured libraries directory > makes the most significant improvement for making the distro easier to use > in the way users have been asking for. > > >> >> Some other distro thoughts came to mind as I went through: >> >> 1/ Can we do something about 3rd party licenses? E.g. automate the command >> line tools we have that check distro jars are represented in the LICENSE >> file so that this happens automatically when distro is built. Also >> it would be nice to have a tool that checks that module NOTICE/LICENSE >> files match the requirements of the source that they hold. This last is >> manual at the moment. > > > The way to do this would be to change to use the maven release plugin and > IANAL plugin which would vastly simplify our distribution build and release > process, i think it is where i think really we need to get to but it will > put some restriction on how we shape the distributions which is one of the > reasons i'm less keen on all these "feature" distros > I looked at this a while back and I agree it adds restrictions. I don't remember the details so I'll have to read up. I seem to think it was early days when I looked at it so it was pretty rough at that point. > > > >> 2/ We need to follow through on the reason Raymond started this thread >> originally and ensure that samples are tested in the ways that a user will >> run then when the distribution is built. >> 3/ As per 2/ but for webapp samples. Can we re-use some of the work that >> was done for webapps in 1.x itest? >> > > I'm starting to think there should be seperate distributions for OSGi and > JSE/Webapps etc. Trying to munge all this into a single distribution that > works for all environments so far looks like its going to make the > distribution a lot more complex and less user friendly than it needs to be. > You could consider this part of the "modularity" exercise of 2.0 and not > munging unrelated things together. If we did that then we can test the > samples included in the distribution properly in the best way for the target > environment. > what would the difference be between these distributions? I think the jars and their organization would be the same. It comes down to how you launch/host the runtime so probably some hosting/launching jars would come and go. Again we need to do more on the launching thread for this point. > > ...ant > > >
