What about moving the build/* files into the new runtime folder?

[Jacopo Cappellato]

Now that we have the new "runtime folder", containing all the runtime
objects, what about moving all the build/* files from each component
into a new runtime/build/ folder?

In this way the only folder in which there will be files written while
building/running the system will be in the runtime folder.

I see advantages in this approach, especially for the distribution of
pre-built releases: the pre-built release could be simply the source
official release + the pre-built objects in the runtime folder.
Also everything apart from the runtime folder could be in a read-only
file system (for example a cd).

Jacopo

[Ashish Vijaywargiya-3]

Jacopo,

How will you manage the content of the build folder ???
Will you add the prefix or suffix for the content of each component or the
component name itself ???

BTW I like the idea.

I vote for it +1.

On 4/4/07, Jacopo Cappellato <[hidden email]> wrote:

>
> Now that we have the new "runtime folder", containing all the runtime
> objects, what about moving all the build/* files from each component
> into a new runtime/build/ folder?
>
> In this way the only folder in which there will be files written while
> building/running the system will be in the runtime folder.
>
> I see advantages in this approach, especially for the distribution of
> pre-built releases: the pre-built release could be simply the source
> official release + the pre-built objects in the runtime folder.
> Also everything apart from the runtime folder could be in a read-only
> file system (for example a cd).
>
> Jacopo
>
>

--
Regards
Ashish Vijaywargiya
Aditisoft Technology Laboratory
http://www.adititechlabs.com
[hidden email]
_______________________
Office : 509.855.4113
Cell    : 91-989-347-9711

[jonwimp]

+1

Jonathon

Jacopo Cappellato wrote:

> Now that we have the new "runtime folder", containing all the runtime
> objects, what about moving all the build/* files from each component
> into a new runtime/build/ folder?
>
> In this way the only folder in which there will be files written while
> building/running the system will be in the runtime folder.
>
> I see advantages in this approach, especially for the distribution of
> pre-built releases: the pre-built release could be simply the source
> official release + the pre-built objects in the runtime folder.
> Also everything apart from the runtime folder could be in a read-only
> file system (for example a cd).
>
> Jacopo
>
>

[Gautam Deb]

+1

Jonathon -- Improov wrote:

> +1
>
> Jonathon
>
> Jacopo Cappellato wrote:
>> Now that we have the new "runtime folder", containing all the runtime
>> objects, what about moving all the build/* files from each component
>> into a new runtime/build/ folder?
>>
>> In this way the only folder in which there will be files written
>> while building/running the system will be in the runtime folder.
>>
>> I see advantages in this approach, especially for the distribution of
>> pre-built releases: the pre-built release could be simply the source
>> official release + the pre-built objects in the runtime folder.
>> Also everything apart from the runtime folder could be in a read-only
>> file system (for example a cd).
>>
>> Jacopo
>>
>>
>
>

[David E Jones]

In a way it is nice for each component to contain and control it's  
own stuff, but this does bring up a good point.

For a release we should probably wipe out the build classes  
directories and just keep the jar files.

For development it's nice to have the jar files to make it possible  
to rebuild incrementally. I guess each build.xml file would have to  
know about the runtime folder and explicitly put it's stuff there,  
and if it doesn't and instead puts it in its own folder, then that's  
okay and it will just stay that way (mainly for add-in hot-deploy  
components and such).

-David


On Apr 4, 2007, at 4:52 AM, Jacopo Cappellato wrote:

> Now that we have the new "runtime folder", containing all the  
> runtime objects, what about moving all the build/* files from each  
> component into a new runtime/build/ folder?
>
> In this way the only folder in which there will be files written  
> while building/running the system will be in the runtime folder.
>
> I see advantages in this approach, especially for the distribution  
> of pre-built releases: the pre-built release could be simply the  
> source official release + the pre-built objects in the runtime folder.
> Also everything apart from the runtime folder could be in a read-
> only file system (for example a cd).
>
> Jacopo
>

[jonwimp]

David,

 > In a way it is nice for each component to contain and control it's own
 > stuff, but this does bring up a good point.

You have a good point. But I think it's also good for new modules, even those in hot-deploy, to
adhere to some "container architecture/structure". Individual modules already cross-reference each
other in terms of functionalities and services. Having the build.xml refer to a standard /runtime
folder wouldn't annoy anybody too much.

 > For a release we should probably wipe out the build classes directories
 > and just keep the jar files.

I have a script that wipes out all src and build/classes folders. All other files, including .ftl
and .xml and such, are interpreted codes, and can't be omitted in a release.

 > For development it's nice to have the jar files to make it possible to
 > rebuild incrementally. I guess each build.xml file would have to know
 > about the runtime folder and explicitly put it's stuff there, and if it
 > doesn't and instead puts it in its own folder, then that's okay and it
 > will just stay that way (mainly for add-in hot-deploy components and such).

Wouldn't matter, since OFBiz will/should still search the build/lib folders for each module.

However, I'd recommend that OFBiz issues a warning whenever it encounters jar files in
module-specific build/lib folders. We don't want developers loading 2 sets of the same classes,
and spending hours wondering why their changes to the .java files have no effect.

Jonathon

David E. Jones wrote:

>
> In a way it is nice for each component to contain and control it's own
> stuff, but this does bring up a good point.
>
> For a release we should probably wipe out the build classes directories
> and just keep the jar files.
>
> For development it's nice to have the jar files to make it possible to
> rebuild incrementally. I guess each build.xml file would have to know
> about the runtime folder and explicitly put it's stuff there, and if it
> doesn't and instead puts it in its own folder, then that's okay and it
> will just stay that way (mainly for add-in hot-deploy components and such).
>
> -David
>
>
> On Apr 4, 2007, at 4:52 AM, Jacopo Cappellato wrote:
>
>> Now that we have the new "runtime folder", containing all the runtime
>> objects, what about moving all the build/* files from each component
>> into a new runtime/build/ folder?
>>
>> In this way the only folder in which there will be files written while
>> building/running the system will be in the runtime folder.
>>
>> I see advantages in this approach, especially for the distribution of
>> pre-built releases: the pre-built release could be simply the source
>> official release + the pre-built objects in the runtime folder.
>> Also everything apart from the runtime folder could be in a read-only
>> file system (for example a cd).
>>
>> Jacopo
>>
>

[David E Jones]

On Apr 4, 2007, at 8:22 AM, Jonathon -- Improov wrote:

> > For development it's nice to have the jar files to make it  
> possible to
> > rebuild incrementally. I guess each build.xml file would have to  
> know
> > about the runtime folder and explicitly put it's stuff there, and  
> if it
> > doesn't and instead puts it in its own folder, then that's okay  
> and it
> > will just stay that way (mainly for add-in hot-deploy components  
> and such).
>
> Wouldn't matter, since OFBiz will/should still search the build/lib  
> folders for each module.
>
> However, I'd recommend that OFBiz issues a warning whenever it  
> encounters jar files in module-specific build/lib folders. We don't  
> want developers loading 2 sets of the same classes, and spending  
> hours wondering why their changes to the .java files have no effect.

Actually, OFBiz doesn't do any searching around, everything on the  
classpath is configured very explicitly, mostly through the ofbiz-
component.xml files for runtime, and through build.xml file for the  
build.

-David

[Jacopo Cappellato]

David,

I'm sorry but I'm not sure to understand what you are suggesting to do.
Are you saying that we should keep the build folders where they are now?

Jacopo


David E. Jones wrote:

>
> In a way it is nice for each component to contain and control it's own
> stuff, but this does bring up a good point.
>
> For a release we should probably wipe out the build classes directories
> and just keep the jar files.
>
> For development it's nice to have the jar files to make it possible to
> rebuild incrementally. I guess each build.xml file would have to know
> about the runtime folder and explicitly put it's stuff there, and if it
> doesn't and instead puts it in its own folder, then that's okay and it
> will just stay that way (mainly for add-in hot-deploy components and such).
>
> -David
>
>
> On Apr 4, 2007, at 4:52 AM, Jacopo Cappellato wrote:
>
>> Now that we have the new "runtime folder", containing all the runtime
>> objects, what about moving all the build/* files from each component
>> into a new runtime/build/ folder?
>>
>> In this way the only folder in which there will be files written while
>> building/running the system will be in the runtime folder.
>>
>> I see advantages in this approach, especially for the distribution of
>> pre-built releases: the pre-built release could be simply the source
>> official release + the pre-built objects in the runtime folder.
>> Also everything apart from the runtime folder could be in a read-only
>> file system (for example a cd).
>>
>> Jacopo
>>
>

[David E Jones]

Whoops, you caught me. Yeah, I was being rather vague about what I  
think we should do...

All in all, I think this approach is fine and will improve certain  
things, especially keeping our directory structure clean.

The only downside I can think of is that right now you can pretty  
much blow away the runtime directory and start again without  
recompiling. We could still do that if the resulting jar file were  
copied somewhere else, but maybe that's not a big deal and I guess we  
have some stuff in the runtime area that you can't blow away without  
causing certain problems... hmmmm...

So, to try to be clear, yes, I think we should do it. Hopefully that  
helps in your decision making about it.

-David


On Apr 4, 2007, at 9:02 AM, Jacopo Cappellato wrote:

> David,
>
> I'm sorry but I'm not sure to understand what you are suggesting to  
> do.
> Are you saying that we should keep the build folders where they are  
> now?
>
> Jacopo
>
>
> David E. Jones wrote:
>> In a way it is nice for each component to contain and control it's  
>> own stuff, but this does bring up a good point.
>> For a release we should probably wipe out the build classes  
>> directories and just keep the jar files.
>> For development it's nice to have the jar files to make it  
>> possible to rebuild incrementally. I guess each build.xml file  
>> would have to know about the runtime folder and explicitly put  
>> it's stuff there, and if it doesn't and instead puts it in its own  
>> folder, then that's okay and it will just stay that way (mainly  
>> for add-in hot-deploy components and such).
>> -David
>> On Apr 4, 2007, at 4:52 AM, Jacopo Cappellato wrote:
>>> Now that we have the new "runtime folder", containing all the  
>>> runtime objects, what about moving all the build/* files from  
>>> each component into a new runtime/build/ folder?
>>>
>>> In this way the only folder in which there will be files written  
>>> while building/running the system will be in the runtime folder.
>>>
>>> I see advantages in this approach, especially for the  
>>> distribution of pre-built releases: the pre-built release could  
>>> be simply the source official release + the pre-built objects in  
>>> the runtime folder.
>>> Also everything apart from the runtime folder could be in a read-
>>> only file system (for example a cd).
>>>
>>> Jacopo
>>>
>

[jonwimp]

David,

 > Actually, OFBiz doesn't do any searching around, everything on the classpath
 > is configured very explicitly, mostly through the ofbiz-component.xml files
 > for runtime, and through build.xml file for the build.

All the more why it's a good idea to get every module's ofbiz-component.xml to run off of
/runtime, and to get build.xml to build into /runtime.

But, if I didn't misunderstand, I do get your point about "polluting" the module-specific
ofbiz-component.xml(s) with lots of "../..", and we might make the mistake of putting one too many
".."(s). We could get ComponentConfig to automatically prepend
"../../runtime/build/<component-name>/" (eg "../../runtime/build/manufacturing/") to every
classpath element specified. How's that?

Anyway, the build.xml files already have "../.." in them. We'll just have to replace:

   <property name="build.dir" value="build"/>

with

   <property name="build.dir" value="${ofbiz.home.dir}/runtime/${name}/build"/>

Yes, I'm crazy about Jacopo's idea with /runtime . :)

Jonathon

David E. Jones wrote:

>
> On Apr 4, 2007, at 8:22 AM, Jonathon -- Improov wrote:
>
>> > For development it's nice to have the jar files to make it possible to
>> > rebuild incrementally. I guess each build.xml file would have to know
>> > about the runtime folder and explicitly put it's stuff there, and if it
>> > doesn't and instead puts it in its own folder, then that's okay and it
>> > will just stay that way (mainly for add-in hot-deploy components and
>> such).
>>
>> Wouldn't matter, since OFBiz will/should still search the build/lib
>> folders for each module.
>>
>> However, I'd recommend that OFBiz issues a warning whenever it
>> encounters jar files in module-specific build/lib folders. We don't
>> want developers loading 2 sets of the same classes, and spending hours
>> wondering why their changes to the .java files have no effect.
>
> Actually, OFBiz doesn't do any searching around, everything on the
> classpath is configured very explicitly, mostly through the
> ofbiz-component.xml files for runtime, and through build.xml file for
> the build.
>
> -David
>

[jonwimp]

David,

 > The only downside I can think of is that right now you can pretty much blow
 > away the runtime directory and start again without recompiling. We could
 > still do that if the resulting jar file were copied somewhere else, but maybe
 > that's not a big deal and I guess we have some stuff in the runtime area that
 > you can't blow away without causing certain problems... hmmmm...

To further aid in spotting potential problems, let's see how we can blow away stuff in /runtime
without affecting, well, important stuff.

I think these can be blown away without problems:

- /runtime/log/*

- /runtime/catalina/work

- /runtime/data/derby and /runtime/data/hsql

I think we can't blow away anything else on /runtime without causing problems.

A simple script can do just that.

Does do solve it? Any other problems we can think of?

Jonathon

David E. Jones wrote:

>
> Whoops, you caught me. Yeah, I was being rather vague about what I think
> we should do...
>
> All in all, I think this approach is fine and will improve certain
> things, especially keeping our directory structure clean.
>
> The only downside I can think of is that right now you can pretty much
> blow away the runtime directory and start again without recompiling. We
> could still do that if the resulting jar file were copied somewhere
> else, but maybe that's not a big deal and I guess we have some stuff in
> the runtime area that you can't blow away without causing certain
> problems... hmmmm...
>
> So, to try to be clear, yes, I think we should do it. Hopefully that
> helps in your decision making about it.
>
> -David
>
>
> On Apr 4, 2007, at 9:02 AM, Jacopo Cappellato wrote:
>
>> David,
>>
>> I'm sorry but I'm not sure to understand what you are suggesting to do.
>> Are you saying that we should keep the build folders where they are now?
>>
>> Jacopo
>>
>>
>> David E. Jones wrote:
>>> In a way it is nice for each component to contain and control it's
>>> own stuff, but this does bring up a good point.
>>> For a release we should probably wipe out the build classes
>>> directories and just keep the jar files.
>>> For development it's nice to have the jar files to make it possible
>>> to rebuild incrementally. I guess each build.xml file would have to
>>> know about the runtime folder and explicitly put it's stuff there,
>>> and if it doesn't and instead puts it in its own folder, then that's
>>> okay and it will just stay that way (mainly for add-in hot-deploy
>>> components and such).
>>> -David
>>> On Apr 4, 2007, at 4:52 AM, Jacopo Cappellato wrote:
>>>> Now that we have the new "runtime folder", containing all the
>>>> runtime objects, what about moving all the build/* files from each
>>>> component into a new runtime/build/ folder?
>>>>
>>>> In this way the only folder in which there will be files written
>>>> while building/running the system will be in the runtime folder.
>>>>
>>>> I see advantages in this approach, especially for the distribution
>>>> of pre-built releases: the pre-built release could be simply the
>>>> source official release + the pre-built objects in the runtime folder.
>>>> Also everything apart from the runtime folder could be in a
>>>> read-only file system (for example a cd).
>>>>
>>>> Jacopo
>>>>
>>
>

[Shi Yusen]

-1

This improvement will introduce a further proposal: should the src be
moved out?

I think if compared with version release, this priority is quite low.

Shi Yusen/Beijing Langhua Ltd.

在 2007-04-04三的 10:52 +0200，Jacopo Cappellato写道：

> Now that we have the new "runtime folder", containing all the runtime
> objects, what about moving all the build/* files from each component
> into a new runtime/build/ folder?
>
> In this way the only folder in which there will be files written while
> building/running the system will be in the runtime folder.
>
> I see advantages in this approach, especially for the distribution of
> pre-built releases: the pre-built release could be simply the source
> official release + the pre-built objects in the runtime folder.
> Also everything apart from the runtime folder could be in a read-only
> file system (for example a cd).
>
> Jacopo
>

[jonwimp]

Version release meaning "stable release"? That's a huge thing, an ongoing effort.

Jacopo's suggestion regarding /runtime is doable right away, small tweak.

The src should stick with the modules themselves. Only the build/lib should be moved to /runtime.

Jonathon

Shi Yusen wrote:

> -1
>
> This improvement will introduce a further proposal: should the src be
> moved out?
>
> I think if compared with version release, this priority is quite low.
>
> Shi Yusen/Beijing Langhua Ltd.
>
> 在 2007-04-04三的 10:52 +0200，Jacopo Cappellato写道：
>> Now that we have the new "runtime folder", containing all the runtime
>> objects, what about moving all the build/* files from each component
>> into a new runtime/build/ folder?
>>
>> In this way the only folder in which there will be files written while
>> building/running the system will be in the runtime folder.
>>
>> I see advantages in this approach, especially for the distribution of
>> pre-built releases: the pre-built release could be simply the source
>> official release + the pre-built objects in the runtime folder.
>> Also everything apart from the runtime folder could be in a read-only
>> file system (for example a cd).
>>
>> Jacopo
>>
>
>

[BJ Freeman]

how about
Leave the build in the components, like they are now for development.

copying all files needed to the runtime folder like that startofbiz.*
hotdeploy folder,etc, so the runtime can  be the only folder distributed.
it would require a copy section be added to each build.xml


Jacopo Cappellato sent the following on 4/4/2007 12:52 AM:

> Now that we have the new "runtime folder", containing all the runtime
> objects, what about moving all the build/* files from each component
> into a new runtime/build/ folder?
>
> In this way the only folder in which there will be files written while
> building/running the system will be in the runtime folder.
>
> I see advantages in this approach, especially for the distribution of
> pre-built releases: the pre-built release could be simply the source
> official release + the pre-built objects in the runtime folder.
> Also everything apart from the runtime folder could be in a read-only
> file system (for example a cd).
>
> Jacopo
>
>
>
>

[David E Jones]

So, in other words: destroy being able to change anything on the fly,  
have duplicates of nearly everything in OFBiz, etc?

That would be very different from the run-in-place semantics, and we  
would lose a lot of what is nice about OFBiz during development.

-David


On Apr 5, 2007, at 5:45 AM, BJ Freeman wrote:

> how about
> Leave the build in the components, like they are now for development.
>
> copying all files needed to the runtime folder like that startofbiz.*
> hotdeploy folder,etc, so the runtime can  be the only folder  
> distributed.
> it would require a copy section be added to each build.xml
>
>
> Jacopo Cappellato sent the following on 4/4/2007 12:52 AM:
>> Now that we have the new "runtime folder", containing all the runtime
>> objects, what about moving all the build/* files from each component
>> into a new runtime/build/ folder?
>>
>> In this way the only folder in which there will be files written  
>> while
>> building/running the system will be in the runtime folder.
>>
>> I see advantages in this approach, especially for the distribution of
>> pre-built releases: the pre-built release could be simply the source
>> official release + the pre-built objects in the runtime folder.
>> Also everything apart from the runtime folder could be in a read-only
>> file system (for example a cd).
>>
>> Jacopo
>>
>>
>>
>>
>

[BJ Freeman]

Not sure I am following you david.
if you startofbiz in the root like it is now then you are using ofbiz in
developement mode.
if you start ofbiz in the runtime you are using it strictly in binary mode.
so you have both.
the startofbiz we use now, would be developement.
I see the runtime as the deployment to other servers or the release
image for binaries.

am I missing something?


David E. Jones sent the following on 4/5/2007 8:58 AM:

>
> So, in other words: destroy being able to change anything on the fly,
> have duplicates of nearly everything in OFBiz, etc?
>
> That would be very different from the run-in-place semantics, and we
> would lose a lot of what is nice about OFBiz during development.
>
> -David
>
>
> On Apr 5, 2007, at 5:45 AM, BJ Freeman wrote:
>
>> how about
>> Leave the build in the components, like they are now for development.
>>
>> copying all files needed to the runtime folder like that startofbiz.*
>> hotdeploy folder,etc, so the runtime can  be the only folder distributed.
>> it would require a copy section be added to each build.xml
>>
>>
>> Jacopo Cappellato sent the following on 4/4/2007 12:52 AM:
>>> Now that we have the new "runtime folder", containing all the runtime
>>> objects, what about moving all the build/* files from each component
>>> into a new runtime/build/ folder?
>>>
>>> In this way the only folder in which there will be files written while
>>> building/running the system will be in the runtime folder.
>>>
>>> I see advantages in this approach, especially for the distribution of
>>> pre-built releases: the pre-built release could be simply the source
>>> official release + the pre-built objects in the runtime folder.
>>> Also everything apart from the runtime folder could be in a read-only
>>> file system (for example a cd).
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>
>

[Jacopo Cappellato]

If we will end up moving the build folder to the runtime folder, what is
  in your opinion the best folder layout?

What do you think of:

runtime/build/
runtime/build/classes/
runtime/build/classes/appserver/
runtime/build/classes/base/
...
runtime/build/libs/
runtime/build/libs/ofbiz-appserver.jar
runtime/build/libs/ofbiz-base.jar
...

?

Jacopo

[jonwimp]

Jacopo,

+1

I thought of putting stuff under say /runtime/build/manufacturing and /runtime/build/ecommerce,
etc. But your method will alert the developer immediately about any name clashes (rare, but still
possible).

Jonathon

Jacopo Cappellato wrote:

> If we will end up moving the build folder to the runtime folder, what is
>  in your opinion the best folder layout?
>
> What do you think of:
>
> runtime/build/
> runtime/build/classes/
> runtime/build/classes/appserver/
> runtime/build/classes/base/
> ...
> runtime/build/libs/
> runtime/build/libs/ofbiz-appserver.jar
> runtime/build/libs/ofbiz-base.jar
> ...
>
> ?
>
> Jacopo
>
>
>
>
>
>
>

[David E Jones]

I see. You're right we could use one for production deployment and  
one development.

What would be the benefit of having two build layouts like this? I  
guess more specifically, how would it help the deploy process to have  
the stuff in the build directory?

The main reason I ask is because the real question is whether or not  
that benefit justifies the effort that would be required to build and  
maintain the build scripts to do so.

-David


On Apr 6, 2007, at 3:13 AM, BJ Freeman wrote:

> Not sure I am following you david.
> if you startofbiz in the root like it is now then you are using  
> ofbiz in
> developement mode.
> if you start ofbiz in the runtime you are using it strictly in  
> binary mode.
> so you have both.
> the startofbiz we use now, would be developement.
> I see the runtime as the deployment to other servers or the release
> image for binaries.
>
> am I missing something?
>
>
> David E. Jones sent the following on 4/5/2007 8:58 AM:
>>
>> So, in other words: destroy being able to change anything on the fly,
>> have duplicates of nearly everything in OFBiz, etc?
>>
>> That would be very different from the run-in-place semantics, and we
>> would lose a lot of what is nice about OFBiz during development.
>>
>> -David
>>
>>
>> On Apr 5, 2007, at 5:45 AM, BJ Freeman wrote:
>>
>>> how about
>>> Leave the build in the components, like they are now for  
>>> development.
>>>
>>> copying all files needed to the runtime folder like that  
>>> startofbiz.*
>>> hotdeploy folder,etc, so the runtime can  be the only folder  
>>> distributed.
>>> it would require a copy section be added to each build.xml
>>>
>>>
>>> Jacopo Cappellato sent the following on 4/4/2007 12:52 AM:
>>>> Now that we have the new "runtime folder", containing all the  
>>>> runtime
>>>> objects, what about moving all the build/* files from each  
>>>> component
>>>> into a new runtime/build/ folder?
>>>>
>>>> In this way the only folder in which there will be files written  
>>>> while
>>>> building/running the system will be in the runtime folder.
>>>>
>>>> I see advantages in this approach, especially for the  
>>>> distribution of
>>>> pre-built releases: the pre-built release could be simply the  
>>>> source
>>>> official release + the pre-built objects in the runtime folder.
>>>> Also everything apart from the runtime folder could be in a read-
>>>> only
>>>> file system (for example a cd).
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

[jonwimp]

David, BJ,

Why not just use /runtime/build to run in both development and deployment modes?

Like I mentioned earlier, we can tweak ComponentConfig to "dictate" the structure that holds
/runtime/build and ofbiz-component.xml files. build.xml files are easy enough to change to support
the /runtime/build structure.

Jonathon

David E. Jones wrote:

>
> I see. You're right we could use one for production deployment and one
> development.
>
> What would be the benefit of having two build layouts like this? I guess
> more specifically, how would it help the deploy process to have the
> stuff in the build directory?
>
> The main reason I ask is because the real question is whether or not
> that benefit justifies the effort that would be required to build and
> maintain the build scripts to do so.
>
> -David
>
>
> On Apr 6, 2007, at 3:13 AM, BJ Freeman wrote:
>
>> Not sure I am following you david.
>> if you startofbiz in the root like it is now then you are using ofbiz in
>> developement mode.
>> if you start ofbiz in the runtime you are using it strictly in binary
>> mode.
>> so you have both.
>> the startofbiz we use now, would be developement.
>> I see the runtime as the deployment to other servers or the release
>> image for binaries.
>>
>> am I missing something?
>>
>>
>> David E. Jones sent the following on 4/5/2007 8:58 AM:
>>>
>>> So, in other words: destroy being able to change anything on the fly,
>>> have duplicates of nearly everything in OFBiz, etc?
>>>
>>> That would be very different from the run-in-place semantics, and we
>>> would lose a lot of what is nice about OFBiz during development.
>>>
>>> -David
>>>
>>>
>>> On Apr 5, 2007, at 5:45 AM, BJ Freeman wrote:
>>>
>>>> how about
>>>> Leave the build in the components, like they are now for development.
>>>>
>>>> copying all files needed to the runtime folder like that startofbiz.*
>>>> hotdeploy folder,etc, so the runtime can  be the only folder
>>>> distributed.
>>>> it would require a copy section be added to each build.xml
>>>>
>>>>
>>>> Jacopo Cappellato sent the following on 4/4/2007 12:52 AM:
>>>>> Now that we have the new "runtime folder", containing all the runtime
>>>>> objects, what about moving all the build/* files from each component
>>>>> into a new runtime/build/ folder?
>>>>>
>>>>> In this way the only folder in which there will be files written while
>>>>> building/running the system will be in the runtime folder.
>>>>>
>>>>> I see advantages in this approach, especially for the distribution of
>>>>> pre-built releases: the pre-built release could be simply the source
>>>>> official release + the pre-built objects in the runtime folder.
>>>>> Also everything apart from the runtime folder could be in a read-only
>>>>> file system (for example a cd).
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>