|
| Re: Migrate old project from 3.1.2 to 3.2 [message #190199 is a reply to message #190167] |
Fri, 26 January 2007 14:44   |
Eclipse User |
|
|
|
Originally posted by: wayne.beaton._NOSPAM_eclipse.org
pigna wrote:
> Can't imagine this is a cumbersome manual task to be done after every
> eclipse upgrade :-) :-)
>
I'm assuming that your project is a Java Project and that you've added
the SWT JAR files. Unfortunately with the upgrade, the names of these
JAR files have changed, so Eclipse can't find them anymore. The same
sort of thing would happen if you upgraded to a different version of
some other JAR (assuming that the version is indicated in the file name).
There are at least two schools of thought here. First, is it reasonable
to assume that you want to upgrade to the latest version of SWT just
because you're upgrading your IDE? If the answer is no (and
organizations with rigorous build and deployment processes are likely to
answer no), then you should just copy the 3.1.2 versions of the JARs
into a common location and just continue to use them from there (after
updating your Java Build Path). If you go this route, you should
consider using a classpath variable.
Or, if you really just want to use the version of SWT that's included
with your development environment, you could just turn your project into
a Plug-in project and use plug-in dependencies to link in the SWT
libraries. Then, next time you upgrade, it'll all just work.
You can use a Plug-in Project even if you're not really building
plug-in. You can just run the code in it as regular Java classes and it
will work just the same. The big difference is that setting up your
classpath will be a lot easier.
As a general rule, you probably don't want to tie the implementation of
your application to specific libraries in your development environment.
Ideally, you should be downloading the specific version of SWT that you
care about, and setting up a location on your hard drive to hold the
libraries (and specific versions) that your application cares about.
Like I said earlier, organizations with strictly defined build and
packaging practices don't tend to depend on something as transient as a
development environment...
HTH,
Wayne
|
|
|
|
Powered by
FUDForum. Page generated in 0.09163 seconds
] 
Search
Help
Register
Login
Home
