Re: License question about Adobe Indesign
Thorsten Scherler wrote: > Hello guys, > > I have a question about Adobe Indesign license. > > Would it be ok to partly reverse engineer the inx - format for us within > a plugin? > > I am not talking about the whole format. I am talking about some > attributes and storing habits of values. I think we need more information to see what the issues might be. Would you provide a URL to any license info. And is there an example of what you are trying to create. > The idea would be to have inx-templates (export format of an indesign > file *.indd) and change some properties and add content. You would need > Indesign installed to create templates, trying to say it can be from > interest for Adobe if we would create such a plugin. More details please about the outputs and inputs. Which part does Forret handle? Are their formats published? > I found out that e.g. a box has a corresponding tag. This tag > has an @IGeo="value". I further found out that this @IGeo values store > information in a certain way about "geographic" information like > position et all.. > > Would it be ok if I develop a plugin in forrest this way. Don't know yet. > Should I > contact Adobe and ask whether we from Apache Forrest can do that? Not necessary at this stage. If we cannot answer it at forrest-dev then take it to [EMAIL PROTECTED] --David
Re: better use of Jira for Forrest
Done. That clarifies the Roadmap. Do any people out in the Forrest dev community know other things that we can do to improve our use of Jira? Or point to projects that use it well. --David
Re: status.xml in "seed site"
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: Ross, during the move of the status/changes/todo processing into the projectInfo plugin, the status.xml file was removed at main/fresh-site/status.xml ... Was that deliberate? ... I did remove it because I moved the functionality from core and to use status.xml you now need to be specifically include the projectInfo plugin in a project. Therefore no status.xml in the seeded site. ... Lets leave it out. Being the one that has unified todo.xml and changes.xml in status.xml and put it in the main dir: +1 Going back I would not do it again, as ATM I believe that having these files separated and in a directory is better. Taking it out of the core makes us not force all users into using it again. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
License question about Adobe Indesign
Hello guys, I have a question about Adobe Indesign license. Would it be ok to partly reverse engineer the inx - format for us within a plugin? I am not talking about the whole format. I am talking about some attributes and storing habits of values. The idea would be to have inx-templates (export format of an indesign file *.indd) and change some properties and add content. You would need Indesign installed to create templates, trying to say it can be from interest for Adobe if we would create such a plugin. I found out that e.g. a box has a corresponding tag. This tag has an @IGeo="value". I further found out that this @IGeo values store information in a certain way about "geographic" information like position et all.. Would it be ok if I develop a plugin in forrest this way. Should I contact Adobe and ask whether we from Apache Forrest can do that? TIA for any hints and thoughts -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
[JIRA] Created: (FOR-471) Missing "--noconfig" causes NoClassDefFoundError due to ant sourcing external config files
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-471 Here is an overview of the issue: - Key: FOR-471 Summary: Missing "--noconfig" causes NoClassDefFoundError due to ant sourcing external config files Type: Bug Status: Unassigned Priority: Major Project: Forrest Components: Launch 'forrest' Launch 'forrest run' Core operations Versions: 0.6 0.7-dev HEAD Assignee: Reporter: Richard Calmbach Created: Fri, 18 Mar 2005 12:35 PM Updated: Fri, 18 Mar 2005 12:35 PM Environment: Any system that already has an Ant installation with config files in the standard locations (/etc/ant.conf, $HOME/.ant/ant.conf, $HOME/.antrc). Description: Forrest comes with a self-contained Ant distribution. In order for it to work properly, it is important to avoid picking up Ant config files that belong to other potentially existing Ant installations on the system. On Red Hat Linux, e.g., the RPM package for ant 1.5.2 installs /etc/ant.conf. When running Forrest 0.6 out of the box (e.g., "forrest -projecthelp"), the tools/ant/bin/ant script included with Forrest sources /etc/ant.conf and picks up an incorrect value for ANT_HOME (/usr/share/ant in this case). This results in a Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher exception when trying to run forrest because there is no /usr/share/ant/lib/ant-launcher.jar. Even if there was, we wouldn't want to pick up those jars anyway, we want the ones that came with Forrest. The fix is to change line 95 (as of v0.6) in src/core/bin/forrest from "$ANT_HOME/bin/ant" -buildfile "$ANTFILE" -Dbasedir="$PROJECT_HOME" -Dforrest.home="$FORREST_DOT_HOME" -emacs $@ to "$ANT_HOME/bin/ant" --noconfig -buildfile "$ANTFILE" -Dbasedir="$PROJECT_HOME" -Dforrest.home="$FORREST_DOT_HOME" -emacs $@ This tells ant to ignore default config files, which is what we want in this case since the ant used by forrest is completely self-contained. As of 3-18-05, this bug is still present in the HEAD revision of the forrest startup script (since v0.7-dev known as bin/forrest). - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: [JIRA] Created: (FOR-470) docs and fresh-site samples for "raw content" need update
[EMAIL PROTECTED] wrote: Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-470 Here is an overview of the issue: - Key: FOR-470 Summary: docs and fresh-site samples for "raw content" need update Type: Task Status: Unassigned Priority: Minor Project: Forrest Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Reporter: David Crossley Created: Fri, 18 Mar 2005 7:08 AM Updated: Fri, 18 Mar 2005 7:08 AM Description: The documentation about "raw content" describes the method used prior to version 0.7 so we need to update docs and the fresh-site samples. faq.html and upgrading_07.html and elsewhere. I haven't been following all forrest development too closely lately since I haven't needed to use forrest myself much. What is the new "raw content" method? I did notice that the forrestbar.xpi and favicon.ico files aren't being handled properly in our own sites. I suppose the best way to answer this would be to update the documentation instead of just replying :-) -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: better use of Jira for Forrest
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: What i am proposing now is an extra step. Remove the option "HEAD version" entirely from Jira. I think it is superfluous. Sorry - I'm reading too fast this morning. If a bug is introduced into head (i.e. wasn't in the previous release) where would it go? The next release due I suppose. Seems fine to me. Yes, that is what i meant. Would it be worth naming the next release 0.8-dev and then renaming to 0.8 when it is released? (not sure if Jira allows this, I assume it does). Yes, that avoids all confusion. Good idea. I just tested by moving 0.7 to 0.7-dev ... hooray. I will do that over the weekend unless someone stops me. --David +1 Good ideas, guys. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
Re: problem with docs at forrest.apache.org/docs/dev/
Ross Gardler wrote: David Crossley wrote: Just a quick note, gotta rush out now. Yes there was stacks of discussion on this topic, but its good to be sure that we all understand, and maybe there is a flaw. The docs that are currently at docs/dev/ are 0.7-dev They will move to /docs/ when the next release happens. Then /docs/dev/ will become 0.8-dev and 0.6 (i.e. current /docs/) goes offline. Yes, that's the problem, all the mail archive links will be broken (in the sense they will refer to a different document from that referred to when the question was answered). Ross /docs/dev/ nested below /docs/ seems weird. I think it would be better to host the current stable release at a url like: /docs/0.7/. This would also permit us to keep documentation for all old releases (although we would probably want warnings on them if they are too old). 0.6 docs had to be kept at /docs/ because they didn't have a split docs/site structure so I kept it as-is. I had been thinking we'd move to something like /docs/0.7/ for future releases, but I can't find any discussion about this in particular. We should give links to documentation using a stable release, not /docs/dev (unless of course the issues in question is new to the dev version). That will keep all of our archived links good. -- Dave Brondsema : [EMAIL PROTECTED] http://www.splike.com : programming http://csx.calvin.edu : student org http://www.brondsema.net : personal signature.asc Description: OpenPGP digital signature
[JIRA] Created: (FOR-470) docs and fresh-site samples for "raw content" need update
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-470 Here is an overview of the issue: - Key: FOR-470 Summary: docs and fresh-site samples for "raw content" need update Type: Task Status: Unassigned Priority: Minor Project: Forrest Fix Fors: 0.7-dev Versions: 0.7-dev Assignee: Reporter: David Crossley Created: Fri, 18 Mar 2005 7:08 AM Updated: Fri, 18 Mar 2005 7:08 AM Description: The documentation about "raw content" describes the method used prior to version 0.7 so we need to update docs and the fresh-site samples. faq.html and upgrading_07.html and elsewhere. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: problem with docs at forrest.apache.org/docs/dev/
Ross Gardler wrote: > David Crossley wrote: > >Just a quick note, gotta rush out now. Yes there was stacks of discussion > >on this topic, but its good to be sure that we all understand, and maybe > >there is a flaw. > > > >The docs that are currently at docs/dev/ are 0.7-dev > >They will move to /docs/ when the next release happens. > >Then /docs/dev/ will become 0.8-dev and 0.6 (i.e. current /docs/) > >goes offline. > > Yes, that's the problem, all the mail archive links will be broken (in > the sense they will refer to a different document from that referred to > when the question was answered). Okay i found some of the old discussion and made links at http://issues.cocoondev.org/browse/FOR-391 --David
[EMAIL PROTECTED]: Project forrest-test (in module forrest) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project forrest-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... Full details are available at: http://brutus.apache.org/gump/public/forrest/forrest-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org/gump/public/forrest/forrest-test/gump_work/build_forrest_forrest-test.html Work Name: build_forrest_forrest-test (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only test [Working Directory: /usr/local/gump/public/workspace/forrest/main] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/forrest/build/xml-forrest.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-18032005.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-18032005/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-18032005/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-18032005/cocoon-deprecated.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-18032005.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-18032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-18032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-18032005.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-18032005.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-18032005/checkstyle-18032005.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-18032005.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-18032005.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-18032005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-18032005.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-dep-18032005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-18032005.jar:/usr/local/gump/public/workspace/excalibur/components/xmlutil/target/excalibur-xmlutil-18032005.jar:/usr/l
[JIRA] Commented: (FOR-391) website docs/site split
The following comment has been added to this issue: Author: David Crossley Created: Fri, 18 Mar 2005 5:20 AM Body: And another one ... 2005-03-17 problem with docs at forrest.apache.org/docs/dev/' http://marc.theaimsgroup.com/?t=0508874 - View this comment: http://issues.cocoondev.org//browse/FOR-391?page=comments#action_12168 - View the issue: http://issues.cocoondev.org//browse/FOR-391 Here is an overview of the issue: - Key: FOR-391 Summary: website docs/site split Type: Task Status: Open Priority: Major Project: Forrest Components: Documentation and website Fix Fors: 0.7-dev Versions: HEAD Assignee: Dave Brondsema Reporter: Dave Brondsema Created: Wed, 24 Nov 2004 10:51 PM Updated: Fri, 18 Mar 2005 5:20 AM Description: Split our website into a standalone documentation site (which will be maintained per version/branch) and the main version-independent site. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[JIRA] Commented: (FOR-391) website docs/site split
The following comment has been added to this issue: Author: David Crossley Created: Fri, 18 Mar 2005 5:18 AM Body: Some discussion on this topic ... 2004-11-02 website documentation version http://marc.theaimsgroup.com/?t=10993759641 2004-11-10 [HEADS-UP] doc reorg http://marc.theaimsgroup.com/?t=11000636233 2004-11-17 how to redirect our website changes http://marc.theaimsgroup.com/?t=11003600482 2005-02-18 [heads-up] forrest website updated http://marc.theaimsgroup.com/?t=11087131301 - View this comment: http://issues.cocoondev.org//browse/FOR-391?page=comments#action_12167 - View the issue: http://issues.cocoondev.org//browse/FOR-391 Here is an overview of the issue: - Key: FOR-391 Summary: website docs/site split Type: Task Status: Open Priority: Major Project: Forrest Components: Documentation and website Fix Fors: 0.7-dev Versions: HEAD Assignee: Dave Brondsema Reporter: Dave Brondsema Created: Wed, 24 Nov 2004 10:51 PM Updated: Fri, 18 Mar 2005 5:18 AM Description: Split our website into a standalone documentation site (which will be maintained per version/branch) and the main version-independent site. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: status.xml in "seed site"
Ross Gardler wrote: > David Crossley wrote: > >Ross, during the move of the status/changes/todo processing > >into the projectInfo plugin, the status.xml file was removed > >at main/fresh-site/status.xml ... Was that deliberate? > > > >http://svn.apache.org/viewcvs?view=rev&rev=156244 > > Ahhh... hmmm... yes... well... errr... I should have discussed this. > > I did remove it because I moved the functionality from core and to use > status.xml you now need to be specifically include the projectInfo > plugin in a project. Therefore no status.xml in the seeded site. That is what i wondered. > However, this may be a case for actually including the plugin in a > seeded site (as we do with pdf-output). > > The reason I extracted this functionlaity was because it was getting in > the way of a legacy project here and we have another projectInfo plugin > for the proprietary legacy files. But this is not a good reason for > removing it from the seeded site. > > I have no strong opinions on whether it be included with the seeded site > or not. Now that i understand what is happening, i see that not too many plugins should be included by default. Lets leave it out. Later we can have a variety of "seed sites" and they can have different things enabled. --David > If you do include it you will need to specify the plugin in > forrest.properties as well. > > Ross
Re: google desktop search in forrest
David Crossley wrote: Ross Gardler wrote: Johannes Schaefer wrote: So far this works fine. Now I need to insert the search term dynamically from the form on the page. I simply don't know how to do that. Do I need to create a Cocoon action? One way would be to use the request generator in Cocoon ( http://cocoon.apache.org/2.1/userdocs/generators/request-generator.html ). This gives you the request headers as an XML stream. Problem is you are only allowed one generator in each pipeline so you would have to do the search using the XSL Document() function. Perhaps sitemap aggregation could be used. I don't think so, we need to extract the request parameters before we can generate the response from Google Desktop. This might be a case for a new generator. It might be useful over at Cocoon as well. Ross
Re: status.xml in "seed site"
David Crossley wrote: Ross, during the move of the status/changes/todo processing into the projectInfo plugin, the status.xml file was removed at main/fresh-site/status.xml ... Was that deliberate? http://svn.apache.org/viewcvs?view=rev&rev=156244 Ahhh... hmmm... yes... well... errr... I should have discussed this. I did remove it because I moved the functionality from core and to use status.xml you now need to be specifically include the projectInfo plugin in a project. Therefore no status.xml in the seeded site. However, this may be a case for actually including the plugin in a seeded site (as we do with pdf-output). The reason I extracted this functionlaity was because it was getting in the way of a legacy project here and we have another projectInfo plugin for the proprietary legacy files. But this is not a good reason for removing it from the seeded site. I have no strong opinions on whether it be included with the seeded site or not. If you do include it you will need to specify the plugin in forrest.properties as well. Ross
Re: google desktop search in forrest
Ross Gardler wrote: > Johannes Schaefer wrote: > > >So far this works fine. > > > >Now I need to insert the search term dynamically > >from the form on the page. I simply don't know how > >to do that. Do I need to create a Cocoon action? > > One way would be to use the request generator in Cocoon ( > http://cocoon.apache.org/2.1/userdocs/generators/request-generator.html > ). This gives you the request headers as an XML stream. > > Problem is you are only allowed one generator in each pipeline so you > would have to do the search using the XSL Document() function. Perhaps sitemap aggregation could be used. --David > This doesn't seem very nice since we are moving some of the logic into > an XSL sheet. I'm sure Cocoon must provide another way. > > >And as I'm writing this: this is only a "live" > >solution ... and here we have Lucene. Hum. > > But google desktop does much more than search the Forrest site right? > > I can image this being useful in some fairly specialised situations, but > if you are after being able to search Forrest docs then you are probably > right in that it presents no benefit of lucene. > > Ross
Re: better use of Jira for Forrest
Ross Gardler wrote: > David Crossley wrote: > >What i am proposing now is an extra step. Remove the option > >"HEAD version" entirely from Jira. I think it is superfluous. > > Sorry - I'm reading too fast this morning. > > If a bug is introduced into head (i.e. wasn't in the previous release) > where would it go? The next release due I suppose. > > Seems fine to me. Yes, that is what i meant. > Would it be worth naming the next release 0.8-dev and then renaming to > 0.8 when it is released? (not sure if Jira allows this, I assume it does). Yes, that avoids all confusion. Good idea. I just tested by moving 0.7 to 0.7-dev ... hooray. I will do that over the weekend unless someone stops me. --David
status.xml in "seed site"
Ross, during the move of the status/changes/todo processing into the projectInfo plugin, the status.xml file was removed at main/fresh-site/status.xml ... Was that deliberate? http://svn.apache.org/viewcvs?view=rev&rev=156244 --David
Re: better use of Jira for Forrest
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: We need to be continually cleaning up our Jira issue tracker. There is a lot of clutter and it means that we cannot have a good view of our situation. We recently defined a stack categories. That helps to provide other ways to browse the outstanding issues. Today i removed the 0.6.1 release version. That helps with the Roadmap because now we can see the 0.8 issues too. That Roadmap shows a stack of issues marked as occuring against HEAD version and then another stack against 0.7 version. Should all the 0.7 ones be moved to HEAD, or the other way around, should all HEAD issues be moved to 0.7 version? I reckon the latter, move HEAD to 0.7 version. Then we should remove "HEAD version" as an option in Jira. What do others reckon? +1 - this seems to have the most meaning when we have 0.7 out the door. Perhaps this should be part of the release process. Everything marked as head during the code freeze should be moved to the upcoming release. Yeah that is what i did last release. What i am proposing now is an extra step. Remove the option "HEAD version" entirely from Jira. I think it is superfluous. Sorry - I'm reading too fast this morning. If a bug is introduced into head (i.e. wasn't in the previous release) where would it go? The next release due I suppose. Seems fine to me. Would it be worth naming the next release 0.8-dev and then renaming to 0.8 when it is released? (not sure if Jira allows this, I assume it does). Ross
Re: [ProjectInfo Plugin] Action layout no more taken into account...
David Crossley wrote: Cyriaque Dupoirieux wrote: Ok, Ross, I was wrong once again, I was not looking in the good direction... In fact, my status.xml declared a before the tag. (I use this section to describe - in my history of modification - the rules I apply to choose the next version of my site (3 digits version...)) When I realized this, I moved the section inside the tag and it's Ok now. I don't explain this strange behavior, our problem is that no DTD controls the status.xml... Yes, forrest-0.7-dev can now. Sjur supplied one recently. For your old project status.xml you can add the declaration ... Of course, I forgot about that. Folks, should we add that to the default status.xml in the "seed site"? +1 Ross
Re: better use of Jira for Forrest
Ross Gardler wrote: > David Crossley wrote: > >We need to be continually cleaning up our Jira issue tracker. > >There is a lot of clutter and it means that we cannot have a > >good view of our situation. > > > >We recently defined a stack categories. That helps to provide > >other ways to browse the outstanding issues. > > > >Today i removed the 0.6.1 release version. That helps with the > >Roadmap because now we can see the 0.8 issues too. > > > >That Roadmap shows a stack of issues marked as occuring against > >HEAD version and then another stack against 0.7 version. > > > >Should all the 0.7 ones be moved to HEAD, or the other way around, > >should all HEAD issues be moved to 0.7 version? > > > >I reckon the latter, move HEAD to 0.7 version. Then we should > >remove "HEAD version" as an option in Jira. > > > >What do others reckon? > > +1 - this seems to have the most meaning when we have 0.7 out the door. > Perhaps this should be part of the release process. Everything marked as > head during the code freeze should be moved to the upcoming release. Yeah that is what i did last release. What i am proposing now is an extra step. Remove the option "HEAD version" entirely from Jira. I think it is superfluous. --David
Re: [ProjectInfo Plugin] Action layout no more taken into account...
Cyriaque Dupoirieux wrote: I don't explain this strange behavior, our problem is that no DTD controls the status.xml... Yes. This is something that needs to be sorted out now that we have the projectInfo plugin. Ross
Re: google desktop search in forrest
Johannes Schaefer wrote: ... So far this works fine. Now I need to insert the search term dynamically from the form on the page. I simply don't know how to do that. Do I need to create a Cocoon action? One way would be to use the request generator in Cocoon ( http://cocoon.apache.org/2.1/userdocs/generators/request-generator.html ). This gives you the request headers as an XML stream. Problem is you are only allowed one generator in each pipeline so you would have to do the search using the XSL Document() function. This doesn't seem very nice since we are moving some of the logic into an XSL sheet. I'm sure Cocoon must provide another way. And as I'm writing this: this is only a "live" solution ... and here we have Lucene. Hum. But google desktop does much more than search the Forrest site right? I can image this being useful in some fairly specialised situations, but if you are after being able to search Forrest docs then you are probably right in that it presents no benefit of lucene. Ross
Re: [ProjectInfo Plugin] Action layout no more taken into account...
Cyriaque Dupoirieux wrote: > Ok, Ross, > >I was wrong once again, I was not looking in the good direction... >In fact, my status.xml declared a before the tag. >(I use this section to describe - in my history of modification - > the rules I apply to choose the next version of my site (3 digits > version...)) >When I realized this, I moved the section inside the tag > and it's Ok now. > >I don't explain this strange behavior, our problem is that no DTD > controls the status.xml... Yes, forrest-0.7-dev can now. Sjur supplied one recently. For your old project status.xml you can add the declaration ... It is already registered in the Forrest core catalogs, so XML editors can use it out-of-the box. Folks, should we add that to the default status.xml in the "seed site"? --David
Re: better use of Jira for Forrest
David Crossley wrote: We need to be continually cleaning up our Jira issue tracker. There is a lot of clutter and it means that we cannot have a good view of our situation. We recently defined a stack categories. That helps to provide other ways to browse the outstanding issues. Today i removed the 0.6.1 release version. That helps with the Roadmap because now we can see the 0.8 issues too. That Roadmap shows a stack of issues marked as occuring against HEAD version and then another stack against 0.7 version. Should all the 0.7 ones be moved to HEAD, or the other way around, should all HEAD issues be moved to 0.7 version? I reckon the latter, move HEAD to 0.7 version. Then we should remove "HEAD version" as an option in Jira. What do others reckon? +1 - this seems to have the most meaning when we have 0.7 out the door. Perhaps this should be part of the release process. Everything marked as head during the code freeze should be moved to the upcoming release. Ross
Re: [ProjectInfo Plugin] Action layout no more taken into account...
Ok, Ross, I was wrong once again, I was not looking in the good direction... In fact, my status.xml declared a before the tag. (I use this section to describe - in my history of modification - the rules I apply to choose the next version of my site (3 digits version...)) When I realized this, I moved the section inside the tag and it's Ok now. I don't explain this strange behavior, our problem is that no DTD controls the status.xml... Thanks, Cyriaque, Ross Gardler a écrit : Cyriaque Dupoirieux wrote: I updated these style sheets : $FORREST_HOME/plugins/org.apache.forrest.plugin.projectInfo/resources/stylesheets/changes2document.xsl and $FORREST_HOME/plugins/org.apache.forrest.plugin.projectInfo/resources/stylesheets/todo2document.xsl They are the right files. I can assure you there is nothing wrong with the local-deploy target as we've been using it to do exactly this kind of change for some time. You can verify this for yourself if you make your changes, do "ant local-deploy" and check the files in FORREST_HOME/build/plugins/. You should see your changes in those files. Assuming that I am correct and the files are being deployed this only leaves me with one of two thoughts: 1) your XSL is not correct 2) I've made some mistake in moving the code from core and in the plugin is not actually being used. You can verify 2 by making some simply, but obvious, change to one of the XSL's - perhaps have it add "It's Working" to the title. If that works then we'll need to see your XSL. Ross Ross Gardler a écrit : Cyriaque Dupoirieux wrote: Hi, I think that there is a problem with ant local-deploy target : * I had the ProjectInfo plug in which was generating well my pages, * I changed a few things in a style sheet and make a local-deploy to take them into account, * The layout - ... in my actions are lost. * Then I get back the original file and make a local-deploy again, * The layout - ... in my actions are still lost. Is there something I did not understand ? What stylesheet file are you editing? Ross
Re: google desktop search in forrest
OK, here is what I've done and some questions. To experiment I created a project with a local sitemap.xmap [1]. This contains a fixed search request to the google search server at port 4664. "format=xml" gives us a nice XML file back where we can extract and present the information [2] So far this works fine. Now I need to insert the search term dynamically from the form on the page. I simply don't know how to do that. Do I need to create a Cocoon action? To experiment yourself you'll have to look up in the Windows registry: HKEY_CURRENT_USER\Software\Google\Google Desktop\API\search_url For the final solution I would think the user hast to specify this in skinconf.xml/search. Mind you: all this is Windows only and needs Google Desktop Search installed on the server. And as I'm writing this: this is only a "live" solution ... and here we have Lucene. Hum. Then maybe there's no way to make it work since the search is only accessible from the machine it runs on. Will have to think this over again. Cheers Johannes [1] sitemap.xmap -- http://apache.org/cocoon/sitemap/1.0";> src="http://127.0.0.1:4664/search&s=?q=forrest&format=xml&num=100" /> -- [2] -- http://www.w3.org/1999/XSL/Transform";> Search Results -- Ross Gardler wrote: Johannes Schaefer wrote: Hi! Is there a way to use the Google desktop search from within Google (as an replacement of either Lucene which only works in "live" mode or Google which does not work on an intranet)? Johannes Ref. http://desktop.google.com/ http://desktop.google.com/developerguide.html#searchapi Not currently. I don't know Google Desktop search but I think this will be easy to add. The search functionality is added in your skins site2xhtml.xsl file Search that file for "start Search" and you'll find the relevant bit. If you ge this working this would be a great contribution to our code. Ross -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005 Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand www.uidesign.de/hmi2005 Nächstes TAE-Seminar zu User Interface Design Ostfildern-Nellingen, 07.-08. April 2005 www.tae.de TAE-Veranstaltung Nr. 31189
better use of Jira for Forrest
We need to be continually cleaning up our Jira issue tracker. There is a lot of clutter and it means that we cannot have a good view of our situation. We recently defined a stack categories. That helps to provide other ways to browse the outstanding issues. Today i removed the 0.6.1 release version. That helps with the Roadmap because now we can see the 0.8 issues too. That Roadmap shows a stack of issues marked as occuring against HEAD version and then another stack against 0.7 version. Should all the 0.7 ones be moved to HEAD, or the other way around, should all HEAD issues be moved to 0.7 version? I reckon the latter, move HEAD to 0.7 version. Then we should remove "HEAD version" as an option in Jira. What do others reckon? Is there anything else that we can do to improve our use of Jira? --David
[notice] websites and mail and svn not available next days
The ASF infrastructure is doing work on the servers over this extended weekend. So you may find that some services are not available. The websites will automatically fail-over to another server. The mail is the priority, and they will try to have it up again ASAP. The SVN and ViewCVS will probably not be available all weekend. Our Forrest Jira is not affected as it is hosted at cocoondev.org --David
