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
