You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Florian MOGA <mo...@gmail.com> on 2010/10/07 12:17:11 UTC
trunk structure - trunk/contrib folder
We have identified the need of having the following types of environments:
- a place where to keep new modules or samples (contrib/)
- a place where to move the new code in order to get built regularly in
order to be able to monitor it's state and ensure doesn't get broken by
latest trunk/ changes (unreleased/)
- a place where to keep released modules and their latest fixes/improvements
(trunk/)
- a place where to copy code from the main development area in order to
experiment things which might break the build (sandbox/<personal folder>)
As a conclusion, code can be moved on the following paths contrib/ ->
unreleased/ -> trunk/ and sandbox/ <-> trunk/.
Currently, the unreleased/ folder is under trunk/ and there have been
discussions about taking it out of trunk/ at the same level with /contrib
and trunk/. The advantages would be that it would make trunk smaller and
easier to build without the new modules and their dependencies. The
disadvantages would be loosing the ability to check out trunk/ and
unreleased/ in one piece and the convenience this brings inside the
development environment. Either way Hudson will be set to build the
unreleased folder/ but not fail the trunk/ build and snapshot deployment if
unreleased/ fails.
After we agree on the above point, it might be a good thing having written
down the purpose of the folders in a README file or in the Developing
Tuscany section on the website so that it will be clear and we can start
gaining the consistency we want.
Re: trunk structure - trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Oct 7, 2010 at 9:00 PM, ant elder <an...@gmail.com> wrote:
> On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <na...@apache.org> wrote:
>> Florian MOGA wrote:
>>>
>>> We have identified the need of having the following types of environments:
>>>
>>> - a place where to keep new modules or samples (contrib/)
>>> - a place where to move the new code in order to get built regularly in
>>> order to be able to monitor it's state and ensure doesn't get broken by
>>> latest trunk/ changes (unreleased/)
>>> - a place where to keep released modules and their latest
>>> fixes/improvements (trunk/)
>>> - a place where to copy code from the main development area in order to
>>> experiment things which might break the build (sandbox/<personal folder>)
>>>
>>> As a conclusion, code can be moved on the following paths contrib/ ->
>>> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>>>
>>> Currently, the unreleased/ folder is under trunk/ and there have been
>>> discussions about taking it out of trunk/ at the same level with /contrib
>>> and trunk/. The advantages would be that it would make trunk smaller and
>>> easier to build without the new modules and their dependencies. The
>>> disadvantages would be loosing the ability to check out trunk/ and
>>> unreleased/ in one piece and the convenience this brings inside the
>>> development environment. Either way Hudson will be set to build the
>>> unreleased folder/ but not fail the trunk/ build and snapshot deployment if
>>> unreleased/ fails.
>>>
>> There are other advantages of having the unreleased code in trunk and
>> in the default top-level trunk build.
>>
>> 1. Having it in trunk makes it clear that it's part of trunk and that
>> people making changes to trunk need to take account of any impact
>> that their changes have on this code.
>> 2. Having it in the default build (not just the Hudson build) makes it
>> immediately obvious if something is broken and requires people to
>> take positive action to correct or work around the problem.
>>
>
> I'm -1 on having this in the default build. That wont fit well with
> the way i develop in Tuscany or how i have my IDE setup, nor will it
> allow the nightly build to work regardless (as commented in [1]) nor
> does it match what was suggested earlier at [2]. If there's code that
> everyone should be building and making sure doesn't get broken then
> put it in trunk proper, if at release time you don't want that
> something released for some reason then just delete it from the
> release branch.
>
> ...ant
>
> [1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
> [2] http://apache.markmail.org/message/uvusqmubd4oudang
>
Are you -1 in having a contrib/unreleased folder inside trunk as part
of the build ? But then you say you are ok on having them as part of
the trunk (which will be built) ? Could you please clarify ?
To me, the benefit of a contrib/unreleased is that, during release
time, the RM does not need to go try to figure out what should be part
of the release or not, other then that, I really don't see a big
difference of having it in trunk or not.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: trunk structure - trunk/contrib folder
Posted by ant elder <an...@gmail.com>.
On Sun, Oct 10, 2010 at 5:45 PM, Simon Nash <na...@apache.org> wrote:
> Simon Nash wrote:
>>
>> ant elder wrote:
>>>
>>> On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <na...@apache.org> wrote:
>>>>
>>>> Florian MOGA wrote:
>>>>>
>>>>> We have identified the need of having the following types of
>>>>> environments:
>>>>>
>>>>> - a place where to keep new modules or samples (contrib/)
>>>>> - a place where to move the new code in order to get built regularly in
>>>>> order to be able to monitor it's state and ensure doesn't get broken by
>>>>> latest trunk/ changes (unreleased/)
>>>>> - a place where to keep released modules and their latest
>>>>> fixes/improvements (trunk/)
>>>>> - a place where to copy code from the main development area in order to
>>>>> experiment things which might break the build (sandbox/<personal
>>>>> folder>)
>>>>>
>>>>> As a conclusion, code can be moved on the following paths contrib/ ->
>>>>> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>>>>>
>>>>> Currently, the unreleased/ folder is under trunk/ and there have been
>>>>> discussions about taking it out of trunk/ at the same level with
>>>>> /contrib
>>>>> and trunk/. The advantages would be that it would make trunk smaller
>>>>> and
>>>>> easier to build without the new modules and their dependencies. The
>>>>> disadvantages would be loosing the ability to check out trunk/ and
>>>>> unreleased/ in one piece and the convenience this brings inside the
>>>>> development environment. Either way Hudson will be set to build the
>>>>> unreleased folder/ but not fail the trunk/ build and snapshot
>>>>> deployment if
>>>>> unreleased/ fails.
>>>>>
>>>> There are other advantages of having the unreleased code in trunk and
>>>> in the default top-level trunk build.
>>>>
>>>> 1. Having it in trunk makes it clear that it's part of trunk and that
>>>> people making changes to trunk need to take account of any impact
>>>> that their changes have on this code.
>>>> 2. Having it in the default build (not just the Hudson build) makes it
>>>> immediately obvious if something is broken and requires people to
>>>> take positive action to correct or work around the problem.
>>>>
>>>
>>> I'm -1 on having this in the default build. That wont fit well with
>>> the way i develop in Tuscany or how i have my IDE setup, nor will it
>>> allow the nightly build to work regardless (as commented in [1]) nor
>>> does it match what was suggested earlier at [2]. If there's code that
>>> everyone should be building and making sure doesn't get broken then
>>> put it in trunk proper, if at release time you don't want that
>>> something released for some reason then just delete it from the
>>> release branch.
>>>
>>> ...ant
>>>
>>> [1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
>>> [2] http://apache.markmail.org/message/uvusqmubd4oudang
>>>
>>>
>> In 1.x these unreleased things are already in trunk. Some of them
>> are in the default build and some aren't. So I don't understand how
>> moving the modules currently in the default build from trunk/xxx to
>> trunk/unreleased/xxx and keeping them in the default build would
>> affect the way people develop in Tuscany or have their IDE set up.
>> I wasn't proposing that anything should go into the default build
>> that isn't there currently.
>>
>> Excluding these things from the release isn't as simple as just
>> deleting them from the release branch. The poms in the modules
>> and samples directories refer to these unreleased things and
>> these would need to be changed in the release branch to match the
>> deletions. Currently these pom changes aren't being done and this
>> is why the source and binary distributions don't match (see
>> TUSCANY-3678). Instead there is complex and error-prone code
>> in the distribution assembly files to exclude one set of things
>> from the binary distribution and a different set of things from
>> the source distribution.
>>
>> This discussion has convinced me that we should fix TUSCANY-3678
>> in 1.6.1 by deleting all the unreleased modules and samples from
>> the release branch and updating the poms and distribution assembly
>> files in the release branch to match these deletions. The modules
>> and samples to be deleted should be all those that weren't included
>> in the 1.6 binary distribution.
>>
>> I'll check in these changes to the 1.6.1 branch over the weekend
>> unless there are any objections. This will allow us to see what the
>> 1.x trunk would look like with the unreleased things removed. In
>> parallel to these 1.6.1 changes we can continue this discussion
>> about the best way to handle the unreleased things within the
>> 1.x and 2.x trunks.
>>
>
> I've looked at the modules, samples and tools directories as released
> in 1.6, and I've also looked at the contents of the maven repo.
>
> The position is a bit less clear cut than I was expecting because
> many of the modules that were excluded from the binary distro in 1.6
> are present in the maven repo. This creates some ambiguity about
> whether these modules are in the "released" or "unreleased" category.
> I have listed these ambiguities below, together with proposals for
> resolving the ambiguity.
>
> The following things are in the 1.6 source tree under "modules", are
> in the default build, and have 1.6 versions present in the maven repo,
> but are omitted from the 1.6 binary distribution:
> binding-atom-js-dojo
> binding-erlang
> binding-erlang-runtime
> binding-sca-corba
> binding-sca-jms
> contribution-jee-impl
> databinding-fastinfoset
> databinding-xstream
> extensibility-equinox
> host-corba-jee
> host-ejb
> host-openejb
> host-tomcat
> implementation-widget-runtime-dojo
> node-launcher-osgi
> policy-transaction
> web-javascript-dojo
> workspace-manager
> I believe these are intended to be "unreleased" but ended up in the
> maven repo because they are part of the default build. For 1.6.1
> I propose to delete all of these from the release branch and not
> include them in the binary distro or the maven repo.
>
I suspect there are two main reasons most of those aren't in the
binary distribution, one is it was just never thought about so they
were forgotten to be added, and the other is that they duplicate some
functionality and 1.x doesn't have any easy way choosing when there
are multiple impls of something on the classpath.
> The following things are in the 1.6 source tree under "tools", are
> in the default build, and have 1.6 versions present in the maven repo,
> but are omitted from the 1.6 binary distribution:
> contrib2wsdl
> eclipse/features/core
> eclipse/plugins/core
> eclipse/site/updatesite
> java2wsdl
> maven/maven-ant-generator
> maven/maven-bundle-plugin
> maven/maven-dependency-lister
> maven/maven-incremental-build
> maven/maven-java2wsdl
> maven/maven-wsdl2java
> I believe these are intended to be "released" to the maven repo only
> and not included in the binary distro. For 1.6.1 I propose to keep
> all of these in the release branch and deploy them to the maven repo,
> but not include them in the binary distro.
>
> The following things are in the 1.6 source tree under "samples" and
> are in the default build, but are omitted from the 1.6 binary distro
> and don't appear in the maven repo (just as none of the other samples
> appear in the maven repo):
> calculator-lean
> calculator-ws-secure-webapp
> customer-dojo
> customer-dojo-webapp
> helloworld-erlang-reference
> helloworld-erlang-service
> helloworld-jms-webapp
> helloworld-ws-reference-lean
> loanapplication
> store-dojo
> I believe these are intended to be "unreleased". For 1.6.1 I propose
> to delete all of these from the release branch not include them in
> the binary distro or the maven repo.
>
> The following things are in the 1.6 source tree but aren't included
> in the binary distribution, the default build, or the maven repo:
> modules/binding-hessian
> tools/maven/maven-osgi-junit
> samples/domain-webapp
> samples/zipcode-jaxws
> I believe these are intended to be "unreleased". For 1.6.1 I propose
> to delete all of these from the release branch and not include them in
> the binary distro or the maven repo.
>
> Have I put all of the above into the "released" and "unreleased"
> categories correctly?
>
> Simon
>
>
The helloworld-jms-webapp sample was intended to be released and i
think it does work, as 1.6.1 is a point release i think its fine not
to include it as it wasn't in 1.6, for 1.7 it would be good to though.
...ant
Re: [1.6.1] customer-dojo samples, was: Re: trunk structure -
trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Oct 12, 2010 at 3:36 AM, Simon Nash <na...@apache.org> wrote:
> Luciano Resende wrote:
>>
>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>>
>>> I've looked at the modules, samples and tools directories as released
>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>
>>> (cut)
>>> customer-dojo
>>> customer-dojo-webapp
>>
>> I don't have any strong feelings about customer-dojo-*. They
>> demonstrate a customer service integrated with JPA and then providing
>> information back to ui via WEB 2.0 bindings... but other then the
>> internals, the UI does not do much.
>>
> I looked at these and there are various problems with the build.xml
> files, dependency mismatches with the binary distro contents, naming
> discrepancies in the READMEs, etc. I think they need a bit more work
> before they're ready to be released. As they weren't in the 1.6 binary
> distro, I'm inclined to delete them from the 1.6.1 branch.
>
+1
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
[1.6.1] customer-dojo samples, was: Re: trunk structure - trunk/contrib
folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>> I've looked at the modules, samples and tools directories as released
>> in 1.6, and I've also looked at the contents of the maven repo.
>>
>> (cut)
>> customer-dojo
>> customer-dojo-webapp
>
> I don't have any strong feelings about customer-dojo-*. They
> demonstrate a customer service integrated with JPA and then providing
> information back to ui via WEB 2.0 bindings... but other then the
> internals, the UI does not do much.
>
I looked at these and there are various problems with the build.xml
files, dependency mismatches with the binary distro contents, naming
discrepancies in the READMEs, etc. I think they need a bit more work
before they're ready to be released. As they weren't in the 1.6 binary
distro, I'm inclined to delete them from the 1.6.1 branch.
Simon
Re: [1.6.1] erlang modules and samples, was: Re: trunk structure -
trunk/contrib folder
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Oct 11, 2010 at 11:44 PM, Raymond Feng <cy...@gmail.com> wrote:
> +1 to add it.
> ________________________________________________________________
> Raymond Feng
> rfeng@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 Oct 11, 2010, at 2:58 PM, Simon Nash wrote:
>
> Luciano Resende wrote:
>
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>
> I've looked at the modules, samples and tools directories as released
>
> in 1.6, and I've also looked at the contents of the maven repo.
>
> (cut)
>
> The earlang extensions have an issue that you have to install earlang
>
> first, before you can do much with it. But other then that, it should
>
> be good to stay.
>
> I installed erlang and ran the erlang samples. The only problem I found
> was that the README instructions for these samples mention using ant but
> there aren't any build.xml files. I added code to the poms to generate
> the build.xml files and everything worked OK. If erlang isn't installed,
> the samples produce a message saying this.
>
> Based on this I see no reason for excluding modules/binding-erlang-* and
> samples/helloworld-erlang-* from the 1.x and 1.6.1 binary distros, and
> I would like to add them. Does anyone disagree with this?
>
> Simon
>
>
>
+1 if they work I think they should be added.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [1.6.1] erlang modules and samples, was: Re: trunk structure - trunk/contrib folder
Posted by Raymond Feng <cy...@gmail.com>.
+1 to add it.
________________________________________________________________
Raymond Feng
rfeng@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 Oct 11, 2010, at 2:58 PM, Simon Nash wrote:
> Luciano Resende wrote:
>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>> I've looked at the modules, samples and tools directories as released
>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>
>>> (cut)
>> The earlang extensions have an issue that you have to install earlang
>> first, before you can do much with it. But other then that, it should
>> be good to stay.
> I installed erlang and ran the erlang samples. The only problem I found
> was that the README instructions for these samples mention using ant but
> there aren't any build.xml files. I added code to the poms to generate
> the build.xml files and everything worked OK. If erlang isn't installed,
> the samples produce a message saying this.
>
> Based on this I see no reason for excluding modules/binding-erlang-* and
> samples/helloworld-erlang-* from the 1.x and 1.6.1 binary distros, and
> I would like to add them. Does anyone disagree with this?
>
> Simon
>
Re: [1.6.1] erlang modules and samples, was: Re: trunk structure -
trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Oct 11, 2010 at 2:58 PM, Simon Nash <na...@apache.org> wrote:
> Luciano Resende wrote:
>>
>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>>
>>> I've looked at the modules, samples and tools directories as released
>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>
>>> (cut)
>>
>> The earlang extensions have an issue that you have to install earlang
>> first, before you can do much with it. But other then that, it should
>> be good to stay.
>>
> I installed erlang and ran the erlang samples. The only problem I found
> was that the README instructions for these samples mention using ant but
> there aren't any build.xml files. I added code to the poms to generate
> the build.xml files and everything worked OK. If erlang isn't installed,
> the samples produce a message saying this.
>
> Based on this I see no reason for excluding modules/binding-erlang-* and
> samples/helloworld-erlang-* from the 1.x and 1.6.1 binary distros, and
> I would like to add them. Does anyone disagree with this?
>
> Simon
>
>
+1
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
[1.6.1] erlang modules and samples, was: Re: trunk structure - trunk/contrib
folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>> I've looked at the modules, samples and tools directories as released
>> in 1.6, and I've also looked at the contents of the maven repo.
>>
>> (cut)
>
> The earlang extensions have an issue that you have to install earlang
> first, before you can do much with it. But other then that, it should
> be good to stay.
>
I installed erlang and ran the erlang samples. The only problem I found
was that the README instructions for these samples mention using ant but
there aren't any build.xml files. I added code to the poms to generate
the build.xml files and everything worked OK. If erlang isn't installed,
the samples produce a message saying this.
Based on this I see no reason for excluding modules/binding-erlang-* and
samples/helloworld-erlang-* from the 1.x and 1.6.1 binary distros, and
I would like to add them. Does anyone disagree with this?
Simon
Re: [1.6.1] host-tomcat and binding-sca-*, was: Re: trunk structure
- trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Tue, Oct 12, 2010 at 3:49 AM, Simon Nash <na...@apache.org> wrote:
>> Luciano Resende wrote:
>>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>>> I've looked at the modules, samples and tools directories as released
>>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>>
>>>> (cut)
>>> I believe a very similar issue happens with
>>> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>>>
>> There aren't any samples that depend on these. Some samples have
>> pom.xml dependencies on host-tomcat but use host-jetty at runtime.
>> Given this, I think we should stay with the current practice of
>> releasing these in the maven repo only and add a note to the release
>> documentation explaining this.
>>
>
> Can this be solved similar to the *-dojo dependencies where if they
> are not in the tuscany-sca-manifest it's fine ? Otherwise I'm fine by
> leaving the way it is today.
>
For host-tomcat there are some additional 3rdparty dependencies that
would need to be added to the lib directory as well. There are currently
no samples that use host-tomcat so it wouldn't be easy to make sure we
have the right set of dependencies and it wouldn't be easy for users
to figure out how to use this from the binary distro. It would be
possible to use the store-dojo sample for this purpose and I'll look
into this.
There's no sample for binding-sca-jms. The binding-sca-jms itest isn't
in the build and doesn't work (it gets a NullPointerException) so there's
apparently no evidence that binding-sca-jms is working. Having discovered
this, I think binding-sca-jms should be excluded from the 1.6.1 release
completely.
There's no sample for binding-sca-corba, but there is an itest
(ScenarioFour in itest/corba) that shows that it works. To put this
in the binary distro I think we would also need a sample showing how
to use it (special configuration of the binding.sca element as well
as picking up the binding-sca-corba module directly from the modules
directory).
Simon
Re: [1.6.1] host-tomcat and binding-sca-*, was: Re: trunk structure -
trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Oct 12, 2010 at 3:49 AM, Simon Nash <na...@apache.org> wrote:
> Luciano Resende wrote:
>>
>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>>
>>> I've looked at the modules, samples and tools directories as released
>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>
>>> (cut)
>>
>> I believe a very similar issue happens with
>> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>>
> There aren't any samples that depend on these. Some samples have
> pom.xml dependencies on host-tomcat but use host-jetty at runtime.
> Given this, I think we should stay with the current practice of
> releasing these in the maven repo only and add a note to the release
> documentation explaining this.
>
Can this be solved similar to the *-dojo dependencies where if they
are not in the tuscany-sca-manifest it's fine ? Otherwise I'm fine by
leaving the way it is today.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
[1.6.1] host-tomcat and binding-sca-*, was: Re: trunk structure -
trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>> I've looked at the modules, samples and tools directories as released
>> in 1.6, and I've also looked at the contents of the maven repo.
>>
>> (cut)
> I believe a very similar issue happens with
> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>
There aren't any samples that depend on these. Some samples have
pom.xml dependencies on host-tomcat but use host-jetty at runtime.
Given this, I think we should stay with the current practice of
releasing these in the maven repo only and add a note to the release
documentation explaining this.
Simon
Re: trunk structure - trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>> I've looked at the modules, samples and tools directories as released
>> in 1.6, and I've also looked at the contents of the maven repo.
>>
>> The position is a bit less clear cut than I was expecting because
>> many of the modules that were excluded from the binary distro in 1.6
>> are present in the maven repo. This creates some ambiguity about
>> whether these modules are in the "released" or "unreleased" category.
>> I have listed these ambiguities below, together with proposals for
>> resolving the ambiguity.
>>
>> The following things are in the 1.6 source tree under "modules", are
>> in the default build, and have 1.6 versions present in the maven repo,
>> but are omitted from the 1.6 binary distribution:
>> binding-atom-js-dojo
>> binding-erlang
>> binding-erlang-runtime
>> binding-sca-corba
>> binding-sca-jms
>> contribution-jee-impl
>> databinding-fastinfoset
>> databinding-xstream
>> extensibility-equinox
>> host-corba-jee
>> host-ejb
>> host-openejb
>> host-tomcat
>> implementation-widget-runtime-dojo
>> node-launcher-osgi
>> policy-transaction
>> web-javascript-dojo
>> workspace-manager
>> I believe these are intended to be "unreleased" but ended up in the
>> maven repo because they are part of the default build. For 1.6.1
>> I propose to delete all of these from the release branch and not
>> include them in the binary distro or the maven repo.
>>
>
> A good source of information for 1.6 can be :
> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.6
>
> The *-dojo modules should not be removed. There is an issue if we have
> both javascript frameworks on the binary distro and how we choose the
> default one. I believe a very similar issue happens with
> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>
> The earlang extensions have an issue that you have to install earlang
> first, before you can do much with it. But other then that, it should
> be good to stay.
>
>
>> The following things are in the 1.6 source tree under "tools", are
>> in the default build, and have 1.6 versions present in the maven repo,
>> but are omitted from the 1.6 binary distribution:
>> contrib2wsdl
>> eclipse/features/core
>> eclipse/plugins/core
>> eclipse/site/updatesite
>
> This is not part of the binary distro, but the main contents of the
> "Tuscany update site" which is used to install the Tuscany Eclipse
> Plugins
> http://www.apache.org/dist/tuscany/java/sca/1.6/tuscany-sca-1.6-updatesite/
>
>> java2wsdl
>> maven/maven-ant-generator
>> maven/maven-bundle-plugin
>> maven/maven-dependency-lister
>> maven/maven-incremental-build
>> maven/maven-java2wsdl
>> maven/maven-wsdl2java
>> I believe these are intended to be "released" to the maven repo only
>> and not included in the binary distro. For 1.6.1 I propose to keep
>> all of these in the release branch and deploy them to the maven repo,
>> but not include them in the binary distro.
>>
>
> Yes, These Tuscany maven plugins are released as maven artifacts only.
>
>
>> The following things are in the 1.6 source tree under "samples" and
>> are in the default build, but are omitted from the 1.6 binary distro
>> and don't appear in the maven repo (just as none of the other samples
>> appear in the maven repo):
>> calculator-lean
>> calculator-ws-secure-webapp
>> customer-dojo
>> customer-dojo-webapp
>
> I don't have any strong feelings about customer-dojo-*. They
> demonstrate a customer service integrated with JPA and then providing
> information back to ui via WEB 2.0 bindings... but other then the
> internals, the UI does not do much.
>
>> helloworld-erlang-reference
>> helloworld-erlang-service
>
> Similar answer as the one above related to the earlang extensions. So
> I'd leave it.
>
>> helloworld-jms-webapp
>> helloworld-ws-reference-lean
>> loanapplication
>> store-dojo
>
> store-dojo is not in the binary distro because the xxx-dojo extensions
> can't be part of it either. But other then that is ready for
> distribution.
>
>
>> I believe these are intended to be "unreleased". For 1.6.1 I propose
>> to delete all of these from the release branch not include them in
>> the binary distro or the maven repo.
>>
>> The following things are in the 1.6 source tree but aren't included
>> in the binary distribution, the default build, or the maven repo:
>> modules/binding-hessian
>> tools/maven/maven-osgi-junit
>> samples/domain-webapp
>> samples/zipcode-jaxws
>> I believe these are intended to be "unreleased". For 1.6.1 I propose
>> to delete all of these from the release branch and not include them in
>> the binary distro or the maven repo.
>>
>> Have I put all of the above into the "released" and "unreleased"
>> categories correctly?
>>
>> Simon
>>
>
> Well, sorry if I missed any :) Anyway, [1] should give you more info
> about the 1.6.x branch status... now, if we talk about trunk, it's a
> totally different issue :).
>
> [1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.6
>
>
>
Thanks for all this very useful information and the pointer to [1].
I think it would be useful to summarize these release packaging
considerations somewhere in the release documentation (maybe
RELEASE_NOTES). Also I will prepare a similar page to [1] for
1.6.1.
Simon
Re: [1.6.1] dojo modules and samples, was: Re: trunk structure -
trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Oct 12, 2010 at 3:02 AM, Simon Nash <na...@apache.org> wrote:
> Luciano Resende wrote:
>>
>> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>>>
>>> I've looked at the modules, samples and tools directories as released
>>> in 1.6, and I've also looked at the contents of the maven repo.
>>>
>>> (cut)
>>
>> The *-dojo modules should not be removed. There is an issue if we have
>> both javascript frameworks on the binary distro and how we choose the
>> default one. I believe a very similar issue happens with
>> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>>
> It should be fine to have the dojo modules in the modules directory
> of the binary distro as long as they aren't included in tuscany-sca-all
> or tuscany-sca-manifest. They can be picked up by explicit references
> from a build.xml file generated by tuscany-maven-ant-generator.
>
> I've tried this approach to run the store-dojo sample and it works fine
> using the generated build.xml file. I also had to change the host-tomcat
> dependency to a host-jetty dependency because the 3rdparty tomcat
> dependencies aren't included in the binary distro. I tried the store
> sample as well, and the extra modules didn't cause any problems.
>
> I'd like to add the dojo modules to the modules directory of the binary
> distro and add the store-dojo sample to show how to use these modules.
> This is much simpler than requiring users to download these modules manually
> from the maven repo and figure out how to use them. I would include a note
> in the release documentation explaining why these modules can't be part of
> tuscany-sca-all and tuscany-sca-manifest. Is there agreement on this?
>
> Simon
>
+1
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
[1.6.1] dojo modules and samples, was: Re: trunk structure - trunk/contrib
folder
Posted by Simon Nash <na...@apache.org>.
Luciano Resende wrote:
> On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>> I've looked at the modules, samples and tools directories as released
>> in 1.6, and I've also looked at the contents of the maven repo.
>>
>> (cut)
>
> The *-dojo modules should not be removed. There is an issue if we have
> both javascript frameworks on the binary distro and how we choose the
> default one. I believe a very similar issue happens with
> binding-sca-corba and binding-sca-jms extensions and host-tomcat.
>
It should be fine to have the dojo modules in the modules directory
of the binary distro as long as they aren't included in tuscany-sca-all
or tuscany-sca-manifest. They can be picked up by explicit references
from a build.xml file generated by tuscany-maven-ant-generator.
I've tried this approach to run the store-dojo sample and it works fine
using the generated build.xml file. I also had to change the host-tomcat
dependency to a host-jetty dependency because the 3rdparty tomcat
dependencies aren't included in the binary distro. I tried the store
sample as well, and the extra modules didn't cause any problems.
I'd like to add the dojo modules to the modules directory of the binary
distro and add the store-dojo sample to show how to use these modules.
This is much simpler than requiring users to download these modules manually
from the maven repo and figure out how to use them. I would include a note
in the release documentation explaining why these modules can't be part of
tuscany-sca-all and tuscany-sca-manifest. Is there agreement on this?
Simon
Re: trunk structure - trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, Oct 10, 2010 at 9:45 AM, Simon Nash <na...@apache.org> wrote:
>
> I've looked at the modules, samples and tools directories as released
> in 1.6, and I've also looked at the contents of the maven repo.
>
> The position is a bit less clear cut than I was expecting because
> many of the modules that were excluded from the binary distro in 1.6
> are present in the maven repo. This creates some ambiguity about
> whether these modules are in the "released" or "unreleased" category.
> I have listed these ambiguities below, together with proposals for
> resolving the ambiguity.
>
> The following things are in the 1.6 source tree under "modules", are
> in the default build, and have 1.6 versions present in the maven repo,
> but are omitted from the 1.6 binary distribution:
> binding-atom-js-dojo
> binding-erlang
> binding-erlang-runtime
> binding-sca-corba
> binding-sca-jms
> contribution-jee-impl
> databinding-fastinfoset
> databinding-xstream
> extensibility-equinox
> host-corba-jee
> host-ejb
> host-openejb
> host-tomcat
> implementation-widget-runtime-dojo
> node-launcher-osgi
> policy-transaction
> web-javascript-dojo
> workspace-manager
> I believe these are intended to be "unreleased" but ended up in the
> maven repo because they are part of the default build. For 1.6.1
> I propose to delete all of these from the release branch and not
> include them in the binary distro or the maven repo.
>
A good source of information for 1.6 can be :
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.6
The *-dojo modules should not be removed. There is an issue if we have
both javascript frameworks on the binary distro and how we choose the
default one. I believe a very similar issue happens with
binding-sca-corba and binding-sca-jms extensions and host-tomcat.
The earlang extensions have an issue that you have to install earlang
first, before you can do much with it. But other then that, it should
be good to stay.
> The following things are in the 1.6 source tree under "tools", are
> in the default build, and have 1.6 versions present in the maven repo,
> but are omitted from the 1.6 binary distribution:
> contrib2wsdl
> eclipse/features/core
> eclipse/plugins/core
> eclipse/site/updatesite
This is not part of the binary distro, but the main contents of the
"Tuscany update site" which is used to install the Tuscany Eclipse
Plugins
http://www.apache.org/dist/tuscany/java/sca/1.6/tuscany-sca-1.6-updatesite/
> java2wsdl
> maven/maven-ant-generator
> maven/maven-bundle-plugin
> maven/maven-dependency-lister
> maven/maven-incremental-build
> maven/maven-java2wsdl
> maven/maven-wsdl2java
> I believe these are intended to be "released" to the maven repo only
> and not included in the binary distro. For 1.6.1 I propose to keep
> all of these in the release branch and deploy them to the maven repo,
> but not include them in the binary distro.
>
Yes, These Tuscany maven plugins are released as maven artifacts only.
> The following things are in the 1.6 source tree under "samples" and
> are in the default build, but are omitted from the 1.6 binary distro
> and don't appear in the maven repo (just as none of the other samples
> appear in the maven repo):
> calculator-lean
> calculator-ws-secure-webapp
> customer-dojo
> customer-dojo-webapp
I don't have any strong feelings about customer-dojo-*. They
demonstrate a customer service integrated with JPA and then providing
information back to ui via WEB 2.0 bindings... but other then the
internals, the UI does not do much.
> helloworld-erlang-reference
> helloworld-erlang-service
Similar answer as the one above related to the earlang extensions. So
I'd leave it.
> helloworld-jms-webapp
> helloworld-ws-reference-lean
> loanapplication
> store-dojo
store-dojo is not in the binary distro because the xxx-dojo extensions
can't be part of it either. But other then that is ready for
distribution.
> I believe these are intended to be "unreleased". For 1.6.1 I propose
> to delete all of these from the release branch not include them in
> the binary distro or the maven repo.
>
> The following things are in the 1.6 source tree but aren't included
> in the binary distribution, the default build, or the maven repo:
> modules/binding-hessian
> tools/maven/maven-osgi-junit
> samples/domain-webapp
> samples/zipcode-jaxws
> I believe these are intended to be "unreleased". For 1.6.1 I propose
> to delete all of these from the release branch and not include them in
> the binary distro or the maven repo.
>
> Have I put all of the above into the "released" and "unreleased"
> categories correctly?
>
> Simon
>
Well, sorry if I missed any :) Anyway, [1] should give you more info
about the 1.6.x branch status... now, if we talk about trunk, it's a
totally different issue :).
[1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.6
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: trunk structure - trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
Simon Nash wrote:
> ant elder wrote:
>> On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <na...@apache.org> wrote:
>>> Florian MOGA wrote:
>>>> We have identified the need of having the following types of
>>>> environments:
>>>>
>>>> - a place where to keep new modules or samples (contrib/)
>>>> - a place where to move the new code in order to get built regularly in
>>>> order to be able to monitor it's state and ensure doesn't get broken by
>>>> latest trunk/ changes (unreleased/)
>>>> - a place where to keep released modules and their latest
>>>> fixes/improvements (trunk/)
>>>> - a place where to copy code from the main development area in order to
>>>> experiment things which might break the build (sandbox/<personal
>>>> folder>)
>>>>
>>>> As a conclusion, code can be moved on the following paths contrib/ ->
>>>> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>>>>
>>>> Currently, the unreleased/ folder is under trunk/ and there have been
>>>> discussions about taking it out of trunk/ at the same level with
>>>> /contrib
>>>> and trunk/. The advantages would be that it would make trunk smaller
>>>> and
>>>> easier to build without the new modules and their dependencies. The
>>>> disadvantages would be loosing the ability to check out trunk/ and
>>>> unreleased/ in one piece and the convenience this brings inside the
>>>> development environment. Either way Hudson will be set to build the
>>>> unreleased folder/ but not fail the trunk/ build and snapshot
>>>> deployment if
>>>> unreleased/ fails.
>>>>
>>> There are other advantages of having the unreleased code in trunk and
>>> in the default top-level trunk build.
>>>
>>> 1. Having it in trunk makes it clear that it's part of trunk and that
>>> people making changes to trunk need to take account of any impact
>>> that their changes have on this code.
>>> 2. Having it in the default build (not just the Hudson build) makes it
>>> immediately obvious if something is broken and requires people to
>>> take positive action to correct or work around the problem.
>>>
>>
>> I'm -1 on having this in the default build. That wont fit well with
>> the way i develop in Tuscany or how i have my IDE setup, nor will it
>> allow the nightly build to work regardless (as commented in [1]) nor
>> does it match what was suggested earlier at [2]. If there's code that
>> everyone should be building and making sure doesn't get broken then
>> put it in trunk proper, if at release time you don't want that
>> something released for some reason then just delete it from the
>> release branch.
>>
>> ...ant
>>
>> [1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
>> [2] http://apache.markmail.org/message/uvusqmubd4oudang
>>
>>
> In 1.x these unreleased things are already in trunk. Some of them
> are in the default build and some aren't. So I don't understand how
> moving the modules currently in the default build from trunk/xxx to
> trunk/unreleased/xxx and keeping them in the default build would
> affect the way people develop in Tuscany or have their IDE set up.
> I wasn't proposing that anything should go into the default build
> that isn't there currently.
>
> Excluding these things from the release isn't as simple as just
> deleting them from the release branch. The poms in the modules
> and samples directories refer to these unreleased things and
> these would need to be changed in the release branch to match the
> deletions. Currently these pom changes aren't being done and this
> is why the source and binary distributions don't match (see
> TUSCANY-3678). Instead there is complex and error-prone code
> in the distribution assembly files to exclude one set of things
> from the binary distribution and a different set of things from
> the source distribution.
>
> This discussion has convinced me that we should fix TUSCANY-3678
> in 1.6.1 by deleting all the unreleased modules and samples from
> the release branch and updating the poms and distribution assembly
> files in the release branch to match these deletions. The modules
> and samples to be deleted should be all those that weren't included
> in the 1.6 binary distribution.
>
> I'll check in these changes to the 1.6.1 branch over the weekend
> unless there are any objections. This will allow us to see what the
> 1.x trunk would look like with the unreleased things removed. In
> parallel to these 1.6.1 changes we can continue this discussion
> about the best way to handle the unreleased things within the
> 1.x and 2.x trunks.
>
I've looked at the modules, samples and tools directories as released
in 1.6, and I've also looked at the contents of the maven repo.
The position is a bit less clear cut than I was expecting because
many of the modules that were excluded from the binary distro in 1.6
are present in the maven repo. This creates some ambiguity about
whether these modules are in the "released" or "unreleased" category.
I have listed these ambiguities below, together with proposals for
resolving the ambiguity.
The following things are in the 1.6 source tree under "modules", are
in the default build, and have 1.6 versions present in the maven repo,
but are omitted from the 1.6 binary distribution:
binding-atom-js-dojo
binding-erlang
binding-erlang-runtime
binding-sca-corba
binding-sca-jms
contribution-jee-impl
databinding-fastinfoset
databinding-xstream
extensibility-equinox
host-corba-jee
host-ejb
host-openejb
host-tomcat
implementation-widget-runtime-dojo
node-launcher-osgi
policy-transaction
web-javascript-dojo
workspace-manager
I believe these are intended to be "unreleased" but ended up in the
maven repo because they are part of the default build. For 1.6.1
I propose to delete all of these from the release branch and not
include them in the binary distro or the maven repo.
The following things are in the 1.6 source tree under "tools", are
in the default build, and have 1.6 versions present in the maven repo,
but are omitted from the 1.6 binary distribution:
contrib2wsdl
eclipse/features/core
eclipse/plugins/core
eclipse/site/updatesite
java2wsdl
maven/maven-ant-generator
maven/maven-bundle-plugin
maven/maven-dependency-lister
maven/maven-incremental-build
maven/maven-java2wsdl
maven/maven-wsdl2java
I believe these are intended to be "released" to the maven repo only
and not included in the binary distro. For 1.6.1 I propose to keep
all of these in the release branch and deploy them to the maven repo,
but not include them in the binary distro.
The following things are in the 1.6 source tree under "samples" and
are in the default build, but are omitted from the 1.6 binary distro
and don't appear in the maven repo (just as none of the other samples
appear in the maven repo):
calculator-lean
calculator-ws-secure-webapp
customer-dojo
customer-dojo-webapp
helloworld-erlang-reference
helloworld-erlang-service
helloworld-jms-webapp
helloworld-ws-reference-lean
loanapplication
store-dojo
I believe these are intended to be "unreleased". For 1.6.1 I propose
to delete all of these from the release branch not include them in
the binary distro or the maven repo.
The following things are in the 1.6 source tree but aren't included
in the binary distribution, the default build, or the maven repo:
modules/binding-hessian
tools/maven/maven-osgi-junit
samples/domain-webapp
samples/zipcode-jaxws
I believe these are intended to be "unreleased". For 1.6.1 I propose
to delete all of these from the release branch and not include them in
the binary distro or the maven repo.
Have I put all of the above into the "released" and "unreleased"
categories correctly?
Simon
Re: trunk structure - trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <na...@apache.org> wrote:
>> Florian MOGA wrote:
>>> We have identified the need of having the following types of environments:
>>>
>>> - a place where to keep new modules or samples (contrib/)
>>> - a place where to move the new code in order to get built regularly in
>>> order to be able to monitor it's state and ensure doesn't get broken by
>>> latest trunk/ changes (unreleased/)
>>> - a place where to keep released modules and their latest
>>> fixes/improvements (trunk/)
>>> - a place where to copy code from the main development area in order to
>>> experiment things which might break the build (sandbox/<personal folder>)
>>>
>>> As a conclusion, code can be moved on the following paths contrib/ ->
>>> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>>>
>>> Currently, the unreleased/ folder is under trunk/ and there have been
>>> discussions about taking it out of trunk/ at the same level with /contrib
>>> and trunk/. The advantages would be that it would make trunk smaller and
>>> easier to build without the new modules and their dependencies. The
>>> disadvantages would be loosing the ability to check out trunk/ and
>>> unreleased/ in one piece and the convenience this brings inside the
>>> development environment. Either way Hudson will be set to build the
>>> unreleased folder/ but not fail the trunk/ build and snapshot deployment if
>>> unreleased/ fails.
>>>
>> There are other advantages of having the unreleased code in trunk and
>> in the default top-level trunk build.
>>
>> 1. Having it in trunk makes it clear that it's part of trunk and that
>> people making changes to trunk need to take account of any impact
>> that their changes have on this code.
>> 2. Having it in the default build (not just the Hudson build) makes it
>> immediately obvious if something is broken and requires people to
>> take positive action to correct or work around the problem.
>>
>
> I'm -1 on having this in the default build. That wont fit well with
> the way i develop in Tuscany or how i have my IDE setup, nor will it
> allow the nightly build to work regardless (as commented in [1]) nor
> does it match what was suggested earlier at [2]. If there's code that
> everyone should be building and making sure doesn't get broken then
> put it in trunk proper, if at release time you don't want that
> something released for some reason then just delete it from the
> release branch.
>
> ...ant
>
> [1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
> [2] http://apache.markmail.org/message/uvusqmubd4oudang
>
>
In 1.x these unreleased things are already in trunk. Some of them
are in the default build and some aren't. So I don't understand how
moving the modules currently in the default build from trunk/xxx to
trunk/unreleased/xxx and keeping them in the default build would
affect the way people develop in Tuscany or have their IDE set up.
I wasn't proposing that anything should go into the default build
that isn't there currently.
Excluding these things from the release isn't as simple as just
deleting them from the release branch. The poms in the modules
and samples directories refer to these unreleased things and
these would need to be changed in the release branch to match the
deletions. Currently these pom changes aren't being done and this
is why the source and binary distributions don't match (see
TUSCANY-3678). Instead there is complex and error-prone code
in the distribution assembly files to exclude one set of things
from the binary distribution and a different set of things from
the source distribution.
This discussion has convinced me that we should fix TUSCANY-3678
in 1.6.1 by deleting all the unreleased modules and samples from
the release branch and updating the poms and distribution assembly
files in the release branch to match these deletions. The modules
and samples to be deleted should be all those that weren't included
in the 1.6 binary distribution.
I'll check in these changes to the 1.6.1 branch over the weekend
unless there are any objections. This will allow us to see what the
1.x trunk would look like with the unreleased things removed. In
parallel to these 1.6.1 changes we can continue this discussion
about the best way to handle the unreleased things within the
1.x and 2.x trunks.
Simon
Re: trunk structure - trunk/contrib folder
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <na...@apache.org> wrote:
> Florian MOGA wrote:
>>
>> We have identified the need of having the following types of environments:
>>
>> - a place where to keep new modules or samples (contrib/)
>> - a place where to move the new code in order to get built regularly in
>> order to be able to monitor it's state and ensure doesn't get broken by
>> latest trunk/ changes (unreleased/)
>> - a place where to keep released modules and their latest
>> fixes/improvements (trunk/)
>> - a place where to copy code from the main development area in order to
>> experiment things which might break the build (sandbox/<personal folder>)
>>
>> As a conclusion, code can be moved on the following paths contrib/ ->
>> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>>
>> Currently, the unreleased/ folder is under trunk/ and there have been
>> discussions about taking it out of trunk/ at the same level with /contrib
>> and trunk/. The advantages would be that it would make trunk smaller and
>> easier to build without the new modules and their dependencies. The
>> disadvantages would be loosing the ability to check out trunk/ and
>> unreleased/ in one piece and the convenience this brings inside the
>> development environment. Either way Hudson will be set to build the
>> unreleased folder/ but not fail the trunk/ build and snapshot deployment if
>> unreleased/ fails.
>>
> There are other advantages of having the unreleased code in trunk and
> in the default top-level trunk build.
>
> 1. Having it in trunk makes it clear that it's part of trunk and that
> people making changes to trunk need to take account of any impact
> that their changes have on this code.
> 2. Having it in the default build (not just the Hudson build) makes it
> immediately obvious if something is broken and requires people to
> take positive action to correct or work around the problem.
>
I'm -1 on having this in the default build. That wont fit well with
the way i develop in Tuscany or how i have my IDE setup, nor will it
allow the nightly build to work regardless (as commented in [1]) nor
does it match what was suggested earlier at [2]. If there's code that
everyone should be building and making sure doesn't get broken then
put it in trunk proper, if at release time you don't want that
something released for some reason then just delete it from the
release branch.
...ant
[1] http://apache.markmail.org/message/q6vnd5ynjezah7ld
[2] http://apache.markmail.org/message/uvusqmubd4oudang
Re: trunk structure - trunk/contrib folder
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Oct 7, 2010 at 5:03 AM, Simon Laws <si...@googlemail.com> wrote:
>> There are other advantages of having the unreleased code in trunk and
>> in the default top-level trunk build.
>>
>> 1. Having it in trunk makes it clear that it's part of trunk and that
>> people making changes to trunk need to take account of any impact
>> that their changes have on this code.
>> 2. Having it in the default build (not just the Hudson build) makes it
>> immediately obvious if something is broken and requires people to
>> take positive action to correct or work around the problem.
>>
>> Simon
>>
>
> +1
>
+1, Anything else is business as usual.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: trunk structure - trunk/contrib folder
Posted by Simon Laws <si...@googlemail.com>.
> There are other advantages of having the unreleased code in trunk and
> in the default top-level trunk build.
>
> 1. Having it in trunk makes it clear that it's part of trunk and that
> people making changes to trunk need to take account of any impact
> that their changes have on this code.
> 2. Having it in the default build (not just the Hudson build) makes it
> immediately obvious if something is broken and requires people to
> take positive action to correct or work around the problem.
>
> Simon
>
+1
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: trunk structure - trunk/contrib folder
Posted by Simon Nash <na...@apache.org>.
Florian MOGA wrote:
> We have identified the need of having the following types of environments:
>
> - a place where to keep new modules or samples (contrib/)
> - a place where to move the new code in order to get built regularly in
> order to be able to monitor it's state and ensure doesn't get broken by
> latest trunk/ changes (unreleased/)
> - a place where to keep released modules and their latest
> fixes/improvements (trunk/)
> - a place where to copy code from the main development area in order to
> experiment things which might break the build (sandbox/<personal folder>)
>
> As a conclusion, code can be moved on the following paths contrib/ ->
> unreleased/ -> trunk/ and sandbox/ <-> trunk/.
>
> Currently, the unreleased/ folder is under trunk/ and there have been
> discussions about taking it out of trunk/ at the same level with
> /contrib and trunk/. The advantages would be that it would make trunk
> smaller and easier to build without the new modules and their
> dependencies. The disadvantages would be loosing the ability to check
> out trunk/ and unreleased/ in one piece and the convenience this brings
> inside the development environment. Either way Hudson will be set to
> build the unreleased folder/ but not fail the trunk/ build and snapshot
> deployment if unreleased/ fails.
>
There are other advantages of having the unreleased code in trunk and
in the default top-level trunk build.
1. Having it in trunk makes it clear that it's part of trunk and that
people making changes to trunk need to take account of any impact
that their changes have on this code.
2. Having it in the default build (not just the Hudson build) makes it
immediately obvious if something is broken and requires people to
take positive action to correct or work around the problem.
Simon
> After we agree on the above point, it might be a good thing having
> written down the purpose of the folders in a README file or in the
> Developing Tuscany section on the website so that it will be clear and
> we can start gaining the consistency we want.
>