Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 10
    • Fix Version/s: 10
    • Component/s: infrastructure
    • Labels:
      None

      Description

      With the repository consolidated (JDK-8165183), it makes organization sense to move the contents of
          corba/src
          jaxp/src
          jaxws/src
          jdk/src
          langtools/src
          nashorn/src
      into
          $OPENJDK/src

      For example, to move
          /jdk/src/java.base
      to
          /src/java.base
      and similarly for each directory corresponding to a module.
          For the HotSpot sources, it is less clear to me what to do. Perhaps the two module directories in HotSpot jdk.hotspot.agent and jdk.vm.ci should be moved into $OPENJDK/src with the remaining files moved into $OPENJDK/src/hotspot/{cpu, os, os_cpu, share}.

      The {$OLD_REPO}/make contents should also be consolidated in some sensible way into a single /make directory.

        Issue Links

          Activity

          darcy Joe Darcy created issue -
          darcy Joe Darcy made changes -
          Field Original Value New Value
          Link This issue is blocked by JDK-8165183 [ JDK-8165183 ]
          darcy Joe Darcy made changes -
          Fix Version/s 10 [ 16302 ]
          darcy Joe Darcy made changes -
          Link This issue relates to JDK-8165187 [ JDK-8165187 ]
          darcy Joe Darcy made changes -
          Summary Flatten src directories into one Flatten src and make directories into one
          darcy Joe Darcy made changes -
          Description With the repository consolidated (JDK-8165183), it makes organization sense to move the contents of
              corba/src
              jaxp/src
              jaxws/src
              jdk/src
              langtools/src
              nashorn/src
          into
              $OPENJDK/src

          For example, to move
              /jdk/src/java.base
          to
              /src/java.base
          and similarly for each directory corresponding to a module.
              For the HotSpot sources, it is less clear to me what to do. Perhaps the two module directories in HotSpot jdk.hotspot.agent and jdk.vm.ci should be moved into $OPENJDK/src with the remaining files moved into $OPENJDK/src/hotspot/{cpu, os, os_cpu, share}
          With the repository consolidated (JDK-8165183), it makes organization sense to move the contents of
              corba/src
              jaxp/src
              jaxws/src
              jdk/src
              langtools/src
              nashorn/src
          into
              $OPENJDK/src

          For example, to move
              /jdk/src/java.base
          to
              /src/java.base
          and similarly for each directory corresponding to a module.
              For the HotSpot sources, it is less clear to me what to do. Perhaps the two module directories in HotSpot jdk.hotspot.agent and jdk.vm.ci should be moved into $OPENJDK/src with the remaining files moved into $OPENJDK/src/hotspot/{cpu, os, os_cpu, share}.

          The {$OLD_REPO}/make contents should also be consolidated in some sensible way into a single /make directory.
          Hide
          erikj Erik Joelsson added a comment -
          I have a working prototype of this. I have only moved the module src dirs. This means jdk/src still contains the following:
          demo
          sample
          linux/doc
          solaris/doc
          bsd/doc

          In the make directory I have moved the makefiles. Left are:
          data mapfiles netbeans non-build-utils scripts src

          The data and mapfiles should ideally be moved to src/<module>/...

          Things I have not yet addressed include (but are not limited to):

          * get_source.sh/hgforest.sh
          * IDE files

          I have left libjvm alone in hotspot/src for now.
          Show
          erikj Erik Joelsson added a comment - I have a working prototype of this. I have only moved the module src dirs. This means jdk/src still contains the following: demo sample linux/doc solaris/doc bsd/doc In the make directory I have moved the makefiles. Left are: data mapfiles netbeans non-build-utils scripts src The data and mapfiles should ideally be moved to src/<module>/... Things I have not yet addressed include (but are not limited to): * get_source.sh/hgforest.sh * IDE files I have left libjvm alone in hotspot/src for now.
          Hide
          erikj Erik Joelsson added a comment -
          I have fixed most differences when comparing to a build from jdk9-master at b131. There are some left:

          Jar files...
                  Only THIS ./lib/modules contains:
                      /jdk.compiler/sun/tools/serialver/resources/serialver.class
                      /jdk.compiler/sun/tools/serialver/resources/serialver_ja.class
                      /jdk.compiler/sun/tools/serialver/resources/serialver_zh_CN.class
                  Differing files in ./lib/modules
                      /java.base/java/lang/invoke/DirectMethodHandle$Holder.class
                      /jdk.jfr/jdk/jfr/internal/types/trace.xml
                      /jdk.jfr/jdk/jfr/internal/types/traceeventscustom.xml
                      /jdk.jfr/jdk/jfr/internal/types/traceeventtypes.xml
                      /jdk.scripting.nashorn/jdk/nashorn/internal/codegen/ClassEmitter$1.class
                      /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator$1.class
                      /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader$2.class
                      /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterServices$1$1.class

          * The serialver classes are generated from properties files. These files used to be in the jdk repository and the properties files there used to just get "cleaned". Now that they are collocated with the langtools jdk.compiler src, the langtools practice of generating classes takes over. I could hack around to avoid this, but to me that would just be wrong.

          * The jdk.jfr xml files are intentionally changed by me. The build process for these did not support arbitrarily moving the closed src dir. I hope to bring this change into JDK 9 separately.

          * The rest of the class files just differ. I don't yet know why. I suspect it's just javac putting things in non deterministic order.

          With the fixed build, I took the newly regenerated forest from b134 and redid the same thing. This time I created a script to do the file reorganization automatically and separated the build file changes from the moves in the b131 version to easily be able to forward port just the build changes. This process is now pretty streamlined, though some manual intervention is needed to resolve merge conflicts.
          Show
          erikj Erik Joelsson added a comment - I have fixed most differences when comparing to a build from jdk9-master at b131. There are some left: Jar files...         Only THIS ./lib/modules contains:             /jdk.compiler/sun/tools/serialver/resources/serialver.class             /jdk.compiler/sun/tools/serialver/resources/serialver_ja.class             /jdk.compiler/sun/tools/serialver/resources/serialver_zh_CN.class         Differing files in ./lib/modules             /java.base/java/lang/invoke/DirectMethodHandle$Holder.class             /jdk.jfr/jdk/jfr/internal/types/trace.xml             /jdk.jfr/jdk/jfr/internal/types/traceeventscustom.xml             /jdk.jfr/jdk/jfr/internal/types/traceeventtypes.xml             /jdk.scripting.nashorn/jdk/nashorn/internal/codegen/ClassEmitter$1.class             /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator$1.class             /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader$2.class             /jdk.scripting.nashorn/jdk/nashorn/internal/runtime/linker/JavaAdapterServices$1$1.class * The serialver classes are generated from properties files. These files used to be in the jdk repository and the properties files there used to just get "cleaned". Now that they are collocated with the langtools jdk.compiler src, the langtools practice of generating classes takes over. I could hack around to avoid this, but to me that would just be wrong. * The jdk.jfr xml files are intentionally changed by me. The build process for these did not support arbitrarily moving the closed src dir. I hope to bring this change into JDK 9 separately. * The rest of the class files just differ. I don't yet know why. I suspect it's just javac putting things in non deterministic order. With the fixed build, I took the newly regenerated forest from b134 and redid the same thing. This time I created a script to do the file reorganization automatically and separated the build file changes from the moves in the b131 version to easily be able to forward port just the build changes. This process is now pretty streamlined, though some manual intervention is needed to resolve merge conflicts.
          Hide
          darcy Joe Darcy added a comment -
          Good to see so few differences!
          Show
          darcy Joe Darcy added a comment - Good to see so few differences!
          Hide
          erikj Erik Joelsson added a comment -
          jdk.jfr change is in mainline JDK-8166202.
          Show
          erikj Erik Joelsson added a comment - jdk.jfr change is in mainline JDK-8166202 .
          erikj Erik Joelsson made changes -
          Affects Version/s 10 [ 16302 ]
          erikj Erik Joelsson made changes -
          Status New [ 10000 ] Open [ 1 ]
          Hide
          erikj Erik Joelsson added a comment -
          I have created a script along with the hg conversion scripts that handles the reshuffle of the files after conversion.
          Show
          erikj Erik Joelsson added a comment - I have created a script along with the hg conversion scripts that handles the reshuffle of the files after conversion.
          Hide
          erikj Erik Joelsson added a comment -
          The shuffling of the source code is automated with scripts. I consider this solved.
          Show
          erikj Erik Joelsson added a comment - The shuffling of the source code is automated with scripts. I consider this solved.
          erikj Erik Joelsson made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Understanding Fix Understood [ 10001 ]
          erikj Erik Joelsson made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Understanding Fix Understood [ 10001 ]
          Resolution Fixed [ 1 ]
          erikj Erik Joelsson made changes -
          Summary Flatten src and make directories into one Preparation: Flatten src and make directories into one

            People

            • Assignee:
              erikj Erik Joelsson
              Reporter:
              darcy Joe Darcy
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: