🚀 go-pugleaf

In <3f95791f@newsgroups.borland.com> Guy Perron wrote:

>  With JBuilder7,
>  I try to do
>  URL url = getClass().getClassLoader().getResource("a file that is in 
>  the same directory as the.jpx file"); I also tried to put the file in 
>  the bin directory of JBuilder, in the root of the classPath It always 
>  return a null pointer for url. What is amasing is that the same code 
>  is working with Eclipse, and BlueJ but it does'nt work in Jbuilder.
>  Anybody as an idea what to do with JBuilder to automatically find 
>  where the user have put his personnal Read-Write data file just by 
>  knowing the name of that file, without asking user?. 

I thought Tor and Lori answered this a couple weeks ago.  

Since you are moving this file around, why not move it
to a place that is "Java sanctioned", that is, where it 
would be readable according to the rules used by the
mechanism?  You should place this file in the classpath
of your application, not in the project directory.
That means, given the following standard directory 
structure in a JBuilder project

  d:/myprojects
      /thisproject
        /bak
        /classes
        /doc
        /src
          - myresourcefile.properties
          - myimagefile.gif
          ... etc.

you should place the file(s) in question at least
in the root of the _source_ directory.  If you 
use JBuilder's standard behavior, .properties and 
gif (and other image format) files will be
copied to your "classes" folder upon building the
project.  If your resource file is not one of the
ones which is copied by default, go to Project 
Properties > Build (tab) > Resource (sub-tab)
and make changes to the "Project-wide defaults
by extension" list.  

In addition, if you are making an application 
archive, you may control which extensions are
copied into the archive.  

A third mechanism for including a file in
the build/deploy output is to add the file
to the project, and alter its "copy/don't copy"
settings in its "Properties" dialog (right-click
on the file's node in the Project Pane, select
"Properties...", and away you go).

(This is all in the online manual which you
agreed to read and understand fully when you
opened the JBuilder box and installed it.  If you
haven't done so, be sure to read at least the
section on how JBuilder constructs paths in 
the "Managing Paths" section of the manual:
Help (menu) > Help topics > Contents (tab) > 
Building Applications with JBuilder (book 
topic) > Building Applications (section) > 
Managing Paths.)


The fact that Eclipse and BlueJ happen to 
allow you to do this is just a non-standard 
quirk in their designs.  BlueJ in particular is 
designed for learning and not producing -- that
means that its author(s) make allowances for
reducing the initial frustration factor of having
to deal with all these kinds of requirements.
Such hand-holding has benefits, but it also has
drawbacks when you are ready to enter the real
world of producing code for a living.
(I remember having to do some hacking to get 
it to run on Mac OS X because of assumptions they
made to "make things easier".  Based on my input 
they changed a few things to make things _correct_ 
rather than just _easier_ to run anywhere.)

Metrowerks' CodeWarrior used to allow you to put
all .java files in one directory, even though the
classes which those files represented were in
different packages.  That makes it _easier_ for
C and C++ programmers who are migrating to Java --
a bulk of Metrowerks customers probably fell into
this category -- but it was just plain wrong according
to the most common interpretation of the Java spec.

You shouldn't base your work on quirks and non-standard
features of any particular IDE.  JBuilder follows
the standard quite closely for just about everything, 
from developing, running/debugging, and deploying 
desktop apps to complex Web apps.


Paul Furbacher [TeamB]

  Save time, search the archives:
       http://info.borland.com/newsgroups/ngsearch.html
       
  Is it in Joi Ellis's Faq-O-Matic? 
       http://www.visi.com/~gyles19/fom-serve/cache/1.html
 
  Finally, please send responses to the newsgroup only.
  That means, do not send email directly to me.
  Thank you.

Thanks a lot for your excellent answer, Paul
Guy.
"Paul Furbacher [TeamB]" <pfurbacher@mac.com> a �crit dans le message de
news:20031021162057575-0400@newsgroups.borland.com...
> In <3f95791f@newsgroups.borland.com> Guy Perron wrote:
>
> >  With JBuilder7,
> >  I try to do
> >  URL url = getClass().getClassLoader().getResource("a file that is in
> >  the same directory as the.jpx file"); I also tried to put the file in
> >  the bin directory of JBuilder, in the root of the classPath It always
> >  return a null pointer for url. What is amasing is that the same code
> >  is working with Eclipse, and BlueJ but it does'nt work in Jbuilder.
> >  Anybody as an idea what to do with JBuilder to automatically find
> >  where the user have put his personnal Read-Write data file just by
> >  knowing the name of that file, without asking user?.
>
> I thought Tor and Lori answered this a couple weeks ago.
>
> Since you are moving this file around, why not move it
> to a place that is "Java sanctioned", that is, where it
> would be readable according to the rules used by the
> mechanism?  You should place this file in the classpath
> of your application, not in the project directory.
> That means, given the following standard directory
> structure in a JBuilder project
>
>   d:/myprojects
>       /thisproject
>         /bak
>         /classes
>         /doc
>         /src
>           - myresourcefile.properties
>           - myimagefile.gif
>           ... etc.
>
> you should place the file(s) in question at least
> in the root of the _source_ directory.  If you
> use JBuilder's standard behavior, .properties and
> gif (and other image format) files will be
> copied to your "classes" folder upon building the
> project.  If your resource file is not one of the
> ones which is copied by default, go to Project
> Properties > Build (tab) > Resource (sub-tab)
> and make changes to the "Project-wide defaults
> by extension" list.
>
> In addition, if you are making an application
> archive, you may control which extensions are
> copied into the archive.
>
> A third mechanism for including a file in
> the build/deploy output is to add the file
> to the project, and alter its "copy/don't copy"
> settings in its "Properties" dialog (right-click
> on the file's node in the Project Pane, select
> "Properties...", and away you go).
>
> (This is all in the online manual which you
> agreed to read and understand fully when you
> opened the JBuilder box and installed it.  If you
> haven't done so, be sure to read at least the
> section on how JBuilder constructs paths in
> the "Managing Paths" section of the manual:
> Help (menu) > Help topics > Contents (tab) >
> Building Applications with JBuilder (book
> topic) > Building Applications (section) >
> Managing Paths.)
>
>
> The fact that Eclipse and BlueJ happen to
> allow you to do this is just a non-standard
> quirk in their designs.  BlueJ in particular is
> designed for learning and not producing -- that
> means that its author(s) make allowances for
> reducing the initial frustration factor of having
> to deal with all these kinds of requirements.
> Such hand-holding has benefits, but it also has
> drawbacks when you are ready to enter the real
> world of producing code for a living.
> (I remember having to do some hacking to get
> it to run on Mac OS X because of assumptions they
> made to "make things easier".  Based on my input
> they changed a few things to make things _correct_
> rather than just _easier_ to run anywhere.)
>
> Metrowerks' CodeWarrior used to allow you to put
> all .java files in one directory, even though the
> classes which those files represented were in
> different packages.  That makes it _easier_ for
> C and C++ programmers who are migrating to Java --
> a bulk of Metrowerks customers probably fell into
> this category -- but it was just plain wrong according
> to the most common interpretation of the Java spec.
>
> You shouldn't base your work on quirks and non-standard
> features of any particular IDE.  JBuilder follows
> the standard quite closely for just about everything,
> from developing, running/debugging, and deploying
> desktop apps to complex Web apps.
>
>
> Paul Furbacher [TeamB]
>
>   Save time, search the archives:
>        http://info.borland.com/newsgroups/ngsearch.html
>
>   Is it in Joi Ellis's Faq-O-Matic?
>        http://www.visi.com/~gyles19/fom-serve/cache/1.html
>
>   Finally, please send responses to the newsgroup only.
>   That means, do not send email directly to me.
>   Thank you.