Derby
  1. Derby
  2. DERBY-223

Change programs under demo directory use consistent package names so IDEs do not report errors

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Demos/Scripts
    • Labels:
      None

      Description

      Currently if you build the demos under eclipse, it gives the following errors:

      Severity Description Resource In Folder Location Creation Time
      2 The declared package does not match the expected package nserverdemo SimpleNetworkClientSample.java derby-trunk/java/demo/nserverdemo line 1 April 14, 2005 9:32:35 AM
      2 The declared package does not match the expected package nserverdemo SimpleNetworkServerSample.java derby-trunk/java/demo/nserverdemo line 1 April 14, 2005 9:32:35 AM
      2 The declared package does not match the expected package simple SimpleApp.java derby-trunk/java/demo/simple line 1 April 14, 2005 9:32:35 AM

      The following demo src files (and their associated documentation for running them) should be changed so that they specify the package "nserverdemo" so they are consistent with the other java source files in the same directory:

      java/demo/nserverdemo/SimpleNetworkClientSample.java
      java/demo/nserverdemo/SimpleNetworkServerSample.java

      The following demo src files (and their associated documentation for running them) should be changed so that they specify the package "simple" so they are consistent with the other java source files in the nserverdemo directory:

      java/demo/simple/SimpleApp.java

        Issue Links

          Activity

          Hide
          John Sisson added a comment -

          Also the files in the demo directory have IBM copyright statements in them and the html files still have references to cloudscape (e.g. CLOUDSCAPE_INSTALL).

          Show
          John Sisson added a comment - Also the files in the demo directory have IBM copyright statements in them and the html files still have references to cloudscape (e.g. CLOUDSCAPE_INSTALL).
          Hide
          Andrew McIntyre added a comment -

          Thanks for spotting that, John. I will open a separate JIRA issue for the copyright statements and Cloudscape references in the demos, as it is a separate issue from the demo package names.

          Show
          Andrew McIntyre added a comment - Thanks for spotting that, John. I will open a separate JIRA issue for the copyright statements and Cloudscape references in the demos, as it is a separate issue from the demo package names.
          Hide
          Thomas Nielsen added a comment -

          As this issue is rather old, I don't know if it's still a problem.
          Attached the necessary diff adding the packagenames anyhow.

          The apache license issuse has been fixed with another JIRA issue as described.

          I don't have an Eclipse env to test it with, but derbyall and suites.All pass with the attached diff.

          Show
          Thomas Nielsen added a comment - As this issue is rather old, I don't know if it's still a problem. Attached the necessary diff adding the packagenames anyhow. The apache license issuse has been fixed with another JIRA issue as described. I don't have an Eclipse env to test it with, but derbyall and suites.All pass with the attached diff.
          Hide
          John H. Embretsen added a comment -

          I think there is a tradeoff here between simplicity and IDE (Eclipse?) compatibility (and Java recommended practices).

          First of all, this change will make things a little bit more complicated for users who run the demo outside an IDE. For example, this currently works (as described in the instructions):

          $ cd demo/programs/simple/
          $ export CLASSPATH=.:$DERBY_INSTALL/lib/derby.jar
          $ java SimpleApp

          The proposed change requires the user to do something like this:

          $ cd demo/programs/simple/
          $ export CLASSPATH=..:$DERBY_INSTALL/lib/derby.jar
          $ java simple.SimpleApp

          or this:

          $ cd demo/programs/
          $ export CLASSPATH=.:$DERBY_INSTALL/lib/derby.jar
          $ java simple.SimpleApp

          (in the latter case the database will end up in a common directory for all the demo programs - potentially confusing)

          I'm just thinking that we should try to keep "simple" demos as simple as possible...

          On the other hand, Eclipse users might benefit from this change (not sure how other IDEs handle this).
          And, there are other benefits of not using the default (unnamed) package, such as the ability to import and reuse the code.
          Does anyone else have opinions on this?

          (Speaking of package names, we might want to follow recommendations in the Java language specification (§6.8.1) and use org.apache.derby... package names for all the demos).

          Anyway, the current proposed patch changes the code but does not include required updates to the documentation (readme/example HTML files in the demo subdirectories). For example, with the simple demo, the current patch will result in the following error if instructions in java/demo/simple/example.html for running in embedded mode are followed verbatim:

          $ java SimpleApp
          Exception in thread "main" java.lang.NoClassDefFoundError: SimpleApp (wrong name: simple/SimpleApp)

          Show
          John H. Embretsen added a comment - I think there is a tradeoff here between simplicity and IDE (Eclipse?) compatibility (and Java recommended practices). First of all, this change will make things a little bit more complicated for users who run the demo outside an IDE. For example, this currently works (as described in the instructions): $ cd demo/programs/simple/ $ export CLASSPATH=.:$DERBY_INSTALL/lib/derby.jar $ java SimpleApp The proposed change requires the user to do something like this: $ cd demo/programs/simple/ $ export CLASSPATH=..:$DERBY_INSTALL/lib/derby.jar $ java simple.SimpleApp or this: $ cd demo/programs/ $ export CLASSPATH=.:$DERBY_INSTALL/lib/derby.jar $ java simple.SimpleApp (in the latter case the database will end up in a common directory for all the demo programs - potentially confusing) I'm just thinking that we should try to keep "simple" demos as simple as possible... On the other hand, Eclipse users might benefit from this change (not sure how other IDEs handle this). And, there are other benefits of not using the default (unnamed) package, such as the ability to import and reuse the code. Does anyone else have opinions on this? (Speaking of package names, we might want to follow recommendations in the Java language specification (§6.8.1) and use org.apache.derby... package names for all the demos). Anyway, the current proposed patch changes the code but does not include required updates to the documentation (readme/example HTML files in the demo subdirectories). For example, with the simple demo, the current patch will result in the following error if instructions in java/demo/simple/example.html for running in embedded mode are followed verbatim: $ java SimpleApp Exception in thread "main" java.lang.NoClassDefFoundError: SimpleApp (wrong name: simple/SimpleApp)
          Hide
          Thomas Nielsen added a comment -

          On further thought I agree that it would probably be better to close this as "won't fix" or similar, for all the reasons John state.

          Show
          Thomas Nielsen added a comment - On further thought I agree that it would probably be better to close this as "won't fix" or similar, for all the reasons John state.
          Hide
          Thomas Nielsen added a comment -

          No objections filed, so I'm removing the suggested path and closing as "won't fix".

          We want to keep the simplest examples as simple as possible to new users.

          Show
          Thomas Nielsen added a comment - No objections filed, so I'm removing the suggested path and closing as "won't fix". We want to keep the simplest examples as simple as possible to new users.

            People

            • Assignee:
              Thomas Nielsen
              Reporter:
              John Sisson
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development