Apache Jena
  1. Apache Jena
  2. JENA-333

Using javadoc 7 causes warning exception in build (DAMLVocabulary, DAML_OIL)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: Jena 2.7.4
    • Fix Version/s: None
    • Component/s: Build, Ontology API
    • Labels:
      None
    • Environment:

      Java 7 (1.7.0_07) Linux 64 bit. (but not Java 1.6.0_24)

      Description

      Under java7, the build of jena core gets two stacktraces (marked as warning) in javadoc production. Unclear if the javadoc output is materially affected.

      The following two files are:

      com/hp/hpl/jena/vocabulary/DAMLVocabulary.java
      com/hp/hpl/jena/vocabulary/DAML_OIL.java

      It's unclear as to whether DAML_OIL.java problems maybe due to implementing DAMLVocabulary and nothing more.

      /usr/lib/jvm/java-7-openjdk-amd64/bin/javadoc \
      -classpath fuseki-server.jar \ – just a source of compiled Jena and all dependencies
      -encoding utf-8 \
      -d jdoc I.java

      The core problem is the form:

      -----------------------------------------------------
      import com.hp.hpl.jena.rdf.model.Resource ;
      import com.hp.hpl.jena.rdf.model.Property ;

      public interface I

      { public Resource Property(); }

      -----------------------------------------------------

      where Property is a class and a method name, which is legal, it just breaks javadoc (standard doclet).

        Activity

        Hide
        Andy Seaborne added a comment -

        Good plan.

        Show
        Andy Seaborne added a comment - Good plan.
        Hide
        Ian Dickinson added a comment -

        OK, I deleted the various DAML vocabulary classes in my local copy of Jena, and then performed a bunch of edits to make the codebase consistent and the tests pass. None of the edits were particularly bothersome - commenting out DAML-specific tests and unparser behaviours - but there were quite a lot of them. I think the right think to do is mark the classes as deprecated this cycle, and I'll remove them - and make the codebase consistent - immediately after we release so that they're gone in the next cycle. Would that be OK?

        Show
        Ian Dickinson added a comment - OK, I deleted the various DAML vocabulary classes in my local copy of Jena, and then performed a bunch of edits to make the codebase consistent and the tests pass. None of the edits were particularly bothersome - commenting out DAML-specific tests and unparser behaviours - but there were quite a lot of them. I think the right think to do is mark the classes as deprecated this cycle, and I'll remove them - and make the codebase consistent - immediately after we release so that they're gone in the next cycle. Would that be OK?
        Hide
        Andy Seaborne added a comment - - edited

        Restored default prefix mappings - tests break otherwise looking for a built-in prefix.

        It seems there are still tests of DAML stuff in Jena in TestOntAssembler. Together with DAMLMicroReasoner just how much of DAML has been removed from Jena? Maybe much/all of it is unreachable from the API.

        Can we do more removal before the next release?

        Show
        Andy Seaborne added a comment - - edited Restored default prefix mappings - tests break otherwise looking for a built-in prefix. It seems there are still tests of DAML stuff in Jena in TestOntAssembler. Together with DAMLMicroReasoner just how much of DAML has been removed from Jena? Maybe much/all of it is unreachable from the API. Can we do more removal before the next release?
        Hide
        Andy Seaborne added a comment -

        I haven't checked on the consequence of ignoring the build error - stand-alone you get one blank page but maybe whether later classes also are missing.

        We can live with two missing pages.

        If there is no other DAML in Jena any more, I think removal is in order.

        I deleted the vocabularies to see what breaks:

        reasoner - DAMLMicroReasonerFactory
        ontapi - DAML_OILProfile
        OntResourceImpl.

        Can these be cleaned up now? Is it just a case of removing old junk?

        ARP and the RDFXML unparser know about DAML vocabulary. We could move the vocabularies to be internal and do a rename of the painful Property().

        For now:

        1/ Classes marked deprecated
        2/ removed from some common prefixes

        Show
        Andy Seaborne added a comment - I haven't checked on the consequence of ignoring the build error - stand-alone you get one blank page but maybe whether later classes also are missing. We can live with two missing pages. If there is no other DAML in Jena any more, I think removal is in order. I deleted the vocabularies to see what breaks: reasoner - DAMLMicroReasonerFactory ontapi - DAML_OILProfile OntResourceImpl. Can these be cleaned up now? Is it just a case of removing old junk? ARP and the RDFXML unparser know about DAML vocabulary. We could move the vocabularies to be internal and do a rename of the painful Property(). For now: 1/ Classes marked deprecated 2/ removed from some common prefixes
        Hide
        Ian Dickinson added a comment -

        The rest of the DAML support is long gone in Jena, so I suggest these classes get removed as soon as practicable. At the very least we should deprecate them this cycle and remove them next cycle. In practice, I strongly doubt anyone would notice if we just removed them now.

        In the meantime, I would like to think that it would be possible to exclude a certain class from Javadoc generation, but a quick look at the Maven javadoc configuration page [1] suggests that you can only exclude by package name, not by class.

        [1] http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html

        Show
        Ian Dickinson added a comment - The rest of the DAML support is long gone in Jena, so I suggest these classes get removed as soon as practicable. At the very least we should deprecate them this cycle and remove them next cycle. In practice, I strongly doubt anyone would notice if we just removed them now. In the meantime, I would like to think that it would be possible to exclude a certain class from Javadoc generation, but a quick look at the Maven javadoc configuration page [1] suggests that you can only exclude by package name, not by class. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html

          People

          • Assignee:
            Ian Dickinson
            Reporter:
            Andy Seaborne
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development