[jira] Updated: (FOR-549) plugin DTD catalogs are not included when running as a servlet WAR
[ http://issues.apache.org/jira/browse/FOR-549?page=all ] David Crossley updated FOR-549: --- Fix Version: 0.8-dev 0.7 Version: 0.8-dev plugin DTD catalogs are not included when running as a servlet WAR -- Key: FOR-549 URL: http://issues.apache.org/jira/browse/FOR-549 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7, 0.8-dev Reporter: David Crossley Fix For: 0.8-dev, 0.7 When using a WAR file under a full Jetty, the plugins catalog.xcat files are not being included. In the webapp, the path to build/plugins/ is different. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-550) build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat
[ http://issues.apache.org/jira/browse/FOR-550?page=all ] David Crossley updated FOR-550: --- Fix Version: 0.8-dev 0.7 Version: 0.7 0.8-dev build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat Key: FOR-550 URL: http://issues.apache.org/jira/browse/FOR-550 Project: Forrest Type: Bug Components: XML grammars validation Versions: 0.7, 0.8-dev Reporter: David Crossley Priority: Minor Fix For: 0.8-dev, 0.7 Attachments: plugins-catalog.txt The generated build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat which definitely breaks when using a war file and is not ideal in the other forrest methods. Patch attached which uses relative paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-550) build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat
[ http://issues.apache.org/jira/browse/FOR-550?page=all ] David Crossley closed FOR-550: -- Resolution: Fixed Fixed in both trunk and 0.7 branch. build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat Key: FOR-550 URL: http://issues.apache.org/jira/browse/FOR-550 Project: Forrest Type: Bug Components: XML grammars validation Versions: 0.7, 0.8-dev Reporter: David Crossley Priority: Minor Fix For: 0.8-dev, 0.7 Attachments: plugins-catalog.txt The generated build/plugins/catalog.xcat has full pathnames to each individual plugin catalog.xcat which definitely breaks when using a war file and is not ideal in the other forrest methods. Patch attached which uses relative paths. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-548) project DTD catalogs are not included when running as a servlet WAR
[ http://issues.apache.org/jira/browse/FOR-548?page=all ] David Crossley updated FOR-548: --- Fix Version: 0.8-dev 0.7 Version: 0.8-dev project DTD catalogs are not included when running as a servlet WAR --- Key: FOR-548 URL: http://issues.apache.org/jira/browse/FOR-548 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7, 0.8-dev Reporter: David Crossley Fix For: 0.8-dev, 0.7 When using a WAR file under a full Jetty, the project catalog.xcat is not being included. The webapp has different paths (webapp/project/*) for the project resources. The src/documentation/classes/CatalogManager.properties file defines the relative path to the project catalog.xcat, which is then broken in a war. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FOR-548) project DTD catalogs are not included when running as a servlet WAR
[ http://issues.apache.org/jira/browse/FOR-548?page=all ] David Crossley resolved FOR-548: Resolution: Incomplete The two different paths were added to the fresh-site/src/documentation/classes/CatalogManager.properties This is a workaround, so the issue is marked as Incomplete. project DTD catalogs are not included when running as a servlet WAR --- Key: FOR-548 URL: http://issues.apache.org/jira/browse/FOR-548 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7, 0.8-dev Reporter: David Crossley Fix For: 0.8-dev, 0.7 When using a WAR file under a full Jetty, the project catalog.xcat is not being included. The webapp has different paths (webapp/project/*) for the project resources. The src/documentation/classes/CatalogManager.properties file defines the relative path to the project catalog.xcat, which is then broken in a war. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Project participation and hackability (was: [VOTE] merge locationmap branch with trunk)
Since this is about project process, hopefully by my opinions I'm not violating some unspoken pmc-only line here... On 6/25/05, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: The discussion that has sparked following the request to merge incomplete branches in the trunk, along with Tim's comments, gives me the opportunity to discuss about how we could manage code change. The goal is to increase developer participation and involvment in the Forrest Project, by reducing the barrier to entry. related As one whose recently climbed that barrier, I'd suggest that the largest barrier of entry to forrest development is it's own cocoon foundations. While patches, trunks, and branches are common, sitemaps and other cocooon concepts take a lot of learning (== time investment==barrier). Of course, I could just be the slow one of the crowd too. I suspect I'm not the only one that looked at forrest and had the initial question, where's the code? /related ... Imagine that all cutting-edge users can use the trunk in production. A patch is just a couple of actions away. And after incorporation, the check is instantaneous, and on a *real* test, as it actually get used. I may be very well be in a unique situation but I can't imagine many folks are able to run a trunk on a live production machine? What about the CM baggage? If I were a client of that *real* test, I think I'd be concerned. If the recent JRE-version related discussion around release time are any indiciation, this is not necessarily unique. This can only work if the trunk is always *usable*, and not only _buildable_. This can make our trunk be really bug-free, as there would really be a lot of eyes looking at the code. I said before that I do like a usable trunk (i.e. buildable + runnable with no hoop jumping). I would thus propose that the trunk be always *releaseable* at all times, and that all new functionality that interferes with usage of prior features be developed on separate branches. This, however, is quite a committment. While I'm for a usable trunk, extending that though to a releasable trunk is more committment than I'd want. Maybe I'm reading too much into it but claiming that at any given moment the trunk is [apache] release quality is bold. Furthremore, these branches should merge whenever possible between them in a single branch so that they can be coded together, and get merged with the trunk only when all developer-known bugs are fixed. I understand that there will inevitably be dependencies between branches but I don't care for merging branches into a single branch (btw, wouldn't that ultimately become the defacto dev trunk?). I hate to keep bringing this up but in the current locationmap branch, we have locationmap functionality==trunkable and views==just-a-hair-shy-of-trunkable; the result is that it's difficult to merge lcoationmap now even thought it's mature enough to be merged. Granted the hurdles we're facing there are trivial but it's a useful example. The point is that if more than one functional components progress on independent paths towards maturity yet exist in the same branch, then there would be a dificult time getting the most mature functionality out the door independent of the others. For those inevitable dependencies, perhaps there's an idea of a branch of a branch given that svn branch is but a copy? This will also make it easier for us to release often, and to learn to make smaller reversible changes rather than big ones that are hard to understand by other developers and users. Let me know what you think. I guess the summary is that this sounds like an Always-Branch system as opposed to the more pragmatic Branch-When-Needed system and that seems overly rigid for little return. In other words, I doubt that a lot of folks are able to run a trunk in a production environment and so burdening yourselves with the overhead of maintaining a trunk in a releasable state for what would amount to a handful of folks that could use it (and likely already have svn loaded anyway) doesn't seem worth it. --tim
