NX:Contractors: Structure of package

[Peter Kovgan]

This is another stupid question from a big amount I've got.
1.Should I insert into runme.jar 2/3 different jars: client and server and network with completely separate classes(any part(client, server) can work without import any class from another part).
Or it's allowed to build 1 runme.jar with all files of client and server imported each other(as in Max book)?
I'll try to be more understandable:
Must I separate client from server completely, Must I not allow import
remote package from client?
I think I must import db package from client to work in standalone mode.
But should I import network parts too, or write separate classes/interfaces
-copies of network's classes in client part?
Thank you for help!!!

[Vlad Rabkin]

Hi Peter,

Should I insert into runme.jar 2/3 different jars

I don't think it is a good idea! I guess that Contractors is almost the same as URLyBird. Instrctions say that runme.jar shoud consist of *.class, not jars!
Sun:

The executable JAR containing the programs. This must be called runme.jar

Best,
Vlad

[Peter Kovgan]

Ok, all programms *.class in single jar.
But for every part of project:
for example client. Must(Have) client to be in package called 'suncertify.client' and include all needed files and remote interfaces in this package or it's allowed to import interfaces from another package,as 'suncertify.remote'?
Mo simple: is this structure as in Max book allowed:
client can import remote classes from another package?
Or client must be separated and must have his own copies of remote interfaces?
Stupid question but I haven't others more intellect...

[Vlad Rabkin]

Hi Peter,

or it's allowed to import interfaces from another package,as 'suncertify.remote'?

Sure. It is a good idea to break down classes to different packages. It is OK for classes from one package to reference classes from another one.
The only thing, which I always try to avoid is to let packages reference each other (e.g. suncertify.client -> suncertify.db and suncertify.db -> suncertify.client).
Best,
Vlad
P.S. There are no stupid questions, there are only sometimes stupid answers

[Paul Tongyoo]

I was under the impression that the package structure of our jar had to reflect the different layers of our system, not the different user modes??
i just have three in mine
suncertify.db
suncertify.rmi
suncertify.gui


Because code from the client mode is supposed to be used in code from the server and standalone modes (ie, all three modes should be tapping into the same gui codebase), wouldn't it be _bad_ to have a package named suncertify.client? Just curious!
Paul

[Peter Kovgan]

Thanks, Vlad!1!
It's easier to catch you in forum, then via private messages
Here in our project client has interface(your DBAdapter) implemented by remote and by client, then remote must import client's package.
From other side :
client must "to know" remote interface to work with it, then client must import remote.
Is it good way?
Or preferable save into client side remote interface and not import it from remote, to avoid dangerous(?why dangerous) crossimport?
Tnanks, Vlad and others(where are others???)!!!

[Vlad Rabkin]

Hi Peter,

then remote must import client's package.

There is no need at all for remote package to reference client package...
Vlad

[Stephen Galbraith]

with reference to Paul "_bad_" comment, I guess it all depends. I mean if your suncertify.gui package has more than just the gui isn't that _bad_ (i.e. misleading). I mean it could contain the the controller responsible for getting the data or the model of the data as well. Whilst these are related to the gui there are not the gui (IMHO). If you take this viewpoint then you need something more abstract than gui to describe this package. Then client sort of makes more sense.

Steve.

[Peter Kovgan]

Yes, you are right, this is my left part of brain imported some content from right one...And right one influenced by yesterday's glass of vodka.

[Paul Tongyoo]

Originally posted by Stephen Galbraith:
with reference to Paul "_bad_" comment, I guess it all depends. I mean if your suncertify.gui package has more than just the gui isn't that _bad_ (i.e. misleading). ...

Ah yes, i see i see - point well taken. Right now my packages are separated by responsibilities (what class relationships must exist to perform some function); and I label the groups of responsibilities into the general db/rmi/gui categories. In addition to my GUIController's responsibility to recieve events from my View and update the state of my Model, another justification for its presence in my "gui category" is that my gui couldn't function without it-- the actual use cases of the GUI would not work properly if the GUIController wasn't there to perform its job correctly.
Thank you for the different perspective Stephen -- i'll tack this point on my wall of list of design decisions to justify in my choices doc!

Regards,
Paul
[ November 06, 2003: Message edited by: Paul Tongyoo ]
[ November 06, 2003: Message edited by: Paul Tongyoo ]

[George Marinkovich]

Originally posted by Peter Kovgan:

1.Should I insert into runme.jar 2/3 different jars: client and server and network with completely separate classes(any part(client, server) can work without import any class from another part).
Or it's allowed to build 1 runme.jar with all files of client and server imported each other(as in Max book)?

Peter,
This wasn't very clear to me in the Contractor instructions either (emphasis added):

When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
java -jar <path_and_filename> [<mode>]
Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory.
The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run.

The consistent use of the word "programs" rather than "program" leads me to believe that Sun is expecting two programs (a client and a server). Also the sentence "When you submit your assignment, each part (client and server) must be executable using a command of this exact form," again leads me to believe that they are talking about two executables: a client executable and a server executable.
The packaging instructions state(emphasis added):

The executable JAR containing the programs. This must be called runme.jar.

Again, note the use of the word "programs" (plural) rather than "program" (singular). What exactly is the purpose of putting two executables in a single runme.jar file?
On the other hand, if you are really supposed to run the "runme.jar" file why wouldn't Sun have said something like "java -jar <path>runme.jar [<mode>]," rather than "java -jar <path_and_filename> [<mode>]."
If there was supposed to be a single executable, then I would have been careful to use the singular (and more natural) "program" rather than "programs." I would not personally refer to a bunch of "*.class" files as "programs." However, I would refer to a executable jar file as a program and would refer to a single public class file having a main method as a program.
Originally, I had a single executable that was capable of functioning in client (standalone and network) as well as server modes. However, I changed to having two executables: a client executable (that can function in standalone and network modes) and a server (that, of course, only functions in server mode).
Personally. I liked having a single executable since I don't see a benefit from having multiple executables, but the instructions (such as they are) led me to change my mind and have two executables. I'm now leaning toward changing back to one executable and avoid over-interpreting the instructions (which among other things are less than grammatical and contain a number of misspellings). Any thoughts?
[ November 08, 2003: Message edited by: George Marinkovich ]

[Peter Kovgan]

Hello George!
I'm still in doubt here.

[Philippe Maquet]

Hi George and Peter,
In URLyBird we have very similar packaging instructions as you with Contractors (one runme.jar and command-line arguments to specify running modes).
It's clear to me that there is only one executable JAR file : runme.jar.
BTW, if you had one executable JAR file per mode, you wouldn't need the command-line argument !
Best,
Phil.