Store sample, was Re: svn commit: r1086858 - /tuscany/sca-java-2.x/trunk/unreleased/samples/applications/
Ant, as the only comments I got about the store sample [1] were that it meets the requirements for releasing it, could you please move it back to trunk and I'll continue to work on it. Thanks in Advance [1] http://tuscany.markmail.org/thread/afro3t4aamqa7jty On Tue, Mar 29, 2011 at 11:44 PM, wrote: > Author: antelder > Date: Wed Mar 30 06:44:42 2011 > New Revision: 1086858 > > URL: http://svn.apache.org/viewvc?rev=1086858&view=rev > Log: > Move the store app to unreleased > > Added: > tuscany/sca-java-2.x/trunk/unreleased/samples/applications/ > - copied from r1086854, tuscany/sca-java-2.x/trunk/samples/applications/ > > -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: [DISCUSS] Minimum standards for released samples
I'm +1 for having a set of standard requirements for the samples to be promoted to trunk and released. That's why I started the samples checklist wiki page in the first place. However, I don't think we need another two month long thread in order to determine which these standards should be. We already had this discussion and we can just summarize it. As I mentioned before on the other thread, I'm fine with doing the release only with getting-started/ samples. With that in mind, I would say we shouldn't delay 2.0-Beta3 any more. It's a minor release anyway and most importantly users need the runtime code released. So I'm +1 for releasing 2.0-Beta3 now. On Wed, Apr 6, 2011 at 12:34 AM, Simon Nash wrote: > ant elder wrote: > >> On Tue, Apr 5, 2011 at 5:45 PM, Simon Nash wrote: >> >>> Following on from the discussion in [1], I'd like to establish >>> whether or not the Tuscany developer community agrees that we >>> should have some minimum standards for a sample to be part of trunk >>> and be delivered in a released binary distribution. >>> >>> If there's agreement that we should establish this principle and >>> have some minimum standards, I'll start another discussion thread >>> on what those minimum standards should be. >>> >>> I am +1 that we should have some minimum standards for a sample to be >>> in trunk and to be released as part of the binary distribution. >>> >>> Simon >>> >>> [1] >>> >>> http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E >>> >>> >>> >> I'm -1 Simon. That doesn't mean I think we should have rubbish >> samples, i just think the time spent rehashing this again would be >> better spent actually writing some samples and documentation. We've >> just spent two months debating the finer points of how to do samples >> and ended up with just 3 in trunk which not even everyone is >> completely happy with. We do have a clearer understanding now of what >> people think but now we need to just get on and do some. >> >> The Apache process is clear - it takes three +1s to do a release - it >> doesn't matter what rules happen to have been come up here in this >> thread 6 months down the road if there is a release with a sample >> that doesn't work but the release gets the votes then that is fine. >> >> Tuscany is the hardest project I know of in Apache to do releases, and >> i've seen a lot of Apache projects. The actual build process takes >> ages and then we drag it out for ages before people will vote and seem >> to make it obligatory to redo it several times over before people will >> vote +1. Thats shooting ourselves in the foot IMHO and instead of >> looking for more rules to make it even harder to get a release out it >> would be better to look for ways to get people to be more willing to >> promptly vote for releases. We'd get more releases much more often and >> then whats the big deal if some new sample slips through with a bug if >> it can be fixed in the next release which is only a short time away. >> >> 2.x has taken a long time and trunk had got a bit full up of samples >> that had been broken with all the refactoring and changes, we've taken >> all those out now and things are much more stable so if we're a little >> be diligent when adding samples now things should remain in better >> shape. >> >> ...ant >> >> >> Actually it should be easier / quicker to do releases if the trunk > samples meet a reasonable quality standard and are kept working on > an ongoing basis. Also, having some criteria for which samples are > included in trunk would mean that we can release the trunk contents > at any time without needing to debate which samples should be in the > release and removing those that are unsuitable. > > Simon > >
Re: [DISCUSS] Minimum standards for released samples
ant elder wrote: On Tue, Apr 5, 2011 at 5:45 PM, Simon Nash wrote: Following on from the discussion in [1], I'd like to establish whether or not the Tuscany developer community agrees that we should have some minimum standards for a sample to be part of trunk and be delivered in a released binary distribution. If there's agreement that we should establish this principle and have some minimum standards, I'll start another discussion thread on what those minimum standards should be. I am +1 that we should have some minimum standards for a sample to be in trunk and to be released as part of the binary distribution. Simon [1] http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E I'm -1 Simon. That doesn't mean I think we should have rubbish samples, i just think the time spent rehashing this again would be better spent actually writing some samples and documentation. We've just spent two months debating the finer points of how to do samples and ended up with just 3 in trunk which not even everyone is completely happy with. We do have a clearer understanding now of what people think but now we need to just get on and do some. The Apache process is clear - it takes three +1s to do a release - it doesn't matter what rules happen to have been come up here in this thread 6 months down the road if there is a release with a sample that doesn't work but the release gets the votes then that is fine. Tuscany is the hardest project I know of in Apache to do releases, and i've seen a lot of Apache projects. The actual build process takes ages and then we drag it out for ages before people will vote and seem to make it obligatory to redo it several times over before people will vote +1. Thats shooting ourselves in the foot IMHO and instead of looking for more rules to make it even harder to get a release out it would be better to look for ways to get people to be more willing to promptly vote for releases. We'd get more releases much more often and then whats the big deal if some new sample slips through with a bug if it can be fixed in the next release which is only a short time away. 2.x has taken a long time and trunk had got a bit full up of samples that had been broken with all the refactoring and changes, we've taken all those out now and things are much more stable so if we're a little be diligent when adding samples now things should remain in better shape. ...ant Actually it should be easier / quicker to do releases if the trunk samples meet a reasonable quality standard and are kept working on an ongoing basis. Also, having some criteria for which samples are included in trunk would mean that we can release the trunk contents at any time without needing to debate which samples should be in the release and removing those that are unsuitable. Simon
[jira] [Commented] (TUSCANY-3858) Eclipse update site doesn't build correctly from a top-level build
[
https://issues.apache.org/jira/browse/TUSCANY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016080#comment-13016080
]
Simon Nash commented on TUSCANY-3858:
-
This seems to be caused by a problem with how Maven handles filter definitions.
At present the filter definitions for the Eclipse update site modules are
specified within the maven-resources-plugin execution configuration. If these
definitions are moved to the element under the build section, the
top-level build works correctly.
> Eclipse update site doesn't build correctly from a top-level build
> --
>
> Key: TUSCANY-3858
> URL: https://issues.apache.org/jira/browse/TUSCANY-3858
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Tools
>Affects Versions: Java-SCA-1.6.1
>Reporter: Simon Nash
>Assignee: Simon Nash
>
> When building the Eclipse update site as part of a top-level build, a number
> of files in the update site are incorrect because resource filtering isn't
> applied correctly. This causes the substitution variable
> ${tuscany.eclipse.version} to appear as a literal string in various xml
> files, manifest files and jar names instead of being replaced by a correct
> value such as 1.6.2.v20110405-1631.
> If the Eclipse update site is built from the tools/eclipse directory,
> everything works correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Minimum standards for released samples
+1. I'm all for this approach. Thanks, Raymond Raymond Feng rf...@apache.org Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com On Apr 5, 2011, at 9:45 AM, Simon Nash wrote: > Following on from the discussion in [1], I'd like to establish > whether or not the Tuscany developer community agrees that we > should have some minimum standards for a sample to be part of trunk > and be delivered in a released binary distribution. > > If there's agreement that we should establish this principle and > have some minimum standards, I'll start another discussion thread > on what those minimum standards should be. > > I am +1 that we should have some minimum standards for a sample to be > in trunk and to be released as part of the binary distribution. > > Simon > > [1] > http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E >
Re: [DISCUSS] Minimum standards for released samples
On Tue, Apr 5, 2011 at 5:45 PM, Simon Nash wrote: > Following on from the discussion in [1], I'd like to establish > whether or not the Tuscany developer community agrees that we > should have some minimum standards for a sample to be part of trunk > and be delivered in a released binary distribution. > > If there's agreement that we should establish this principle and > have some minimum standards, I'll start another discussion thread > on what those minimum standards should be. > > I am +1 that we should have some minimum standards for a sample to be > in trunk and to be released as part of the binary distribution. > > Simon > > [1] > http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E > > I'm -1 Simon. That doesn't mean I think we should have rubbish samples, i just think the time spent rehashing this again would be better spent actually writing some samples and documentation. We've just spent two months debating the finer points of how to do samples and ended up with just 3 in trunk which not even everyone is completely happy with. We do have a clearer understanding now of what people think but now we need to just get on and do some. The Apache process is clear - it takes three +1s to do a release - it doesn't matter what rules happen to have been come up here in this thread 6 months down the road if there is a release with a sample that doesn't work but the release gets the votes then that is fine. Tuscany is the hardest project I know of in Apache to do releases, and i've seen a lot of Apache projects. The actual build process takes ages and then we drag it out for ages before people will vote and seem to make it obligatory to redo it several times over before people will vote +1. Thats shooting ourselves in the foot IMHO and instead of looking for more rules to make it even harder to get a release out it would be better to look for ways to get people to be more willing to promptly vote for releases. We'd get more releases much more often and then whats the big deal if some new sample slips through with a bug if it can be fixed in the next release which is only a short time away. 2.x has taken a long time and trunk had got a bit full up of samples that had been broken with all the refactoring and changes, we've taken all those out now and things are much more stable so if we're a little be diligent when adding samples now things should remain in better shape. ...ant
Re: [DISCUSS] Minimum standards for released samples
On Tue, Apr 5, 2011 at 9:45 AM, Simon Nash wrote: > Following on from the discussion in [1], I'd like to establish > whether or not the Tuscany developer community agrees that we > should have some minimum standards for a sample to be part of trunk > and be delivered in a released binary distribution. > > If there's agreement that we should establish this principle and > have some minimum standards, I'll start another discussion thread > on what those minimum standards should be. > > I am +1 that we should have some minimum standards for a sample to be > in trunk and to be released as part of the binary distribution. > > Simon > > [1] > http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E > > +1 -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
[DISCUSS] Minimum standards for released samples
Following on from the discussion in [1], I'd like to establish whether or not the Tuscany developer community agrees that we should have some minimum standards for a sample to be part of trunk and be delivered in a released binary distribution. If there's agreement that we should establish this principle and have some minimum standards, I'll start another discussion thread on what those minimum standards should be. I am +1 that we should have some minimum standards for a sample to be in trunk and to be released as part of the binary distribution. Simon [1] http://mail-archives.apache.org/mod_mbox/tuscany-dev/201104.mbox/%3c4d9b41c8.50...@apache.org%3E
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
ant elder wrote: On Tue, Apr 5, 2011 at 10:20 AM, Simon Nash wrote: Luciano Resende wrote: On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng wrote: I like the "commit then review" approach much better. When we add samples into trunk, we have the responsibility to keep them working (in the right way). +1, And this might really be the reason for having this whole discussion. In Tuscany, usually people would dump samples into samples and only look into them when during the release time. Having a reduced number of samples will help, but sample ownership might be the main issue here. I agree that sample code shouldn't be dumped into trunk with the expectation that someone will get it into proper shape for the next release. Regarding ownership, this word might be interpreted in different ways by different people. If it means that someone who commits a new sample should do the whole job of making sure that it meets all the requirements for samples in trunk, I'm +1 for this. Another interpretation of ownership could be to regard a particular individual as responsible for maintaining particular samples (or other parts of the codebase) on an ongoing basis. In Tuscany we don't have this kind of personal ownership but instead regard the whole community as responsible, and I wouldn't want to see that change. For non-sample code that's added to trunk, I think we have general agreement that the new code needs to build OK, have unit tests, and pass its unit tests. For sample code that's added to trunk, all the above apply and there are additional requirements that the sample includes documentation describing what it does, how to run it, and the expected results from running it. It's also a requirement that the sample runs correctly and does what the documentation says it will do. Simon What we know from recent and past events is that there isn't really that much agreement on many things and that people may get upset if things are taken out of trunk. If you read back in the sample thread even something like the requirement to have a sample readme doesn't have universal support, and, if a readme is so banal that it doesn't add much over what you already get from the sample name then the existence of one doesn't really make the world that much of a better place. I think one of the most important things we can do is try to keep each other happy. We've a relatively small dev community so we should do what we can to keep everyone involved and productive and find ways to make space for everyone to do what we they think is important or useful. ...ant Yes, keeping each other happy is definitely a good thing. However, let's not forget that we have users who will definitely not be happy if we deliver releases with samples that don't work or have no instructions for running them or have instructions that are wrong. Also, certain members of our own community will not be happy if we deliver releases that cause our users to be unhappy. I'll start a separate discussion thread on whether our community agrees with the principle of establishing some minimum standards for the samples in trunk that we deliver in our released binary disitributions. If there's agreement on that, I'll start a discussion on what those mimimum standards should be. Simon
[jira] [Created] (TUSCANY-3858) Eclipse update site doesn't build correctly from a top-level build
Eclipse update site doesn't build correctly from a top-level build
--
Key: TUSCANY-3858
URL: https://issues.apache.org/jira/browse/TUSCANY-3858
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-1.6.1
Reporter: Simon Nash
Assignee: Simon Nash
When building the Eclipse update site as part of a top-level build, a number of
files in the update site are incorrect because resource filtering isn't applied
correctly. This causes the substitution variable ${tuscany.eclipse.version} to
appear as a literal string in various xml files, manifest files and jar names
instead of being replaced by a correct value such as 1.6.2.v20110405-1631.
If the Eclipse update site is built from the tools/eclipse directory,
everything works correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
On Tue, Apr 5, 2011 at 10:20 AM, Simon Nash wrote: > Luciano Resende wrote: >> >> On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng wrote: >>> >>> I like the "commit then review" approach much better. When we add samples >>> into trunk, we have the responsibility to keep them working (in the right >>> way). >> >> +1, And this might really be the reason for having this whole >> discussion. In Tuscany, usually people would dump samples into samples >> and only look into them when during the release time. Having a reduced >> number of samples will help, but sample ownership might be the main >> issue here. >> > I agree that sample code shouldn't be dumped into trunk with the expectation > that someone will get it into proper shape for the next release. > > Regarding ownership, this word might be interpreted in different ways by > different people. If it means that someone who commits a new sample should > do the whole job of making sure that it meets all the requirements for > samples in trunk, I'm +1 for this. Another interpretation of ownership > could > be to regard a particular individual as responsible for maintaining > particular > samples (or other parts of the codebase) on an ongoing basis. In Tuscany we > don't have this kind of personal ownership but instead regard the whole > community as responsible, and I wouldn't want to see that change. > > For non-sample code that's added to trunk, I think we have general agreement > that the new code needs to build OK, have unit tests, and pass its unit > tests. > > For sample code that's added to trunk, all the above apply and there are > additional requirements that the sample includes documentation describing > what it does, how to run it, and the expected results from running it. > It's also a requirement that the sample runs correctly and does what the > documentation says it will do. > > Simon > > What we know from recent and past events is that there isn't really that much agreement on many things and that people may get upset if things are taken out of trunk. If you read back in the sample thread even something like the requirement to have a sample readme doesn't have universal support, and, if a readme is so banal that it doesn't add much over what you already get from the sample name then the existence of one doesn't really make the world that much of a better place. I think one of the most important things we can do is try to keep each other happy. We've a relatively small dev community so we should do what we can to keep everyone involved and productive and find ways to make space for everyone to do what we they think is important or useful. ...ant
Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)
Luciano Resende wrote: On Mon, Apr 4, 2011 at 9:12 AM, Raymond Feng wrote: I like the "commit then review" approach much better. When we add samples into trunk, we have the responsibility to keep them working (in the right way). +1, And this might really be the reason for having this whole discussion. In Tuscany, usually people would dump samples into samples and only look into them when during the release time. Having a reduced number of samples will help, but sample ownership might be the main issue here. I agree that sample code shouldn't be dumped into trunk with the expectation that someone will get it into proper shape for the next release. Regarding ownership, this word might be interpreted in different ways by different people. If it means that someone who commits a new sample should do the whole job of making sure that it meets all the requirements for samples in trunk, I'm +1 for this. Another interpretation of ownership could be to regard a particular individual as responsible for maintaining particular samples (or other parts of the codebase) on an ongoing basis. In Tuscany we don't have this kind of personal ownership but instead regard the whole community as responsible, and I wouldn't want to see that change. For non-sample code that's added to trunk, I think we have general agreement that the new code needs to build OK, have unit tests, and pass its unit tests. For sample code that's added to trunk, all the above apply and there are additional requirements that the sample includes documentation describing what it does, how to run it, and the expected results from running it. It's also a requirement that the sample runs correctly and does what the documentation says it will do. Simon
Re: tuscany-gsoc-2011
On Mon, Apr 4, 2011 at 11:01 PM, ejaj on resurgence wrote: > Hi everyone, > I am Ejaj Hassan and m interested in working on the manager webapp for > tuscany- GSOC project. I have chatted with Ant on this and now i'm > doing some research on Tuscany and sca too.Hence i would like to write > my proposal n could keep up some questions. > Thanks and best wishes to all. > Hi Ejaj, One approach to this that might work well would be to have an app that exposes as rest endpoints all or similar functions that the Tuscany Shell supports at the command line, and then have a presentation layer over the top of that which provides a pretty web gui. To do those you'd need to learn about JAX-RS and pick some web framework to write the presentation layer with. I'm a little nervous that this could be quite a lot to achieve in the GSoC timeframe though, especially as you'd be having to start from scratch learning about those things. I suppose we could treat those as two separate parts, so you concentrating on the JAX-RS part first and see how that goes. I'm not sure what the simplest approach to the gui would be, you'd want a web framework with a very small learning curve so you don't spend to much time before you can get going, do you or anyone here have any suggestions or preferences? ...ant
