struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <>
Subject Re: [OT] MacOS X Java/Struts development (was RE: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available))
Date Mon, 01 Mar 2004 16:20:13 GMT
I use xcode on osx and personally i prefer it to those swing based 
things, (although IDEA I hear is in a class of its own).

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 []
> 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 []
>> Sent: Saturday, February 28, 2004 8:57 AM
>> To: Struts Users Mailing List
>> Cc:
>> 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:
>> #
>> 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:
>> guide.html#Overriding_Stated_Dependen
>> cies
>> Properties are defined like so:
>> (
>> guide.html#Properties_Processing):
>>>  The properties files in Maven are processed in the following order:
>>> 	*	 ${project.home}/
>>> 	*	${project.home}/
>>> 	*	${user.home}/
>>>  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}/  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}/" but if it were just for a specific
>> project, you'd define it in ${project.home}/
>> Did I answer the right question?
>> Joe
>> -- 
>> Joe Germuska
>>        "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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message