Re: [Ginp-developers] Latest changes - deployment problems

[Brian B. <br...@Pi...>]

Doug Culnane wrote:
> Sorry Brian but I have not finished the set up wizard and it does not
> work.  Either we need to go back to the tapestry version from Justin or
> Someone needs to finish it.

That is a huge relief to me. I really didn't want to back out my changes 
but I had to assume I was the guilty party in the absence of evidence to 
the contrary.

I'll stop worrying and move forward instead.


> It would be great to update the manual because it was written by someone
> that understands the GINP, not a user.  However the code needs to work
> first.... Maybe your effort would be better served improving the code
> then the manual.

Agreed. I'm very pleased to find the war from the latest source works in 
basic demo mode. I think I will (very soon) start to restructure the 
manual. I'll follow the simplistic scheme that I suggested until we have 
the "clever stuff" working, then I'll re-organise the manual.

ginp.xml isn't too complex to copy/paste/edit by hand for a demo system, 
so I will start there.


> Your error looks like the WebAp server can not load the taglib class. 
> Check supported version of JSP and Servet specifications in web.xml and
> ginp.tld and for your server. Also check for any start up errors on your
> web server.

Good advice, thanks. I probably have some jars in 
{CATALINA_HOME}/common/lib that worked OK with the "old" ginp.war and 
the Container ClassLoader is pre-empting the jars bundled in the new war.


-----------------------

Your comments above have encouraged me to keep going. When I started 
researching maven, I was a die-hard ant advocate. By the time I had done 
some sample maven applications, I was beginning to be convinced. I made 
a mental note to convert one of my own complex systems to manage its 
dependencies better.

I found it very hard to gain any traction when working on the ginp setup 
problems yesterday. There was so much new (but useful) technology 
involved, but it was so hard to penetrate because I didn't have any 
experience with what it should look like when working. I'm familiar with 
reading java servlet source files generated from jsp's, but they are 
almost impenetrable when custom taglibs are involved. Then throw in 
Tapestry and Hivemind and Spring....

I'd like to refactor ginp into a (small) set of dependent maven 
projects. I don't think it would take a lot of work, but it will mean 
major surgery to the source tree. The maven team have convinced me it is 
a bad idea to make the pom.xml more complex by using a "non-standard" 
directory structure... get it right and then forget it.

I'd like to move the setup logic (Tapestry application) off into a 
sub-project. This would make it much simpler to understand and also 
remove it from the mainline webapp. Of course, the sub-project will 
still be built into the final war, but it will be MUCH simpler to 
understand and work on (and fix) when it is ring-fenced.

The refactoring will naturally identify some core classes used by the 
setup and mainline sub-projects. With luck, some of the more complex 
classes can be refactored into their respective sub-projects. This would 
be a good opportunity to sort out the platform-specific path issues by 
writing more unit tests.

I wonder whether this refactoring might make it much easier for someone 
to create and build their own webapp for their own photos and style? 
Let's wait and see.

I will not start on refactoring unless you like the idea. If you do, I'd 
try out some ideas in my own sandbox to see what structure feels most 
natural. Then we can talk about the best approach and how to restructure 
the source tree.

Thanks again...

Brian