Hi Ulrich,
while I'm at it:)
Am 14.08.2004 um 14:13 schrieb Ulrich Köster:
>> With WOLips, it's possible to use a classpath container for the WO
>> Frameworks, i.e.:
>>
>> In the .classpath, you have:
>> <classpathentry kind="con"
>> path="org.objectstyle.wolips.WO_CLASSPATH/JavaEOAccess/JavaEOControl/
>> JavaFoundation"/>
>>
>> instead of many entries like:
>> <classpathentry kind="var"
>> path="NEXT_ROOT/Library/Frameworks/JavaEOAccess.framework/Resources/
>> Java/javaeoaccess.jar"/>
>
> We're working on a new classpath container with several imporvements
> like src location, javadoc location, export and ordering.
Was there any progress with the new container? Every time I think about
it, I come to the same problems:
- the JavaDoc stuff is hard to set up, and you need to do this on every
machine, because it's stored per workspace, not in the project.
- the src attachements don't persist because the container eats them,
but even if it stored them in the .project or .classpath files, you
wouldn't have much fun if your developers used different layouts.
- the EXTERNAL_BUILD_ROOT could be working for sth different then
~/Roots, allowing people to manage releases by setting vars in WOLips.
In fact, it should go away and be replaced by sth like
NSProjectSearchPath and NSLibrarySearchPath.
In my case, I have to include all the Wonder frameworks as projects
because I need to debug them. I seldom make changes, but I need the
source to set breakpoints and see what's going on. The other people
here don't need this, but need the source of other frameworks for the
same reason. In their case, they are not even in a fixed location like
~/Wonder but somewhere under ~/Public/Releases/R23. The way it is now,
we all need to have copies of the .project and .classpath files like
.project.ak because we kept overriding each others files very
frequently in the repository.
My suggestion would be:
- extend woproject tasks by a <searchpath> item like
<wocompile>
<frameworks names="JavaWebObjects/.../MyStuff">
<searchpath>//->> is a patternset
<include name="${user.home}/Roots"/>
<include name="${user.home}/Library/Frameworks"/>
<include name="/Library/Frameworks"/>
<include name="/System/Library/Frameworks"/>
</searchpath>
</frameworks>
</wocompile>
Then you could do way with all the ant.wosomethingorother alltogether.
You'd still need them for the <otherclasspath>, though...but honestly,
does anyone use this feature since you can put stuff in
/Library/WebObjects/Extensions?
This would solve two problems: the order of frameworks can't be
determined now if you don't add tons of <frameworks> tags and you could
have cheap release management. Just replace <searchpath> with a pathref
to a release build directory.
- now, as names="..." could be a (fixed) variable, you could just as
well move it to build.properties, where it can be read/written by
wolips.
woproject.frameworks=JavaWebObjects/....
same with the search path's
woproject.librarysearchpath=("~/Roots","/Library/Frameworks","/System/
Library/Frameworks")
and finally
woproject.srcsearchpath=("~/Jobs", "~/Wonder/Common")
assuming that the project's directories are named like the resulting
frameworks.
The javadoc support is a bit more involved, as the setting is
workspace-wide, not project wide. I'd opt for a WOLipsConf.plist in the
correct prefs folder for the platform, with entries like:
{
frameworks = {
javaDoc = {
JavaWebObjects = "file:///Developer...";
JavaDirectToWeb = "http://developer.apple.com/Developer...";
};
};
}
which would set up the correct path's so external JDs work without
setting up each and every jar.
As for the other problem (external JD showing up only in browser) I
started to look into the SWT examples, where there is a Browser view.
Probably one can create an Adaptor that gets used when displaying help
and stuff.
Cheers, Anjo
This archive was generated by hypermail 2.0.0 : Thu Oct 07 2004 - 17:19:31 EDT