ginp-developers Mailing List for Java Photo Gallery Web Application (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

buy pills  overnite  navigate our place

All the festive occasions will be more joyous with these wonderful gifts!
We invite you to visit our store today!
http://hiruaoge.com/

do...@cu... wrote:
> Not sure either but I think it has to do with versioning and persistence
> of objects in a J2EE container.  Basically it is good practice to change
> this number if you change the fields a class has.  That was interfaces etc
> do not get into versioning problems of stored objects.
> 

So, are you saying that most of these classes need to be serializable?

... or did the fields get put there by someone's java IDE when the 
classes were first created (e.g. with a j2ee flag set in some wizard 
properties)?

Am I being too simplistic here? Isn't a Serializable class one where the 
instance fields can/must be externalised... and to do that the class 
MUST have at least ONE instance field?

Some of the classes I've looked at so far have none, so what point 
Serializing?. Some have just a GinpModel, or also a Log instance - do 
they need Serializing?

I would like to know whether to remove the serialVersionUID static 
final's or, if we will keep them, what to say in the javadoc comments to 
explain why they are there at all.

Help!

Brian

I'm still plodding through my CheckStyle code cleanup. So far, I've not 
done anything about several classes that are missing javadoc's for 
fields. Before I added a comment, I wanted it to be meaningful.

Here's an example from net.sf.ginp.tags.PageNavigator ...

private static final long serialVersionUID = -6994731253601826937L;

I didn't know what this was for and did some digging. Apparently it is a 
technique for making a class Serializable in a way that supports 
"compatible" code changes that would not be possible if the class were 
to simply implement the java.io.Serializable interface. It becomes the 
programmer's responsibility to decide when a change is not backward 
compatible and generate a new long value.

Well, I still don't get it. Why does net.sf.ginp.tags.PageNavigator need 
to be Serialized at all? Can I simply delete the fields from this type 
of class, or is there some subtle gotcha associated with one of the 
frameworks we are using? I don't think so, but will wait to hear your 
opinion because it isn't worth the risk of breaking a working version.

Regards,

Brian

Doug Culnane wrote:
> You have more patience than I do.  Jalopy and checkstyle are very cool
> but there is a lot of hassle to get the most out of them.  I have done
> this before but Jalopy has changed since then and the Maven plug-in is
> no longer available except in source format.

I wouldn't call it patience - more like "too stubborn to give up".

> Excellent work Brian.  Please do check it in.

As you will see, I checked in all the source and xml files after the 
jalopy run.

Next, I went through and fixed every CheckStyle line length error. The 
system is now down to "only" 1290 style errors. I've committed all these 
changes too.

I hope to have a couple of spare hours over the weekend. I think I will 
stop working "vertically" to resolve style errors - in future I'll 
select a single source file and clean it up as much as possible in a 
single hit. I'm not going to be obsessive and fix everything - if it 
isn't quick or serious, I'll leave it until another time. I want to get 
the error count down to a low number (whatever that might be!)

Regards,

Brian

Well, things didn't work out quite so well in practice. I did a "mvn 
site" against your latest source and CheckStyle threw out more than 7800 
errors!

I took ~/commands/Logon.java as a typical example and started to fix the 
errors manually. Fixing one would usually cause another to pop out and 
replace it. By the time I'd spent an hour, I hit a major snag because we 
did not have the Apache Copyright statement in our source!!! I realised 
there was something fundamental going wrong. How could we be using and 
enforcing Sun coding conventions if we needed an Apache copyright?

Well, several days later I've worked a lot of this out. It is a pity 
there isn't better documentation on the web - or if there is, I couldn't 
find it with google.

I followed your tracks to start with. I found out how to run Jalopy and 
decided the only sensible option was a single-shot from the 
command-line. Eventually, I found some instructions on how to create my 
own Jalopy configuration file by running the preferences.sh gui; 
incorporate our own copyright statement; then export the xml file. I 
then ran Jalopy against the source - I couldn't get recursion to work so 
I ran it directory-by-directory.

In the middle of my Jalopy experiments, I kept running "mvn 
checkstyle:checkstyle" to monitor my progress. CheckStyle did not appear 
to be applying the Sun coding standards - at least not the same ones as 
Jalopy!

Eventually I took a CVS snapshot of sun-checks.xml from the CheckStyle 
source and modified pom.xml to use it. That wasn't any good because it 
needed a valid DTD. I found the correct doctype statement, pasted it in 
and checkstyle ran OK with a BIG reduction in the error count.

So, here is the situation. I have used Jalopy to reformat all the source 
according to explicit Sun standards. It looks MUCH better to my eye, 
e.g. opening curlies on the same line, fewer spaces in argument lists, 
etc. It might not be perfect, but it is good enough to live with. Sorry 
to say that every source module now looks different to the versions that 
you checked-in last week...

I've also put my jalopy-ginp.xml file into the source tree, even though 
it isn't (and shouldn't) be used by maven, it is worth keeping for 
documentation purposes. Besides, we might want to tinker with it in 
future (or rip it off for other projects).

I've put my working checkstyle-ginp.xml file in the source tree too, and 
now pom.xml uses it when running CheckStyle.

Currently, we still have 1404 style errors after a clean/test/site 
sequence. I've reviewed quite a few and they appear to be reasonable and 
worth fixing. I won't go into detail, but some are of more concern than 
others.

I'm ready to commit all these changes. I intend to do it in two chunks - 
the xml's first, then all the updated java source files. I don't think 
it is worth the effort of regressing your changes, so I would commit 
against the latest version. Are you happy for me to go ahead?

Regards,

Brian

p.s. I haven't yet run Jalopy against the test classes, but would do 
once the main classes were mostly cleaned up.

Doug Culnane wrote:
> I have a look at Jalopy and the maven plugin and it has got a bit more
> complicated than it used to be.  Basically I have lost patience with
> it.  I can not find a SUN standard configuration so the best match is
> the Maven coding conventions and the Jalopy standard.  It used to be a
> bit easier to use but now it has gone all wizard, gui, product,
> commercial etc... and I therefore it is beyond me to be able to
> integrate it into the project as i used to do.
> 
> I can switch to the SUN standard for checkstyle but this complains a lot
> about the use of {()} etc....
> 
> Therefore I would suggest that we leave it as it is and new code is
> formated manually.  Thank Jalopy for doing 95% of the formating for us
> and the rest we do by hand as and when we can be bothered.  The
> Checkstyle Maven standard is the authority on what is and is not well
> formatted.  Maven issue a formatter config for different IDEs
> (http://maven.apache.org/guides/development/guide-m2-development.html#Maven%20Code%20Style). 
> 
> 
> Is this acceptable to you, or do you have a better idea.?

Yes, that's fine.

We'll take the Jalopy formatting as our "new" starting point. Any work I 
do on the code cleanup will be acceptable as long as it reduces the 
number of maven complaints.

Thanks for taking a sensible decision. We don't want to make work for 
ourselves!

Brian

Dear Brian,

I have a look at Jalopy and the maven plugin and it has got a bit more
complicated than it used to be.  Basically I have lost patience with
it.  I can not find a SUN standard configuration so the best match is
the Maven coding conventions and the Jalopy standard.  It used to be a
bit easier to use but now it has gone all wizard, gui, product,
commercial etc... and I therefore it is beyond me to be able to
integrate it into the project as i used to do.

I can switch to the SUN standard for checkstyle but this complains a lot
about the use of {()} etc....

Therefore I would suggest that we leave it as it is and new code is
formated manually.  Thank Jalopy for doing 95% of the formating for us
and the rest we do by hand as and when we can be bothered.  The
Checkstyle Maven standard is the authority on what is and is not well
formatted.  Maven issue a formatter config for different IDEs
(http://maven.apache.org/guides/development/guide-m2-development.html#Maven%20Code%20Style). 

Is this acceptable to you, or do you have a better idea.?

note
{
    JavaDocs have to be done by had but maybe your IDE can help.
}

All the best,

Doug

Brian Burch wrote:
> Doug Culnane wrote:
>   
>> Done a one time format of all code with Japloy default settings, and
>> checked it in.
>>     
>
> Fast work! My svn update collected a lot of changed source.
>
> I looked at a random source and thought the default jalopy settings were 
> a bit strange...
>
> - two blanks for any empty argument list.
>
> - some very long lines that will get warnings in the style checks.
>
> - argument lists split, but aligned too far over on the right.
>
>
> In general, I find it very readable.. and the tabs have gone so there 
> aren't any statement continuations hidden off the right of my page.
>
> However, the Checkstyle report claims there are 788 errors. Although 
> most are to do with javadoc, there are quite a lot that are not. Should 
> we change the rules for Jalopy or Checkstyle?
>
> Do you want to fine-tune, or just leave things alone?
>
> Either is OK with me, but I won't start the code quality work until you 
> say you have finished formatting.
>
> Thanks,
>
> Brian
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ginp-developers mailing list
> Gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-developers
>   

Doug Culnane wrote:
> Done a one time format of all code with Japloy default settings, and
> checked it in.

Fast work! My svn update collected a lot of changed source.

I looked at a random source and thought the default jalopy settings were 
a bit strange...

- two blanks for any empty argument list.

- some very long lines that will get warnings in the style checks.

- argument lists split, but aligned too far over on the right.

In general, I find it very readable.. and the tabs have gone so there 
aren't any statement continuations hidden off the right of my page.

However, the Checkstyle report claims there are 788 errors. Although 
most are to do with javadoc, there are quite a lot that are not. Should 
we change the rules for Jalopy or Checkstyle?

Do you want to fine-tune, or just leave things alone?

Either is OK with me, but I won't start the code quality work until you 
say you have finished formatting.

Thanks,

Brian

Done a one time format of all code with Japloy default settings, and
checked it in.

All the best,

Doug

Doug Culnane wrote:
> Brian Burch wrote:
>> Q: would you add it to the maven pom.xml so it is run at every build, or 
>> just a one-time process?
> Yes it goes in the "<build>" section of the POM.  I would bind this in
> so it runs on every install phase.
>> Q: what style would you impose on the project? (I tend to use the Rogue 
>> Wave Java Style book as my base reference, then modify my code style 
>> where necessary to fit that of the project I'm working on.)
>>   
> Not sure.  Jalopy is very configurable but it "ships with sensible
> default settings (mimicking the Sun Java coding convention)."  I would
> use these. 
> 
> I could set up Jalopy and you can try it with the command. 
> mvn install
> This will format all code.  I will check in Jalopy in the POM and all
> the formatted code.  This will be a big change in the subversion
> repository, so please tell me when you have everything checked in and
> then I will do this.  After that if "mvn install" is run regularly then
> the formatting will be stable and only new stuff will get altered. 
> However you need to be aware that you and your formatter are changing
> code and this can get confusing and create SVN conflicts.
> 
> The problem with setting up an IDE is that a project uses multiple
> IDEs.  JUnit, Eclipse and Netbeans have now all be used for the GINP. 
> Getting these set up the same is not easy.
> 
> An alternative is to run Jalopy once from the command line, but this
> need to be done regularly.

Thanks for explaining. I think it is not worth the extra complexity to 
setup and run Jalopy on every build. I can't imagine us suddenly 
attracting a large number of active and anarchic developers...

I think the best approach is for you to run Jalopy against your own 
sandbox with the Sun style (if that suits you best). You can then take a 
look at the reports and source code it produces - and whether the build 
still works successfully. Assuming you don't have any big problems and 
you like the results, then just commit the cleaned-up modules. (It might 
be worth tagging before and after - or is that just "cvs thinking"?)

Let me have a reference to whatever style you adopt. I'll run an update 
against my sandbox to collect your changes and simply(?) follow the new 
coding style for any future changes I make.

> Another alternative is not to do any formatting but this also has problems.

No, I think it is probably worth the one-time effort to tidy the code. 
If you do the Jalopy stuff, I'll reciprocate (when you have finished!) 
by fixing some of the more embarrassing problems from the code quality 
reports.

I didn't plan to make any more changes for a week or so. If you want to 
do the Jalopy run further away than that, just let me know so I can 
commit any pending changes before you start. Once you start running 
Jalopy, I'll consider the repository frozen until you tell me you have 
finished with it.

Regards,

Brian

Brian Burch wrote:
> Q: would you add it to the maven pom.xml so it is run at every build, or 
> just a one-time process?
>   
Yes it goes in the "<build>" section of the POM.  I would bind this in
so it runs on every install phase.
> Q: what style would you impose on the project? (I tend to use the Rogue 
> Wave Java Style book as my base reference, then modify my code style 
> where necessary to fit that of the project I'm working on.)
>   
Not sure.  Jalopy is very configurable but it "ships with sensible
default settings (mimicking the Sun Java coding convention)."  I would
use these. 

I could set up Jalopy and you can try it with the command. 
> mvn install

This will format all code.  I will check in Jalopy in the POM and all
the formatted code.  This will be a big change in the subversion
repository, so please tell me when you have everything checked in and
then I will do this.  After that if "mvn install" is run regularly then
the formatting will be stable and only new stuff will get altered. 
However you need to be aware that you and your formatter are changing
code and this can get confusing and create SVN conflicts.

The problem with setting up an IDE is that a project uses multiple
IDEs.  JUnit, Eclipse and Netbeans have now all be used for the GINP. 
Getting these set up the same is not easy.

An alternative is to run Jalopy once from the command line, but this
need to be done regularly.

Another alternative is not to do any formatting but this also has problems.

Let me know what you want?

All the best,

Doug

Doug Culnane wrote:
> Dear Brian,
> 
> After your points about code style I thought I would check in a bit of
> Maven QA reporting.  This produces reports that are not good for my ego
> but they are a great way to measure code quality and the quality
> improvements if any...
> 
> Update with
>> svn up
> 
> Generate site locally using:
>> mvn site
> 
> Check out reports at: ginp/target/site/project-reports.html

It worked very well, although I had to run it from a command line.

This was because my Netbeans maven2 had problems finding some 
dependencies when running the custom goal called "site". I'll worry 
about it another time...

> Let me know if we really want this in the live site....?  I am happy to
> publish and I think it will motivate me to improve quality.

No, I don't think this needs to be on the main site until you feel we 
are ready to publish an 0.30 war for download. At that time, I don't see 
a problem confessing to bad style. As you say, with the reports as a 
reminder, it encourages us to do a bit extra whenever working on a 
particular module. No need for explicit objectives, just good intentions.

Of course, now that I can run the reports locally, I'll be able to do 
something myself.

> Also let me know if you want the code formated automatically with Jalopy?

I didn't know about Jalopy, but have just looked at the site at SourceForge.

Q: would you add it to the maven pom.xml so it is run at every build, or 
just a one-time process?

Q: what style would you impose on the project? (I tend to use the Rogue 
Wave Java Style book as my base reference, then modify my code style 
where necessary to fit that of the project I'm working on.)

Brian

Dear Brian,

After your points about code style I thought I would check in a bit of
Maven QA reporting.  This produces reports that are not good for my ego
but they are a great way to measure code quality and the quality
improvements if any...

Update with
> svn up

Generate site locally using:
> mvn site

Check out reports at: ginp/target/site/project-reports.html

Let me know if we really want this in the live site....?  I am happy to
publish and I think it will motivate me to improve quality.

Also let me know if you want the code formated automatically with Jalopy?

All the best,

Doug

Brian Burch wrote:
> Doug, I wonder whether you can help my understanding of the ginp webapp 
> by correcting any mis-apprehensions I might have?
>
>
> 1. ginp.xml defines the photo directory list to an instance of the webapp.
>   
Yes.  You define your root folders, which are your "Collections".
> 2. All users browsing the same webapp (context) navigate the same set of 
> photos because they all "share" the same ginp.xml.
>   
No each root folder has an optional user/password restriction.
> 3. No matter what you tell the configuration wizard about your existing 
> or new ginp.xml, the file that is actually used to find and show 
> pictures MUST exist as /ginp/WEB-INF/ginp.xml.
>   
In the current 2 year old release you can set the location of your
file.  This (in my opinion) is not ideal.  I started to rewrite the
wizard to get rid of Tapestry and its dependencies, and to fix the
location of the con fig file in %WebAP_context_Name%/WEB-INF/ginp.xml

> 4. ginp.xml can point to more than one "Collection" of photos, each is 
> found in the local filesystem (but normally outside the webapp directory).
>   
Yes.
> 5. The Collection logic assumes you will have a 3-deep file hierarchy, 
> e.g. 
> /path-to-some-directory/individual-photo-directory/one-or-more-jpegs. 
> You need to represent your "complete collection" of photos (however it 
> might really be organised) as a set of 3-level Collection objects within 
> ginp.xml.
>   
No.  Multiple depth is possible.  Define the root in ginp.xml and the
ginp does the rest.  folders and files are read directly from the file
system.  Only thumbnails are stored in a special sub-directory in each
folder.
> 6. The ginp.xml file is read during each webapp startup - it is NOT 
> currently cached as some kind of persistent object that survives a 
> tomcat restart or deployment of a new war file.
>   
True.  Read at configure during startup.  It's persistence comes from
the file on the disk.
> 7. Does the security stuff work? i.e. shouldn't a Collection defined 
> with users and/or administrators only be viewed after a logon has been 
> forced? (This doesn't seem to work on my system, so I currently add 
> security constraints to ginp's web.xml to make tomcat enforce my access 
> rules.)
>   
Should work but the wizard does not create the file correctly.  In the
old days (last release) admin users could edit a XML file that contained
data for the folder.  I removed this feature because I wanted to use
EXIF or a database to store data.  This work is not started.
> 8. The setup application (only?) uses Hivemind and Hibernate to create 
> an external  persistent representation of ginp.xml as a java object. 
> Does it work? Is the persistent object ever used outside the 
> configuration wizard? How does this all relate to the use and 
> maintenance of the "real" ginp.xml file?
>   
Hibernate was written out (or should be).  Hivemind did work but I never
finished the conversion of the wizard and do not understand how best to
use Hivemind.
> ---------
>
> One of my reasons for suggesting that we refactor the setup logic into a 
> maven sub-project was to help clarify these issues for anyone looking at 
> the code for the first time.
>
> I really don't know how much of what we have now is mainline logic, how 
> much is work-in-progress, and how much is abandoned experimentation.
>   
Me neither.  which is why Hibernate got cleaned out and Tapestry too. 
All we need is an HTML form to write an initial config file.  Hivemind
is very interesting but need to be understood and I just did not get
round to this.

Sorry this is a mess if you need help let me know and I can clean it up
a bit.

All the best,

Doug
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ginp-developers mailing list
> Gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-developers
>   

Brian Burch wrote:
> Doug, I hope you can spare a few minutes to deal with this list of loose 
> ends for me...
>
> 1. I have updated the "manual". I've made a few cosmetic changes and 
> fixed some typos, but mainly I've re-organised and expanded the initial 
> "Getting Started" section. In particular, I've described how to work 
> around a failure in the configuration wizard. I've worded it so when we 
> get round to fixing the problem, the manual will still make some sort of 
> sense.
>
> I intend to do some work on the next section "How to build the ginp into 
> your site" fairly soon, but I've got to try doing it myself first.
>
>
> 2. If you are happy with this latest change, would you mind updating the 
> public site on SourceForge? I noticed my last significant change - the 
> "new" GetFolderInfo.java module hasn't turned up on the CVS change log yet.
>   
Will try to update the public site for you now.  Check the last
published date on each page.
> Without this module, the non-basic demo styles will continue to crash as 
> soon as they are selected.
>
>
> 3. Incidentally, the latest download shown on 
> http://sourceforge.net/project/showfiles.php?group_id=105663
> is labelled v0.23 and dated nearly TWO YEARS AGO! Is this correct?
>   
Yes.  As mentioned earlier a release is long overdue but the code has
not got to release stage for it to happen.
>
> 4. While working on manual.xml, I couldn't check it properly on my own 
> web site. This is because the demo index page links to 
> /src/main/webapp/manual.jsp, but the jsp tries to present a non-existent 
> file called /docs/manual.html to the browser. Anyway, manual.xml is not 
> even shipped in ginp.war at the moment.
>   
This is an error there should be no JSP pages in the website they are
all HTML now.  Do a
> mvn site
this generates the public website in your target/site folder.  You can
check it there.
> This is obviously a hangover from the pre-maven days, but I'm not sure 
> how best to tidy it up. Do you have any suggestions? It would make 
> future updates to the manual easier to test if it were deployed properly.
>   
Not sue how to do this either.  Link to the public website would be easiest.
>
> 5. I keep getting pangs of conscience when working on the source. The 
> code looks very messy when viewed with my netbeans ide. It is full of 
> tab characters, but they are presumably rendered differently to your 
> development system.
>
> Several years ago, I had a change rejected from a mature open source 
> project because of my embedded tab characters. I was sternly told the 
> project had coding style rules that must be adhered to. Since that time, 
> I've worked on several open source projects that have different style 
> rules, BUT ALL BAN TAB CHARACTERS. These days I simply leave both 
> netbeans and eclipse to their default settings - to replace local tabs 
> with 4 space characters and indent continuations with 8 spaces. This 
> standard seems to be widely implemented.
>
> So, I'm basically apologising for messing up the appearance of your code 
> whenever I touch a line... when I save the file each line that I've 
> modified has its tabs replaced with spaces. I hope this isn't causing 
> too much confusion and irritation.
>   
Code formatters cause problems with managing changes in source code.  I
can build jalopy and checkstyle into the Maven build to automatically
format and report on code format errors if you like.  This is a question
of taste but I think the this is the best method of coping with code
formatting.   Do you want this?  The alternative is setting up your
IDE.  Either way it is your call on how to do this but I can offer you
what I think is a cool Maven solution.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ginp-developers mailing list
> Gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-developers
>   

Doug, I wonder whether you can help my understanding of the ginp webapp 
by correcting any mis-apprehensions I might have?

1. ginp.xml defines the photo directory list to an instance of the webapp.

2. All users browsing the same webapp (context) navigate the same set of 
photos because they all "share" the same ginp.xml.

3. No matter what you tell the configuration wizard about your existing 
or new ginp.xml, the file that is actually used to find and show 
pictures MUST exist as /ginp/WEB-INF/ginp.xml.

4. ginp.xml can point to more than one "Collection" of photos, each is 
found in the local filesystem (but normally outside the webapp directory).

5. The Collection logic assumes you will have a 3-deep file hierarchy, 
e.g. 
/path-to-some-directory/individual-photo-directory/one-or-more-jpegs. 
You need to represent your "complete collection" of photos (however it 
might really be organised) as a set of 3-level Collection objects within 
ginp.xml.

6. The ginp.xml file is read during each webapp startup - it is NOT 
currently cached as some kind of persistent object that survives a 
tomcat restart or deployment of a new war file.

7. Does the security stuff work? i.e. shouldn't a Collection defined 
with users and/or administrators only be viewed after a logon has been 
forced? (This doesn't seem to work on my system, so I currently add 
security constraints to ginp's web.xml to make tomcat enforce my access 
rules.)

8. The setup application (only?) uses Hivemind and Hibernate to create 
an external  persistent representation of ginp.xml as a java object. 
Does it work? Is the persistent object ever used outside the 
configuration wizard? How does this all relate to the use and 
maintenance of the "real" ginp.xml file?

---------

One of my reasons for suggesting that we refactor the setup logic into a 
maven sub-project was to help clarify these issues for anyone looking at 
the code for the first time.

I really don't know how much of what we have now is mainline logic, how 
much is work-in-progress, and how much is abandoned experimentation.

Doug, I hope you can spare a few minutes to deal with this list of loose 
ends for me...

1. I have updated the "manual". I've made a few cosmetic changes and 
fixed some typos, but mainly I've re-organised and expanded the initial 
"Getting Started" section. In particular, I've described how to work 
around a failure in the configuration wizard. I've worded it so when we 
get round to fixing the problem, the manual will still make some sort of 
sense.

I intend to do some work on the next section "How to build the ginp into 
your site" fairly soon, but I've got to try doing it myself first.

2. If you are happy with this latest change, would you mind updating the 
public site on SourceForge? I noticed my last significant change - the 
"new" GetFolderInfo.java module hasn't turned up on the CVS change log yet.

Without this module, the non-basic demo styles will continue to crash as 
soon as they are selected.

3. Incidentally, the latest download shown on 
http://sourceforge.net/project/showfiles.php?group_id=105663
is labelled v0.23 and dated nearly TWO YEARS AGO! Is this correct?

4. While working on manual.xml, I couldn't check it properly on my own 
web site. This is because the demo index page links to 
/src/main/webapp/manual.jsp, but the jsp tries to present a non-existent 
file called /docs/manual.html to the browser. Anyway, manual.xml is not 
even shipped in ginp.war at the moment.

This is obviously a hangover from the pre-maven days, but I'm not sure 
how best to tidy it up. Do you have any suggestions? It would make 
future updates to the manual easier to test if it were deployed properly.

5. I keep getting pangs of conscience when working on the source. The 
code looks very messy when viewed with my netbeans ide. It is full of 
tab characters, but they are presumably rendered differently to your 
development system.

Several years ago, I had a change rejected from a mature open source 
project because of my embedded tab characters. I was sternly told the 
project had coding style rules that must be adhered to. Since that time, 
I've worked on several open source projects that have different style 
rules, BUT ALL BAN TAB CHARACTERS. These days I simply leave both 
netbeans and eclipse to their default settings - to replace local tabs 
with 4 space characters and indent continuations with 8 spaces. This 
standard seems to be widely implemented.

So, I'm basically apologising for messing up the appearance of your code 
whenever I touch a line... when I save the file each line that I've 
modified has its tabs replaced with spaces. I hope this isn't causing 
too much confusion and irritation.

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

The JasperException was telling the truth, but it took me a while to 
stop searching for a self-inflicted ClassLoader problem and do some 
proper diagnosis.

The ginp.tld file had been carried over from the pre-maven source 
without significant change except refactoing to the new package names. 
It relates a tag called "getfolderinfo" to the refactored tag 
implementation class net.sf.ginp.tags.GetFolderInfo.

When I looked carefully at the source package net.sf.ginp.tags, I saw 
this class was completely missing... hence the failures. The tag 
<ginp:getfolderinfo> is used by collection.jsp in each of the three 
styles, but crucially not in the Base style (which worked OK).

I compared GetFolderInfo.java from the V0-13-5, pre-setup and post-setup 
repositories. post-setup was the latest, so I used it to create a new 
class in net.sf.ginp.tags. I then converted it to Commons Logging, 
resolved the other import errors and upgraded the calls to 
GinpModel.getLanguageCode().

The build is successful and I'm very pleased to say it all works fine on 
my own tomcat server.

Perhaps this is a good opportunity to generate a new snapshot for the 
public web site?

Brian

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

2004	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (7)
2005	Jan (35)	Feb (7)	Mar (18)	Apr (6)	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2007	Jan (28)	Feb (3)	Mar	Apr	May	Jun	Jul (5)	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug (1)	Sep (1)	Oct	Nov (1)	Dec (14)
2009	Jan (31)	Feb (8)	Mar (21)	Apr (30)	May (86)	Jun (78)	Jul (41)	Aug (33)	Sep (20)	Oct (38)	Nov (9)	Dec (4)
2010	Jan	Feb	Mar (32)	Apr (53)	May (20)	Jun (18)	Jul (9)	Aug (1)	Sep (1)	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (3)	Dec
2014	Jan (1)	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

ginp-developers Mailing List for Java Photo Gallery Web Application (Page 2)

ginp-developers — ginp Developers