IMO, we shouldn't even try to use one "consistent" way to launch Tuscany in the
samples. I don't like the magic plugin approach. The whole idea of Tuscany/SCA
is to adapt to whatever technology/container people use instead of reinventing
the wheels. Think about Spring, there is no mandatory way to use it.
Sent from my iPad
On Apr 2, 2011, at 1:59 PM, ant elder <antel...@apache.org> wrote:
> On Fri, Apr 1, 2011 at 5:57 PM, Luciano Resende <luckbr1...@gmail.com> wrote:
>> On Fri, Apr 1, 2011 at 5:32 AM, ant elder <antel...@apache.org> wrote:
>>>>
>>>> Replying to that now quite old email...
>>>>
>>>> As you asked about this i had a go at adding support to the Tuscany
>>>> plugin to support that and there is now some initial code that seems
>>>> to work. So if you add the pom.xml of a webapp project :
>>>>
>>>> <plugin>
>>>> <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>> <artifactId>maven-tuscany-plugin</artifactId>
>>>> <version>${tuscany.version}</version>
>>>> </plugin>
>>>>
>>>> then when doing "mvn tuscany:run" it will see that the packaging type
>>>> is war and launch an embeded Tomcat to run the webapp project.
>>>>
>>>> In a similar vein, i've also added support for having the plugin run a
>>>> classes main method instead of launching Tuscany, so if you have:
>>>>
>>>> <plugin>
>>>> <groupId>org.apache.tuscany.maven.plugins</groupId>
>>>> <artifactId>maven-tuscany-plugin</artifactId>
>>>> <version>${tuscany.version}</version>
>>>> <configuration>
>>>> <mainClass>sample.HelloworldSCAClient</mainClass>
>>>> </configuration>
>>>> </plugin>
>>>>
>>>> then when doing "mvn tuscany:run" the main method of that class gets
>>>> called.
>>>>
>>>> So using those if we add the tuscany plugin definition to the samples
>>>> then you'll be able to run any sample by doing just "mvn tuscany:run"
>>>> instead of having different ways for different samples depending on
>>>> what type of sample it is.
>>>>
>>>> ...ant
>>>>
>>>
>>> I've updated all the samples in unreleased to demonstrate this, if
>>> we're happy with the approach i'll add it to the samples in trunk.
>>>
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/samples/getting-started/
>>>
>>> ...ant
>>>
>>
>> It would be great if we could summarize the requirements we have for
>> the samples on the page Florian created [1].
>
> There is some stuff there already and i expect we'll add more as we
> work things out. Everyone has access to update the page so ...
>
>> The information provided
>> above as how to instrument the sample is also very good to be on that
>> page,
>
> Sure ok i'll add that if we use it, i am waiting to see if there are
> any comments for or against - "if we're happy with the approach i'll
> add it to the samples"
>
>> 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.
>
>> 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?
>
> So what shall we do about this, how can we find consensus on an approach?
>
> 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?
>
> What else, any suggestions anyone?
>
> ...ant
