Fw: Need clarification for Spindle

----- Original Message -----
From: Geoff Longman
To: [email protected]
Sent: Friday, March 14, 2003 7:55 AM
Subject: Need clarification for Spindle


Thinking about building Tapestry projects and a tricky case has emerged.

I'm calling the Tapestry related stuff that the new spinde.core plugin build
finds Tapestry artifacts

artifacts are:

tapestry project, approot folder, servlet context folder, and the following
files:

application, page, jwc, template

I want to drop the restriction of one app/lib per project which was there to
'hardcode' the ownership relationship between artifacts (primarily app/lib
to jwc/page files).

Instead the new builder expands the scope to include templates and will
determine this relationship (using the new lookup rules) but there are cases
where a direct 1:1 relationship won't happen.

Some cases:

-templates/specs in approot and directly under context root are visible to
all applications in the project
-applications/libraries in the project may refer to the same pages/jwc files
(templates too????).

The first case is unavoidable and there will be workarounds for this (for
now spindle.core will mark warnings in artifacts that depend on these).
Thinking about treating these guys special in that they will not have an
'owner', rather they will be added as implicit children to all the
applications defined in web.xml. GUI support when it comes will need to sort
this out.

The second case is what I'm wondering about...

In a perfect scenario, the library mechanism would be used to share pages
and components and the second case would never arise.
Spindle is sunk if the second case occurs because it *really* depends on the
1:1 scenario.

Fishing for comment on the following possible spindle.core reactions to this
case:

1. First one wins, during processing the first library or application
encountered by the builder in the project gets the link and any subsequent
ones don't and an error is marked in thier spec (as if the artifact was
missing altogether). When the GUI support comes along lookups in the winner
will see the conflicting artifact, but lookups in the subsequent will not.

2. Make this case one of the "build failed" conditions for the builder.
Would be like an unresolved classpath error in a java build. the project is
marked in error, the products of the build are thrown away, and at GUI time
very little functionality would be available (source manipulation only).

Either is fine with me, but I'm leaning towards #2 as I don't think that in
#1 the same winner would arise with every build which could cause confusion.

Geoff

Geoffrey Longman
Intelligent Works Inc.





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en