On Sun, Apr 3, 2011 at 12:32 AM, ant elder <antel...@apache.org> wrote: > On Sun, Apr 3, 2011 at 5:52 AM, Luciano Resende <luckbr1...@gmail.com> wrote: >> On Sat, Apr 2, 2011 at 1:59 PM, ant elder <antel...@apache.org> 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. >> > > I'm still not quite getting what you are saying we should actually do. > > If we have a contribution or webapp sample we do have several ways of > running them, one of them is using the tuscany plugin, others are > things like using the scripts to start the Shell, or including the > Jetty or Tomcat plugin to start jetty/Tomcat, one of the > running-tuscany samples to start a Tuscany runtime etc, and we have > samples that show lots of different ways of doing things in the > learning-more and running-tuscany samples, > > But, the helloworld contribution samples dont do anything by > themselves without having something within the sample build to run it > in Tuscany, are you saying that you think the Tuscany plugin MUST NOT > be one of these ways? Eg I pointed you at the helloworld-contribution2 > sample in unreleased as an example of not including any way to run it > - do you prefer approach? Or do you have some other approach to > suggest? >
I was under the impression that the Tuscany plugin was going to be the ONLY way to run the samples. If that's not the case, then, why all the samples were pulled out ? And why store sample that is running ok from a distribution from both ant and maven is not "ready" to be in the sample folder ? >> 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 > > The pom type features were created to build distributions not for > users to use as dependency groups, it was just an accidental > misunderstaning that they started getting used like that. You never > answer what it is you don't like about the base jar or address the > points I raise against the the pom type approach in > http://apache.markmail.org/message/qttcn6ngmllptaq2, but surely if > you're arguing that there are many different environments and > approaches to using Tuscany which we should be showing and supporting > in the samples then the base jar is one of the valid ways? > The only way I'd agree with a shadded jar usage, is if they are completely optional and more like an distribution option which I though you had started in the past [1] [1] https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/distribution/aggregations/ >> , 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. >> > > Ok but what exactly are you suggesting we do now? > > I would like to do a release to get the latest code out but it sounds > like you wont help or vote for a release with the samples as they are. > What do we need to do so that we can do a release? > > ...ant > It's my duty as a a committer and PMC member to review and approve the releases of the project. All of this discussions started because I was helping getting samples into trunk for the release and you moved them out of the trunk to the unreleased folder. Now, if you think I'm not helping, or that I'm not going to vote to something because I don't like it, sorry !!! -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
