OFBiz and how to move forward (was Re: How to use ProjectMgr in 13.07)
Hi All, In the thread suggestion have been made to move applications (as a fork/split off) away from the Apache OFBiz project to be maintained by other people. This is part of an ongoing discussion that started back in 2012 (if I recall correctly). Back then this didn't lead to consensus. Now it also seems that this is a subject that community members aren't willing to consent to. Diminishing the project to something that Scott would like to result in (a project that only works on - in a debatable order of importance - frame work elements, base registers as party, order and product, and e-commerce) is, in my opinion, a path to the ASF attic. Yes, it means that the current group of committers and PMC members can reduce their workload by focussing on the issues they care about (which they already do - nothing changes in that aspect). But the additional benefit for them (and negative impact on you as user and contributor to parts that aren't in their sphere of interest) is that they don't have to consider the issues you raise and you as a (potential) committer. Like I said it is a path to the attic. And let me explain why. Contraction to the favourites applications of the few leads to less. Less adoption of OFBiz as a suite of business solutions. Leading to less contributors, leading to less committers, leading to less issues reported, leading to less issues resolved. And this leads to even more contraction. It is a vicious circle. Because sooner or later people move on. And the above is what this project doesn't need. What you shouldn't go for. An Apache project is nothing more and nothing less than a group of people willing to contribute and collaborate. And the result of that contribution and that collaboration is something that the (majority of the) users - also you - need and/or want. But it all starts with that willingness. When you look through our OFBiz JIRA and the mailing lists you'll find that there have been and are plenty of people - again also you - contributing to all kinds of aspects of the project. It doesn't (and shouldn't) matter whether that contribution is improvements (bugs and otherwise) to the feature set of the software, in the area of documentation, or even regarding process and policy improvements. You are, with your contributions of any kind, contributing to the health and future of the project. And never forget: your contributions matter, even if some regards them as minor or mediocre. So the first part of participating in this project is covered and secured. Lots of people willing to contribute! As for the second part, the willingness to collaborate, it cannot be denied that people have favourites. Some prefer to work on issues related to framework, some prefer to commit patches of issues from people they like collaborating with. This is also thru for this project. And though it leaves some areas of the project (temporarily) under addressed it can be easily remediated. By inviting more contributors to be a committer. That will lead to more issues resolved, more people working with others, a project where losing a PMC member or a contributor is covered with replacement, an increase in adoption. And this is a virtuous circle. This is the circle we should go for. Now, we don't have to discuss setting up additional technical infrastructures as svn sub-projects with associated JIRA constructs and mailing lists when we don't want to embark on that journey of attracting and getting more. Without more people willing to collaborate it is a moot point. As I said earlier in this posting we have (and had) a lot of people contributing to all of the aspects of the project. All of these are potential committers. Yet it seems that inviting a person to be a committer is something that may only happen when the contributions of that person are of an exceptional benefit to the project, when contributor has super human characteristics, or when the contributor works in the areas that are favoured by the deciders of this project. We need to address that mindset within our community first. Before we discuss setting up additional lower, technical infrastructures to ensure that the other (good) applications get into releases. In fact, we wouldn't be having this discussion about workload and such with more people on board. So far we have read the viewpoints of Jacopo, Jacques and Scott (as PMC Members). I invite others to share their viewpoints as well. The future of OFBiz (and your role and contributions) is important enough to express your viewpoint. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: How to use ProjectMgr in 13.07
as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com To: dev@ofbiz.apache.org mailto:dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com mailto:adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com http://www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub
Re: How to use ProjectMgr in 13.07
should think that the name of the module has anything to do with what it will actually do. Mixing them in with modules that are actively maintained is not helpful. I hope that this helps. Ron Regards Scott On 8/11/2014, at 9:21 am, Ron Wheeler rwhee...@artifact-software.com wrote: Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material
Re: How to use ProjectMgr in 13.07
Hi Ron, I really hope you are right on your vision for this. What you said makes sense and needs some testing to affirm it. Sign me up for the birt component as well as bootstrap for now if this goes forward! Taher Alkhateeb
Re: OFBiz and how to move forward (was Re: How to use ProjectMgr in 13.07)
Diminishing the project to something that Scott would like to result in (a project that only works on - in a debatable order of importance - frame work elements, base registers as party, order and product, and e-commerce) is, in my opinion, a path to the ASF attic. I completely disagree with that opinion and since so much of what you wrote is based on that premise, I won't bother replying to the rest. I can only speak to what I've experienced and what I've seen but in general: - The core components that live under framework and applications (which certainly are not best described as base registers) are the most useful set of components to implement anything a business might need. I've worked for many different clients and many different projects over the last 7 years and aside from ecommerce I have never had a set of requirements brought to me that fit well with any of the special purpose components. - Contributions to the applications/framework components outweigh those received by the special purpose components by a massive scale (no I don't have numbers, I just have that impression from reading almost every user/dev email for the last 9 years) Given that OFBiz exists today in large part because of the very adaptable core components, the premise that focusing only on those is a path to the ASF attic is quite false. What the OFBiz project needs to be aiming for (IMHO) is to be a lean code base that is capable of meeting the core needs of the largest possible number of businesses. Virtually all large applications (open source or otherwise) gain a large portion of their strength by having a healthy and diverse external ecosystem. Look at Eclipse, Magento and Xero to name a few. Attempting to keep everything in-house within the TLP is the equivalent of Apple trying to build every application an iDevice might need instead of opening the AppStore. They would've ended up with a large number of sub-par applications but instead they focused on a few core apps that almost everyone would use. Phone OS's are actually a really good example of how important it is for a platform to have a healthy eco-system. I think that the special purpose components are a good way to bootstrap an external eco-system that would help diversify OFBiz as a platform. Attempting to make OFBiz even more monolithic is the wrong course. Regards Scott On 10/11/2014, at 11:59 pm, Pierre Smits pierre.sm...@gmail.com wrote: Hi All, In the thread suggestion have been made to move applications (as a fork/split off) away from the Apache OFBiz project to be maintained by other people. This is part of an ongoing discussion that started back in 2012 (if I recall correctly). Back then this didn't lead to consensus. Now it also seems that this is a subject that community members aren't willing to consent to. Diminishing the project to something that Scott would like to result in (a project that only works on - in a debatable order of importance - frame work elements, base registers as party, order and product, and e-commerce) is, in my opinion, a path to the ASF attic. Yes, it means that the current group of committers and PMC members can reduce their workload by focussing on the issues they care about (which they already do - nothing changes in that aspect). But the additional benefit for them (and negative impact on you as user and contributor to parts that aren't in their sphere of interest) is that they don't have to consider the issues you raise and you as a (potential) committer. Like I said it is a path to the attic. And let me explain why. Contraction to the favourites applications of the few leads to less. Less adoption of OFBiz as a suite of business solutions. Leading to less contributors, leading to less committers, leading to less issues reported, leading to less issues resolved. And this leads to even more contraction. It is a vicious circle. Because sooner or later people move on. And the above is what this project doesn't need. What you shouldn't go for. An Apache project is nothing more and nothing less than a group of people willing to contribute and collaborate. And the result of that contribution and that collaboration is something that the (majority of the) users - also you - need and/or want. But it all starts with that willingness. When you look through our OFBiz JIRA and the mailing lists you'll find that there have been and are plenty of people - again also you - contributing to all kinds of aspects of the project. It doesn't (and shouldn't) matter whether that contribution is improvements (bugs and otherwise) to the feature set of the software, in the area of documentation, or even regarding process and policy improvements. You are, with your contributions of any kind, contributing to the health and future of the project. And never forget: your contributions matter, even if some regards them as minor or mediocre. So the first part of
Re: How to use ProjectMgr in 13.07
Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version
Re: How to use ProjectMgr in 13.07
band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose
Re: How to use ProjectMgr in 13.07
This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- www.nereide.fr Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr http://www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Jacques, Birt is definitely important for us Taher Alkhateeb On Nov 7, 2014 2:40 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- http://www.nereide.fr Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Jacopo, Well thought and a good suggestion IMHO. Definitely a good middle ground solution that supports all components and keeps things alive Taher Alkhateeb Taher Alkhateeb On Nov 7, 2014 3:05 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
I'm all for it, good idea! Jacques Le 07/11/2014 13:11, Taher Alkhateeb a écrit : Hi Jacopo, Well thought and a good suggestion IMHO. Definitely a good middle ground solution that supports all components and keeps things alive Taher Alkhateeb Taher Alkhateeb On Nov 7, 2014 3:05 PM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- Mail Attachment.jpeg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what do you think? Jacques Le 21/10/2014 09:06, gil portenseigne a écrit : I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to
Re: How to use ProjectMgr in 13.07
I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization work we did on the branch (and also from some licensing issues that may affects some of the artifacts in some of the specialpurpose components) . Jacopo as long as they are backed by some efforts, come to mind project manager (Pierre Smits?) scrum (Hans?) examples and ext (at least me) myportal (French people use portals, not sure for myportal?) Other components? IRRW Jacopo said he was not against a new discussion on this subject (I could not find his message), what
Re: How to use ProjectMgr in 13.07
Hi All, I agree that hot-deploy component don't have to be installed with the core project by default. But in the other hand it could be interesting to be aware of those projects. When I read this topics, it seems matching with an extension manager... French community is working on this extension manager project maybe it could be the way to split specific OFBiz extension and the core project ? Am I wrong ? Julien. Le 07/11/2014 17:32, Adrian Crum a écrit : I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization
Re: How to use ProjectMgr in 13.07
I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled in order to avoid the users to get a default ootb release/branch with enabled special purpose functionalities that may override the more general purpose ones offered by the core applications. We should still consider the idea of providing separate products for the specialpurpose components (and having them in the branch would help this process). If the idea I am proposing here (include the specialpurpose components in the branch but not in the releases) we could re-add them (as disabled) also to the 13.07 branch but exclude them from all the releases (13.07.02 etc...): this will protect all the stabilization
Re: How to use ProjectMgr in 13.07
I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just the OFBiz components that are officially part of the core. Clearly good communication between the core project and the sub-project about release plans would help everyone but the core group would be basically free to release the core as they want and the sub-projects would have to communicate to their uses communities what impact this would have on the users of the modules. If a sub-project needs a change to the core to implement some feature, they would have to file an enhancement JIRA issue and convince someone to add it (unless they are a committer on the core). If two sub-projects had a compatibility issue, they would at least know who to talk to get a solution. Ron On 07/11/2014 7:04 AM, Jacopo Cappellato wrote: On Nov 7, 2014, at 12:36 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This will no longer work for some components (scrum for instance) I believe we could be reintroduce some specialpurpose component in next release, There is a difference between including them in a release branch and including them in the releases: I would be more inclined to include (all of them) in the release branches but exclude them from the releases; this would simplify the work required to keep them in synch and would also help end users to integrate them. However the specialpurpose components should be disabled
Re: How to use ProjectMgr in 13.07
Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub-project's user community can support or they might maintain 2 versions 13.07 and a 14.xx. that works with a recent version of the trunk. In any case, it would no longer be a problem for the OFBiz core developers and they could release just
Re: How to use ProjectMgr in 13.07
Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I
Re: How to use ProjectMgr in 13.07
diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly nothing to stop a fork of any part of OFBiz but there is some advantage to keeping OZBiz in one piece. The most important thing is that it allows the sub-project to use the OFBiz name and Apache branding in its marketing material and documentation. It also builds the pool of potential contributors and committers for the core. Ron On 07/11/2014 11:44 AM, Jacopo Cappellato wrote: I am fine with the idea of encouraging the growth of an ecosystem of *projects* about OFBiz (not necessarily all within the ASF) but I disagree that they should be *sub-projects* of OFBiz, mostly because sub-projects just add complexity within the OFBiz community (with more paperwork required). Jacopo On Nov 7, 2014, at 5:32 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I agree with a separate community approach, for these reasons: The special purpose components started out as little demonstrations of how OFBiz can be extended to role-specific applications. Since then, some of those components have expanded into full-featured applications - so the overhead of maintaining them has increased beyond what we expected initially. Some special purpose components were included as the result of a community discussion and effort, but others were simply dumped into the repository without any discussion or community participation - and as a result they receive little support. Some special purpose components were created and initially supported by community members who are not around any more. As a result of all of these things, the special purpose components are not well maintained. From my perspective, if anyone believes a component needs more attention and would like to develop it further, then they should spin it off to a separate project. So, instead of having a conversation about how the OFBiz community can better support the Project Manager component, maybe we should have a conversation about how to spin it off to a separate community. Opentaps started off that way. Initially, it was OFBiz plus additional components: Financials, CRM, and Warehousing. I think the OFBiz community would benefit if we stopped trying to be all things to all people, and instead focus on providing a sound and flexible data model - combined with robust, reliable services. Special purpose applications, and even presentation layer details can be left to other communities. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 4:02 PM, Ron Wheeler wrote: I may be beating a dead horse but what Jacopo is proposing and the concern that Jacques raised about resources would seem to fit very well into a sub-project structure. Split these modules out of the main line into their own OFBiz sub-projects where they could attract their own resources (committers even) and would be responsible for delivering modules that worked with the various OFBiz cores that exist. Let the sub-projects worry about their own relationship to OFBiz releases and release branches. They might just support the released 13.07.xx version, if that is what the sub
Re: How to use ProjectMgr in 13.07
The barrier to working on the framework is a technical one. Anyone wanting to work on the framework must understand these things: 1. OFBiz design philosophy and its high-level design. 2. Design patterns (ie GOF). 3. Concurrency (database and Java). 4. Commit history. It would be wonderful if more people would get involved in the framework. It just takes a bit of research, and a little time asking questions from those who have been working on it for a while. Adrian Crum Sandglass Software www.sandglass-software.com On 11/7/2014 8:21 PM, Ron Wheeler wrote: Taher Alkhateeb raised some valid concerns. My take (also as a newcomer) is that there is a high barrier to entry for people working on the framework and this makes it hard to get new people into the OFBiz project. By creating sub-projects that have a much smaller scope and do not have any affect on the overall robustness of the system, we would allow new people to take on tasks that have a much narrower scope and are more in-line withtheir abilities and interests. It will also allow OFBiz to attract subject matter experts on certain areas such as the BIRT language, data analysis, project management or manufacturing who are not attracted to the framework development tasks. The current level of complexity forces the group to be a small band of dedicated people who have the detailed technical understanding of the framework and tools used to build and maintain it. There is nothing to prevent framework contributors from also joining sub-projects where they have an interest. It would also provide a level of transparency about what is getting supported. If no one is active in the BIRT sub-project, at least you know that it is not supported. At the moment, you have no idea about the interest in supporting BIRT. If you need it and it is not supported, currently you do not have anyone to talk to except the framework mailing list. If it had its own sub-project, you would have a leader and a list of people who once had an interest in it. If no one was interested in your BIRT issue, you could always hire someone to work on the bits that you needed fixed. If BIRT is completely orphaned,you could take over leadership of the BIRT sub-project and get it back going. I think that the project management and SCRUM projects could probably put together sub-projects. You would have to do a bit of work to get a BIRT group growing. However, it looks like a good candidate for a separate project since BIRT is a completely different programming language and a lot of the skills have to do with business analysis, usability and data analysis rather than Java coding. You might find that a BIRT sub-project attracts a number of people who would not be interested in supporting the framework. Sub-project will also reduce the amount of traffic on the dev list and allow people to focus on what they think matters to them. They also allow other people to take on leadership roles in these areas which reduces the burden on the current core contributors. Sub-projects are a key part of many Apache projects, so I believe that they must serve a useful purpose. I think that this project is really in need of a way to grow the community without diluting the quality and I see sub-projects as a way to keep the focus within Apache OFBiz rather than fork the parts into outside open source projects which is the current direction. Ron On 07/11/2014 2:08 PM, Taher Alkhateeb wrote: Hi Everyone, I do not have a long history with the OFBiz project to understand its history, but from the last few years I noticed the following: - The system is huge - Documentation is wanting - The community is suffering from low number of experienced developers For example, I use and want to support the BIRT reporting component. Yet there are very few committed developers experienced and comfortable enough in maintaining it and upgrading with new releases. So, I would imagine taking it out as an almost sure death sentence given the already low resources. With all due respect, talking about sub-projects and plans and resources and commit access and all of that stuff does not make sense when you barely have enough experienced people maintaining the code. I see only a few names over and over who are doing the real heavy work. So for my 2 cents, I still strongly encourage the initial suggestion by Jacopo. I think other suggestions would probably kill any less heavily maintained components. Taher Alkhateeb - Original Message - From: Ron Wheeler rwhee...@artifact-software.com To: dev@ofbiz.apache.org Sent: Friday, 7 November, 2014 9:29:05 PM Subject: Re: How to use ProjectMgr in 13.07 I was trying to find some Apache docs about what is involved. Separating the SCM controls so that the sub-projects can have their own committers is an important task. Any idea about what else is required? In any case, it would be the people who want to support the sub-project to do the paperwork. There is clearly
Re: How to use ProjectMgr in 13.07
I've never used svn external property, just discovering. That sounds usefull and i'll try it out ! Thanks for the advice ! Gil On 20/10/2014 19:08, Jacques Le Roux wrote: I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr -- www.nereide.fr Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr http://www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
Re: How to use ProjectMgr in 13.07
I use svn external in the stable demo, already explained that in the MLs: see https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup You can use the same to keep in sync, only consider projectmgr in your case. Since there is no projectmgr in R13.07 the risk of gettins conflicts or build issue is extremely low Jacques Le 20/10/2014 17:28, gil portenseigne a écrit : Hi Jacopo, Ok then, i will have to re-synchronize new trunk devs each time i'll feel it necessary. My fear is about incompatibility between 13.07 and trunk technologies, but that won't happen soon, or i might backport the evolution into my local environment. That will do the job ! Thanks Gil On 20/10/2014 16:36, Jacopo Cappellato wrote: Hi Gil, I would suggest to check it out from the trunk to the hot-deploy folder of 13.07: cd hot-deploy svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr Jacopo On Oct 20, 2014, at 4:11 PM, gil portenseigne gil.portensei...@nereide.fr wrote: Hi all, I don't want to relaunch the debate around including the projectMgmt component into the 13.07 release, but i have a question : What is the best way to import the projectMgr component in my local 13.07 checkout environment, to start using it in a real project and to contribute on upgrading it for trunk and/or the 13.07 release ? Trunk technical evolution might be a problem if a want to stick to 13.07 release with projectMgmt features. Should I use trunk instead ? Cheers Gil -- siteon0.jpg Gil Portenseigne Consultant ERP OFBiz Société Néréide 3b Les isles 37270 Veretz Tel : 09 74 53 46 09, puis 1, poste 61 Mob : 06 82 740 444 www.nereide.fr
