> Another idea, that doesn't sit well with me. Shouldn't
> framework/base/src/start be split into it's own component? Maybe
> framework/start, or just move that code to the top-level.
There are certainly a lot of areas that could use re-organization. I myself have been vocal about
how SVN shouldn't contain binaries (compiled codes); there's no meaningful way for SVN to
version-control binaries, and the bloat it causes is > 50% of the size of OFBiz download (over 35MB).
But IMHO, there will always be a perceived need to re-org.
If things works now, and they are not terribly out-of-place (say having PartyMgr codes residing in
/framework), then I'd say we leave it as is for now.
Jonathon
Adam Heath wrote:
Adam Heath wrote:
David E Jones wrote:
Not sure if I like this... My preference would be that each build file
only owns its directory and below. This change makes a lower level build
file manage something higher level.
What if the framework or base directories move, or we want more build
flexibility?
I can see how if you build just the base component or just the framework
directory that the ofbiz.jar file won't get updated. In a way that would
be expected though...
If anyone else has an opinion on this please chime in. It's not a big
deal, but is one of those things that could make life difficult in the
future and just need to be changed back.
In that argument, framework/build.xml should not update it either, and
only the top-level.
The reason why I did this, is quite often I'd cd into framework/base,
and just run ant there. Then I'd wonder why my changes hadn't taken
place, because the ofbiz.jar at the top-level hadn't been updated.
Maybe a better change would to not copy the file at all, and just modify
the startup to pull from framework/base.
I'm not wedded to this change, btw; if enough others don't think it's
wise, I'll undo it.
I looked into altering things to pull from framework/base, so that no
top-level ofbiz.jar would be nescessary. While modifying the
scripts/code is simple enough, there is plenty of documentation and best
practices that point to the ofbiz.jar in the top-level. Changing humans
is hard, so having it automatically updated is the correct approach.
Whether that's done in framework/base, or some place else, is what is
being discussed.
Another idea, that doesn't sit well with me. Shouldn't
framework/base/src/start be split into it's own component? Maybe
framework/start, or just move that code to the top-level. After all,
it's just the start code that goes into ofbiz.jar. If it were moved to
the top-level, then this argument would become moot.
