[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: Migrate old project from 3.1.2 to 3.2

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