This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes IDEs, Version Control and other tools and the fly likes Upgrading from Netbeans 3.5 to Netbeans 6.1 and Subversion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Upgrading from Netbeans 3.5 to Netbeans 6.1 and Subversion" Watch "Upgrading from Netbeans 3.5 to Netbeans 6.1 and Subversion" New topic

Upgrading from Netbeans 3.5 to Netbeans 6.1 and Subversion

Tim Sparg
Ranch Hand

Joined: Dec 29, 2006
Posts: 40
Hi all

We are in the process of reorganising and upgrading our whole java infrastructure.
To give you some background these are the changes that will be occurring:
JDK versions are changing from 1.4 to 1.6
Netbeans versions will be upgrading from 3.5 to 6.1
and all our code will be placed into a Subversion repository ( Before this it was all placed on the file system and backed up every night)

As can be expected the upgrade from JDK 1.4 to 1.6 did cause some grief, mainly around the use of enum as a keyword and getting new versions of external libraries.

The major problem we are now having is the way that Netbeans 6.1 looks at its source as opposed to Netbeans 3.5
We have many applications built off the same source code base with many sharing common classes, some being utility classes, others being specific to a process ie mail.

This is best illustrated with an example:

So to clarify the Sender will have the following files:

And the Receiver will have these files:

As you can see there are many classes that both applications will use.
If you created a standard Java application with Netbeans you would have to split your source up and make a copy for each application. Obviously this is undesirable.
The other option is to create a Java project from existing sources. Here you can have the same source code shared between the multiple applications without any replication.

Unfortunately this plays havoc when you throw the repository into the mix.
Subversion(by this i refer to the Subversion module in Netbeans) has no problems with the standard Java Project, but when you try and use Subversion together with the 'Project from existing sources' its a no go. Subversion will import and maintain the Netbeans project. But the project now does not contain the source code, only a reference to where the source code can be found.

As a work around I have thought of implementing the following solution:
Create a utilites library that will hold classes such as SqlInserterUtil, NullValueUtil
Create a process (in this case mail) library that will hold classes such as ObjectThatWillBeSentAndReceived
These projects then become suppliers to the applications themselves, Sender and Receiver

Your structure now looks as follows:

utilites Library

Mail Library

uses utilities, Mail

uses utilities, Mail

Could i have thoughts on this please, Is there a better way to do this? is this the preferred way to do this?

There is no insanity so devastating in man's life as utter sanity
I agree. Here's the link:
subject: Upgrading from Netbeans 3.5 to Netbeans 6.1 and Subversion
Similar Threads
version control not found
Websphere Application Server 7 (WAS 7) with NetBeans IDE 7
com.sun.mail... no classdef error when sending Mail
donation to javaranch