> IDEs will need to adjust their files accordingly.

For the first step (the removal covered by JDK-8269259), I think I got them all for IntelliJ and Eclipse, but that will need to be verified.

I want to hear if there are any other comments, so I'll send a PR later this week or on Monday.

-- Kevin


On 6/23/2021 4:43 PM, Nir Lisker wrote:
Sounds good. I never understood the current organization scheme.

IDEs will need to adjust their files accordingly.

On Thu, Jun 24, 2021 at 1:31 AM Kevin Rushforth <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:

    I missed one. I also propose to delete:

    tests/functional/*

    This was one of the directories that prompted this discussion in the
    first place. It was on my working list to delete and I missed
    copying it
    into this email.

    -- Kevin


    On 6/23/2021 3:27 PM, Kevin Rushforth wrote:
    > We discussed earlier the idea of cleaning up some of the unused
    > programs and eventually reorganizing the apps and test directories.
    >
    > As a first step, I filed JDK-8269259 [1] in which I propose to
    delete
    > the following applications, tests, and scripts that are either
    > obsolete or unmaintained:
    >
    > apps/performance/*
    >
    > apps/tests/HelloTest
    >
    > apps/toys/FXSlideShow
    > apps/toys/Industrial
    > apps/toys/Shape3DToy
    > apps/toys/StretchyGrid
    > apps/toys/TouchSuite
    >
    > tests/performance/VMPerformance
    >
    > tools/*
    >
    > While some of them might be useful, they aren't in their current
    form,
    > and it is likely not worth the effort to fix them. They will be
    in the
    > repo history if anyone really needs them.
    >
    > If anyone objects to a specific program or subdirectory in the
    above
    > list, let me know how you are using it or why you think it is still
    > useful.
    >
    > To put this in context, this is step 1 of a multipart effort to
    reduce
    > unmaintained or obsolete applications, tests, and scripts in our
    repo.
    >
    > When we are all done, the test directory will contain automated and
    > manual tests that are built on a regular basis (and it should be
    > straightforward to run the manual tests). The apps directory
    will just
    > contain the samples [2].
    >
    > The following directories will be examined during this extended
    effort.
    >
    > apps/
    >   performance/
    >   tests/
    >   toys/
    >
    > tests/
    >   functional/
    >   manual/
    >   performance/
    >
    > tools/
    >   gltrace/
    >   scripts/
    >
    > As mentioned at the beginning, step 1 is to identify those programs
    > that will be deleted. That way we don't expend any more effort
    on them
    > when we do subsequent steps.
    >
    > I expect the rest will be done incrementally, and include (not
    > necessarily in order):
    >
    > 1. Wire up the programs under tests/manual to the build,
    possibly with
    > a new gradle task. If it isn't built as part of "gradle test" then
    > that new task needs to be added to "gradle all"
    >
    > 2. Wire up the programs under tests/performance to the build,
    probably
    > the same build task as used in step 1.
    >
    > 3. Move the remaining test programs from apps/toys/* and
    apps/tests/*
    > to tests/manual/ -- since we currently use many of these in manual
    > testing, they need to continue to be built by either "gradle
    all" or
    > "gradle test", and be easily able to run even if step 1 isn't done.
    >
    > 4. If there are any remaining test programs in apps/performance,
    move
    > them to tests/performance (currently I propose to delete them
    all, so
    > this step will go away).
    >
    > Comments?
    >
    > -- Kevin
    >
    > [1] https://bugs.openjdk.java.net/browse/JDK-8269259
    <https://bugs.openjdk.java.net/browse/JDK-8269259>
    >
    > [2] As a separate effort -- not directly associated with this
    cleanup
    > -- the samples could possibly be forked and maintained elsewhere as
    > long as they are easy to download, build and run. Anything
    related to
    > apps/samples should be discussed in a separate email thread.
    >


Reply via email to