On Sat, Apr 2, 2011 at 1:59 PM, ant elder <[email protected]> wrote: >> I'd add the expectations and/or user experience when running the >> samples, as it seems that we are droping support for ant completely >> (which to me is ok, as I mostly use maven), but I'm not sure if users >> are ok with that. >> > > At least Mike and Simon L have said in this thread they prefer Ant > builds to Maven for the samples. Ant is harder because of all the > dependencies and where to find the dependencies. There has been things > suggested in this thread, and there are the previous attempts, and > we've all the manifest jars gen'd for each extension now in the binary > distribution, but it all seems a bit complicated and hard to find > something that looks very elegant so i decided not to worry about Ant > builds for now and focus on Maven (which is hard enough to find > something everyone likes on its own), if someone else wants to look at > Ant now that would be great by me. >
I just want to raise the issue that, in real deployment scenarios, users will not use the tuscany/maven plugin. Also, what's the support for environments such as OSGi, etc ? That's why I think to demonstrate different ways to run the samples, which is aligned with the scenarios used by our users in real deployments. Having said that, consistency and simplicity are always welcome. >> Also, we should clarify what we mean by consistent build, particular >> regarding "base + extension", if we are using the base pom, fine, if >> we are using the base jar, sorry, but I believe couple of us don't >> agree with mandating that. And, reviewing the getting-started sample, >> it seems that you are forcing to use the base jar. >> > > Firstly, nothing is being unilaterally mandated or forced to be used. > We've been discussing how to do the samples for months now, trying to > work out consensuses and compromises and I've been updating the > helloworld samples in the unreleased folder as we go and I've asked a > bunch of times for feedback and comments on the approach they use and > no one ever mentioned or complained about them using the base jar, so > thats how they are when moved back into trunk and the samples wiki > page was updated based on what they did. > > I don't really like using the base pom type dependency, unless there > are good reasons it seems better to me to provide a single jar for > groupings we know are useful than to have pom type dependencies. We've > talked about this before, eg one from me is: > http://apache.markmail.org/message/qttcn6ngmllptaq2. What don't you > like about the base jar? > I don't want to restart the same discussion again, [1] is one of those discussions, and as far as I remember, various members of the community wanted to go with soft-dependency via pom (thus us creating the features a long time ago, and if I remember correctly, Simon L creating the base-runtime pom recently), and you were the only one forcing the usage of the jar. [1] http://markmail.org/message/jkkuqmthnspns64q > So what shall we do about this, how can we find consensus on an approach? > See above, I really thought we had consensus on this case, but you keep trying to bring this up again, or we keep finding it when we spend tons of time investigating issues. > We could avoid it for the contribution samples by not including a test > that starts tuscany so they just need the sca-api dependency, eg as > was done in this sample - > https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/helloworld-contribution2/ > > We could use the individual module dependencies directly and perhaps > have another go at merging some of those together so there's not so > many. > > Perhaps just don't worry about having a consistent approach across the > samples and instead people just do what they like? > I think we need to find the right balance here, although consistency is good, if the side effect of this is to not have any sample that demonstrates different deployment scenarios, this is also not good. > What else, any suggestions anyone? > > ...ant > -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
