Simon Nash wrote:
ant elder wrote:
On Thu, Oct 7, 2010 at 12:34 PM, Simon Nash <n...@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

Reply via email to