Home » Newcomers » Newcomers » Querying Eclipse app directory
| Querying Eclipse app directory [message #196034] |
Sun, 25 February 2007 02:19  |
Eclipse User |
|
|
|
Originally posted by: mgenovese.austin.rr.com
I promise I'm not a noob, but this sure feels like a noob question:
How do I programmatically query the directory where an Eclipse RCP app
resides on the filesystem?
If I use:
System.getProperty("user.dir")
it yields the Eclipse RCP app directory ONLY if I started it from that
directory. If I start it from another directory, that is what's
returned. In other words, it gives me the current working directory.
Again, I want the executable's directory, no matter where it's called from.
Maybe this information can be obtained from Java alone, but I haven't
discovered how. Thought perhaps Eclipse has its own way providing this
info.
Any help appreciated. Thanks.
Matt
--
|
|
|
| Re: Querying Eclipse app directory [message #196061 is a reply to message #196034] |
Sun, 25 February 2007 06:43  |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Matt Genovese" <mgenovese@austin.rr.com> wrote in message
news:erqrnj$5h2$1@utils.eclipse.org...
>I promise I'm not a noob, but this sure feels like a noob question:
>
> How do I programmatically query the directory where an Eclipse RCP app
> resides on the filesystem?
First, ask yourself the question of why you want to know, because there are
usually a lot of alternatives - e.g., if you want to find a file in a
plug-in there's a better way, if you want to find the config data there's a
better way, if you're looking for a temp directory to write to there's a
better way, and so on.
But then, look at the routines in org.eclipse.core.runtime.Platform: e.g.,
getInstallLocation(), getInstanceLocation(), getConfigurationLocation(),
etc.
(I *think* Platform is part of RCP? I'm more familiar with the SDK than
with RCP. Ignore me if I'm a level up.)
|
|
|
| Re: Querying Eclipse app directory [message #196086 is a reply to message #196061] |
Sun, 25 February 2007 19:41 |
| Eclipse User |
|
|
|
Originally posted by: mgenovese.austin.rr.com
Hi Walter,
Thanks much for the reply.
The reason I want to know is so I can read and write some non-Eclipse
files that will be installed in the same directory as where my Eclipse
RCP app was installed. I say "non-Eclipse" files because they are ones
my application maintains, versus things like Preferences that Eclipse
maintains.
So with that additional info, are the runtime.Platform routines still
the best way to go? I was not aware of them, so I'll take a look.
Thanks again for the info.
Cheers,
Matt
--
Walter Harley wrote:
> "Matt Genovese" <mgenovese@austin.rr.com> wrote in message
> news:erqrnj$5h2$1@utils.eclipse.org...
>> I promise I'm not a noob, but this sure feels like a noob question:
>>
>> How do I programmatically query the directory where an Eclipse RCP app
>> resides on the filesystem?
>
> First, ask yourself the question of why you want to know, because there are
> usually a lot of alternatives - e.g., if you want to find a file in a
> plug-in there's a better way, if you want to find the config data there's a
> better way, if you're looking for a temp directory to write to there's a
> better way, and so on.
>
> But then, look at the routines in org.eclipse.core.runtime.Platform: e.g.,
> getInstallLocation(), getInstanceLocation(), getConfigurationLocation(),
> etc.
>
> (I *think* Platform is part of RCP? I'm more familiar with the SDK than
> with RCP. Ignore me if I'm a level up.)
>
>
|
|
|
| Re: Querying Eclipse app directory [message #196094 is a reply to message #196086] |
Sun, 25 February 2007 19:55 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Matt Genovese" <mgenovese@austin.rr.com> wrote in message
news:45E1E665.9000705@austin.rr.com...
>
> The reason I want to know is so I can read and write some non-Eclipse
> files that will be installed in the same directory as where my Eclipse RCP
> app was installed. I say "non-Eclipse" files because they are ones my
> application maintains, versus things like Preferences that Eclipse
> maintains.
>
> So with that additional info, are the runtime.Platform routines still the
> best way to go? I was not aware of them, so I'll take a look. Thanks
> again for the info.
I would strongly suggest using the Platform routines. You should not assume
that the Eclipse (or RCP app) install location is writeable for you at
runtime; for instance, the app could be running off a shared read-only
location, with individual users' configuration data stored in their private
writeable locations. Or security settings could prevent RCP from being able
to write to the install location at runtime unless they are logged in with
an admin password.
I'm guessing from your description that what you want is
getConfigurationLocation(), but you should look through all the
getXXXLocation() methods and try to determine which is most appropriate.
You will save your users a lot of frustration.
If you just want to install (i.e. at install time rather than runtime) some
files and then read them at runtime, getInstallLocation() might be the right
answer; though I would wonder why those files aren't part of a bundle (i.e.
plug-in) somewhere rather than being at the install root. But if you want
to write to them at runtime you should definitely try to use the appropriate
location.
I'm still a bit confused by what you mean by "non-Eclipse", though. If
these are files that your RCP application produces, then they're as much
"Eclipse" as anything else is, even if you're using your own APIs to write
them rather than, e.g., the Preferences API. You could manage them with a
plug-in and store them in that plug-in's configuration location (using
Plugin.getStateLocation()). If they're files produced by some other
application, then of course it's that application's structure that needs to
be queried, rather than Eclipse.
|
|
|
| Re: Querying Eclipse app directory [message #196100 is a reply to message #196094] |
Sun, 25 February 2007 20:22 |
| Eclipse User |
|
|
|
Originally posted by: mgenovese.austin.rr.com
When I say "non-Eclipse", I really just meant the files are managed by
my application code versus the Eclipse core per se; that was the
distinction I was going for.
So you're thinking I can read/write persistent data in the area returned
by Platform.getStateLocation()? By the nature of that area, that sounds
like a place for such files, which would be read/write on systems that
have ACL's as part of the filesystem (e.g. Unix). I assume the
getConfigurationLocation() method would have the same ACL's too.
The idea is the following: My Eclipse application + some other
non-Eclipse apps are installed by the same installer. My Eclipse app
needs to know the location of these other apps. Therefore the installer
will create a log file, and after installation it will call my Eclipse
app to parse that log file, and in turn it will create a configuration
file designating where the other applications are located on that
particular system. Then, my Eclipse app will read this configuration
file at start-up every time so it knows where the other apps are
located. So, this configuration file is persistent, and created during
install, and it's presumed write privileges still exist when created.
Hope that makes sense.
Thanks again for the guidance. If the configuration area or state area
are typically read/write for RCP installations, then I will keep my
runtime writing to those locations - that's useful to know.
Thanks,
Matt
--
Walter Harley wrote:
> "Matt Genovese" <mgenovese@austin.rr.com> wrote in message
> news:45E1E665.9000705@austin.rr.com...
>> The reason I want to know is so I can read and write some non-Eclipse
>> files that will be installed in the same directory as where my Eclipse RCP
>> app was installed. I say "non-Eclipse" files because they are ones my
>> application maintains, versus things like Preferences that Eclipse
>> maintains.
>>
>> So with that additional info, are the runtime.Platform routines still the
>> best way to go? I was not aware of them, so I'll take a look. Thanks
>> again for the info.
>
>
> I would strongly suggest using the Platform routines. You should not assume
> that the Eclipse (or RCP app) install location is writeable for you at
> runtime; for instance, the app could be running off a shared read-only
> location, with individual users' configuration data stored in their private
> writeable locations. Or security settings could prevent RCP from being able
> to write to the install location at runtime unless they are logged in with
> an admin password.
>
> I'm guessing from your description that what you want is
> getConfigurationLocation(), but you should look through all the
> getXXXLocation() methods and try to determine which is most appropriate.
> You will save your users a lot of frustration.
>
> If you just want to install (i.e. at install time rather than runtime) some
> files and then read them at runtime, getInstallLocation() might be the right
> answer; though I would wonder why those files aren't part of a bundle (i.e.
> plug-in) somewhere rather than being at the install root. But if you want
> to write to them at runtime you should definitely try to use the appropriate
> location.
>
> I'm still a bit confused by what you mean by "non-Eclipse", though. If
> these are files that your RCP application produces, then they're as much
> "Eclipse" as anything else is, even if you're using your own APIs to write
> them rather than, e.g., the Preferences API. You could manage them with a
> plug-in and store them in that plug-in's configuration location (using
> Plugin.getStateLocation()). If they're files produced by some other
> application, then of course it's that application's structure that needs to
> be queried, rather than Eclipse.
>
>
|
|
|
| Re: Querying Eclipse app directory [message #196108 is a reply to message #196100] |
Sun, 25 February 2007 20:35 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Matt Genovese" <mgenovese@austin.rr.com> wrote in message
news:45E1EFFA.6080206@austin.rr.com...
> When I say "non-Eclipse", I really just meant the files are managed by my
> application code versus the Eclipse core per se; that was the distinction
> I was going for.
>
> So you're thinking I can read/write persistent data in the area returned
> by Platform.getStateLocation()? By the nature of that area, that sounds
> like a place for such files, which would be read/write on systems that
> have ACL's as part of the filesystem (e.g. Unix). I assume the
> getConfigurationLocation() method would have the same ACL's too.
Plugin.getStateLocation() gives you a location which is specific to a
particular plug-in and workspace (I'm not sure how or whether it translates
to RCP as opposed to the Eclipse IDE). It is precisely for the purpose of
plug-ins that need to write their own config information or other such data.
An example would be that, in the Eclipse SDK, the Java tooling writes index
files there. In a normal install of the Eclipse SDK, it's
[workspace-root]/.metadata/[plug-in-name]. As I said, I don't know whether
that's available in RCP.
Platform.getConfigurationLocation() is possibly better for your case. But
you should dig through the javadoc yourself to make sure. I'm an Eclipse
developer, not an RCP developer...
The basic point here is that there are various locations available depending
on whether you need read-only or read-write privileges and on whether the
data is per-user, per-workspace, per-installation, per-project, etc.; and
there are different APIs to access each of those possibilities (though not
every logical combination is available).
> The idea is the following: My Eclipse application + some other
> non-Eclipse apps are installed by the same installer. My Eclipse app
> needs to know the location of these other apps. Therefore the installer
> will create a log file, and after installation it will call my Eclipse app
> to parse that log file, and in turn it will create a configuration file
> designating where the other applications are located on that particular
> system. Then, my Eclipse app will read this configuration file at
> start-up every time so it knows where the other apps are located. So,
> this configuration file is persistent, and created during install, and
> it's presumed write privileges still exist when created.
I'm not clear on why the installer can't write the configuration file
itself? Then you'd not need write privileges post-install, I would think.
But I assume there are details of your situation that I'm unaware of, and
anyway, this is a forum for questions about Eclipse, not for generic
application design discussions :-)
|
|
|
Goto Forum:
Current Time: Wed Apr 24 19:18:03 GMT 2024
Powered by FUDForum. Page generated in 0.08356 seconds |
] 
Search
Help
Register
Login
Home
