For a while the SAIL page on SourceForge has been a bit of a dead end for anyone who didn't already know what SAIL was. Basically, the link to the demo didn't work.
I'd added a link to that from the Pas root page on the wiki and added a link to that from the SAIL sourceforge page. So now you can tell anyone interested in SAIL to go to sail.sf.net, like we always have, and they'll actually be able to click through to a demo.
I'm still trying to redeploy the Pas project site with Maven, but it looks like my checkout is corrupted somehow. This came up a month or two ago so I'll go look for e-mails that might help me sort it out.
Now the Maven projects in the SAIL and TELS codebases build and deploy sites again. I also got the hierarchical site linking working partially. If you go to the main SAIL Framework page, http://sail.sourceforge.net/ you'll see a Modules list which has "SAIL Core". For some reason the URL is messed up though.
Go to the main TELS page, http://tels.sourceforge.net/ and you'll see three modules: Sensemaker, Pedraw and Pas Suite. For some reason the URLs are wrong for the first too. But click on Pas Suite and you'll see another Modules section with the subparts. The links work for PLR and WPC, but not for PAR or PAWS.
Keeping our projects structured hierarchically should help new users understand how all the projects fit together. I think the reason the hierarchy isn't being reflected correctly on the site is in part due to the mix we have of flat and nested folders for our projects. I think the Maven standard practice is to make the directory hierarchy match the project hierarchy. It makes writing and updating all those relative paths unnecessary. And I think if we moved to this it wouldn't impact Eclipse use since every Java project is a leaf node in the tree. It's only POM projects that have children, but we don't need to edit those in Eclipse. A simple text editor on the file system will do and I'd say that it's even better.
Scott, what do you think of moving to nested project folders? If we do make the move, it would be a good time to take a forward look at all the groupId and artifactIds and parent relationships of all the projects.
-Turadg
On 10/13/06, Turadg Aleahmad <tur...@gmail.com> wrote:
> For a while the SAIL page on SourceForge has been a bit of a dead end > for anyone who didn't already know what SAIL was. Basically, the link > to the demo didn't work.
> I'd added a link to that from the Pas root page on the wiki and added > a link to that from the SAIL sourceforge page. So now you can tell > anyone interested in SAIL to go to sail.sf.net, like we always have, > and they'll actually be able to click through to a demo.
> I'm still trying to redeploy the Pas project site with Maven, but it > looks like my checkout is corrupted somehow. This came up a month or > two ago so I'll go look for e-mails that might help me sort it out.
On Fri, 2006-10-13 at 21:19 -0400, Turadg Aleahmad wrote: > I got the "corrupted" checkout sorted out.
> Now the Maven projects in the SAIL and TELS codebases build and deploy > sites again. I also got the hierarchical site linking working > partially. If you go to the main SAIL Framework page, > http://sail.sourceforge.net/ > you'll see a Modules list which has "SAIL Core". For some reason the > URL is messed up though.
I was struggling with a similar problem at the same time. I was trying to setup m2 poms for the concord projects. And I was getting weird urls for the scm. I finally tracked it down to inheritance.
> Keeping our projects structured hierarchically should help new users > understand how all the projects fit together. I think the reason the > hierarchy isn't being reflected correctly on the site is in part due > to the mix we have of flat and nested folders for our projects. I > think the Maven standard practice is to make the directory hierarchy > match the project hierarchy. It makes writing and updating all those > relative paths unnecessary. And I think if we moved to this it > wouldn't impact Eclipse use since every Java project is a leaf node in > the tree. It's only POM projects that have children, but we don't > need to edit those in Eclipse. A simple text editor on the file > system will do and I'd say that it's even better.
> Scott, what do you think of moving to nested project folders? If we > do make the move, it would be a good time to take a forward look at > all the groupId and artifactIds and parent relationships of all the > projects.
I agree now. Originally I pushed for the flat folder approach because I thought it would be easier for Eclispe users. But I've found that at least with subversion you can check out a project and uncheck the "Check recursively" box. Also the m2eclipse plugin can handle nested maven projects, so even if you did check out all of pas-suite it could still work. So checking out the entire pas-suite would be really easy, if they were nested. This would help developers like Laurel that want to have everything.
In other maven news, I made up a little xslt that helps manage the redundant information in pom.xml files. It can be run over a pom and update any of the redundant info: parent version number, bootstrap repository, scm. I'm using it for the concord m2 poms. I'll find some place to put it in the sail and pas svn repositories.
|
