Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24557 > unrolled thread

Package naming, disk organization

Back to article view | Back to comp.lang.java.programmer

Contents

  Package naming, disk organization Dave <dboland9@fastmail.fm> - 2013-07-01 17:39 -0400
    Re: Package naming, disk organization markspace <markspace@nospam.nospam> - 2013-07-01 15:22 -0700
      Re: Package naming, disk organization Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-01 23:56 +0000
    Re: Package naming, disk organization Roedy Green <see_website@mindprod.com.invalid> - 2013-07-01 15:35 -0700
    Re: Package naming, disk organization Roedy Green <see_website@mindprod.com.invalid> - 2013-07-01 15:36 -0700
    Re: Package naming, disk organization Lew <lewbloch@gmail.com> - 2013-07-01 17:22 -0700
      Re: Package naming, disk organization Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-07-02 18:51 +0300
      Re: Package naming, disk organization Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 23:50 -0300
    Re: Package naming, disk organization Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-01 21:30 -0400
      Re: Package naming, disk organization markspace <markspace@nospam.nospam> - 2013-07-01 18:43 -0700
    Re: Package naming, disk organization Dave <dboland9@fastmail.fm> - 2013-07-02 11:09 -0400
      Re: Package naming, disk organization Arne Vajhøj <arne@vajhoej.dk> - 2013-07-03 22:53 -0400
      Re: Package naming, disk organization markspace <markspace@nospam.nospam> - 2013-07-03 20:35 -0700
        Re: Package naming, disk organization Dave <dboland9@fastmail.fm> - 2013-07-04 12:34 -0400
          Re: Package naming, disk organization Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2013-07-04 20:08 +0300
          Re: Package naming, disk organization lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-04 18:24 +0100
          Re: Package naming, disk organization Lew <lewbloch@gmail.com> - 2013-07-04 11:26 -0700
          Re: Package naming, disk organization Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 15:42 -0400
          Re: Package naming, disk organization Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-04 20:40 +0000
            Re: Package naming, disk organization Lew <lewbloch@gmail.com> - 2013-07-04 14:01 -0700
            Re: Package naming, disk organization Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 17:06 -0400
      Re: Package naming, disk organization Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 15:39 -0400

Page 1 of 2  [1] 2  Next page →

#24557 — Package naming, disk organization

I'm having fun with Java (really!), but the real-world use of packages 
is driving me crazy.  If I were a corp. with a web site I might have a 
something like this: org.davesjava.firstlgproj for a package 
specification. I guess the disk drive files would be something like: 
home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

However:
* I don't have a commercial organization (yet), so I would need 
something else - but what?  Would jsoft.davesjava.firstlgproj be ok?  It 
seems to work for one trial, but down the road...

* I read that Java programmers like to have a source path and a class 
path on the hard drive, which makes sense.  So how does that work for 
package specifications?  Would it be: src/jsoft/davesjava/firstlgproj 
and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package 
specification of jsoft.davesjava.firstlgproj still be ok?

* There is a conflict between a simple file structure and a conventional 
package specification.  For example, I may like:
home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that 
translates into jsoft.class.firstlgproj - not exactly to convention.

So, I'm looking for some suggestions from people that have been there 
done that.

Thanks,
Dave

[toc] | [next] | [standalone]

#24558

On 7/1/2013 2:39 PM, Dave wrote:
> I'm having fun with Java (really!), but the real-world use of packages
> is driving me crazy.  If I were a corp. with a web site I might have a
> something like this: org.davesjava.firstlgproj for a package
> specification. I guess the disk drive files would be something like:
> home/org/davesjava/firstlgproj (I use Linux, so there are no '\').
>
> However:
> * I don't have a commercial organization (yet), so I would need
> something else - but what?

If it's just your stuff, make up whatever name you like, it rarely 
matters.  I make up all sorts of package names and it's never made a 
difference.

Just don't use a name like "org.apache" or "com.microsoft" and you are OK.


> package specifications?  Would it be: src/jsoft/davesjava/firstlgproj
> and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package
> specification of jsoft.davesjava.firstlgproj still be ok?

Yes, yes and yes.

>
> * There is a conflict between a simple file structure and a conventional
> package specification.  For example, I may like:
> home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that

/home/jsoft/src/firstproj/src/jsoft/davesjava/firstlgproj

I don't like the first "src" in there though.  I'd remove it and just 
use /home/jsoft/firstproj/src/jsoft/davesjava/firstlgproj.

I use

/home/myname/Dev/proj/projname/src/packagename/name

I don't think I'd like to have a /src directory for ALL sources, that 
wouldn't make sense to me.  I use Dev/proj/projectname and keep all the 
files, source and compiled, in one spot under that project name.

[toc] | [prev] | [next] | [standalone]

#24561

On Mon, 01 Jul 2013 15:22:35 -0700, markspace wrote:

>> However:
>> * I don't have a commercial organization (yet), so I would need
>> something else - but what?
>
AFAIK domain names, if you or the outfit you work for an owns one, are 
commonly used as the first two terms in the package name because its a 
convenient way of generating package names that are very unlikely to 
clash with anything else. I use a structure like this (Linux system):

/home/user/project_dir/org/gregorie/package_name/*.class

where the source header will say "package org.gregorie.package_name;"
and the root of the class name inside the jar file will be org.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#24559

On Mon, 01 Jul 2013 17:39:45 -0400, Dave <dboland9@fastmail.fm> wrote,
quoted or indirectly quoted someone who said :

>* I don't have a commercial organization (yet), so I would need 
>something else - but what? 

You can register a domain for in the order of $10 a year.

See http://mindprod/jgloss/domain.html

You don't have to host a website, but even that can be free.
see 
http://mindprod.com/ispvendors.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Getting information off the Internet is 
like taking a drink from a fire hydrant.
~ Mitch Kapor 1950-11-01

[toc] | [prev] | [next] | [standalone]

#24560

On Mon, 01 Jul 2013 17:39:45 -0400, Dave <dboland9@fastmail.fm> wrote,
quoted or indirectly quoted someone who said :

>* I read that Java programmers like to have a source path and a class 
>path on the hard drive, which makes sense.  So how does that work for 
>package specifications?  Would it be: src/jsoft/davesjava/firstlgproj 
>and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package 
>specification of jsoft.davesjava.firstlgproj still be ok?

Let your IDE decide how to lay out source and object.  It might put
them in the same dir or separate dirs. You almost never need think
about it.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Getting information off the Internet is 
like taking a drink from a fire hydrant.
~ Mitch Kapor 1950-11-01

[toc] | [prev] | [next] | [standalone]

#24562

Dave wrote:
> I'm having fun with Java (really!), but the real-world use of packages 
> is driving me crazy.  If I were a corp. with a web site I might have a 
> something like this: org.davesjava.firstlgproj for a package 
> specification. I guess the disk drive files would be something like: 
> home/org/davesjava/firstlgproj (I use Linux, so there are no '\').

The disk drive organization in most Java implementations matches the package 
organization, rooted at a directory mentioned in the class path.

> However:
> 
> * I don't have a commercial organization (yet), so I would need 

Irrelevant, as others have told you. Use the domain you would have if you had one.

Who says you have to have a commercial organization to have a domain?

Who told you you had to have a domain to use it as your package name? The only rule
is that you cannot use someone else's.

> something else - but what?  Would jsoft.davesjava.firstlgproj be ok?  It 

The first element should be a top-level domain, like "com".

Do not use the word "java" in your package names. What's the point? If it isn't 
Java it isn't in your Java program. Also, "Java" is trademarked.

> seems to work for one trial, but down the road...

What exactly do you fear?

What evidence led you to that concern?

> * I read that Java programmers like to have a source path and a class 

Huh?

Java programmers don't "like" anything. We do what the platform calls for.

> path on the hard drive, which makes sense.  So how does that work for 
> package specifications?  Would it be: src/jsoft/davesjava/firstlgproj 

Is "src" in your classpath or sourcepath?

> and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package 

Is "class" in your classpath or sourcepath?

The first element of your package name by convention should equate to a TLD.
Use "com", typically.

> specification of jsoft.davesjava.firstlgproj still be ok?
> 
> * There is a conflict between a simple file structure and a conventional 
> package specification.  For example, I may like:

No, there isn't.

> home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that 
> translates into jsoft.class.firstlgproj - not exactly to convention.

Don't use "class" or "package" or "java" or any garbage like that in your package names
unless there is a specific semantic to the use of the term. The fact that there are classes 
in a package does not need reinforcement in your names. It only serves to add clutter to 
do that.

> So, I'm looking for some suggestions from people that have been there 
> done that.

What does the documentation suggest you do?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#24588

Lew <lewbloch@gmail.com> writes:

> The first element of your package name by convention should equate to a TLD.
> Use "com", typically.

Or to a national top-level domain, like "fi" in Finland.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#24757

On 07/01/2013 09:22 PM, Lew wrote:
> Dave wrote:
[ SNIP ]

>
> Don't use "class" or "package" or "java" or any garbage like that in your package names
> unless there is a specific semantic to the use of the term. The fact that there are classes
> in a package does not need reinforcement in your names. It only serves to add clutter to
> do that.
>
>> So, I'm looking for some suggestions from people that have been there
>> done that.
>
> What does the documentation suggest you do?
>
Nothing much useful in the tutorials, unless you're a corporation with a 
domain or domains. The docs don't make it clear that you can use 
whatever hierarchy you damned well want for your packages - it bleats 
too much about Internet domains. Sun (Oracle) clearly not thinking about 
the hundreds of thousands of Java programmers out there w/o a domain name.

Me, I use for personal projects org.ahs.* If the American Horticultural 
Society ever gets some of my private code and is pissed, I'll sue 'em.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#24566

On 7/1/2013 5:39 PM, Dave wrote:
> I'm having fun with Java (really!), but the real-world use of packages
> is driving me crazy.  If I were a corp. with a web site I might have a
> something like this: org.davesjava.firstlgproj for a package
> specification. I guess the disk drive files would be something like:
> home/org/davesjava/firstlgproj (I use Linux, so there are no '\').
>
> However:
> * I don't have a commercial organization (yet), so I would need
> something else - but what?  Would jsoft.davesjava.firstlgproj be ok?  It
> seems to work for one trial, but down the road...
>
> * I read that Java programmers like to have a source path and a class
> path on the hard drive, which makes sense.  So how does that work for
> package specifications?  Would it be: src/jsoft/davesjava/firstlgproj
> and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package
> specification of jsoft.davesjava.firstlgproj still be ok?
>
> * There is a conflict between a simple file structure and a conventional
> package specification.  For example, I may like:
> home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
> translates into jsoft.class.firstlgproj - not exactly to convention.
>
> So, I'm looking for some suggestions from people that have been there
> done that.

     I concur with markspace and Martin Gregorie.  As for the
actual package name, it matters a lot less nowadays than it may
have when Java was young.  Y'see, the tools have learned about
Java and can easily "refactor" a package: Start with dboland.foo,
later change your mind and choose com.bigcompanythatboughtme.foo,
and the tools will handle the rename -- both of the renamed package
and of references to it in extra-package files.

     That, of course, assumes all the relevant sources are visible to
the tool when the rename occurs.  If you've already distributed the
dboland.foo package to umpty-leven other people who've been writing
their own code to use it, they may be somewhat perturbed when your
next patch release arrives and changes the world.  But as long as the
code is in a "pre-public" stage, dboland.whatever is fine.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#24567

On 7/1/2013 6:30 PM, Eric Sosman wrote:
>   If you've already distributed the
> dboland.foo package to umpty-leven other people who've been writing
> their own code to use it, they may be somewhat perturbed when your
> next patch release arrives and changes the world.

I've seen smaller, real world libraries do this, although not at the 
patch level.  When they roll major versions though, they'll switch top 
level package names.

MapDB, for example, used to be JDBM and all in the jdbm.stuff package. 
Then they were an Apache project for a while and used an 
org.apache.mapdb.stuff package name, now they've gone "real" and got an 
mapdb.org domain and are releasing under package org.mapdb.stuff.

It's not a huge deal and there's always ways to manage it.

[toc] | [prev] | [next] | [standalone]

#24586

On 07/01/2013 05:39 PM, Dave wrote:
> I'm having fun with Java (really!), but the real-world use of packages
> is driving me crazy.  If I were a corp. with a web site I might have a
> something like this: org.davesjava.firstlgproj for a package
> specification. I guess the disk drive files would be something like:
> home/org/davesjava/firstlgproj (I use Linux, so there are no '\').
>
> However:
> * I don't have a commercial organization (yet), so I would need
> something else - but what?  Would jsoft.davesjava.firstlgproj be ok?  It
> seems to work for one trial, but down the road...
>
> * I read that Java programmers like to have a source path and a class
> path on the hard drive, which makes sense.  So how does that work for
> package specifications?  Would it be: src/jsoft/davesjava/firstlgproj
> and class/jsoft/davesjava/firstlgproj ?  Assuming so, would a package
> specification of jsoft.davesjava.firstlgproj still be ok?
>
> * There is a conflict between a simple file structure and a conventional
> package specification.  For example, I may like:
> home/jsoft/src/firstlgproj and home/jsoft/class/firstljproj , but that
> translates into jsoft.class.firstlgproj - not exactly to convention.
>
> So, I'm looking for some suggestions from people that have been there
> done that.
>
> Thanks,
> Dave

Fist, thanks for all of the insight!  Based on what everyone has said, 
and what I have read (Oracle, other online info), the plan is to:

1. Eventually get URL, but that will have to wait until a few other 
shoes have dropped so I don't have to keep changing it (as was mentioned 
by a few of you).  Something I did not consider, but with the wave of 
mergers of companies, I can see that this could be a real headache to 
down-stream developers using my packages.

2. For now, use foo.dboland.<proj_name> as the URL.  The disk 
organization would then be (Linux):
	home/user/javadev/src/foo/dboland/<proj_name>
	home/user/javadev/class/foo/dboland/<proj_name>
The class path will be: home/user/javadev/class
And the package specification will be: foo.dboland.<proj_name>

3. I have been looking for the source path documentation, but had not 
heard of it until it was mentioned in this thread.

Any thoughts/comments?

Thanks again!
Dave

[toc] | [prev] | [next] | [standalone]

#24617

On 7/2/2013 11:18 AM, Stefan Ram wrote:
> Dave <dboland9@fastmail.fm> writes:
>> by a few of you).  Something I did not consider, but with the wave of
>> mergers of companies, I can see that this could be a real headache to
>
>    What about a GUID as a package name?
>
>    like
>
> package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f;
>
>    , then named projects:
>
> package guid.02e091ad_d35d_4d2c_b46f_6c6c79e4992f.spreadsheet;
>
>    ?
>
>    If this is too long, any random combination should help to
>    make conflicts unlikely:
>
> package di28Tcx01GGc.spreadsheet;

Package names are no different than other names, the name
is intended to tell what it is.

Using GUID's will loose the documentation in the name.

Not good.

Arne

[toc] | [prev] | [next] | [standalone]

#24618

On 7/2/2013 8:09 AM, Dave wrote:

> 2. For now, use foo.dboland.<proj_name> as the URL.  The disk
> organization would then be (Linux):
>      home/user/javadev/src/foo/dboland/<proj_name>
>      home/user/javadev/class/foo/dboland/<proj_name>
> The class path will be: home/user/javadev/class
> And the package specification will be: foo.dboland.<proj_name>

I don't like "foo", too likely to collide with something.  Use dboland 
as the top name, I think that's much better.

I still don't like the split between src and class at the top level. 
It's weird, and as others have pointed out you'll fight most tools 
(IDEs, etc.) to do it this way.  Easier is project_name/src and 
project_name/build/classes.

Getting a domain name is the absolute least of your concerns.

[toc] | [prev] | [next] | [standalone]

#24620

On 07/03/2013 11:35 PM, markspace wrote:
> On 7/2/2013 8:09 AM, Dave wrote:
>
>> 2. For now, use foo.dboland.<proj_name> as the URL.  The disk
>> organization would then be (Linux):
>>      home/user/javadev/src/foo/dboland/<proj_name>
>>      home/user/javadev/class/foo/dboland/<proj_name>
>> The class path will be: home/user/javadev/class
>> And the package specification will be: foo.dboland.<proj_name>
>
> I don't like "foo", too likely to collide with something.  Use dboland
> as the top name, I think that's much better.
>
> I still don't like the split between src and class at the top level.
> It's weird, and as others have pointed out you'll fight most tools
> (IDEs, etc.) to do it this way.  Easier is project_name/src and
> project_name/build/classes.
>
> Getting a domain name is the absolute least of your concerns.
>
>

This is the one thing (so far) that I really don't like about Java.  The 
Oracle assumes that developers are corporations with web sites.  The 
reality is that some are learning a new language, or developing software 
for others, etc.  So, the package name/path needs to reflect this 
diversity.  By the way, the idea for a source and a class path is 
discussed by the Oracle at:
http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html

I should also point out that I'm a tad old fashion (I guess) because I 
use an editor and command line.  I do plan to go to an IDE - once I'm 
told which one everyone wants to use.

Ok, back to the subject.  I want to obey the conventions, but not box 
myself in or create future problems.  So how about:
* domain (used for general Java development for now): dboland
* source: home/user/javadev/dboland/proj_name/src
* classes: home/user/javadev/dboland/proj_name/classes
   // I don't get the need for build/classes.
* CLASSPATH: home/user/javadev/dboland

Comments?

Dave

[toc] | [prev] | [next] | [standalone]

#24621

Dave <dboland9@fastmail.fm> writes:

> Ok, back to the subject.  I want to obey the conventions, but not box
> myself in or create future problems.  So how about:
> * domain (used for general Java development for now): dboland
> * source: home/user/javadev/dboland/proj_name/src
> * classes: home/user/javadev/dboland/proj_name/classes
>   // I don't get the need for build/classes.
> * CLASSPATH: home/user/javadev/dboland

CLASSPATH: home/user/javadev/dboland/proj_name/classes

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#24622

On 04/07/13 17:34, Dave wrote:
> On 07/03/2013 11:35 PM, markspace wrote:
>> On 7/2/2013 8:09 AM, Dave wrote:

<snip>

>
> This is the one thing (so far) that I really don't like about Java.  The
> Oracle assumes that developers are corporations with web sites.

Huh!, you don't have to be a corporation to have a website and you don't 
need to have a website to have a domain name.

Anyway, it's nothing to do with Oracle, it was ever thus.

You can get a .co.uk domain name from 123-reg for a few quid a year
If you want to develop software that will be used by people outside your 
sphere of influence then it will be a good investment. I don't know why 
you haven't done it yet.

Register dboland.co.uk, it's still available and will cost £6.98 for two 
years, surely it's worth that just to end the angst :-)

Then your packages will be

uk.co.dboland...

Done and dusted and no chance of your code clashing with anyone else's, 
ever.

this would give you

/home/user/javadev/projectname/source/uk/co/dboland

if you have a package called utilities the directory structure would be

/home/user/javadev/projectname/source/uk/co/dboland/utilities/

and the package name would be

uk.co.dboland.utilities

Everything else is just stuff, there are certain conventions that you 
should follow if you are building web apps but apart from that you can 
more or less do what you want.

people use a build directory to collect together all the stuff they need 
to build a component (say a jar file), some people get real anal about 
this stuff but whatever works for you.

So you might have

/home/user/javadev/projectname/build
/home/user/javadev/projectname/build/classes
/home/user/javadev/projectname/build/classes/uk/co/dboland/utilities/

etc etc

<snip>


> I should also point out that I'm a tad old fashion (I guess) because I
> use an editor and command line.  I do plan to go to an IDE - once I'm
> told which one everyone wants to use.

<tinhat>
There is only one ... Eclipse :-)
</tinhat>


> Ok, back to the subject.  I want to obey the conventions, but not box
> myself in or create future problems.  So how about:
> * domain (used for general Java development for now): dboland
> * source: home/user/javadev/dboland/proj_name/src

Not really

/home/user/javadev/projectname/source/uk/co/dboland/utilities/

> * classes: home/user/javadev/dboland/proj_name/classes

/home/user/javadev/projectname/classes/uk/co/dboland/utilities/

>    // I don't get the need for build/classes.

See above

> * CLASSPATH: home/user/javadev/dboland

Hmm, for the above your classpath would be
/home/user/javadev/projectname/classes

Any questions :-)

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

[toc] | [prev] | [next] | [standalone]

#24623

Dave wrote:
> This is the one thing (so far) that I really don't like about Java.  The 
> 
> Oracle assumes that developers are corporations with web sites.  The 

You have been disabused of this notion by several in this thread.

Are you paying attention to the responses?

> reality is that some are learning a new language, or developing software 
> for others, etc.  So, the package name/path needs to reflect this 
> diversity.  By the way, the idea for a source and a class path is 

Okay.

> discussed by the Oracle at:
> http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html
> 
> I should also point out that I'm a tad old[-]fashion[ed] (I guess) because I 

Why the colorful characterization?

> use an editor and command line.  I do plan to go to an IDE - once I'm 

Does "command line" for you include tools like Ant and Gradle?

> told which one everyone wants to use.

I recommend you use the one you want to use. Don't be a sheep.

There are three commonly recommended, NetBeans, Eclipse and IntelliJ. 
It makes no difference to anyone else which one you prefer, or if 
you prefer none.
 
> Ok, back to the subject.  I want to obey the conventions, but not box 
> myself in or create future problems.  So how about:

Three things, divergent.

You "obey" conventions (the correct term is "follow") in order to 
facilitate social integration. It was ever thus.

Conventions are not strait jackets. Programmers are logical. Use what works.

> * domain (used for general Java development for now): dboland
> 
> * source: home/user/javadev/dboland/proj_name/src
> 
> * classes: home/user/javadev/dboland/proj_name/classes

There are several conventions for the output of the compiler and other 
build steps. Raw "classes" isn't really one of them. The IDEs and many 
projects use "build/" or "bin/", and beneath that, "classes/". 

The reason is that there are many artifacts, not just classes.

There is ample material online as to what is a good project structure.
I strongly suggest you look those up and follow them.

>    // I don't get the need for build/classes.

So you ignore it without investigation? Tsk.

You will have great difficulties in your programming life.

In this case you made the wrong decision for a large number of 
real-world scenarios. Find out why, and under what circumstances 
your choice is appropriate, and under which not.

> * CLASSPATH: home/user/javadev/dboland

Nope. That will not work.

Classpath is the root of the *class* hierarchy, which you already 
specified to be your "classes/" subdirectory. Study the docs.

> Comments?

RTFM more.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#24625

On 7/4/2013 12:34 PM, Dave wrote:
> On 07/03/2013 11:35 PM, markspace wrote:
>> On 7/2/2013 8:09 AM, Dave wrote:
>>
>>> 2. For now, use foo.dboland.<proj_name> as the URL.  The disk
>>> organization would then be (Linux):
>>>      home/user/javadev/src/foo/dboland/<proj_name>
>>>      home/user/javadev/class/foo/dboland/<proj_name>
>>> The class path will be: home/user/javadev/class
>>> And the package specification will be: foo.dboland.<proj_name>
>>
>> I don't like "foo", too likely to collide with something.  Use dboland
>> as the top name, I think that's much better.
>>
>> I still don't like the split between src and class at the top level.
>> It's weird, and as others have pointed out you'll fight most tools
>> (IDEs, etc.) to do it this way.  Easier is project_name/src and
>> project_name/build/classes.
>>
>> Getting a domain name is the absolute least of your concerns.
>
> This is the one thing (so far) that I really don't like about Java.  The
> Oracle assumes that developers are corporations with web sites.  The
> reality is that some are learning a new language, or developing software
> for others, etc.  So, the package name/path needs to reflect this
> diversity.  By the way, the idea for a source and a class path is
> discussed by the Oracle at:
> http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html
>
> I should also point out that I'm a tad old fashion (I guess) because I
> use an editor and command line.  I do plan to go to an IDE - once I'm
> told which one everyone wants to use.
>
> Ok, back to the subject.  I want to obey the conventions, but not box
> myself in or create future problems.  So how about:
> * domain (used for general Java development for now): dboland
> * source: home/user/javadev/dboland/proj_name/src
> * classes: home/user/javadev/dboland/proj_name/classes
>    // I don't get the need for build/classes.
> * CLASSPATH: home/user/javadev/dboland

The domain should really not be a problem.

Several has already pointed out that you can buy
yourname.tld rather cheap.

tld.yourname.dboland

But you could also get yourname.somefreeservice.tld
for free many places and you could use that.

tld.somefreeservice.yourname.dboland

Arne

[toc] | [prev] | [next] | [standalone]

#24628

On Thu, 04 Jul 2013 12:34:57 -0400, Dave wrote:

> On 07/03/2013 11:35 PM, markspace wrote:
>> I still don't like the split between src and class at the top level.
>> It's weird, and as others have pointed out you'll fight most tools
>> (IDEs, etc.) to do it this way.  Easier is project_name/src and
>> project_name/build/classes.
>>
Same here - and I've never bothered with any attempt to separate .java 
files from the rest of the compiler output. All the tools (javac, ant, 
javadocs etc.) can work very nicely with this mix. I know some C 
programmers like to separate source from object, but in Java its really 
just as easy to leave them in the same place. ant, in particular, is even 
has a notation, "org/**/*.class", which means "walk the directory tree 
whose root is 'org' and apply this operation to every class file in the 
tree. IOW, if it was building a jarfile, it would include all the 
directories and class files while omitting any other files in the tree.

>> Getting a domain name is the absolute least of your concerns.
>>
Indeed, though there is an Internet convention that .co.uk and .com 
should be used if you intend to sell stuff from your domain but that non-
profit organisations are better placed in .org.uk or .org 


> I should also point out that I'm a tad old fashion (I guess) because I
> use an editor and command line.  I do plan to go to an IDE - once I'm
> told which one everyone wants to use.
> 
I should add that I don't usually use an IDE: I find that my needs are 
nicely met by a decent multi-buffering text editor and ant (the Javan 
equivalent of make).
 
> Ok, back to the subject.  I want to obey the conventions, but not box
> myself in or create future problems.  So how about:
> * domain (used for general Java development for now): dboland * source:
> home/user/javadev/dboland/proj_name/src * classes:
> home/user/javadev/dboland/proj_name/classes
>    // I don't get the need for build/classes.
> * CLASSPATH: home/user/javadev/dboland
>
I maintain a separate directory where I place jar files, /home/java/jarlib
and put that in the CLASSPATH During development I don't bother with 
project jar files, but run everything from the project directory:

My login directory:      /home/user
My project directory:    /home/user/project
Typical package name:    org.gregorie.project
.java, .class files etc: /home/user/project/org/gregorie/project/*.class

so, if I'm in ~/project, running 'ant' will compile any changed classes 
and then running "java org/gregorie/project/MainClass" will run the
newly compiled stuff. Similarly, ant can run 'jar' and build a correct 
jarfile in ~/project using a manifest that would also be in ~/project.
Last, nut not least, ~/project is the base module directory for CVS (or 
any other version control system.

> Comments?
>
HTH
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#24630

Martin Gregorie wrote:
...
> I maintain a separate directory where I place jar files, /home/java/jarlib
> and put that in the CLASSPATH During development I don't bother with 

N.b., to "put that in the CLASSPATH" requires the correct syntax, which 
Martin elided. Beginners might put the directory itself in the CLASSPATH 
without the "*" notation. Make sure you specify what you think you're 
specifying.

Putting just the directory in the CLASSPATH means it can find class files 
rooted there, but JARs are another matter.

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/classpath.html

-- 
Lew

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web