Mike Schrag a écrit :
>> There is also the case where you have frameworks shared between
>> several project types: why should the framework modeled after wolips
>> way if it has to be used and/or *maintained* elsewhere?
> Use binary frameworks with src jars in them if you're not maintaining
> the source in WOLips.
you mean like ProjectWonder frameworks:
MyFramework.framework
|__ Resources
| \__ Java
| |-- MyFramework.jar
| \__ src.jar
\__ WebServerResources
\__ ...
I could build my frameworks with this structure indeed.
But if I add this framework to a wolips project, is src.jar
automatically filtered from the list of jars the framework provide? I
guess I have to omit src.jar from the NSJavaPath property of Info.plist
>> At least for frameworks, I vote for configurability.
>> For applications, I agree that conventions wins over configuration.
> You're really voting for "configurability enough to make YOUR frameworks
> work."
Yes, indeed. But I guess other might have the same needs.
The general case of "configurability" is a huge nightmare,
> because people make crazy project layouts. If we need to know which
> folders contain Components, in the Maven and FBL type, this is very easy
> to answer. Once you remove that restriction, it becomes a huge pain. Do
> you have one top level Components folder? Do you have 10? Maybe you
> put your components next to your java files in your source tree -- the
> old patternset approach would technically allow this to happen, but as a
> result, the tools have a very difficult time making reasonable guesses
> about defaults, etc.
>
>> PS: my current application/project have two webobjects specific
>> frameworks, that I changed to match the wolips way, as I have chosen
>> wolips over my previous build tools. But it depends also on 6 other
>> frameworks that are not webobjects specific.
> I'm not sure I follow what you mean ... You have frameworks that aren't
> WO-specific? I'm guessing you're using the term "framework" loosely
> here?
I use "framework" to mean "library". But I'd like that library to be
built as a WebObjects framework, so I use the term "framework".
Do you just mean you have a project dependency that isn't a WO
> framework at all (i.e. just ends up as a regular java jar?)?
Yes. The libraries are used by command line tools, by JEE applications
and by WebObjects applications.
If you
> don't have Components and WebServerResources and all the things that
> make a framework a Framework, then you would link to it just like any
> other Java Project (just add a project dependency).
Yes, but the generated
App.woa/Contents/{MacOS,UNIX,Windows}/*ClassPath*.txt are wrong (they do
not include the lines for the frameworks I build for these libraries.)
You'll need to
> either use something like Maven or add some custom ant build steps to
> get the jars in a place that your WO app can use them, but the current
> WOLips doesn't provide anything specific for this either. I link
> against non-WO frameworks without any problems.
I'd like something that means "build this java project as a webobjects
framework, and link to it like a webobjects framework, even though it
looks like a plain old java project"
You're right, the solution for now is to add custom ant build steps
(This is what I do), but I'd like the wolips builder to handle this
situation as well.
Am I the only one to work like this? (share libraries between several
projects types) What do you think?
with best regards,
jephté clain
This archive was generated by hypermail 2.0.0 : Fri Feb 06 2009 - 07:11:14 EST