Problems building the showcase app

[Craig McClanahan <cr...@apache.org>]

I just checked out the trunk of our new repository and tried to build it.
Building the libraries went fine, but building the showcase app uncovered a
problem ... it is looking for "
org.apache.struts:struts-tiles2:jar:1.3.6-SNAPSHOT" as a dependency, which I
don't have on this machine.  I could go download the Struts sources and
build this, but there is a bigger issue.  Shouldn't a "Standalone Tiles"
showcase application *not* require any particular framework?

Craig

Re: Problems building the showcase app

["David H. DeWolf" <dd...@apache.org>]

I believe that the 1.3.6-SNAPSHOT is the first version with the 
struts1-tiles2 integration work that Antonio has been working.  That's 
the reason for the snapshot. . .Antonio will know for sure, I'm sure 
he'll chime in here soon.

Until he chimes in, removing the showcase from the framework build will 
at least allow tiles to build cleanly.  Sounds like those that have 
chimed in so far agree with that approach, so if no one does it tonight, 
I'll tackle it in the morning.

David

Wendy Smoak wrote:
> On 1/25/07, Craig McClanahan <cr...@apache.org> wrote:
> 
>> I can see the logic of that, but can we at least make it use a 
>> non-snapshot
>> version (it currently asks for a Struts 1.3.6-SNAPSHOT) so you can 
>> actually
>> build it?  :-)
> 
> If we can use the 1.3.5 release, great, but I wonder if the example
> app needs code that was added later.
> 
> If that's the case, it's no different than the Shale build depending
> on a snapshot of Tiles 2.  Make sure the Struts snapshots are in the
> repo, then add the apache.snapshots <repository> to pom.xml.
> 
> (The repository definition needs to be commented out for a release.)
> 

Re: Problems building the showcase app

[Wendy Smoak <ws...@gmail.com>]

On 1/25/07, Craig McClanahan <cr...@apache.org> wrote:

> I can see the logic of that, but can we at least make it use a non-snapshot
> version (it currently asks for a Struts 1.3.6-SNAPSHOT) so you can actually
> build it?  :-)

If we can use the 1.3.5 release, great, but I wonder if the example
app needs code that was added later.

If that's the case, it's no different than the Shale build depending
on a snapshot of Tiles 2.  Make sure the Struts snapshots are in the
repo, then add the apache.snapshots <repository> to pom.xml.

(The repository definition needs to be commented out for a release.)

-- 
Wendy

Re: Problems building the showcase app

[Craig McClanahan <cr...@apache.org>]

On 1/25/07, Greg Reddin <gr...@gmail.com> 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.


Indeed.

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.


I can see the logic of that, but can we at least make it use a non-snapshot
version (it currently asks for a Struts 1.3.6-SNAPSHOT) so you can actually
build it?  :-)

Craig



  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
>
>

Re: Problems building the showcase app

[Nathan Bubna <nb...@gmail.com>]

On 1/25/07, David H. DeWolf <dd...@apache.org> wrote:
> I think you meant:
>
> "I'd like them to be releasable, so the sandbox would NOT do it for me."
> Right?

yeah, sorry.

> 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. . .

works for me, but we might want to change showcase/ to something a wee
bit more generic like demo/ or examples/.

> 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.

yes, it would.

>
> 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 <gr...@gmail.com> 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
> >>
> >>
> >
>

Re: Problems building the showcase app

["David H. DeWolf" <dd...@apache.org>]

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 <gr...@gmail.com> 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
>>
>>
> 

Re: Problems building the showcase app

[Nathan Bubna <nb...@gmail.com>]

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 <gr...@gmail.com> 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
>
>

Re: Problems building the showcase app

[Greg Reddin <gr...@gmail.com>]

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

Re: Problems building the showcase app

["David H. DeWolf" <dd...@apache.org>]

I think I agree.  Didn't we discuss at one time (when creating our 
charter/tlp resolution perhaps?) that the glue code between tiles and 
other frameworks should not be part of the tiles project, but instead a 
part of the framework embedding tiles?

David

Craig McClanahan wrote:
> I just checked out the trunk of our new repository and tried to build it.
> Building the libraries went fine, but building the showcase app uncovered a
> problem ... it is looking for "
> org.apache.struts:struts-tiles2:jar:1.3.6-SNAPSHOT" as a dependency, 
> which I
> don't have on this machine.  I could go download the Struts sources and
> build this, but there is a bigger issue.  Shouldn't a "Standalone Tiles"
> showcase application *not* require any particular framework?
> 
> Craig
> 

Re: Problems building the showcase app

[Craig McClanahan <cr...@apache.org>]

On 1/27/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 1/24/07, Craig McClanahan <cr...@apache.org> wrote:
>
> > I just checked out the trunk of our new repository and tried to build
> it.
>
> The showcase app should now build with no struts or tiles jars in your
> local repo.  (They're all available in the ASF snapshot repo.)


Yep, that worked.  Thanks!

--
> Wendy
>


Craig

Re: Problems building the showcase app

[Wendy Smoak <ws...@gmail.com>]

On 1/24/07, Craig McClanahan <cr...@apache.org> wrote:

> I just checked out the trunk of our new repository and tried to build it.

The showcase app should now build with no struts or tiles jars in your
local repo.  (They're all available in the ASF snapshot repo.)

-- 
Wendy