On Sun, Oct 10, 2010 at 5:45 PM, Simon Nash <[email protected]> wrote: > Simon Nash wrote: >> >> ant elder wrote: >>> >>> On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <[email protected]> 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
