RE: [Cxtable-devel] Borne- a question about packages...

[Williams, D. <DAV...@ca...>]

I guess my thing is that every .java I pointed to for the base comm package are involved in some way in base comm...

The "enable" stuff is either registry or client related.  The Peer enable is client. 

How would I move the files around w/ cvs...or do you think you would prefer to do it?




David Scott Williams
Computer Associates
Marketing Representative-Sales Call Center
One Computer Associates Plaza 
Islandia, New York  11749
tel: +1 800-243-9462 ext. 73431
tel: +1 631-342-3431 (Direct)
fax: +1 631-342-5734
wi...@ca...






-----Original Message-----
From: Borne Goodman-Mace [mailto:bm...@eg...]
Sent: Tuesday, December 11, 2001 11:22 AM
To: Williams, David
Subject: RE: [Cxtable-devel] Borne- a question about packages...


After all the re-packaging is done in CVS, yes.  I would probably like
to use the same structure as I do in my ominit tree, which is in the
base have a bin, src, lib, and dist directories, under src have the
source tree, when ant builds the class files (and javadoc) it would go
under the dist tree, startup scripts would be in the bin directory, and
any 3rd party libraries we use (such as possible jaxb) would be under
lib.

--bjgm

On Tue, 2001-12-11 at 11:07, Williams, David wrote:
> Incidentally..the build.xml file would of course be for after we've actually packaged, right?
> 
> 
> David Scott Williams
> Computer Associates
> Marketing Representative-Sales Call Center
> One Computer Associates Plaza 
> Islandia, New York  11749
> tel: +1 800-243-9462 ext. 73431
> tel: +1 631-342-3431 (Direct)
> fax: +1 631-342-5734
> wi...@ca...
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Borne Goodman-Mace [mailto:bm...@eg...]
> Sent: Tuesday, December 11, 2001 10:54 AM
> To: Williams, David
> Subject: RE: [Cxtable-devel] Borne- a question about packages...
> 
> 
> are you trying to build based on the current cvs tree?  if so, I can try
> to reproduce the problem.  I think currently in CVS (unless you removed
> them), there are a couple of files that are in there twice, and could be
> causing some issues.
> 
> also, I am using Ant on a couple of my projects and it works very
> nicely.  If you like I can create a build.xml for cxtable and get it
> compiling with Ant.
> 
> btw, not indept at all!  some compiler issues can be very sneaky to find
> / fix.
> 
> --bjgm
> 
> On Tue, 2001-12-11 at 10:50, Williams, David wrote:
> > Whenever I attempt to build a project where package A imports from B, and B imports from A, my compiler barfs...when it is only source.... is this something I've done wrong with my classpath?
> > 
> > (I'm probably appearing more and more inept with each of these questions...but I risk it anyway... )
> > 
> > 
> > David Scott Williams
> > Computer Associates
> > Marketing Representative-Sales Call Center
> > One Computer Associates Plaza 
> > Islandia, New York  11749
> > tel: +1 800-243-9462 ext. 73431
> > tel: +1 631-342-3431 (Direct)
> > fax: +1 631-342-5734
> > wi...@ca...
> > 
> > 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Borne Goodman-Mace [mailto:bm...@eg...]
> > Sent: Tuesday, December 11, 2001 10:42 AM
> > To: cxt...@li...
> > Subject: Re: [Cxtable-devel] Borne- a question about packages...
> > 
> > 
> > Usually there is some level of cross pollination from one package to
> > another.  The main thing to consider when breaking down the classes into
> > packages is logical use, and the growth of that particular package in
> > the future.  You want to keep the number of classes reasonably small so
> > that you don't have 100 classes in one package, which can be a bit
> > overwhelming.
> > 
> > An example I will give is my package hierarchy in the ominit project I
> > am working on:
> > 
> > ---client
> > ------ui
> > ---------system
> > ---------chat
> > ---------arena
> > ------net
> > ---common
> > ---server
> > ------net
> > ------services
> > ---------chat
> > ---------arena
> > ---util
> > ---xml
> > 
> > Most of these packages have only 1 or 2 classes in them, and at a max
> > (for now) 5 or 6.  Even if this does grow, I broke down the packages
> > based on functionality, and it is easy enough to add more, like I plan
> > to have a persistence layer (which could be on the client and the
> > server).  The main reason to have a package system is to be able to find
> > related functionality.
> > 
> > I would certainly have a plugins package, and then under it each plugin
> > could have it's own hierarchy, or just all be lumped into one directory,
> > depending on the complexity of the plugin.
> > 
> > Loading the plugins in a reflective manner isn't all that difficult of a
> > problem.  What is needed is just a Plug-In interface so you have a set
> > of methods you know you can call on the object you instantiate, and then
> > do a Class.forName(<class name>).  Once you have the Class object you
> > can create an instance of it.  Cast that instance to whatever interface
> > all the plug-in's implement, and off you go.... I am more than happy to
> > do this implementation if you like.
> > 
> > --bjgm
> > 
> > On Mon, 2001-12-10 at 14:58, Williams, David wrote:
> > > Let's say I have Package One, Package Two and Package Three
> > > 
> > > 
> > > In One, there are 2-3 classes that are used elsewhere.
> > > In Two, it uses classes from One, as well as classes from Three...also, it has 2-3 classes used elsewhere
> > > In Three, there are classes that are used elsewhere and uses classes from Two
> > > 
> > > When you go to compile them, all of the things in Two that require Three will be unhappy.  All of the things in Three that require Two would be unhappy..
> > > 
> > > I guess I could think of about 5 packages that the project could be placed in, but 3 of them overlap, and so my thought is that those 3 should become 1 package... 
> > > 
> > > ~Dave
> > > 
> > > PS- The "Chess Game" is technically a plugin...partially due to my lack of skill with packaging and custom class loaders, the "Plugin" implementors share the directory with the remainder of the project.  These classes could be placed ENTIRELY in their own package, but then I would need to figure out a way to access them reflectively later...
> > > 
> > > ~Dave
> > 
> > 
> > 
> > _______________________________________________
> > Cxtable-devel mailing list
> > Cxt...@li...
> > https://lists.sourceforge.net/lists/listinfo/cxtable-devel
>