Xcode isn't as bigger leap at apple would have you believe I had project builder doing the same sorts of things with ant. But its quite nice that all the basics are there (JBoss-tomcat, ant, xdoclet) and you can create you own templates.
Does all you need without messing with your stuff too much like eclipse.
Its a different kettle of fish to the old java development on MacOS that you mentioned.
On 1 Mar 2004, at 16:45, Nguyen, Hien wrote:
I'm using Panther (OS X 10.3) with Eclipse, tomcat, mySQL and things are
working perfectly fine. The latest JDK on OS X is 1.4.2.
-----Original Message-----
From: Jeff Kyser [mailto:[EMAIL PROTECTED]
Sent: Monday, March 01, 2004 10:23 AM
To: Struts Users Mailing List
Subject: Re: [OT] MacOS X Java/Struts development (was RE: [OT] Maven (was
Re: [ANNOUNCE] Struts 1.2.0 Test Build available))
I have been extremely happy with IDEA on the MacOS X platform, although Mac
was a little late getting a jdk1.4 up and running.
I'm on Jaguar, have not migrated to Panther...
-jeff
On Monday, March 1, 2004, at 09:07 AM, Paul, R. Chip wrote:
I had been considering moving to MacOS X for a while now just because
of
general windows frustration. I was wondering how many issues, such as
the
one below, there are in developing on a mac? I've heard that Eclipse
runs
much faster in Windows than on a Mac as well, and I don't know if their
Xcode environment can work with java. The last time I was developing
java
on a mac was about 8 years ago, I think we were using Codewarrior at
the
time.
Are many people on the list developing java with MacOS, and which tools work best on that platform?
-----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Saturday, February 28, 2004 8:57 AM To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
that lets me define the individual versions of *all* dependencies for
*all* projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build
***all*** of the components that are going in to my overall exectable.
I am *so* not interested in dealing with runtime exceptions because
different dependent packages were compiled against different versions
of the dependent libraries.
Can someone please help me understand how to do this with Maven? Without it, I'm not planning to switch any of my personal or internal-to-Sun projects (even if the Struts committers decide to switch Struts development itself).
This is actually pretty easy, if I understand you correctly. If you define the Maven property "maven.jar.override" to the value "on", then when resolving dependencies, Maven will check each against a possibly defined override.
For example, the version of Cactus that everyone else in Struts uses doesn't work on Mac OS X. The Cactus CVS head has the patch that works, so in my Struts/maven environment, I have this defined:
maven.jar.override=on # patched version of cactus related to Mac OS X: # http://issues.apache.org/bugzilla/show_bug.cgi?id=25266i maven.jar.cactus-ant=1.6dev-2003-12-07 maven.jar.jakarta-cactus-framework=13-1.6dev
You can use full paths to JARs as well as version numbers. This is detailed here: http://maven.apache.org/reference/user- guide.html#Overriding_Stated_Dependen cies
Properties are defined like so: (http://maven.apache.org/reference/user- guide.html#Properties_Processing):
The properties files in Maven are processed in the following order:
* ${project.home}/project.properties * ${project.home}/build.properties * ${user.home}/build.properties
Where the last definition wins. So, Maven moves through this sequence of properties files overridding any previously defined properties with newer definitions. In this sequence your ${user.home}/build.properties has the final say in the list of properties files processed. We will call the list of properties files that Maven processes the standard properties file set.
In addition, System properties are processed after the above chain of properties files are processed. So, a property specified on the CLI using the -Dproperty=value convention will override any previous definition of that property.
So if you wanted to have it universally, you'd define this in "${user.home}/build.properties" but if it were just for a specific project, you'd define it in ${project.home}/build.properties
Did I answer the right question?
Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
