There exists a Java project maintained in a SVN repository (access
over the internet). It's mostly pure Java (Java 6), but has a few
niceties to tie into the OS. The OS at this point is Windows. People
use a variety of IDEs, with an ant-based build process.
My job is supposed to be, to get this thing running on a Mac (and
later maybe Linux, too).
I'd love to use XCode, for one, because I am familiar with it
(although not in a Java environment), and because it supports SVN,
while e.g. Eclipse does CVS.
Use an external build target in XCode, and set that up to run Ant. I
use a build tool path of:
/Developer/Java/Ant/bin/ant
and arguments:
-f <path to build XML file> -emacs $(ACTION)
Note that the -emacs argument is required to get error messages to
sync with the source code in the XCode build status viewer. IIRC I
was unable to get $ACTION passed through to a shell script build
target when I was trying to automate builds for 1.1.8 for Mac OS 9,
so stick with the external build target.
I'm fairly new to all this ant and Java stuff, so I wonder what's the
suggested/common practice is to deal with such scenarios, given the
absence of a preprocessor in Java, etc.
Java doesn't have conditional compilation, so all platform decisions
must be made in live code at runtime. The common practice for this is
to use the properties "java.version", "os.name", "os.arch" and
"os.version" for this task. Since parsing these properties is
significant, cache the results of processing them using static flags
or other variables (e.g. public static boolean variables like
IS_MACINTOSH, IS_WINDOWS, etc.).
For involved platform integration code, using a Factory Pattern
hidden behind a Facade can really help simplify such code. For example:
public interface PlatformSupport { ... }
public class MacSupport implements PlatformSupport { ... }
public class WindowsSupport implements PlatformSupport { .... }
...
public class CurrentPlatform {
public static boolean IS_MACINTOSH = ...;
public static boolean IS_WINDOWS = ...;
private static PlatformSupport current = null;
public synchronized PlatformSupport getInstance() {
if (current == null) current = createPlatformInstance();
return current;
}
private PlatformSupport createPlatformInstance() {
if (IS_MACINTOSH)
return Class.forName(MAC_SUPPORT_CLASS).newInstance();
if (IS_WINDOWS)
return Class.forName(WIN_SUPPORT_CLASS).newInstance();
...
return new DefaultPlatformSupport();
}
}
Note the use of Class.forName and Class.newInstance to instantiate
the platform-specific class. This is to accomodate the use of
platform-specific symbols in the class being instantiated.
Is there a way to import an existing ant-based project into XCode,
without messing it all up?
If you're familiar with XCode, you can create an empty project, add
an external target, etc. There may be an automated way of doing this,
I've never trusted XCode enough to try looking for one (I'm a bit
paranoid, but not, I hope, delusionally so :-).
Is there a way to maintain a Java project in an ant-based XCode
project, such that it remains compatible with other IDEs that may
check out the project, and can do conditional builds depending on the
platform?
All the XCode specific stuff gets stashed in the XCode project bundle
proper. To SVN the bundle appears as a directory, so you can place it
under SVN control if you like. I tar up the project, editing out per-
user settings in the process, and commit the archive. There is no
need to commit the XCode project bundle if the others on the project
are not using XCode. Everything in the Java source code should be
pure Java, build clean on other platforms, but anything Mac-specific
should be dead code unless actually run on a Mac. Note that, if your
Mac support code uses Apple-specific classes (e.g.
ApplicationListener) you will need to provide the stubs JAR file for
this package so that compilation of the Mac-specific code does not
fail on other platforms. It *can* be done using reflection, but its
rather painful (requires the use of a dynamic proxy). Search the
archives of this list, there may be an implementation you can use and
avoid having to do it yourself.
Or am I best off simply copying the Java code and starting a new,
independent project/branch based on it, which of course would make
syncing changes in the main project with the Mac version somewhat of
a PITA to say the least?
Don't do that. It might be of value for the short haul, while you are
actively porting, but when you're done you'll want to merge your
branch back onto the main trunk. I'd only recommend doing that if the
port was going to take a long time, and you needed to check in
unstable porting changes as a backup process. I also think it would
be easier to do your own backups to a FireWire drive, so wouldn't
recommend branching in any case. Just be sure things still work for
the other platforms before you commit anything.
Finally, given the current state of J2SE6 on the Mac (developer pre-
release only), you may want to consider porting to Linux first. There
is a user base on Linux that already has access to production J2SE6
releases, that can take advantage of your work immediately. The Mac
community will have to wait for Apple to release J2SE6 (and as usual,
they aren't saying when that will be). Although it would be nice to
have the port ready and waiting when that happens, you should
consider whether your user base would be better served by placing
your effort on Linux first.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden
