Re: wolips / webobjects build question
Re: wolips / webobjects build question
- Subject: Re: wolips / webobjects build question
- From: Fred Shurtleff <email@hidden>
- Date: Tue, 11 Dec 2007 14:02:50 -0500
Kieran, I understand what you mean - and ERExtensions is in the #1
position(by default I suppose) and javaWO frameworks follow. And these
settings were set in the Wonder release - I only Imported it into
Eclipse and did not make any changes.
That is why I am so confused! All those Red X errors are a pain to look at!
Kieran Kelleher wrote:
In Order and Export, move ERExtensions and any other workspace project
references up above WO Frameworks library reference...
On Dec 11, 2007, at 11:03 AM, Fred Shurtleff wrote:
Re: kind of a similar problem, I was wondering if these settings
could explain why I am getting many 'wavy red underlines with red
x's) errors in my java files for very familiar methods belonging to
WO classes. For example, my ERXArrayUtilities.java file in the
ERExtensions project is littered with the following type errors:
The method objectAtIndex(int) is undefined for the type NSArray
The method addObject(Object) is undefined for the type NSMutableArray
The method objectForKey(Object) is undefined for the type NSDictionary
Yet this project does include the com.webobjects.foundation framework
in its build path.
Can anyone see why I am getting these errors? What am I missing?
Kieran Kelleher wrote:
In the "Order and Export" tab of the framework's build path, turn on
the checkboxes (meaning export) for the two jars. Then every project
that references the framework will "see" the jars inside the framework.
For example
------------------------------------------------------------------------
On Dec 10, 2007, at 4:47 PM, Ricardo Parada wrote:
Hello WOLips experts,
I'm trying to figure out how to do the following. Basically I have
a webobjects framework that builds using ant. The framework really
has no code. It just has two .jar files that are combined into
one. For example, the following ant snippet from the build.xml
file does the work:
<unjar src="foo1.jar" dest="${build.dir}" />
<unjar src="foo2.jar" dest="${build.dir}" />
<mkdir dir="Java" />
<jar destfile="Java/foo.jar" basedir="${build.dir}"
excludes="META-INF/SUN_MICR.*" />
This builds into a Foo.framework which contains foo.jar. And
foo.jar is basically foo1.jar and foo2.jar combined.
I then have other normal WebObjects frameworks that reference the
Foo framework project.
I'm trying to convert this Foo framework project to build with
Eclipse / WOLips standard build files and get away from using my
custom build.xml file.
So using WOLips/Eclipse I created a WebObjects Framework project
called Foo. I then dragged and dropped the foo1.jar and foo2.jar
into the Libraries folder under the Foo project in the Eclipse
package explorer view.
The problem I have is that other frameworks that reference project
Foo are still not able to import and use the classes in the Foo jars.
Any ideas or suggestions?
Thanks,
Ricardo J. Parada
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
MacOS: Tiger 10.4.11
Eclipse: 3.3.1.1
WOLips: 3.3.4705
WebObjects: 5.3.3
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
MacOS: Tiger 10.4.11
Eclipse: 3.3.1.1
WOLips: 3.3.4705
WebObjects: 5.3.3
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden