[jira] [Commented] (OFBIZ-6110) Move as much as possible demo data from ecommerce to product or order components

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338182#comment-14338182 ]

Jacopo Cappellato commented on OFBIZ-6110:
------------------------------------------

the whole data model is defined by the components in the framework and applications; a few other components in specialpuprose just extend some entities. This gives us a good starting point: we can leave extend-entity definition in the specific components and move all entity definitions to the common component.

> Move as much as possible demo data from ecommerce to product or order components
> --------------------------------------------------------------------------------
>
>                 Key: OFBIZ-6110
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-6110
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: order, product, specialpurpose/ecommerce
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Priority: Minor
>             Fix For: Upcoming Branch
>
>
> It would be better if we have most of the demo product data in product or maybe in order component. Because almost all what can be done concerning ordering in ecommerce can also be done in order manager from which anyway ecommerce depends on
> More generally each component should have the data to be able to work as much on its own as possible. Even if that means redundancy of some sorts. Most of the time, we can avoid redudancy when there are components dependencies and the component data are loaded after the main one.
> This is when https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies helps and shows why it should be actively maintained! For instance I'm not sure we show data loading order there...

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Ron Wheeler]

One of the things that makes this discussion a bit more complex than it
needs to be, is the mixing of modules with deployment artifacts.
Having the packaging for coding tied to the deployment strategy mixes
unit testing with integration testing, production deployment and demo
deployment.

Getting into multiple Maven projects for development, unit testing and
delivery of components would make the project easier to learn and customize.
It would also make it easier to deliver the framework with the essential
party functions as a separate dependency for developers.
It would also make it impossible for circular dependencies to be created.

Using an installer to produce various deployment configurations would
clarify the separation of demo setups and production installations
- configuration files
   - container configurations
   - application configuration
- seed data
- demo data
- documentation

I know that this is a bigger shift of mindset so I will not "contribute"
this to the JIRA.

Ron

On 26/02/2015 5:09 AM, Jacopo Cappellato (JIRA) wrote:

>      [ https://issues.apache.org/jira/browse/OFBIZ-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338182#comment-14338182 ]
>
> Jacopo Cappellato commented on OFBIZ-6110:
> ------------------------------------------
>
> the whole data model is defined by the components in the framework and applications; a few other components in specialpuprose just extend some entities. This gives us a good starting point: we can leave extend-entity definition in the specific components and move all entity definitions to the common component.
>
>
>> Move as much as possible demo data from ecommerce to product or order components
>> --------------------------------------------------------------------------------
>>
>>                  Key: OFBIZ-6110
>>                  URL: https://issues.apache.org/jira/browse/OFBIZ-6110
>>              Project: OFBiz
>>           Issue Type: Improvement
>>           Components: order, product, specialpurpose/ecommerce
>>     Affects Versions: Trunk
>>             Reporter: Jacques Le Roux
>>             Priority: Minor
>>              Fix For: Upcoming Branch
>>
>>
>> It would be better if we have most of the demo product data in product or maybe in order component. Because almost all what can be done concerning ordering in ecommerce can also be done in order manager from which anyway ecommerce depends on
>> More generally each component should have the data to be able to work as much on its own as possible. Even if that means redundancy of some sorts. Most of the time, we can avoid redudancy when there are components dependencies and the component data are loaded after the main one.
>> This is when https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies helps and shows why it should be actively maintained! For instance I'm not sure we show data loading order there...
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

In any ways, I'm all against Maven

Jacques

Le 26/02/2015 14:48, Ron Wheeler a écrit :
> Getting into multiple Maven projects for development, unit testing and delivery of components would make the project easier to learn and customize.

[Ron Wheeler]

I have used for the past 7 years and love it.

It does take a bit of getting used to but once you have your projects
and Maven repo set up, it is really smooth.

New people only have to worry about code and the policy that you follow
for releases and SNAPSHOTs.
Dependencies, builds, project structure, deployment are all pre-defined
when they check-out a project.
They do not have to worry about the build process, it is all in the POM
and if they know Maven, it is the same as every other project that they
have worked on.

It encourages a rigorous and consistent development process.

It also makes it easy to share libraries and I don't see how the
framework could be popular on its own, if it was not available in Maven
Central as a Maven artifact.

Most people get into trouble trying to do crazy things like using Maven
as a deployment tool.
It is good at what it does and there are other tools - installers - that
are better at packaging up things for deployment.

We use it exclusively from within Eclipse/STS so we have nice GUI tools
for managing dependencies and triggering builds and tests.
We use a small subset of the plug-ins and have never had the need to
build a custom plug-in.

When I was young with no grey hair, I got used to building with Ant and
still love it for system administration scripts
I don't like it as a build tool.
I can see its value as part of creating the deployment configurations
that get fed into an installer to support multiple deployment packages
(containers, operating systems, with/ without demo data, etc.) and
post-installation scripts to load demo data or set up the run-time
configuration (container configuration, server startup, etc.).



Ron

On 26/02/2015 8:54 AM, Jacques Le Roux wrote:
> In any ways, I'm all against Maven
>
> Jacques
>
> Le 26/02/2015 14:48, Ron Wheeler a écrit :
>> Getting into multiple Maven projects for development, unit testing
>> and delivery of components would make the project easier to learn and
>> customize.
>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

Le 26/02/2015 15:35, Ron Wheeler a écrit :
> It does take a bit of getting used to but once you have your projects and Maven repo set up, it is really smooth.

I think also about the cost to move to it... Actually I don't even think about it...

Jacques