[jira] Updated: (MDOAP-25) foaf:Organization usage doesn't comply with DoaP/FoaF specs.
[ http://jira.codehaus.org/browse/MDOAP-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Fliss updated MDOAP-25: --- Attachment: MDOAP-25.patch This is a patch that generates correct foaf:Organization tags in relation to foaf:Person tags. It includes unit test updates. foaf:Organization usage doesn't comply with DoaP/FoaF specs. Key: MDOAP-25 URL: http://jira.codehaus.org/browse/MDOAP-25 Project: Maven 2.x DOAP Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Any Reporter: Tim Fliss Priority: Minor Attachments: doap-organization-bugreport.tgz, MDOAP-25.patch Summary The foaf:Organization node is misplaced inside the foaf:Person node. It is not compliant with the FoaF or Doap specs. The Problem This is an instance of the issue described here: http://lists.foaf-project.org/pipermail/foaf-dev/2009-January/009452.html foaf:Organization like foaf:Group is a foaf:Agent (see http://xmlns.com/foaf/spec/#term_Agent), so the issue is the same. The recommended syntax from the DoaP project examples is to use the foaf:member property between the foaf:Organization node and the foaf:Person node. Unfortunately, per the FoaF spec, the relation only goes in that direction (Organization-member-Person) with no convenient inverse property. The Fix The best fix I can currently find is to use blank nodes and a separate Organization element that is not nested in the person element. Unfortunately, because the DoaP plugin isn't using native RDF tools internally, this will require a little more bookkeeping. rdf:RDF doap:Project maintainer rdf:nodeID=jdoe/ founder rdf:nodeID=jdoe/ /doap:Project Person nodeID=jdoe nameJohn Doe/name mbox rdf:resource=mailto:j...@example.org; / /Person doap:Organization doap:homepage rdf:resource=http://www.example.org; / doap:member rdf:nodeID=jdoe / /doap:Organization /rdf:RDF Additional Info Info about rdf:nodeID is available at: http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-blank-nodes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOAP-24) programing-language, os and name properties should be an RDF literals, not a RDF resources.
programing-language, os and name properties should be an RDF literals, not a RDF resources. --- Key: MDOAP-24 URL: http://jira.codehaus.org/browse/MDOAP-24 Project: Maven 2.x DOAP Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Any Reporter: Tim Fliss Priority: Minor Attachments: doap-language-bugreport.tgz, maven-doap-plugin.diff Summary The programming-language, os, and name properties are literals, not URIs. They should not be written as rdf:resources in the RDF output. The Problem While the resulting RDF will validate, what happens is that an RDF parser will interpret programming-language rdf:resource=java / as a URI fragment. (see the attached incorrect doap-language-bugreport.tgz:/target/site/doap_doap-language.rdf) Since there is no explicit xml:base in the DoaP file generated by the plugin, the resulting URL is based on the default supplied by the RDF parser. For example using the W3C RDF Validator yields: http://www.w3.org/RDF/Validator/run/java rather than simply java XML Base for RDF is specified at: see http://www.w3.org/TR/2003/PR-rdf-syntax-grammar-20031215/#section-Syntax-ID-xml-base Also note that the Apache Doap instructions correctly do not have rdf:resource for the programming language element: http://projects.apache.org/languages.html The Fix Instead of programming-language rdf:resource=java /, the plugin should generate programming-languagejava/programming-language. Similar changes apply to the os and name properties. Validation I am attaching diffs that include changes to the unit tests. Also, the RDF validator at http://www.w3.org/RDF/Validator/direct may be used to demonstrate that the progamming language, etc. elements are getting resolved to: http://www.w3.org/RDF/Validator/run/java rather than simply java. Simply java is what it should be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOAP-25) foaf:Organization usage doesn't comply with DoaP/FoaF specs.
foaf:Organization usage doesn't comply with DoaP/FoaF specs. Key: MDOAP-25 URL: http://jira.codehaus.org/browse/MDOAP-25 Project: Maven 2.x DOAP Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Any Reporter: Tim Fliss Priority: Minor Attachments: doap-organization-bugreport.tgz Summary The foaf:Organization node is misplaced inside the foaf:Person node. It is not compliant with the FoaF or Doap specs. The Problem This is an instance of the issue described here: http://lists.foaf-project.org/pipermail/foaf-dev/2009-January/009452.html foaf:Organization like foaf:Group is a foaf:Agent (see http://xmlns.com/foaf/spec/#term_Agent), so the issue is the same. The recommended syntax from the DoaP project examples is to use the foaf:member property between the foaf:Organization node and the foaf:Person node. Unfortunately, per the FoaF spec, the relation only goes in that direction (Organization-member-Person) with no convenient inverse property. The Fix The best fix I can currently find is to use blank nodes and a separate Organization element that is not nested in the person element. Unfortunately, because the DoaP plugin isn't using native RDF tools internally, this will require a little more bookkeeping. rdf:RDF doap:Project maintainer rdf:nodeID=jdoe/ founder rdf:nodeID=jdoe/ /doap:Project Person nodeID=jdoe nameJohn Doe/name mbox rdf:resource=mailto:j...@example.org; / /Person doap:Organization doap:homepage rdf:resource=http://www.example.org; / doap:member rdf:nodeID=jdoe / /doap:Organization /rdf:RDF Additional Info Info about rdf:nodeID is available at: http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-blank-nodes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-20) Antrun plugin defaults to using jre classpath instead of jdk
[
http://jira.codehaus.org/browse/MANTRUN-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=135753#action_135753
]
Tim Fliss commented on MANTRUN-20:
--
I agree. Normal doesn't mean correct. referencing tools.jar seems to be the
workaround (an unsatisfactory one if you need to build on macs because of all
the extra profile settings). If java.home pointed at the actual java.home set
by the user, and would find tools.jar on its own. In any case a better
explanation would help.
Antrun plugin defaults to using jre classpath instead of jdk
Key: MANTRUN-20
URL: http://jira.codehaus.org/browse/MANTRUN-20
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Reporter: ruel loehr
Assignee: Brett Porter
When executing ant tasks via the antrun plugin, maven reconciles them with a
jre classpath. You can verify this by running the antrun plugin with the
following task:
echo message={java.home/
The solution I can see is to add a plugin dependency on the antrun plugin
which resolves to the tools.jar, however another bug prevents this from
working in anything but top level projects. Hence, the antrun plugin cannot
be used for any compilation purposes (javac, rmic) for child projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
