I think you meant:
"I'd like them to be releasable, so the sandbox would NOT do it for me."
Right?
I agree, let's do #1. Sounds like we've just convinced ourselves that
our svn repo needs to support more than one project and should be
refactored. I'm thinking it should be something like:
tiles2/trunk
tiles2/branches/
tiles2/tags/
maven/trunk
...
showcase/
...
site/
...
Where maven/* would contain the master pom and in the future possibly
some archetypes, etc. . .
The other option would be to leave the showcase where it is but not to
include it as a module in the parent. I think this may become confusing
though.
David
Nathan Bubna wrote:
I'm with Greg on this. I definitely don't think want to add
dependencies on other frameworks to Tiles itself, but i don't know
that it's a bad thing to have them in our example apps. It's kind of
nice to be able to show people what Tiles can do in various
situations, including with various frameworks.
Separating the Tiles examples from Tiles itself sounds like a pretty
fair solution. I think option #1 below is my favorite. I'd like
them to be releasable, so the sandbox would do it for me. And i don't
think we should consider #3 until we face actual license issues.
On 1/25/07, Greg Reddin <[EMAIL PROTECTED]> wrote:
Well the showcase app is one of those grey areas. It's hard to showcase
everything that Tiles can do without bringing in some bits from
frameworks
we might hook it up to. In some ways the showcase app almost looks
like a
sandbox for exploring ideas of how you might use Tiles.
I definitely don't want Tiles to provide the glue code for other
frameworks,
but I don't see anything wrong with us providing (in some way) a package
that showcases ways you might use Tiles with other frameworks. Here
are a
few possibilities:
1. Release the showcase app separately, thus making it possible to build
Tiles without the external dependencies.
2. Create a sandbox and place things like the showcase app there.
3. Put it somewhere else (like Google Code or SF.net) We did this
over at
Shale to avoid bringing in incompatible dependencies.
Greg
