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

[Doug C. <do...@cu...>]

>
>
> 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....
>   
Me too which is why the setup thing is not finished.
> 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.
>   
Project standardization is one of the benefits of Maven.
> 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.
>   
Not sure is splitting up the ginp into sub projects is such a good
idea.  This will make a very simple application complex.  The whole idea
of the wizard is that it make the install easy not more complex. The
wizard just needs fixed or refactored for clearer explanation.
> 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.
>   
This would be a good argument for refactoring.
> 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
>
>   
By all means refactor but be careful that the changes you make make
sense and are not just changes.  I would say that effort fixing the
wizard or building in new features would be a better use of your time. 
However I am not motivated to work too much on the ginp so if you can
progress the project to a new release go for it.

All the best,

Doug