Re: [INFO] Trunk demo back

[Todd Thorner]

Thanks very much.


On 17-06-24 12:57 AM, Jacques Le Roux wrote:

We had it again tonight.

Actually for a reason, the shutdown did not work, the process got 
stuck. Killing (-15) the pending shutdown and previous start processes 
allowed to restart cleanly


I'll wait a bit and if this happens too often I'll get back to using 
terminateOfbiz.


In the meantime I have improved terminateOfbiz at revision: 1799736

https://fr.wikipedia.org/wiki/Kill_(Unix)

https://unix.stackexchange.com/questions/8916/when-should-i-not-kill-9-a-process 



Jacques


Le 20/06/2017 à 09:15, Jacques Le Roux a écrit :

Hi,

The trunk demo is back (failed to start this night)

Jacques

Re: Theme Language and Timezone Video tutorial

[Todd Thorner]

Thanks very much for helping to make OFBiz more accessible to the world.


On 17-08-30 04:53 AM, Deepak Dixit wrote:

We have uploaded new video related to "Theme Language and Timezone"
prepared by Pranay Pandey.

Description:
Learn how to navigate through Apache OFBiz application for setting user
preferences for application UI theme, language, time zone and locate, view
user/party profile.

Here is the youtube and vimeo link for the

https://youtu.be/TDJpVQRVTvI
https://vimeo.com/231685386

Thank you Pranay for your effort.

Thanks & Regards
--
Deepak Dixit
https://ofbiz.apache.org/

Re: Ofbiz vs Shopify or Magento

[Todd Thorner]

Comparing features & capabilities is one thing.  Calling popularity a 
form of competition is irrelevant to this or that enterprise's business 
imperative.



That said, I have no clue regarding a features matrix.  Perhaps that'd 
be a good addition to the web page.




On 17-09-15 09:44 AM, ja...@productive1.com wrote:

I was recently asked this question..."How does Ofbiz compare to Shopify
and Magento.

I was a bit bias as I have been exploring ofbiz for a few months but it
seems that OFbiz offers so much more than the both of them even though
Shopify and Magento have done a great marketing job.

My question to the group.  What are the major strengths and weakness of
OFbiz compared to the two and can Ofbiz REALLY compete against them?

GO!

Thanks,

James

"All major browsers" to support W3C payment request API

[Todd Thorner]

I'm not sure how many developers using OFbiz on the back end will be 
interested in this, but here is the link.



https://www.w3.org/blog/wpwg/2017/09/14/payment-request-api-now-being-implemented-in-all-major-browsers-advances-on-the-recommendation-track/

Re: [FYI] Why Java numbers will maybe be alike Ubuntu and OFBiz

[Todd Thorner]

Yeah, as long as upgrades are smooth for end users, such a release 
schedule appears to be a good idea for all stakeholders.




On 17-09-27 01:57 AM, Jacques Le Roux wrote:

Well explained here : https://mreinhold.org/blog/forward-faster

I wish I had the same good arguments when I proposed this numbering 
for OFBiz back in the days :D


Jacques

Re: [ANNOUNCE] The Big Book for Apache OFBiz Data Model 2017 Released

[Todd Thorner]

This is great news, and thanks to all who made it happen.


Is this book sufficient to understand data modeling as it applies to 
OFBiz, or should users also take time to read those related third party 
titles (The Data Model Resource Book)?




On 17-10-05 03:32 AM, Aditya Sharma wrote:

Hello All,

It gives me immense pleasure informing you all that we have updated *The Big
Book of Apache OFBiz Data Model* according to the latest trunk version.

The key features:
* Colored content with titles according to the internal color pattern.
* Addition of a separate page for integration specific entities.
* Removal of technical process diagrams, making it specific for entities.
* Addition of 77 new entities.
* Removal of 8 entities.
* Addition of around 200+ new fields in entities (Though major portion
includes the addition of description or attrDescription fields in
*Attribute or *TypeAttr entities).
* Removal of 24 fields.

Thanks to Sonal Patwari for all the effort she put in this whole task.
Thanks to Pranay Pandey and Deepak Dixit for the guidance provided.

I have uploaded the files on Data Model Diagrams page. Here is the link
.

Cheers!

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 

Re: Some Information for Creating Modular Documentation

[Todd Thorner]

Yes, that is best practice for documentation, thanks for sharing the links.



On 17-11-15 06:29 AM, Sharan Foga wrote:

Hi All

(I'm resending this message as the original message I sent this 
morning didn't get through to the mailing list. I seem to have an 
intermittent problem with posting somehow ;-)


I recently interviewed Robert Kratky, a Technical Writer from Red Hat 
about his presentation on documentation at the Open Source Summit in 
Prague a few weeks ago. He has some good advice for us and anyone 
looking at writing good documentation. His talk was about how to move 
from feature based documentation (which is what we have tended to do) 
to more user story based documentation that is driven more by how our 
users use the software.


You can listen to the interview at the link below:

https://wp.me/p8gHED-QF

Please take a look at his presentation

schd.ws/hosted_files/osseu17/5f/%28OSSEU%2017%29%20Going%20Modular-%20Turning%20Legacy%20Docs%20into%20User-Story-Based%20Content.pdf 



and also at the github repo with some guidelines for writing modular 
documentation,


https://github.com/redhat-documentation/modular-docs

So as our community continues in its documentation efforts I'd like to 
highlight that anyone can contribute and help by letting us know how 
you are using OFBiz and what are your main user stories.


Thanks
Sharan

Re: Some Information for Creating Modular Documentation

[Todd Thorner]

Documentation is never a liability, unless one considers consumers to be 
a liability (which would make one more of a do-as-you-are-told 
bureaucrat than an I-hope-to-please-you business manager).



Consumers, far from being a liability, are the most important 
considerations within any healthy economy.  As Frederic Bastiat said 
(translated from the original French): "Treat all economic questions 
from the viewpoint of the consumer, for the interests of the consumer 
are the interests of the human race."



Fortunately, each of us spends the vast majority of life, even while at 
work producing things for market, consuming things already available 
from various markets.  Each must embrace the concept of consumer as 
king/queen, or else risk undermining everyone's economic viability (i.e. 
a slippery slope toward the absolute bureaucracy of socialist 
totalitarianism whether it happens to resemble Soviet-style bureaucracy 
or zwangswirtschaft-style bureaucracy).



Bottom line: this is a user mailing list, which makes it a mailing list 
catered toward OFBiz consumers.  When consumers encounter implications 
that they are not the most important consideration, they become inspired 
to take their business elsewhere (at least until encroaching 
totalitarianism precludes such options as things become more bureaucratic).




On 17-11-17 01:34 AM, Taher Alkhateeb wrote:


I went through the material (thank you again for sharing) and I have a
few additional thoughts to share.

Primarily I think there is no silver bullet, and there is no solution
that somehow makes documentation "Fun". It's always going to be a
liability that just comes with any software solution. With that being
said, I would argue that a guide-based vs feature-based documentation
is not necessarily mutually exclusive. You can have both and they
complement each other.

So maybe we should consider designing documentation such that:
- Guides are good, we need a few good ones for common scenarios (hello
world, new component. deployment, security, caching, etc ...)
- Reference material is also good, possibly broken down by feature / module.
- Everything should ideally be as short and concise as reasonably possible,
- Content reuse should be applied as much as possible.
- Documentation needs to constantly evolve (add, change and especially _REMOVE_)

A good example for documentation I always like to use is Gradle [1].
They really have fantastic documentation and I use ALL OF IT. I used
the guides many times, but I also constantly look at the DSL
reference. And when I am trying to implement an advanced feature, I
roll my sleeves and start digging into the API documentation.

To summarize, I think perhaps we should consider the following types
of documentation as beneficial:
- Focused guides (to achieve a specific task)
- Reference documentation (not necessarily covering 100% of everything)
- API documentation (auto generated from source code)

[1] https://gradle.org/docs/

On Thu, Nov 16, 2017 at 9:05 AM, Jacques Le Roux
 wrote:

Le 16/11/2017 à 06:34, Woosang Jung a écrit :

On 2017-11-15 10:10, Jacques Le Roux  wrote:

Le 15/11/2017 à 17:54, Jacques Le Roux a écrit :

This is more for users I guess? Could the technical documentation be
based on the same?

I read a bit more and now clearly understand that it's applicable to all
(user, technical, etc.)

Jacques

I'm all for it. How do I let you know what my main user stories are? Do I
add to this thread?

Woosang

Hi Woosang,

Here are several possible ways for providing your user stories, by order of
preference:

1. If you are a registered wiki contributor (recommended) and want to format
them in Confluence (easier for us), look at the wiki pages I referred
above and see if a new page is needed. If you need, create a new page and
add you user stories there else use an existing page
2. If you are not a registered wiki contributor and don't want to be one,
you can still add your Confluence formatted user stories as comments in
existing pages. So if you need a new page you need to ask for its
creation before adding comments...
3. If you don't want to provide Confluence formatted user stories then open
a Jira and add your unformatted user stories in a text file

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices

Thanks

Jacques
PS:we will maybe need to update
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
for how to document using information above and more...

Re: *.html file rendering in OFBiz screen

[Todd Thorner]

Ah, thanks very much for the explanation.



On 17-12-11 10:14 AM, Michael Brohl wrote:

Hi Amit,

there seems to be a misunderstanding: ftl files are Freemarker 
template files (hence the extension). They can contain any text and 
also html or any other format along with the Freemarker language to 
deal with dynamic data to be rendered. Using the Freemarker language 
is optional.


If you want to render a plain html file, you can just fill your 
template with the html. The output of the ftl file rendered by OFBiz 
is send to the client's browser and diplayed there.


There is no need for an extra extension handled in the HtmlWidget.

Regards,

Michael


Am 11.12.17 um 17:00 schrieb Amit Gadaley:

Hello Everyone,

OFBiz only supports the rendering of *.ftl files in OFBiz screens.
*.ftl files are same as *.html files with richer capabilities but 
sometimes
there are situations where a user needs to render only *.html files 
instead

of *.ftl files.

I have debugged the code and figure out that method 
'*renderHtmlTemplate*'

of HtmlWidget.java is responsible for rendering *.ftl files. I walked
through it and met with this condition:

if (location.endsWith(".ftl")) {
  // render file
} else {
 //return error
}

My proposal is to update this condition like this:

if (location.endsWith(".ftl") || location.endsWith(".html")) {
  // render file
} else {
 //return error
}

I have tested it and it is working fine. I don't see any harm in this
change.

Please share your inputs on this.

Re: *.html file rendering in OFBiz screen

[Todd Thorner]

+1 ... although this might be a better thread for the dev mailing list.


Bottom line: never try to make your customers adjust their processes 
& prerogatives to match your product/service, because that's how 
bureaucracies conduct themselves.




On 17-12-11 08:00 AM, Amit Gadaley wrote:

Hello Everyone,

OFBiz only supports the rendering of *.ftl files in OFBiz screens.
*.ftl files are same as *.html files with richer capabilities but sometimes
there are situations where a user needs to render only *.html files instead
of *.ftl files.

I have debugged the code and figure out that method '*renderHtmlTemplate*'
of HtmlWidget.java is responsible for rendering *.ftl files. I walked
through it and met with this condition:

if (location.endsWith(".ftl")) {
  // render file
} else {
 //return error
}

My proposal is to update this condition like this:

if (location.endsWith(".ftl") || location.endsWith(".html")) {
  // render file
} else {
 //return error
}

I have tested it and it is working fine. I don't see any harm in this
change.

Please share your inputs on this.

Re: Anyone know a way to apply condition to view-entity and then left join to another view-entity?

[Todd Thorner]

I'm very new to OFbiz and very rusty at MVC programming (haven't done
any since Struts 1.x), but I bumped into this page when I was
researching ecommerce front-ends:
http://www.magentocommerce.com/boards/viewthread/33703/

Not sure if that has anything to do with what you're trying to
accomplish, but I thought I'd try pretending to help.  As people might
be able to guess, I'm quite lost so far.


Todd

P.S. to everyone on the board: I hope to learn enough about OFbiz to
pitch in with documentation.  I have 15+ years experience as a tech
writer, mostly doing API docs for SDK products.  At the rate I'm getting
up to speed, it shouldn't take me more than a few years...



On 13-10-30 08:56 AM, Christian Carlow wrote:
> Does anyone know a way to apply a condition to a view-entity and then
> left join it to another view-entity?
> 
> I need to be able to apply a condition to the OrderShipment entity where
> shipmentId = parameters.shipmentId and then left join this conditioned
> view-entity to another view-entity.
> 
> I couldn't figure out how to do it with DynamicViewEntity.

Re: Updated OFBiz Manufacturing & MRP Book

[Todd Thorner]

Hi Sharan,

Thank you very much for updating your book.  Considering that I'm an
OFBiz newbie, might the book help me get a handle on general aspects of
OFBiz as well as its manufacturing/MRP facilities?


Thanks for any insight,

Todd



On 13-11-12 10:08 AM, Sharan-F wrote:
> Hi Everyone
> 
> Just a quick note to let you know that I’ve updated the  “Getting Started
> with Apache OFBiz Manufacturing & MRP” book for release 12.04. It’s
> available from Lulu.com via the link below.
> 
> http://www.lulu.com/shop/sharan-foga/getting-started-with-apache-ofbiz-manufacturing-mrp/paperback/product-21280140.html
> >  
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/Updated-OFBiz-Manufacturing-MRP-Book-tp4645669.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: Updated OFBiz Manufacturing & MRP Book

[Todd Thorner]

I also would like to offer thanks to everyone who was kind enough to
direct my attention to these two books.

For newbies around here like me who didn't quite catch those URLs, here
they are again for future reference from a MarkMail search:

OFBiz Ecommerce Out-Of-The-Box:
www.lulu.com/shop/ruth-hoffman/ofbiz-ecommerce-out-of-the-box/paperback/product-21134896.html

Getting Started with Apache OFBiz Manufacturing & MRP:
http://www.lulu.com/shop/sharan-foga/getting-started-with-apache-ofbiz-manufacturing-mrp/paperback/product-21280140.html

I think they might be wise investments for all but the most capable
OFBiz gurus.  Either that or they're lulu-lemons.  Ha, joke from
Vancouver, I'm sure they'll be great.




On 13-11-13 05:59 AM, Ruth Hoffman wrote:
> Hi All:
> Thanks Pierre for the endorsement!
> 
> I am no offering the Catalog Manager book. It is too out of date.
> Perhaps if I have time next year I will update it.
> 
> I still am selling "OFBiz Ecommerce Out-Of-The-Box". You can get it here:
> 
> www.lulu.com/shop/ruth-hoffman/ofbiz-ecommerce-out-of-the-box/paperback/product-21134896.html
> 
> 
> Best Regards,
> Ruth Hoffman
> rhoff...@aesolves.com
> On 11/13/13 4:02 AM, Pierre Smits wrote:
>> Hi Todd,
>>
>> It sure does. But I advise you to also look into the book 'The OFBiz
>> Catalog Manager' about getting started with the catalog manager (product
>> definitions) by Ruth Hoffman.
>>
>> Should you however need in depth information regarding manufacturing with
>> OFBiz, feel free to contact me directly.
>>
>> With regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Wed, Nov 13, 2013 at 12:01 AM, Todd Thorner
>> wrote:
>>
>>> Hi Sharan,
>>>
>>> Thank you very much for updating your book.  Considering that I'm an
>>> OFBiz newbie, might the book help me get a handle on general aspects of
>>> OFBiz as well as its manufacturing/MRP facilities?
>>>
>>>
>>> Thanks for any insight,
>>>
>>> Todd
>>>
>>>
>>>
>>> On 13-11-12 10:08 AM, Sharan-F wrote:
>>>> Hi Everyone
>>>>
>>>> Just a quick note to let you know that I’ve updated the  “Getting
>>>> Started
>>>> with Apache OFBiz Manufacturing & MRP” book for release 12.04. It’s
>>>> available from Lulu.com via the link below.
>>>>
>>>>
>>> http://www.lulu.com/shop/sharan-foga/getting-started-with-apache-ofbiz-manufacturing-mrp/paperback/product-21280140.html
>>>
>>>> <
>>> http://www.lulu.com/shop/sharan-foga/getting-started-with-apache-ofbiz-manufacturing-mrp/paperback/product-21280140.html
>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>>
>>>>
>>>> -- 
>>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Updated-OFBiz-Manufacturing-MRP-Book-tp4645669.html
>>>
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>
> 

Re: intro to Ofbiz dev presentation

[Todd Thorner]

This noob thanks you.



On 14-01-14 10:16 AM, Jad El Omeiri wrote:
> Hi all,
> 
> I just recently made a presentation about Ofbiz development.
> I thought it would be good sharing the link with you: 
> http://prezi.com/qqp54gt46pn_/?utm_campaign=share&utm_medium=copy&rc=ex0share
> 
>   
> as you can see it online.
> 
> note: credit goes to the book "Apache Ofbiz Development" as it was my
> reference
> advice for all beginners: the book is a must read book!
> 
> 
> 
> -
> Jad El Omeiri
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/intro-to-Ofbiz-dev-presentation-tp4647207.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: intro to Ofbiz dev presentation

[Todd Thorner]

For those who Linux, check out the "Sozi" extension to the Inkscape
application.



On 14-01-15 01:13 AM, Jad El Omeiri wrote:
> Welcome all! it's great to see that I'm able to at least give a 'little
> something' back to the community!
> My presentation is in fact just a "summary" of the book /Apache Ofbiz
> Development/.
> And concerning the tool:  prezi    is indeed great &
> easy to use (I always use it)
> 
> 
> 
> -
> Jad El Omeiri
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/intro-to-Ofbiz-dev-presentation-tp4647207p4647224.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: intro to Ofbiz dev presentation

[Todd Thorner]

You must be joking.  Jad mentioned a great presentation tool called
Prezi, and I added a recommendation for Linux users to check out an
equivalent tool called Sozi so they can create their own poster-zoom
presentations about OFBiz or anything else.

Way to bureaucrat up the place...



On 14-01-15 06:57 AM, Pierre Smits wrote:
> Todd,
> 
> How does your reply aid the prospering of OFBiz in particular? Or is this
> to be considered as spam?
> 
> Pierre Smits
> 
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> 
> On Wed, Jan 15, 2014 at 3:46 PM, Todd Thorner wrote:
> 
>> For those who Linux, check out the "Sozi" extension to the Inkscape
>> application.
> 

Re: WEBINARS

[Todd Thorner]

Thank you, Mr. Smits, for starting this webinar project.  I wish you the
best success and I hope to get a chance to learn some things.

Is there a way to have a general theme in the webinars featuring two
fictional people who are trying to implement similar but not identical
configurations of OFBiz, to demonstrate the different things that might
need to be done in different circumstances?  Maybe someone wants an
ecommerce store front and someone else has different needs?  Call those
two people Alice and Bob, and use each webinar to teach people about the
considerations they need to keep in mind as they try to implement their
own OFBiz solution.

I'm an OFBiz noob, so I don't even know if there's enough things
"different" about various kinds of configurations to make them into a
webinar subject-of-study, let alone the general theme of multiple webinars.

In any case, I'm looking forward to any webinars that can help me take
off the OFBiz training wheels.


On 14-02-10 02:30 AM, Pierre Smits wrote:
> Hi All,
> 
> I am planning to do a series of webinars on how to use the various back end
> applications, starting of with Manufacturing.
> 
> But I am eager to learn what you would like to be handled in this series,
> so please send some feedback and we will see what an how this can be
> scheduled.
> 
> Regards,
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 

Re: OFBiz Performance, a good story

[Todd Thorner]

Thank you, Mr. Byers, for posting such a remark-worthy suggestion, and
thank you, Mr. Rosser, for providing the inertia that might help start
an exciting new OFBiz-related project (congrats as well on securing a
happy jeweler client).

I would be an enthusiastic participant in any documentation project
whose outcome helped business managers become dedicated OFBiz end users.
 Indeed, I am one such hopeful business manager, excited by the prospect
of having OFBiz at the core of my transactional processes, daunted by
the IT learning curve.

I am by trade a tech writer with over 15 years of experience, mostly
doing API docs for SDK products.  I also have a Fine Arts degree in
Creative Writing, and those two properties combined make me one of the
most sought-after writers in the Vancouver IT industry.  I am, though,
as I said, now working on becoming a successful business owner.

>From my perspective, this might be a proverbial golden opportunity.  I
would learn a lot and move up that learning curve, plus I have much to
offer those who seek to improve OFBiz documentation and attract more
CFOs & CMOs to the product.

I ask the community how a prospective team might start a workflow (Agile
or whatever) for such a project.  Would a focal point of managing
productivity be JIRA or something like that?  Is there an
eat-the-dog-food instance of OFBiz out there allowing authorized
contributors to use its Scrum functionality?  Maybe even its CMS
interface?  I would love to help make OFBiz compatible with any
arbitrary CMIS-compliant product, but that's just me...

Thanks for everything that everyone does to make this product world-class.



On 14-02-13 07:26 AM, Ted Byers wrote:
> On Thu, Feb 13, 2014 at 7:06 AM, Nick Rosser  wrote:
> 
>> All,
>>
>> I thought I'd share some encouraging news from a recent implementation we
>> were involved in:
>>
>>  * we built a site for a Philly based jeweler who has some unique
>>products geared for Valentine's Day
>>  * they start their sale on 1-Jan, it typically gains real momentum by
>>the end of Jan, and peaks around the 11th, 12th Feb
>>  * peak #visitors (day): 20,000
>>  * peak #pageviews (day): 150,000
>>  * peak #orders (day): ~4000
>>  * peak #concurrent users: 275
>>
>> And perhaps the most impressive fact around performance was that during
>> peak the site was flying, no noticeable difference if there was a single
>> user or 275 concurrent users.
>>
> 
> This looks good.  It wouldn't be so good if you had to deploy on the latest
> super-computer to get that performance, but it would be astounding if you
> could get that off a five year old desktop that would otherwise be a really
> ugly paper-weight.  ;-)
> 
> I agree with you that it would be good to collect reports like yours
> regarding good performance.  Might I suggest setting something up either on
> the OFBiz site, or on yours, to make such reports easy to find.  I would
> also suggest that the technical details of the host be provided (whether
> that is on Amazon's service, or one of the many other hosting services),
> documenting at least the amount of RAM, number of cores/processors, and
> hard disk space.  And with the processors, some indication of the speed of
> the processor (after all, my current workstation, with 8 cores, is more
> than an order of magnitude faster than my old HP that had a 4 core AMD -
> not all cores were created equal).  And how many (virtual) machines were
> used: 2, 3, more?  And if more than one, how is each used?
> 
> It is great that this is affordable for small business, but a good
> businessman is going to want information that lets him assess the cost of
> getting it done (both initial setup and continuing monthly costs), along
> with the performance, and whether or not the interface is user friendly.
> How can a businessman hope to do a cost-benefit analysis without such
> information, especially if he or she knows little about IT save that it is
> needed and must rely on outside consultants?
> 
> I would suggest that, in addition to providing information suitable for
> other developers interested in contributing code, and more for users, it is
> necessary for some documentation, along with reports of performance like
> yours, written to deal with the concerns of a businessman from the
> perspective of businessmen.  Only then will OFBiz really thrive, if I may
> use that metaphor.
> 
> Cheers
> 
> Ted
> 

Re: OFBiz Performance, a good story

[Todd Thorner]

Hi Ted,

I'm still in full-doofus mode regarding OFBiz and its capabilities for
integrating with third-party services/apps from various
frameworks/languages.  I'm not even strong enough on the uptake to know
whether something like the ASF's Camel project might be stepping in the
right direction.

I haven't thought much about UML diagramming tools since I used the old
Rational Rose product while doing some Struts 1.x web app programming
(over 10 years ago).  I'm afraid that when it comes to
design/development/implementation this tech writer is always playing
catch-up with the professionals.  Documentation is my strength.

That said, diagramming some use cases in UML would be an important
consideration for coming up with answers to various questions that
C-levels might have while conducting OFBiz cost-benefit analyses.  I
know that Ruth Hoffman wrote a great introductory book about high-level
OFBiz ecommerce functionality, a solid jumping-off point for business
managers who are as IT-non-savvy as I am.

I am among the demographic of end users for such hand-holding
documentation.  How can another OFBIz-related project help potential end
users take that next step from Hoffman's introductory book toward
practical milestones?

Perhaps gathering requirements would be a reasonable place to start.  I
will evaluate options for hosting such a collaborative documentation
project (question for OFBiz site admins: is there a sandbox area in the
wiki that is available?)

I sense a tiny bit of traction.  Here's hoping it gets beyond just a few
people talking around one another.





On 14-02-13 10:12 AM, Ted Byers wrote:
> On Thu, Feb 13, 2014 at 12:36 PM, Todd Thorner wrote:
> 
>> Thank you, Mr. Byers, for posting such a remark-worthy suggestion, and
>> thank you, Mr. Rosser, for providing the inertia that might help start
>> an exciting new OFBiz-related project (congrats as well on securing a
>> happy jeweler client).
>>
>> I would be an enthusiastic participant in any documentation project
>> whose outcome helped business managers become dedicated OFBiz end users.
>>  Indeed, I am one such hopeful business manager, excited by the prospect
>> of having OFBiz at the core of my transactional processes, daunted by
>> the IT learning curve.
>>
>> I am by trade a tech writer with over 15 years of experience, mostly
>> doing API docs for SDK products.  I also have a Fine Arts degree in
>> Creative Writing, and those two properties combined make me one of the
>> most sought-after writers in the Vancouver IT industry.  I am, though,
>> as I said, now working on becoming a successful business owner.
>>
>> From my perspective, this might be a proverbial golden opportunity.  I
>> would learn a lot and move up that learning curve, plus I have much to
>> offer those who seek to improve OFBiz documentation and attract more
>> CFOs & CMOs to the product.
>>
>> I ask the community how a prospective team might start a workflow (Agile
>> or whatever) for such a project.  Would a focal point of managing
>> productivity be JIRA or something like that?  Is there an
>> eat-the-dog-food instance of OFBiz out there allowing authorized
>> contributors to use its Scrum functionality?  Maybe even its CMS
>> interface?  I would love to help make OFBiz compatible with any
>> arbitrary CMIS-compliant product, but that's just me...
>>
>> Thanks for everything that everyone does to make this product world-class.
>>
>>
> You're welcome Todd,
> 
> I don't have a specific answer for the questions you raise.  I generally go
> with whatever works with the team with whom I am working at the time.
> 
> My priority, right now, is to first learn how to set up a multi-tenant
> installation of OFBiz, as well as a multi-site installation of wordpress;
> and then how to integrate the two so that OFBiz's ecommerce component can
> be used to handle payment for subscriptions to the contents on one or more
> of the sites in the Wordpress installation.  I'd also want to be able to
> support use of, the relevant back office components (e.g. the accounting),
> for a venture that is focused on publishing.
> 
> I then want to install Redmine, in order to be able to exploit it's project
> management features (including issue/bug tracking).  I have not yet begun
> to see to what extent Redmine's capabilities are complementary to OFBiz's
> capabilities or how much overlap there may be, e.g., WRT the work effort
> components).  While Redmine, itself, integrates into a couple version
> control products (notably Subversion), it does not seem to have, as far as
> I can tell, support for any of the UML diagrams.  What I am keeping an eye
>

Re: OFBiz Performance, a good story

[Todd Thorner]

Thanks very much for the information, Mr. Le Roux.  I'm not sure what I
might be able to do to help the project, so I'll look into the
contributor thing.  Considering how little time I've had to spend on my
company's OFBiz rollout, I'm still counted among the newest of the
newbies.  I am starting to learn a few things, though, from following
these mailing list threads.

>From the long "OFBiz.org site: easier navigation to Service Providers
and End Users" thread that's been bouncing around here (it has evolved
into more of an admin discussion than a user discussion), I gather that
I could create my own OFBiz-related content (e.g. documentation) to be
hosted elsewhere, so long as I adhere to OFBiz/ASF guidelines.  Heck,
even books are possible, if I manage to grab enough of a clue.

All in all, I need to learn more before I can start creating anything.
That's ok, though, I'm accustomed to the tech writer process.  I don't
want to take up people's time on this user-specific mailing list for the
sake of a corollary technical project, so I'll try to keep it to a bunch
of "Hey, how does this work in OFBiz" questions until I have some kind
of alpha-release announcement for other users.

Thanks again.




On 14-02-23 04:39 AM, Jacques Le Roux wrote:
> I'm not quite sure what you are looking for
> 
> Before living the project David created a space for requirements
> https://cwiki.apache.org/confluence/display/OFBREQDES/Home But it's not
> open like the wiki.
> 
> In the wiki you have this blank page
> https://cwiki.apache.org/confluence/display/OFBIZ/Requirements+gathering
> with children pages
> 
> You can edit and create you own pages in the wiki as soon as you are
> registered as a contributor (see explanation at top of each wiki page)
> 
> HTH
> 
> Jacques
> 
> Le 13/02/2014 20:22, Todd Thorner a écrit :
>> Hi Ted,
>>
>> I'm still in full-doofus mode regarding OFBiz and its capabilities for
>> integrating with third-party services/apps from various
>> frameworks/languages.  I'm not even strong enough on the uptake to know
>> whether something like the ASF's Camel project might be stepping in the
>> right direction.
>>
>> I haven't thought much about UML diagramming tools since I used the old
>> Rational Rose product while doing some Struts 1.x web app programming
>> (over 10 years ago).  I'm afraid that when it comes to
>> design/development/implementation this tech writer is always playing
>> catch-up with the professionals.  Documentation is my strength.
>>
>> That said, diagramming some use cases in UML would be an important
>> consideration for coming up with answers to various questions that
>> C-levels might have while conducting OFBiz cost-benefit analyses.  I
>> know that Ruth Hoffman wrote a great introductory book about high-level
>> OFBiz ecommerce functionality, a solid jumping-off point for business
>> managers who are as IT-non-savvy as I am.
>>
>> I am among the demographic of end users for such hand-holding
>> documentation.  How can another OFBIz-related project help potential end
>> users take that next step from Hoffman's introductory book toward
>> practical milestones?
>>
>> Perhaps gathering requirements would be a reasonable place to start.  I
>> will evaluate options for hosting such a collaborative documentation
>> project (question for OFBiz site admins: is there a sandbox area in the
>> wiki that is available?)
>>
>> I sense a tiny bit of traction.  Here's hoping it gets beyond just a few
>> people talking around one another.
>>
>>
>>
>>
>>
>> On 14-02-13 10:12 AM, Ted Byers wrote:
>>> On Thu, Feb 13, 2014 at 12:36 PM, Todd Thorner
>>> wrote:
>>>
>>>> Thank you, Mr. Byers, for posting such a remark-worthy suggestion, and
>>>> thank you, Mr. Rosser, for providing the inertia that might help start
>>>> an exciting new OFBiz-related project (congrats as well on securing a
>>>> happy jeweler client).
>>>>
>>>> I would be an enthusiastic participant in any documentation project
>>>> whose outcome helped business managers become dedicated OFBiz end
>>>> users.
>>>>   Indeed, I am one such hopeful business manager, excited by the
>>>> prospect
>>>> of having OFBiz at the core of my transactional processes, daunted by
>>>> the IT learning curve.
>>>>
>>>> I am by trade a tech writer with over 15 years of experience, mostly
>>>> doing API docs for SDK products.  I also have a Fine

Re: Ofbiz data model

[Todd Thorner]

Perhaps look toward presenting the data model with one of those
Prezi/Sozi poster-zoom thingies.  If the data model changes frequently,
I'd recommend Sozi because at the end of the day Sozi presentations are
merely SVG files (which are of course XML files that can be spun-up from
various editable source files).



On 14-03-02 01:33 AM, Jacques Le Roux wrote:
> The data model illustration by David at
> https://cwiki.apache.org/confluence/display/OFBTECH/Data+Model+Diagrams
> was done in Fall 2008.
> The data model has not changed much since and you can safely refer to
> it. At least it's IMO the better illustration we have...
> AFAIK it's complete, well organised and easy to read (as can be: though
> there are "only" 800+ tables in OFBiz, against for instance 3500+ in
> Adempiere, it's still a BIG data model)
> I personally renamed the PDFs to have the page numbers in names. It's
> then easier to know which file to open when looking at the TOC.
> There were some other efforts, some are older but could be interesting
> also in some cases (not arranged the same way).
> https://cwiki.apache.org/confluence/display/OFBIZ/Data+Model+Packages
> https://cwiki.apache.org/confluence/display/OFBIZ/Key+data+model+reference
> 
> When I began to work with OFBiz (ten years ago) I looked for a graphic
> tool to dynamically represent the data model. I tried some then but
> nothing was really useful.
> Maybe there are appropriate tools now...
> 
> HTH
> 
> Jacques
> 
> 
> Le 02/03/2014 07:58, Adrian Crum a écrit :
>> Originally, the data model was based on the The Data Model Resource
>> Book. But the project has deviated from that model a lot since then.
>>
>> The diagrams you are looking at are quite old, and they demonstrate a
>> fundamental flaw in documentation of that sort - the data model
>> continues to evolve and any attempt to document it is obsolete soon
>> after it is created.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 3/1/2014 5:36 PM, Chris Perry wrote:
>>> Hi Jacques,
>>> I did see those diagrams. Is that the complete data model? I thought
>>> there
>>> was another set of diagrams in the older user documentation that was
>>> (possibly) more complete.
>>>
>>> Thanks,
>>> Chris
>>>
>>> -Original Message-
>>> From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
>>> Sent: Saturday, March 01, 2014 2:57 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Ofbiz data model
>>>
>>> I guess you are thinking about this page
>>> https://cwiki.apache.org/confluence/display/OFBTECH/Data+Model
>>>
>>> Jacques
>>>
>>> Le 01/03/2014 20:24, Chris Perry a écrit :
 Can someone please point me to the complete set of data model diagrams
 that used to be easy to find?



 Thanks,

 Chris


>>>
>>

Re: Reposting from David Jones on Moqui

[Todd Thorner]

I just found out about Moqui, but I refuse to sign up for LinkedIn so I
won't be joining that community anytime soon.

Pity party for me, I suppose.  Considering how I'm just barely getting
on board with the whole "ERP/E-Commerce framework" thing, I'd prefer to
start off with the latest up-and-coming technology.  I loathe the idea
of keeping some legacy system patched together while 99.99% of the
business world has moved on to something else.  I can remember the whole
"Forget about DP and just keep using these Selectrics we all know and
love" debate among tech writers 25-odd years ago, as well as the
argument about whether RDBMS/SQL was going to make much of an impact on
companies with established, proprietary mainframe systems.  For that
matter, ten or twelve years ago I was a big fan of Struts, although many
have since moved on to Springier things (or away from Java altogether).

Are differences between the OFBiz and Moqui frameworks quite
significant?  That's not a question directed toward Mr. Byers
specifically, I'm just trying to get a potential business strategy
straightened out in my head.

Aside: I might as well put in my 0.02 regarding the teleconference that
Mr. Smits arranged.  Almost all software products both open source and
proprietary share a major end user pain point: documentation.  All too
often, in a bug-ticket kind of way, such pain points go beyond being
major to become critical show-stoppers.

Oh, and also 0.02 worth of cheerleading for CMIS.  If y'all get a
chance, take a look at the ASF Chemistry project, it might offer a way
to lessen some of this project's code maintenance chores (although I'm
in no way qualified to be certain one way or the other).



On 14-03-07 08:43 AM, Al Byers wrote:
> And BTW, I need to emphasize that I do not think the PMC has been selfish
> in their actions. They have added untold value to OFBiz. If I had made the
> sacrifices that they have made, I would be hesitant to entertain notions
> that would detract from that value. I just happen to think that when looked
> at objectively, porting to Moqui would be the best choice in terms of
> keeping the project viable.
> 
> 
> On Fri, Mar 7, 2014 at 11:12 AM, Al Byers wrote:
> 
>> Adrian, I think that you have summed up the situation in your succinct
>> post - there are some service providers who are heavily invested in this
>> project and it is their concern for their own interests that is  guiding
>> OFBiz. Someone new looking at OFBiz should lament the fact that so much
>> application value is tied to such old technology. Then they should look at
>> Moqui and see how easy it would be to port that value to a new platform -
>> at least much easier than creating a new framework - and wonder why it is
>> not being done.
>>
>> I reject the idea that "anyone is interested in building applications on
>> Moqui, [...]should do it in the Moqui community". OFBiz does not belong to
>> the PMC; it belongs to everybody. I have a dream... sorry, got carried
>> away. This seems like a test of the Apache framework - does it provide for
>> the long-term life of a project when it conflicts with the self-interests
>> of the PMC?
>>
>>
>> On Fri, Mar 7, 2014 at 10:24 AM, Adrian Crum <
>> adrian.c...@sandglass-software.com> wrote:
>>
>>> Switching OFBiz to a different framework has been discussed in the past,
>>> and I brought up the subject again in a recent thread on the dev mailing
>>> list. At this time, there are some PMC members who are opposed to the idea,
>>> so I don't see any hope for switching to Moqui in this project.
>>>
>>> If anyone is interested in building applications on Moqui, then they
>>> should do it in the Moqui community.
>>>
>>> I don't agree that OFBiz is a sinking ship. There are a number of service
>>> providers who are heavily invested in this project, and they are not going
>>> to throw that all away for a new one.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>>
>>> On 3/7/2014 5:58 AM, Al Byers wrote:
>>>
 In light of the current discussion about the future of OFBiz I thought it
 would be worth revisiting one of my finer moments by reposting this from
 David Jones. In today's world 12 technology years is a lifetime. It is
 not
 reasonable to think that we can keep scaling the original framework.
 Another thing to think about is that in order to attract a new group of
 users sometimes it takes a big new idea and Moqui fills that role. We
 should all keep in mind that OFBiz succeeded secondly because of all the
 hard work put in by the community, but firstly because of the brilliant
 architecture and foundation provided by David (and Andrew). When that
 same
 mind applies it to fixing most of OFBiz's problems we should be talking
 about how to transition - end of discussion, IMHO.

 I believe that it has been since David wrote this email that he has
 integrated Elasticsearch and Drools into Moqui. Those 

Re: Reposting from David Jones on Moqui

[Todd Thorner]

Cool, thanks for the information and for the framework contribution.
One thing I do like is Moqui's public domain non-license arrangement
with potential users (my opinion is that IP stands for Imaginary
Property).  If that project wanted to use your type conversion framework
(or anything else from the OFBiz project), they would need to include a
copy of the Apache License over there too, right?

That would, of course, destroy their vision of having a project
unencumbered by any IP legalese.  I think I'd rather see them write
their own framework from scratch (more duplication of effort of course
but that was always their call to make).

I'm hoping the ASF will release all projects into the public domain.



On 14-03-07 01:58 PM, Adrian Crum wrote:
> On 3/7/2014 11:58 AM, Skip wrote:
>> I am sure Moqui is a fine framework, but I must agree with Adrian.  Yes,
>> lets all just abandon hundreds of man-years of work and start from
>> scratch.
>> I don't know about most of you, but I derive most of my income servicing
>> EXISTING Ofbiz derived works.
>>
>> Specifically, I take issue with the following from Al:
>>
>> 1.  "It is not reasonable to think that we can keep scaling the original
>> framework." --- Bull.  Ofbiz (or derivitives) is used by many LARGE
>> companies and scaling does not seem to be an issue.  Furthermore,
>> Ofbiz is
>> mostly used by smallish companies where scale is not an issue.
> 
> From a developer's perspective, OFBiz is in some ways more scalable than
> Moqui. I'm going to give an arcane example, but I think it illustrates
> well why I am not enthusiastic about switching to Moqui.
> 
> Some years ago I introduced a new data type in the OFBiz framework -
> TimeDuration. Getting that new data type integrated into the framework
> was a huge problem, because there are many places in the framework where
> data type conversion is needed, and in all those places there were long
> switch statements. Every one of those switch statements needed to be
> modified to accommodate the new data type. Worse, not all of the switch
> statements were the same - so the existing data type conversion was
> inconsistent.
> 
> So, I created a flexible, expandable data conversion framework that
> makes it easy to introduce new data types into the project - without the
> need to modify the framework code. I replaced all of the switch
> statements with calls to the conversion framework. Now users can create
> their own data types and add them into the conversion framework easily.
> 
> How does Moqui handle data conversion? Multiple switch statements. So, a
> scalability problem that was solved in OFBiz was duplicated in Moqui.
> 
> -Adrian

Re: Reposting from David Jones on Moqui

[Todd Thorner]

All I know is I'm more confused than ever, and that's saying something
because I'm always a bit of a drooler.

For the time being, I hitch my business wagon to neither project.  My
business is lucky that way, being at the moment completely ERPa derpa it
will be able to adapt to one or the other (or maybe yet another) after I
have time for more thorough information gathering.

Mr. Jones, if you're influential over at Moqui (I'm guessing you are if
you started the darned thing), please consider creating a regular ol'
mailing list so I can join the community and learn more.  I prefer to
stop taking up space within the OFBiz ml talking about how I'd like to
check out one of its alternatives -- but I don't do LinkedIn and Stack
Overflow is more for my potential "I'm trying to implement this..."
questions.



On 14-03-10 08:45 AM, Pierre Smits wrote:
> This is truly a nice thread. With lots of assumptions and veiled
> accusations of hardened viewpoints... The other must change for my benefit
> (that is what I perceive)...
> 
> But let us bring in some perspective:
> 
>- SAP r/3  was launched in 2002
>and was/is an evolution of something else.
>- JD Edwards  came from the
>mainframe (way back when)
>- The variants offered by Microsoft came from all over the world and
>started also way back when...
> 
> 
> And are these competitors all at the end of their individual lifecycles?
> I dare to say No.
> 
> And do these all have (had) their share of legacy issues?
> And if started anew would the owners/architects/business consultants/system
> developers/programmers et al. behind these product shed paradigms and
> introduce new ones?
> And if done so, would these new paradigms not also require a lot of effort
> (of a lot of people) to implement, reach maturity and when new architects
> get on board lose their momentum?
> 
> I dare to say Yes.
> 
> What I am trying to get accross is this:
> It took a lot of persons to get OFBiz to where it is now. This is not only
> the feat of David, though his contribution is substantial.
> 
> And David starting over (and shedding wrong paradigms - in his vision and
> perception) took him 4 year to get Moqui to where it is now. But it doesn't
> deliver today what OFBiz delivers. Yes, it is a clean slate. With new
> learning (steep) learning curves and such...
> 
> But yes, when anyone needs to implement something new for a customer the
> criteria on which you need to choose the framework to work with is your
> skill set, as time-to-market dictates cost.
> 
> David chose to not do the paradigm shifts within this community. And why?
> 
> Anyway, that ship has sailed and that can be regarded as sad.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 

Re: WEBINARS

[Todd Thorner]

I'm willing to help if I can, although the only thing I have to offer at
this point is editing talent (making good writing look like great writing).

Keep in mind something that seriously ticked me off the other day.  I
wanted to check out a webinar for a product called Wowza, which bills
itself as a streaming server that "allows just about anyone on any
platform to watch your video source."  Problem was, the webinar service
they used pulled the ol' "We're sorry, but unless you are using Windows
or Mac you cannot join this webinar" garbage, which ended up making
Wowza itself look bad.

Which is to say: if your product is marketed as something that works on
platforms other than Windows/Mac, make sure your webinars don't insult
those who prefer something besides Windows/Mac.  Not that OFBiz has ever
done any such thing, just saying ... that I'm willing to help if I can.

Here's one opinion.  Use poster-zoom presentations about the OFBiz MVC
framework & data model as visual aids during webinars (also as
standalone pages accessible from the site or the wiki or something like
that).



On 14-03-16 03:12 PM, Pierre Smits wrote:
> Hi Lei,
> 
> As this is volunteer work I can't possibly give any schedule on this. But I
> have noted the interest areas and will take that as guidance.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 

Re: Actionable tasks of the week - volunteers?

[Todd Thorner]

Thank you, Mr. Cappellato, for this initiative.  It's a great idea IMO,
please keep 'em coming.

I will watch for more emails such as this one, hoping to find something
that isn't too challenging for my meagre skill set.  Already, though,
this first email has inspired me to make time over the weekend to peruse
the JIRA tickets, to see if there is some "Mickey Mouse" thing I could
do to help.  If I find anything, I'll come back to this ml to ask about
getting initiated as an authorized project contributor.




On 14-03-20 09:01 AM, Jacopo Cappellato wrote:
> In order to encourage the participation of the community into the development 
> of OFBiz and specifically in the resolution of tickets filed in Jira, I would 
> like to try this experiment.
> 
> From time to time I will review a series of tickets, select the ones that 
> look not too complex, actionable but still need some work, I will do a 
> preliminary research and study and will provide some directions/hints for a 
> resolution; then I will send an email (this email) with the list of tickets, 
> looking for volunteers to try to fix them.
> If you want to give it a try, just assign the ticket to yourself and start 
> playing with it. I will then take care of reviewing the work and committing 
> it to the official repository (of course recognizing merit to the author in 
> the commit log).
> 
> If the experiment will work other committers may want to do the same in order 
> to process more tickets from our backlog.
> 
> Here is the first batch of tasks that I have reviewed:
> 
> https://issues.apache.org/jira/browse/OFBIZ-5589 (see my analysis in the 
> comment, create a patch with the suggested enhancements)
> https://issues.apache.org/jira/browse/OFBIZ-5590 (try to get some more info 
> from the reporter and then probably resolve as "not a problem")
> https://issues.apache.org/jira/browse/OFBIZ-5551 (get more information from 
> the reporter - see my questions - and try to recreate the issue gathering 
> more details)
> https://issues.apache.org/jira/browse/OFBIZ-5543 (see my comments: the bug 
> has been reported in 11.04; it works in the trunk; try to recreate in 11.04 
> and then identify the oldest branch where it works and try to backport the 
> fix)
> https://issues.apache.org/jira/browse/OFBIZ-5559 (the patch available should 
> be good for the trunk but it would be great to have a deeper review before 
> its committed)
> https://issues.apache.org/jira/browse/OFBIZ- (recreate the error, review 
> and test the patch, convert it from git to svn patch)
> https://issues.apache.org/jira/browse/OFBIZ-5553 (review and test the patch 
> that converts an ftl into widgets; is the new version functionally 
> equivalent? is the code well formatted and written?)
> 
> Thanks in advance,
> 
> Jacopo
> 

Re: OfBiz workflow

[Todd Thorner]

Forgive the amateur-speak, but would it be ok to invent an abstracted
layer of vendor-neutral APIs & service bindings & such forth that
engenders implementation interest among entities like SugarCRM and its
competitors?  It'd be kind of like what SQL did for the database
industry, or what CMIS is doing for content management.

How about docker-friendly OFBiz modules & components?  That coupled with
"standards" at the transport/messaging/whatever layer would make OFBiz
very customizable, at least for *NIX admins.  Check out this
infomercial:
https://coreos.com/blog/coreos-just-got-easier-to-try-with-panamax/

In any case, adapt or die.  As an Alfresco user, I offer thanks to those
considering Activiti workflow integration for OFBiz.  Now if I could
only make some progress up the learning curve for this project ...



On 14-09-19 09:20 AM, Ted Byers wrote:
> On Fri, Sep 19, 2014 at 11:42 AM, Ron Wheeler
>  wrote:
>> They are suggesting that you will use the one that OFBiz already has for
>> that purpose.
>> Nothing new to do. Just create the module identification and then the issues
>> that you need in order to define the work on the Workflow project.
>>
> 
> I am suggesting nothing of the sort.  Rather, I am just curious as to
> who pays for the use of this particular commercial product.  And, I am
> curious as to what open source alternatives exist and how they
> compare.
> 
> As a software engineer, I HATE reinventing the wheel.  Thus, if I were
> involved in OFBiz much earlier in its development, I would have
> suggested facilitating use of it WITH SugarCRM (or it's competitor,
> whose name I have quite forgotten at the moment), instead of
> developing a whole new contact management system within OFBiz, and for
> content management, I would have suggested facilitating use of OFBiz
> WITH Wordpress, again instead of developing a whole new content
> management system.  But then, if the available options for particular
> tasks is deemed wanting for whatever reason, I'd have no objection to
> the development of new code, either to try to use these (obviously
> open source) products while adding code to address perceived
> deficiencies or to create a competitor de novo (there are sometimes
> good reasons for doing this too).
> 
> But, in this present context, I am only interested in the cost of the
> present practice, and who pays, and the decision making process that
> led to use of jira instead of the alternatives (if there are viable
> alternatives).  Understanding this may well inform my own decisions in
> the not too distant future.
> 
> I am not, at present, interested in recommending changing anything,
> especially if those who are actually doing the work are happy with
> what is presently in place.
> 
> Cheers
> 
> Ted
> 
>> Rn
>>
>> On 19/09/2014 11:34 AM, Ted Byers wrote:
>>>
>>> On Fri, Sep 19, 2014 at 11:19 AM, Adrian Crum
>>>  wrote:

 Typically, this sort of thing is done in Jira - which provides a set of
 collaboration tools and a means for voting on the change.

>>> Jira is proprietary; so who pays for it?  Or, is it free for open
>>> source projects, non-profit organizations or educational institutions?
>>>   Is there not an open source equivalent?
>>>
>>> Cheers
>>>
>>> Ted
>>>
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com


 On 9/19/2014 2:17 PM, Ron Wheeler wrote:
>
> I would suggest an virtual meeting as an alternative so that the team
> can decide on scope, initial tasks, priorities and project management
> structure.
> This should be followed by a note to the ML summarizing the discussion
> and decisions taken and could include an invitation to others to
> participate.
>
> This might save several weeks of dancing on the ML.
>
> Ron
>
>
> On 19/09/2014 8:00 AM, Pierre Smits wrote:
>>
>> Varun044,
>>
>> The path is to work together with the contributors who pledged their
>> willingness to work on this. These are:
>>
>>  - Hans Bakker
>>  - Mohd Viqar
>>  - Rong Nguyen
>>
>> The best place to do this is discuss it in this mailing list.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Sep 19, 2014 at 1:54 PM, varun044  wrote:
>>
>>> Thanks you for the prompt reply Pierre.
>>>
>>> So, if I have to implement workflow in ofbiz now, which is the best
>>> path?
>>> Should I check into Activiti?
>>>
>>> If you have some resources on the same, kindly share.
>>>
>>> Thanks again!
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>>> http://ofbiz.135035.n4.nabble.com/OfBiz-workflow-tp4655455p4655462.html
>>> Sent from the OFBiz - User mailing l

Re: OfBiz workflow

[Todd Thorner]

Thank you, sir, for taking time out of your day to explain a few things.
 Most of it is penetrating a certain thick skull.


On 14-09-19 11:05 AM, Ted Byers wrote:
> Of course Todd.  All that you're suggesting is fine, as long as there
> is a rational  argument for doing it (and in many cases there is - I
> just ask that if I involve myself in a project, I know what that
> argument is).
> 
> I am not about to develop a new CRM de novo, when there exists
> products like SugarCRM.  It would be different in only two cases: 1)
> the existing products are immature and unreliable and the effort to
> make them adequate for use in production is greater than the cost to
> start again de movo, and 2) the product is mature and quite usable,
> but lacks support for a key, and essential feature, and the
> architecture used makes adding support for the missing feature
> impracticable.  If there is a product that satisfies most of my
> requirements, I am most likely to develop new code just to add support
> to that product for the features(s) I require that are not already
> there.
> 
> Now, commercial entities, with big bucks to invest, may well want to
> develop a new entry for a given market, just because they can; but
> that is based on a perceived opportunity and a belief they can produce
> a better product than those that currently exist and so out-compete
> the existing products/providers.  But that is a completely different
> situation that I have not experienced directly, and am not likely to.
> 
> Cheers
> 
> Ted
> 
> On Fri, Sep 19, 2014 at 1:27 PM, Todd Thorner  wrote:
>> Forgive the amateur-speak, but would it be ok to invent an abstracted
>> layer of vendor-neutral APIs & service bindings & such forth that
>> engenders implementation interest among entities like SugarCRM and its
>> competitors?  It'd be kind of like what SQL did for the database
>> industry, or what CMIS is doing for content management.
>>
>> How about docker-friendly OFBiz modules & components?  That coupled with
>> "standards" at the transport/messaging/whatever layer would make OFBiz
>> very customizable, at least for *NIX admins.  Check out this
>> infomercial:
>> https://coreos.com/blog/coreos-just-got-easier-to-try-with-panamax/
>>
>> In any case, adapt or die.  As an Alfresco user, I offer thanks to those
>> considering Activiti workflow integration for OFBiz.  Now if I could
>> only make some progress up the learning curve for this project ...
>>
>>
>>
>> On 14-09-19 09:20 AM, Ted Byers wrote:
>>> On Fri, Sep 19, 2014 at 11:42 AM, Ron Wheeler
>>>  wrote:
>>>> They are suggesting that you will use the one that OFBiz already has for
>>>> that purpose.
>>>> Nothing new to do. Just create the module identification and then the 
>>>> issues
>>>> that you need in order to define the work on the Workflow project.
>>>>
>>>
>>> I am suggesting nothing of the sort.  Rather, I am just curious as to
>>> who pays for the use of this particular commercial product.  And, I am
>>> curious as to what open source alternatives exist and how they
>>> compare.
>>>
>>> As a software engineer, I HATE reinventing the wheel.  Thus, if I were
>>> involved in OFBiz much earlier in its development, I would have
>>> suggested facilitating use of it WITH SugarCRM (or it's competitor,
>>> whose name I have quite forgotten at the moment), instead of
>>> developing a whole new contact management system within OFBiz, and for
>>> content management, I would have suggested facilitating use of OFBiz
>>> WITH Wordpress, again instead of developing a whole new content
>>> management system.  But then, if the available options for particular
>>> tasks is deemed wanting for whatever reason, I'd have no objection to
>>> the development of new code, either to try to use these (obviously
>>> open source) products while adding code to address perceived
>>> deficiencies or to create a competitor de novo (there are sometimes
>>> good reasons for doing this too).
>>>
>>> But, in this present context, I am only interested in the cost of the
>>> present practice, and who pays, and the decision making process that
>>> led to use of jira instead of the alternatives (if there are viable
>>> alternatives).  Understanding this may well inform my own decisions in
>>> the not too distant future.
>>>
>>> I am not, at present, interested in recommending changing anything,
>>> especially if those who are a

Re: Mike's response to "Project morale"

[Todd Thorner]

Thank you, sir.  I have been biting my cybertongue this whole time,
knowing that the flames would die and hoping in the meantime to avoid
perpetuation of the childishness -- but this call for bureaucratic "big
guns" to bully other bureaucrats into some sense of bureaucratic order
is just too much.

Remember, everyone, this project isn't called OFBureau.  Raise your
hands in the air, all you entrepreneurs out there.



On 14-09-24 03:30 PM, Mike wrote:
> Correction:  I agree that a more appropriate, respectful tone should be
> expressed on the ML, but I don't believe it is necessary to get the PMC
> involved.
> 
> On Wed, Sep 24, 2014 at 3:00 PM, Mike  wrote:
> 
>> +1
>>
>> On Wed, Sep 24, 2014 at 8:22 AM, Ron Wheeler <
>> rwhee...@artifact-software.com> wrote:
>>
>>> The Chairperson and the senior PMC members need to step in very quickly
>>> to stop personal attacks.
>>> This is a very corrosive element in this project and the PMC needs to see
>>> that this is not allowed in the ML or meetings.
>>> People need to be able to disagree without being disagreeable.
>>>
>>> When a conversation strays from concepts or technology into insults and
>>> personal attacks, it is the person making the personal attack that loses
>>> the respect of the community.
>>>
>>> View from the cheap seats.
>>> Ron
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwhee...@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>
> 

Re: [VOTE] PROJECTMGR in upcoming release

[Todd Thorner]

This sounds good.  But then, what do I know?

I am still willing to pitch in on documentation, once I wrap my head
around the project (or a potential sub-project).  For now it's a matter
of free time and all that ...


On 14-10-01 07:46 AM, Ron Wheeler wrote:
> The sub-project is a very useful Apache tool for helping projects grow.
> http://db.apache.org/newproject.html  is interesting reading.
> http://ant.apache.org/antlibs/ very minimal description about Ant
> sub-projects but we all use their work.
> http://lucene.472066.n3.nabble.com/Close-of-Apache-Lucene-s-Open-Relevance-sub-project-td4141160.html
> a note about the official closure of a sub-project - very clear about
> why and what closure means.
> http://en.wikipedia.org/wiki/Apache_Ivy  another popular sub-project.
> Description implies that it started in incubation and graduated to a
> top-level package and then became a sub-project of Ant.
> http://icodebythesea.blogspot.ca/2009/04/apache-servicemix-kernel-subproject.html
> is an example of a sub-project moving between two top-level projects.
> 
> The sub-project structure allows for more specialization within the
> project resources so that people who are wizards with databases,
> kernels, etc get to worry about data access, performance, scalability,
> reliability, security while others who have more domain interest get to
> worry about features, usability, graphic design, workflow, reporting
> without getting in each other's hair.
> 
> It also ensures a clearer demarcation between framework, core ERP and
> modules.
> I suspect that it would clean up project communication since people
> could subscribe to the sub-project lists that pertained to their interests.
> 
> It might be easier for the existing community to accept new committers
> if the new people were part of a sub-project and were not committing to
> the particular codebase (framework, core, etc.) that the current
> committers are working on.
> 
> It probably would help clarify the documentation since there would be a
> much clearer separation of framework from core from modules since each
> sub-project would have its own section in the project documentation.
> Each sub-project would have a much better defined target audience so
> writing docs would be a bit simpler and the language and terminology
> could be more relevant to the target audience.
> 
> Ron
> 
> 
> On 01/10/2014 10:17 AM, Pierre Smits wrote:
>> Ron,
>>
>> In the past there was a WIKI page decribing who was interested and who
>> was willing to work on what. I don't know whether that page still exists.
>>
>> In the past we also had a system of having committers dedicated and
>> committed to a subset of the trunk. This should still be feasible. But
>> for that you need more committers. And to get more committers, this
>> project needs to solicit and accept more.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com 
>>
>> On Wed, Oct 1, 2014 at 4:10 PM, Ron Wheeler
>> > > wrote:
>>
>> A defined method of deciding what moves from the trunk to a
>> release would solve this.
>> Back to my previous comment about 1 person to test and 1 person to
>> fix bugs (could be the same person I suppose) would be a good
>> starting minimum.
>>
>> Ron
>>
>> On 01/10/2014 2:56 AM, Pierre Smits wrote:
>>
>> The excuse of using PROJECTMgr in an older branch (12.x, the
>> latest stable
>> release) and testing it against trunk and therefor not
>> including it in a
>> release of a newer branch, is a lame one.
>>
>> We are diligent about this, meaning that we do follow up
>> against any
>> potential new release branch in order to be able to migrate to
>> the newer
>> branch when there is something released.
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM  *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Wed, Oct 1, 2014 at 7:45 AM, Jacopo Cappellato <
>> jacopo.cappell...@hotwaxmedia.com
>> > wrote:
>>
>> The fact that someone is using it in an older branch and
>> testing it in
>> trunk is not enough to guarantee it works well with 13.07;
>> the trunk and
>> 13.07 are very different codebases.
>> Additionally, the "projectmgr" component has 0 unit tests;
>> I am not sure
>> about about its stability, but for example comments in
>> code like the
>> following don't make me feel super confident:
>>
>> 
>>
>> On

Re: OFBIZ manual??

[Todd Thorner]

Great to know, thanks for sharing.  Thanks especially to those involved
with the current doc effort, it might actually be time for me to give
OFBiz implementation another one of my amateur tries.



On 14-10-01 12:35 PM, joelfrad...@gmail.com wrote:
> I thought I was seeing things. I read most of the pages when I first started
> and I could see great strides at least without seeing side by side what I
> saw the first time.
> Fir example I was referred to the security model documentation and I think
> you must have updated that page it was great. Maybe I just understand it
> better, but I don't recall it having examples in FTL and XML etc. It was
> very clear and helpful today. 
> 
> 
> 
> -
> Joel Fradkin
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/OFBIZ-manual-tp4656272p4656356.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: ShipmentCostEstimate is the Supplier Shipping Price

[Todd Thorner]

Thanks, Forrest, for making time to add valuable information that
benefits future MarkMail answer-hunters.  Such details would make a good
tutorial for beginners to OFBiz services.



On 14-11-03 08:50 PM, Forrest Rae wrote:
> Hi Again,
> 
> First, apologies for the length of this mail, but I learned quite a bit
> in the last couple weeks of working on this in my spare time and I don't
> want these lessons to be applicable to only myself.
> 
> I wanted to get back and answer my own post now that I've figured it out
> for mailing list archival purposes.  For anyone else that is struggling
> to learn OFBiz, and not sure how something works, the best method I've
> found is to set a break point via Java debugging and step through the
> code.  Find a service you're particularly interested in, for me it was
> storeOrder, find the associated routing that is invoked by inspecting
> the XML configuration for the service, and step through the code in the
> debugger line by line.
> 
> For my purposes, I wanted to see how the associated purchase orders were
> generated when a sales order was created for dropship products.  It was
> pretty easy to find a service that was called via an SECA in
> applications/order/servicedef/secas.xml called
> checkCreateDropShipPurchaseOrders.  Setting a break point here and
> stepping through the code showed me how purchase orders were created.
> 
> If you read below, you see that I was trying to ensure the amount I was
> trying to charge for shipping was passed to the supplier, from sales
> order to purchase order.  I was hoping there was an easy way of doing
> this, but it turns out there wasn't.  If you look at the Java code for
> checkCreateDropShipPurchaseOrders, you can see that it doesn't do
> anything with OrderAdjustment entity.
> 
> It took me a while to figure out that Shipping and Handling charges were
> tracked via OrderAdjustment.  I determined this by tracing the code in
> the Order view back to where it pulls the data from.
> 
> Once I had all the information together, I had enough information to
> write a service that would be triggered via an SECA that given a sales
> order id, could find the associated purchase order, and create an
> OrderAdjustment for that purchase order.  (I also had to learn MiniLang
> in the process).
> 
> My code has some limitations, especially when mixing orders from
> different suppliers where not all items are dropship.  Also, it might be
> nice if you could configure this to happen per product, rather than per
> purchase order.  Additionally, I feel like this functionality belongs in
> Java closer to checkCreateDropShipPurchaseOrders, rather than as a SECA.
> 
> Feedback is definitely appreciated!  My apologies for the line wrapping
> in email, let me know if there was a better way to present this kind of
> thing.
> 
> =
> First, I had to overload the ordermgr in my ofbiz-component.xml:
> =
> 
> 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> 
> xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/ofbiz-component.xsd";>
> 
> 
> 
>  location="servicedef/services.xml"/>
>  location="servicedef/secas.xml"/>
> 
>  title="DropShipPOAdjustment"
> server="default-server"
> location="webapp/dropShipPOAdjustment"
> base-permission="OFBTOOLS,ORDERMGR"
> mount-point="/dropShipPOAdjustment"
> app-bar-display="true"/>
> 
>  title="Order-Customized"
> description="OrderComponentDescription"
> server="default-server"
> location="webapp/ordermgr"
> base-permission="OFBTOOLS,ORDERMGR"
> mount-point="/ordermgr"/>
> 
> 
> =
> Next, create a service that is triggered by SECA in my services.xml:
> =
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/services.xsd";>
>   DropShipPOAdjustment Services
>   
>   1.0
>location="component://dropShipPOAdjustment/script/com/fidelissd/order/dropShipPOAdjustmentSimple.xml"
> invoke="dropShipPOAdjustmentSimple">
>   For each Purchase Order related to a Sales Order,
> associate those adjustments to the Purchase Orders
>optional="false" />
>optional="false" />
>   
> 
> 
> The actual SECA is next, in secas.xml:
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/service-eca.xsd";>
>   
>run-as-user="system" />
>   
> 
> 
> =
> Finally, the code of my service in dropShipPOAdjustmentSimple.xml:
> =

Re: ShipmentCostEstimate is the Supplier Shipping Price

[Todd Thorner]

Sorry, Forrest, I'm still pretty clueless about OFBiz and can't begin to
help anyone with the project's wiki accessibility.  I was actually
kicking myself in that message for not yet being able to help the
project by turning someone else's generous mailing list contribution
(e.g. your instructions) into a small-scope tutorial (I'm a tech writer
in search of a SME or three).

Perhaps someone more in-the-know can help you get started on transposing
your instructions to the wiki.


On 14-11-05 11:28 AM, Forrest Rae wrote:
> Joel, That was the whole point here, not to mess with the main line
> code, but to make my modifications in my custom component in the
> hot-deploy directory.  You'll see that I don't touch any of the order
> code in the applications directory.
> 
> Todd, I'm happy to write something up on the wiki, please let me know
> where to put it and I'll make it happen.
> 
> I am curious what people's thoughts are in making a modification to the
> existing code to accomplish this though, as I explain in my previous
> mail.  I could make a patch to the Java code, and include a new setting
> in the supplier screens to control whether shipping and handling charges
> are passed to the PO.  If people are interested in this of course...
> 
> -Forrest
> 
> On 11/4/2014 9:32 AM, joelfrad...@gmail.com wrote:
>> Yea great detail on how you handled it.
>> I know for myself I moved all my code to hot-deploy project.
>> Not sure it will help that much for new versions, but I try to avoid messing
>> with the original code unless I copy it into my hot-deploy.

Re: Notes from Apachecon EU Budapest Meeting

[Todd Thorner]

Quick opinions on the rough ideas...

1. Turn the "kernel" into something based around containers (e.g.
docker).  This approach could also apply to many dev-ops considerations
that are internal to the project.
2. Make DITA the basis of all documentation.



On 14-11-26 04:13 AM, Sharan-F wrote:
> Hi Everyone
> 
> Please see below for the link to the notes from the meeting we held at
> Apacheon in Budapest last week. 
> 
> https://cwiki.apache.org/confluence/display/OFBIZ/Apachecon+Workshop%3A+19th+November+2014
> 
>   
> 
> A key point to remember is that no decisions were made and that these are
> just the notes from our discussions. 
> 
> As you will see, a lot of ideas/proposals came up that need community
> feedback, discussion and opinion.
> 
> Please feel free to provide any feedback or comments using this mailing list
> thread. 
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/Notes-from-Apachecon-EU-Budapest-Meeting-tp4658991.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: Notes from Apachecon EU Budapest Meeting

[Todd Thorner]

DITA is an OASIS "standard" that has been steadily supplanting other
"standards" like Docbook to become a dev-ops go-to for information
architecture: http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html

Having said that, it comes down to a business-versus-bureaucracy thing.
 One of the rough ideas bandied at Apachecon was to develop "a strategy
to encourage more business users," and typically that means minimizing
the bureaucracy of the project (as in: don't scare away business
managers who are assessing OFBiz on behalf of their organization).

DITA's advantage over things like wiki-only or HTML-only (or trying to
maintain wiki markup plus HTML markup plus whatever else) is its ability
to store content as single-sourced files and then transform those files
from their native XML format into appropriate end user formats (e.g.
XHTML or PDF/FOP or SCORM or even some wiki markups depending on the
plugged-in extension to the transformation engine).  For information on
the most popular transformation engine (which takes raw DITA files and
transforms them from their native XML format to a format that end users
can read), try this: http://www.dita-ot.org/1.8/.

Most OFBiz documentation contributors, understandably, have been
comfortable gaining professional experience using things like Docbook
(which is by no means obsolete but rather is suffering from the recent
migration toward DITA), so any embrace of DITA could necessitate some
kind of bureaucratic dictate that "all contributors will now write
documentation based on the DITA standard," which is not likely to go
over well with either the writer-contributors or the business managers
assessing OFBiz while hoping to avoid overly-bureaucratic open source
projects.

Probably the best approach, at least for the next few years, is to
encourage doc commits of DITA-based source files while continuing to
accept with thanks everything writers are willing to contribute.  Some
of the Open Toolkit engine transformations (which at the end of the day
are ant-target-thingies) might be used to backward-transform someone's
Docbook contribution into DITA format.  A goal worthy of debate on the
developer ml is to consider a day "three years from now" when:

- most tech writers are contributing DITA files
- transformations exist to turn other contributed docs into DITA files
- transformations exist to turn single-sourced DITA files into
appropriate end user documents (wiki pages, etc.)

The biggest advantage of single-sourcing documentation is that when
OFBiz framework specs change you need only edit one file to enable
necessary updates to information destined for multiple end user doc
targets, instead of wondering if there's another wiki page (or PDF or
whatever) out there somewhere that got overlooked.

Beyond this overview I'm too tech-tetched to help much with putting the
transformation engine through a set of tests or anything like that.
Those who know Ant should have few problems experimenting here & there
(resources permitting of course).

I will add some final links to peruse:

The Derby project appears to use DITA as the basis of its documentation:
https://db.apache.org/derby/manuals/index.html

The FOP project appears to be debating whether or not to tighten up the
integration/coupling of DITA and FOP:
https://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/201403.mbox/%3c533322f6.8050...@artifact-software.com%3E

The OpenOffice project appears to have been considering DITA as a format
for its documentation-related source files (although Confluence markup
as an engine output target doesn't appear to be implemented inside
Apache or elsewhere):
https://cwiki.apache.org/confluence/display/OOOUSERS/User+Documentation+Plan




On 14-11-26 07:38 AM, Pierre Smits wrote:
> Todd, all,
> 
> Don't you just love those acronyms What is meant by that (DITA)?
> Remember, the audience is diverse.
> 
> DITA as opposed to PITA?
> 
> Al jokes apart. Documentation is important with respect to adoption. From
> all angles: business, development, deployment/implementation, etc.
> 
> Regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Wed, Nov 26, 2014 at 4:11 PM, Todd Thorner 
> wrote:
> 
>> Quick opinions on the rough ideas...
>>
>> 1. Turn the "kernel" into something based around containers (e.g.
>> docker).  This approach could also apply to many dev-ops considerations
>> that are internal to the project.
>> 2. Make DITA the basis of all documentation.
>>
>>
>>
>> On 14-11-26 04:13 AM, Sharan-F wrote:
>>> Hi Everyone
>>>
>>> Please see below for the link to t

Re: Notes from Apachecon EU Budapest Meeting

[Todd Thorner]

"...used throughout the industry" is known as argumentum ad populum --
and besides it isn't even a very accurate assertion.  Perhaps Mr. Z is
referring to the use of Confluence within the ASF, and "available
support" is of course a decent argument for sticking with wiki-only
documentation as long as the ASF provides superlative infrastructure &
support.  Otherwise it will become a sticky wiki wicket that
offers only greater long-term restrictions than something like
single-sourced DITA or Docbook (even with adequate wiki support the
writing as it were appears to be on the proverbial wall regarding
technical communication trends).

There is such a thing as change management.  Indeed, if there were no
such thing, bureaucracy would grind all potential change to a permanent
halt.  Change for change's sake is a business management pitfall,
obviously, so it comes down to a decision about whether the project has
enough resources to spare for investigating DITA (which is gaining
popularity among tech writers more than any similar typing architecture
or proprietary wiki engine).

"Change because there's something new to try" is a management no-no.

"Don't change because everyone is used to the old way" is a management
no-no.

I am ignorant about this project's current resources or ultimate
aspirations.  I'm guessing that open source human resources are scarce,
which typically means (at least in the software game) that documentation
gets tartarooed toward "oh, anyone can whip up some documentation during
the final days before release" oblivion.  Fair enough, and contributors
are being generous with improvements to the documentation as it exists
right now, so if resources are less than available for appropriate
change management commitment then the existing wiki is the way to go for
the next few years.  As a tech writer, though, one with experience
stretching back to the 80s, I am confident asserting that after "the
next few years" a proprietary wiki engine, when compared with
single-sourced XML markup that can target multiple output formats, will
come to be seen as more of an anchor than a lifeline.  Perhaps a few
years out is a reasonable dart-toss goal for a documentation change
management sub-project.

Aside: my "two cents" OFBiz wish list has CMIS integration at the top
(minor sub-project with a large potential end user payoff), as well as
something like https://coreos.com/"; target="_blank">CoreOS
integration right beneath that (major sub-project with a ginormous
potential end user & dev-ops payoff).  I try, of course, to be one of
those "take what I can and be thankful" users because my typical open
source contributions amount to cybergum-flapping opinions.



On 14-11-28 06:51 PM, Mike Z wrote:
> I think that recently the docs have made a great leap forward thanks to the
> good folks here on the mailing list.  The more comfortable people are with
> the wiki the more it will be used.  Confluence is a standard wiki used
> throughout the industry and I think it would be a mistake to change things
> just as it is gaining steam.
> 
> Sent from my BlackBerry® PlayBook™
> www.blackberry.com
> 
> --
> *From:* "Sharan-F" 
> *To:* "user@ofbiz.apache.org" 
> *Sent:* November 28, 2014 6:02 AM
> *Subject:* Re: Notes from Apachecon EU Budapest Meeting
> 
> Hi Todd
> 
> Thanks for explaining this and giving the links.
> 
> I'd like to investigate this as I'm keen to understand if we need to discuss
> changing our approach to in application documentation.
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Notes-from-Apachecon-EU-Budapest-Meeting-tp4658991p4659098.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: Help needed to update an OFBiz Wiki Graffle Diagram

[Todd Thorner]

What happens if you change a .graffle file's extension to something else
like SVG or XML?  Any luck?  I know very little about Mac lock-ins, but
if you can get a text-based file to display (e.g. if .graffle is .xml
underneath) you might be able to edit the text.

You could also try taking a screenshot and then editing that by
overlaying the newer links on top of the old image.  Quality might suffer.

Perhaps committers could consider SVG as a forward-thinking standard
format for the project's graphical source files (production-ready files
can be exported as whatever).  My preferred tool is Inkscape
(Windows/Mac/Linux).



On 14-12-15 06:33 AM, Ron Wheeler wrote:
> Can we move them to open source products such as  Open Office or ArgoUML
> or Freeplane?
> These run on all platforms and are all free.
> 
> Ron
> 
> On 15/12/2014 7:30 AM, Sharan-F wrote:
>> Hi All
>>
>> Does anyone in the community have access to Graffle on a Mac who is
>> willing
>> to help us update one of our wiki diagrams?
>>
>> The diagram that needs to be updated is called
>> OFBizComponentDependencies.graffle (see link below)
>>
>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766065&metadataLink=true
>>
>> 
>>
>>
>> It forms part of the page around Component Set and Component Set
>> Dependencies page that we want keep up to date.
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
>>
>>
>> We need to update some links so please respond if you can help.
>>
>> Thanks
>> Sharan
>>
>>
>>
>>
>> -- 
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Help-needed-to-update-an-OFBiz-Wiki-Graffle-Diagram-tp4659615.html
>>
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
> 
> 

Re: Help needed to update an OFBiz Wiki Graffle Diagram

[Todd Thorner]

Yeah, graphs & charts represent special cases.



On 14-12-15 09:49 AM, Ron Wheeler wrote:
> If people don't like the idea of using the Graphviz version that I made,
> there is a viewer for graffle that runs on the PC. Not sure if any of
> their other free utilities will output an SVG.
> Graphviz can outout SVG.
> I am not sure if it would be easy to use svg as a source.
> 
> Graphviz offers high level control over placement that usually gives a
> clean graph without having to manually place nodes.
> 
> I have just started to use the dynamic javascript version of graphviz in
> my ETVL tool to output org charts embedded into HTML pages from
> hierarchical data.
> Works fine but the org charts are not as nice looking as GetOrgChart's
> charts and GetOrgChart produces a chart that can be interrogated in the
> browser to view the detail information stored at each node so I support
> both ways of generating charts in HTML format.
> 
> Ron
> 
> On 15/12/2014 12:04 PM, Todd Thorner wrote:
>> What happens if you change a .graffle file's extension to something else
>> like SVG or XML?  Any luck?  I know very little about Mac lock-ins, but
>> if you can get a text-based file to display (e.g. if .graffle is .xml
>> underneath) you might be able to edit the text.
>>
>> You could also try taking a screenshot and then editing that by
>> overlaying the newer links on top of the old image.  Quality might
>> suffer.
>>
>> Perhaps committers could consider SVG as a forward-thinking standard
>> format for the project's graphical source files (production-ready files
>> can be exported as whatever).  My preferred tool is Inkscape
>> (Windows/Mac/Linux).
>>
>>
>>
>> On 14-12-15 06:33 AM, Ron Wheeler wrote:
>>> Can we move them to open source products such as  Open Office or ArgoUML
>>> or Freeplane?
>>> These run on all platforms and are all free.
>>>
>>> Ron
>>>
>>> On 15/12/2014 7:30 AM, Sharan-F wrote:
>>>> Hi All
>>>>
>>>> Does anyone in the community have access to Graffle on a Mac who is
>>>> willing
>>>> to help us update one of our wiki diagrams?
>>>>
>>>> The diagram that needs to be updated is called
>>>> OFBizComponentDependencies.graffle (see link below)
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766065&metadataLink=true
>>>>
>>>>
>>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766065&metadataLink=true>
>>>>
>>>>
>>>>
>>>> It forms part of the page around Component Set and Component Set
>>>> Dependencies page that we want keep up to date.
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
>>>>
>>>>
>>>>
>>>> We need to update some links so please respond if you can help.
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> View this message in context:
>>>> http://ofbiz.135035.n4.nabble.com/Help-needed-to-update-an-OFBiz-Wiki-Graffle-Diagram-tp4659615.html
>>>>
>>>>
>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>
>>>
> 
> 

Re: Help needed to update an OFBiz Wiki Graffle Diagram

[Todd Thorner]

I'm sold ... for what that's worth.  Is there any UML-type facility for
the project's future of design & spec-chasing?



On 14-12-15 10:41 AM, Ron Wheeler wrote:
> On 15/12/2014 1:30 PM, Todd Thorner wrote:
>> Yeah, graphs & charts represent special cases.
> 
> For the first applications of our ETVL, org charts were a very useful
> output since we were dealing with people in organizations where a clean
> hierarchy is the common way that companies are organized. It was useful
> to have the organizational structure (departments, divisions, etc) as
> well as reporting relationships between people.
> 
> Graphviz is capable of producing very complex charts and has a fair
> amount of language features to support customizing the appearance.
> 
> Ron
> 
>>
>>
>>
>> On 14-12-15 09:49 AM, Ron Wheeler wrote:
>>> If people don't like the idea of using the Graphviz version that I made,
>>> there is a viewer for graffle that runs on the PC. Not sure if any of
>>> their other free utilities will output an SVG.
>>> Graphviz can outout SVG.
>>> I am not sure if it would be easy to use svg as a source.
>>>
>>> Graphviz offers high level control over placement that usually gives a
>>> clean graph without having to manually place nodes.
>>>
>>> I have just started to use the dynamic javascript version of graphviz in
>>> my ETVL tool to output org charts embedded into HTML pages from
>>> hierarchical data.
>>> Works fine but the org charts are not as nice looking as GetOrgChart's
>>> charts and GetOrgChart produces a chart that can be interrogated in the
>>> browser to view the detail information stored at each node so I support
>>> both ways of generating charts in HTML format.
>>>
>>> Ron
>>>
>>> On 15/12/2014 12:04 PM, Todd Thorner wrote:
>>>> What happens if you change a .graffle file's extension to something
>>>> else
>>>> like SVG or XML?  Any luck?  I know very little about Mac lock-ins, but
>>>> if you can get a text-based file to display (e.g. if .graffle is .xml
>>>> underneath) you might be able to edit the text.
>>>>
>>>> You could also try taking a screenshot and then editing that by
>>>> overlaying the newer links on top of the old image.  Quality might
>>>> suffer.
>>>>
>>>> Perhaps committers could consider SVG as a forward-thinking standard
>>>> format for the project's graphical source files (production-ready files
>>>> can be exported as whatever).  My preferred tool is Inkscape
>>>> (Windows/Mac/Linux).
>>>>
>>>>
>>>>
>>>> On 14-12-15 06:33 AM, Ron Wheeler wrote:
>>>>> Can we move them to open source products such as  Open Office or
>>>>> ArgoUML
>>>>> or Freeplane?
>>>>> These run on all platforms and are all free.
>>>>>
>>>>> Ron
>>>>>
>>>>> On 15/12/2014 7:30 AM, Sharan-F wrote:
>>>>>> Hi All
>>>>>>
>>>>>> Does anyone in the community have access to Graffle on a Mac who is
>>>>>> willing
>>>>>> to help us update one of our wiki diagrams?
>>>>>>
>>>>>> The diagram that needs to be updated is called
>>>>>> OFBizComponentDependencies.graffle (see link below)
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766065&metadataLink=true
>>>>>>
>>>>>>
>>>>>>
>>>>>> <https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766065&metadataLink=true>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It forms part of the page around Component Set and Component Set
>>>>>> Dependencies page that we want keep up to date.
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> We need to update some links so please respond if you can help.
>>>>>>
>>>>>> Thanks
>>>>>> Sharan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> View this message in context:
>>>>>> http://ofbiz.135035.n4.nabble.com/Help-needed-to-update-an-OFBiz-Wiki-Graffle-Diagram-tp4659615.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>>>>
>>>
> 
> 

Re: More ApacheCon 2015

[Todd Thorner]

My comment is of the "thank you" variety.



On 14-12-22 08:26 AM, Ruth Hoffman wrote:
> Hi List:
> Sorry about the previous duplicate posts. Having some issues signing up
> for the list.
> 
> About ApacheCon 2015: I also submitted a proposal for a presentation
> titled "Apache OFBiz Top 10". The inspiration for this presentation can
> be found in a brochure I wrote (some time ago) based on the most common
> reasons my clients have chosen OFBiz.
> 
> You can download a free copy of the brochure on my website:
> 
> http://www.aesolves.com.
> 
> Make sure you scroll down the page to where the download buttons appear.
> 
> As always, any comments or suggestions are welcome:
> 
> rhoff...@aesolves.net
> 
> Best Regards,
> Ruth Hoffman

Re: [PROPOSAL] Increase community involvement by enabling contributors to assign themselves to their own issues.

[Todd Thorner]

"Did you know that Jira is underneath using the OFBiz Entity Engine?"

That is interesting, could you elaborate?



On 15-01-31 09:58 AM, Jacques Le Roux wrote:
> Jira is really easy to use, at least when you being and don't try to
> setting it from the inside
> This could help you https://www.atlassian.com/software/university/overview
> 
> Did you know that Jira is underneath using the OFBiz Entity Engine ?
> 
> Jacques
> 
> Le 31/01/2015 17:30, Blaxton a écrit :
>> What is the best way of starting with  OfBiz?
>> I was thinking get a host , use the CMS feature of OfBiz and build a
>> website
>> to get familiar with OfBiz and then start contributing to development.
>> I have never worked with JIRA but have a good knowledge of Java, JSP
>> and Servlet.
>> Is there any training courses available in North America ?
>> Any suggestion that help me to contribute to development as soon as
>> possible is appreciated.
>> Thanks
>>
>>  
>>   From: Pierre Smits 
>>   To: user@ofbiz.apache.org
>>   Sent: Friday, January 30, 2015 7:13 AM
>>   Subject: [PROPOSAL] Increase community involvement by enabling
>> contributors to assign themselves to their own issues.
>> Hi All,
>>
>>
>> *Preamble*
>> Currently community involvement in the project is good, but like in any
>> other other open source project it could be better. And better is more
>> favourable than just good or good enough, right?
>>
>> The thing is, that many perceive that contributors don't take
>> ownership of
>> their own issues in JIRA. They create the issue and at best provide
>> comments to further explain and/or add replies to questions? But that is
>> that. And the person assigned to the issue is regarded as the one
>> responsible for having the issue brought to closure.
>>
>> This has led to the situation that we now have approx of 780 open issues,
>> of which 600 are unassigned.  Some of which are quite old (pre r10), even
>> those with committers assigned.
>>
>> But this isn't how it should be. The creator of the issue should be
>> regarded as the owner, the persons who brings the issue to closure.
>> And the
>> committer should be regarded as the gatekeeper/enabler regarding having
>> patches committed and process followed.
>>
>> Currently contributors can't be assigned to issues they are willing to
>> work
>> on, so that they can take ownership. That contributors can't be
>> assigned to
>> a JIRA issue, is due to the fact that they don't have the proper role
>> set.
>> In stead of being identified with the role 'Contributor Project Role',
>> they
>> are treated as 'Any Registered User' (in accordance with the standard
>> permissions scheme for JIRA, see
>> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
>>
>> ).
>>
>> *Improvement (the proposal)*
>> In order to improve this situation and increase community involvement, we
>> should assign the 'Contributor Project Role' to recognised contributors
>> (see the Contributors page in the wiki:
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Apache+OFBiz+Contributors)
>>
>> so that they can be assigned to JIRA issues. Also, we should enable
>> contributors to be able to assign themselves to their own issues and have
>> them take ownership.
>>
>> Enabling contributors to take ownership of JIRA issues will enable the
>> project to identify the more active community members more easily (as
>> opposed to those who fire and forget) and get more issues assigned and
>> closed, but it also helps lessening the burden on committers.
>> Infrastructure has already such a construct  in place to enable project
>> contributors to do more (see
>> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization,
>>
>> the *Default plus Contributor Assign Permission Scheme*).
>>
>> What do you think?
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>>

Re: mailing list usage request

[Todd Thorner]

For looking up information that might already be covered in previous ML
threads (but possibly missing from the online documentation), try
searching the OFBiz category at markmail.org.


On 15-02-21 07:39 AM, Davide Ciofetti wrote:
> Hi everybody,
> i subscribed an account into user and dev mailing lists.
> I already searched for instructions and I read and re-read the help lot of
> times without to find what I needed.
> 
> I need a help for the use of the mailing list.
> 
> Cause the high reception frequency of the mails, I decided to subscribe to
> the digest.
> 
> But this don't let me to reply to a specific thread.
> 
> for example 2 days ago I wrote a message and someone replied to me: how to
> reply to a specific message using the digest? Now I converted back to the
> simple mailing list, without digest
> 
> Thank you.
> 
> Davide
> 
> PS
> I hope this is the right place where to write to. If not, please indicate
> me where I can
> 

Re: Ofbiz JCR/Jackrabbit Integration - Future plans

[Todd Thorner]

Although my lack of contribution skills makes the idea of me-merit
rather dubious, I feel obligated to chime in about my preference for a
CMIS implementation over JSRs.  Seems more language/vendor agnostic and
possibly more future-proof.

My merit is so dubious that I realize this might not even be what you're
talking about.  To me the amateur, Jackrabbit is a way to roll your own
implementation of a CMS integration.  If that's the same Jackrabbit
you're talking about, please take a look at the Apache Chemistry project
to discover (or recall) what I consider to be progress on that front.



On 15-02-28 05:22 AM, Jacques Le Roux wrote:
> Yes, you are right Pierre, we should do that on request. Maybe it's not
> too late for Jackrabbit...
> 
> Jacques
> 
> Le 28/02/2015 12:54, Pierre Smits a écrit :
>> It is however unfortunate that we don't do issues per development branch,
>> otherwise it would have been registered/visible what needs to be done.
>>
>> Best regards,
>>
>> Pierre

Re: Ofbiz JCR/Jackrabbit Integration - Future plans

[Todd Thorner]

I can appreciate where the devs are coming from.  It is possible that
the OASIS-by-way-of-AIIM "standard" will not become anything big enough
to bother implementing.

CMIS has been making steady progress since 2008 (longer if you count the
work AIIM had been doing on it).  I wish I had stronger coding skills so
I could walk the proverbial talk (or even better: I wish I was rich
enough to pay an appropriate coder bounty).  There are obviously plenty
of people who use a JCR-compliant CMS solution and will continue with
what is working for them, so finishing the remaining 10% or so of
Jackrabbit integration has value for plenty of OFBIz users.

I'm guessing that CMIS integration would offer value for even more
users, so maybe it's a "one thing at a time" dev-ops consideration.  In
the Programming Languages section for the Jackrabbit project it says
"Java."  The Programming Languages section for the Chemistry project
says "Java, Python, PHP, C#, Objective-C."  That might not be
meaningful, though, depending on the existing OFBiz framework and how
Jackrabbit/CMIS would need to be implemented (server only or client-side
interfaces as well).  Like I said, I'm not exactly on the ball regarding
the project's codebase.

So, for the sake of crystal ball user gazing, would it be difficult to
install a future OFBiz and then strip out components that the user
doesn't anticipate needing?  If I'm not mistaken that's one of the
project's big selling points, the modularity.



On 15-02-28 09:07 AM, Pierre Smits wrote:
> Todd,
> 
> Thank you for your contribution.
> 
> As it is with all open source projects, nothing won't happen unless someone
> starts doing. The JCR integration is 80-90% there, Cemistry just appeared
> (for the first time, if my memory doesn't fail).
> 
> Best regards,
> 
> Pierre
> 
> Op zaterdag 28 februari 2015 heeft Todd Thorner 
> het volgende geschreven:
> 
>> Although my lack of contribution skills makes the idea of me-merit
>> rather dubious, I feel obligated to chime in about my preference for a
>> CMIS implementation over JSRs.  Seems more language/vendor agnostic and
>> possibly more future-proof.
>>
>> My merit is so dubious that I realize this might not even be what you're
>> talking about.  To me the amateur, Jackrabbit is a way to roll your own
>> implementation of a CMS integration.  If that's the same Jackrabbit
>> you're talking about, please take a look at the Apache Chemistry project
>> to discover (or recall) what I consider to be progress on that front.
>>
>>
>>
>> On 15-02-28 05:22 AM, Jacques Le Roux wrote:
>>> Yes, you are right Pierre, we should do that on request. Maybe it's not
>>> too late for Jackrabbit...
>>>
>>> Jacques
>>>
>>> Le 28/02/2015 12:54, Pierre Smits a écrit :
>>>> It is however unfortunate that we don't do issues per development
>> branch,
>>>> otherwise it would have been registered/visible what needs to be done.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre
>>
> 
> 

Re: Ofbiz JCR/Jackrabbit Integration - Future plans

[Todd Thorner]

Great information, thanks.  I always thought Jackrabbit to be a JCR kind
of thing, didn't know it was a more generic DB kind of thing (mind you
content repositories can be persisted using databases so maybe
Jackrabbit is a "special use" kind of DB that offers the name-value
pairs of a NoSQL-ish setup).

I don't think the Chemistry project is for creating from scratch a
CMIS-ready system as much as it's for enabling messaging-level
interoperability between existing CMSs from various vendors (at least
between those which bother to integrate CMIS-compliant interfaces).  I
think I'll join its ml for a while to learn more about the kinds of
explosive compounds an amateur like me can create with such chemistry sets.

Either way, I'm not skilled enough to help develop an OFBiz integration
with Jackrabbit or CMIS.  So I'll do the typical cop-out thing: thank
contributors past & present for their efforts and hope that a day comes
when part of OFBiz's marketing includes blah-blah about users being able
to plug in any JCR-compliant or CMIS-compliant content repository of
their choosing.  Project gurus might even think about thinking about the
whole pay-to-stream market, cater to all those aspiring web site
retailers of both live streaming and VOD (no I'm not one nor do I work
for one).

Are OFBiz entities among the things that get stored within the embedded
CMS?  Is there anything OOTB that gets stored in some database which is
separate and distinct from the database for storing CMS-specific stuff?
 I would appreciate a wiki URL or similar resource for learning more
about these related topics (OFBiz persistence mechanisms and CMS whatnot).



On 15-02-28 02:24 PM, Ron Wheeler wrote:
> I don't think that Chemistry and Jackrabbit are the same thing at all.
> Chemistry is a CMIS tool-kit.
> Jackrabbit is a NoSQL database engine that can be used to build any
> application that fits into a node and link model.
> I think that Jackrabbit competes more directly with Mongo-DB.
> 
> Chemistry is a higher level set of tools to build CMIS systems.
> http://chemistry.apache.org/java/developing/guide.html describes
> Chemistry as
> 
> "CMIS (Content Management Interoperability Services) is a
> vendor-neutralOASIS Web services interface specification
> <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis>that
> enables interoperability between Enterprise Content Management (ECM)
> systems. CMIS allows rich information to be shared across Internet
> protocols in vendor-neutral formats, among document systems, publishers
> and repositories, in a single enterprise and between companies."
> 
> I think that OFBiz's entity-relationship model would not get much help
> from the CMIS tools.
> 
> http://chemistry.apache.org/java/developing/repositories/dev-repositories-jcr.html
> talks about a bridge that allows Chemistry to access content stored in
> Jackrabbit.
> 
> I use Jackrabbit for the Artifact ADTransform ETVL.
> Jackrabbit has the ability to use in-memory or disk storage configured
> at run-time.
> ADTransform uses the in-memory database configuration for speed but can
> be configured to use disks if the data streams are very large and will
> not fit in memory.
> 
> OFBiz's entity database model could be implemented in Jackrabbit (or
> Mongo-DB) pretty comfortably.
> 
> Another junior member's 2 cents.
> Ron
> 
> On 28/02/2015 1:58 PM, Todd Thorner wrote:
>> I can appreciate where the devs are coming from.  It is possible that
>> the OASIS-by-way-of-AIIM "standard" will not become anything big enough
>> to bother implementing.
>>
>> CMIS has been making steady progress since 2008 (longer if you count the
>> work AIIM had been doing on it).  I wish I had stronger coding skills so
>> I could walk the proverbial talk (or even better: I wish I was rich
>> enough to pay an appropriate coder bounty).  There are obviously plenty
>> of people who use a JCR-compliant CMS solution and will continue with
>> what is working for them, so finishing the remaining 10% or so of
>> Jackrabbit integration has value for plenty of OFBIz users.
>>
>> I'm guessing that CMIS integration would offer value for even more
>> users, so maybe it's a "one thing at a time" dev-ops consideration.  In
>> the Programming Languages section for the Jackrabbit project it says
>> "Java."  The Programming Languages section for the Chemistry project
>> says "Java, Python, PHP, C#, Objective-C."  That might not be
>> meaningful, though, depending on the existing OFBiz framework and how
>> Jackrabbit/CMIS would need to be implemented (server only or client-side
>> interfaces as well). 

Re: OFBiz Twitter Account

[Todd Thorner]

Good call, Mr. Brohl.



On 15-03-25 09:58 AM, Michael Brohl wrote:
> Hi Sharan,
> 
> don't know who owns this account but maybe
> https://twitter.com/ApacheOfbiz would be better to aim on?
> 
> Regards,
> 
> Michael
> ecomify.de
> 
> Am 25.03.15 um 17:40 schrieb Sharan-F:
>> Hi All
>>
>> Does anyone own (or knows who owns!) the following twitter account.
>>
>> https://twitter.com/OFBiz 
>>
>> I'd like to find out if we could ask to use it for the project.
>>
>> Thanks
>> Sharan
>>
>>
>>
>>
>> -- 
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/OFBiz-Twitter-Account-tp4665864.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 
> 

Re: Multi-Tenant with MySQL or Postgress - Working?

[Todd Thorner]

Thanks, Fernando, I look forward to overcoming a bit more of my
ignorance by way of e-following your progress.



On 15-05-21 08:20 AM, FGomez wrote:
> Jacques, Pierre and Arum
> 
> Thanks for the technical answer.
> 
> I agreed with the advantages of a DB per Tenant and the scalability of
> the HW infrastructure underneath . Hence the maintenance and support
> issues.
> I test with v14.12 and advise.
> 
> Regards,
> Fernando
> 
> 
> 
> 
> Le 2015-05-21 03:09, Jacques Le Roux a écrit :
>> More accurately multi-tenancy has been introduced in trunk in February
>> 2010 and has been continuously improved since.
>> It works with all the DBMSs you can fiund in the EntityEngine.xml file.
>> The number of tenants depends on the material resources, not the code.
>> It's not a solution to scale above thousands tough (you need a DB by
>> tenant...)
>> This limitation comes with the obvious advantages of having separated
>> DBs. You can find details about these advantages on the Net, notably
>> when it comes to backups things and guarantee access separation...
>>
>> Jacques
>>
>>
>> Le 21/05/2015 07:59, Pierre Smits a écrit :
>>> Hi Fernando.
>>>
>>> Multi-tenancy has been around since prior r12.x. And is working with
>>> both
>>> PostgreSQL and MySQL.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Thu, May 21, 2015 at 4:34 AM, FGomez  wrote:
>>>
 Hi All,

 I wanted to know if anyone has Multi-tenant running in production
 (or dev)
 with more then 3 tenants/clients with PostgreSql or mySql DBs?
 With v13.07 or v14.12 ( I believe the domain on the script is only
 available with the 'ant create-tenant' on v14.12 only).

 Thanks you for the feedback.

 Regards,
 Fernando




> 

Re: [DISCUSSION] OFBiz Online Documentation

[Todd Thorner]

I'm willing to pitch in, but as I stated in a message earlier today I'm
still rather ignorant about OFBiz (I've had zero free time to take the
figurative plunge).

First and foremost for documentation: single-sourcing and DITA/DocBook.
 Discuss ...



On 15-05-21 09:45 AM, Sharan-F wrote:
> I'd like to put forward a proposal for discussion around the project End User
> Documentation. 
> 
> We know that we have incomplete documentation and need an active strategy to
> complete it. The help itself can be divided it into two distinct areas
> 
> 1. Online / in Application Help
> 2. User Documentation on the Wiki (NOTE: I will be starting another
> discussion thread around this)
> 
> *
> Online / In Application Help*
> This is the help that appears when someone using OFBiz clicks the help icon.
> It is contextual and normally related to a screen that the user is on. It
> can describe what a screen is used for, the data to be entered or the use of
> a key, button or icon.
> 
> Screens and menus can be changed so it needs to be flexible and
> customisable.
> 
> Our current online help has been implemented using Docbook and the OFBiz
> CMS. I don't think that this currently works well because
> 
> - it is too hard to keep up to date as each change needs to be submitted as
> a patch
> - you need to understand and create the new data items for the CMS for each
> page of documentation
> - existing items need to be linked into the correct place in the document
> hierarchy
> - the docbook implementation isn't complete and there are a lot standard
> tags that cannot be used
> 
> *Proposal*
> We know that we have had limited contributions to the online help system and
> currently this has been significantly reduced. 
> 
> If we could make the online help more accessible to our community to update
> this could stimulate more interest in it.
> 
> Rather than trying to maintain the online help as if it were code – could it
> be treated differently to allow a wider range of people to provide updates.
> 
> As an example, I would like to find out if all the data from the online help
> :
> 
> - could be extracted
> - imported into a more document oriented/friendly editing environment or
> application
> - updated by community members (who could be given access to create / update
> / edit details)
> - changes would be reviewed and approved 
> - once approved the changes could be committed / the help could be
> re-imported back into OFBiz or just delivered as a separate package that
> could be easily loaded back into OFBiz
> 
> *Potential Benefits*
> - Community Members could work and update it easily
> - Reviews could be done before the documents are accepted
> - Different languages could be supported
> - We could have versions of help for different OFBiz versions
> 
> These are my initial thoughts so I'm happy to get any feedback or
> alternative suggestions for how we could solve our existing problems.
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-OFBiz-Online-Documentation-tp4668869.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: [DISCUSSION] OFBiz End User Wiki Documentation

[Todd Thorner]

The key to minimizing effort is single-sourcing.  That is the business
requirement (maybe), now the community must settle on appropriate
technologies.

My opinion is that DocBook is obsolete.  One non-committer vote for DITA.



On 15-05-21 09:59 AM, Sharan-F wrote:
> Hi Everyone
> 
> i'd like to put forward another proposal for discussion around the project
> End User Documentation. 
> 
> We know that we have incomplete documentation and need an active strategy to
> complete it. The help itself can be divided it into two distinct areas
> 
> 1. Online / in Application Help *(NOTE*: A discussion for this has been
> started in another thread)
> 2. User Documentation on the Wiki
> 
> *
> User Documentation on the Wiki *
> Our current End User Documentation is fragmented (End User Docs,
> Requirements and Designs, Wiki) and mixed in with various other
> documentation on the Wiki. Attempts have been made to create the
> documentation but the level of information required has been varied and
> unclear.
> 
> Confluence is the Apache tool for managing wiki but it does have its limits
> that have caused frustration in the past.
> 
> *Proposal*
> Our community surveys show that we don't have a lot of typical 'End Users'
> in our Community Base. The users that we do have are more 'Key Users' or
> 'Application Experts'. What I mean here is that they are users that
> understand their own business flows and are interested in knowing how to
> setup OFBiz for their business.
> 
> Rather than be focussed on End Users – I think this documentation could be
> focussed on the 'Key Users' and giving them the information they need to
> configure or setup OFBiz for a business. As a possible guide it  could
> contain the following:
> 
> - business process flows
> - use cases
> - application guide (details and steps for implementing the process flow)
> - configuration instructions 
> - tips and tricks
> - glossary
> - details about data loading (e.g seed or production data)
> 
> *Key Benefit*
> Our user documentation has a clear purpose rather than trying to fulfill
> mulitple different roles 
> 
> Once again these are my initial thoughts so am very happy (and keen) to get
> feedback from the community (especially user) about this. 
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-OFBiz-End-User-Wiki-Documentation-tp4668872.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: [DISCUSSION] OFBiz End User Wiki Documentation

[Todd Thorner]

iki_single_source_publishing/
> 
> Great summary of how to use Confluence in an environment that includes a
> number of source formats and desired output.
> 
> I use DITA for software docs and like the way that it integrates with
> Eclipse/STS.
> 
> Ron
> 
> 
> On 21/05/2015 1:22 PM, Todd Thorner wrote:
>> The key to minimizing effort is single-sourcing.  That is the business
>> requirement (maybe), now the community must settle on appropriate
>> technologies.
>>
>> My opinion is that DocBook is obsolete.  One non-committer vote for DITA.
>>
>>
>>
>> On 15-05-21 09:59 AM, Sharan-F wrote:
>>> Hi Everyone
>>>
>>> i'd like to put forward another proposal for discussion around the
>>> project
>>> End User Documentation.
>>>
>>> We know that we have incomplete documentation and need an active
>>> strategy to
>>> complete it. The help itself can be divided it into two distinct areas
>>>
>>> 1. Online / in Application Help *(NOTE*: A discussion for this has been
>>> started in another thread)
>>> 2. User Documentation on the Wiki
>>>
>>> *
>>> User Documentation on the Wiki *
>>> Our current End User Documentation is fragmented (End User Docs,
>>> Requirements and Designs, Wiki) and mixed in with various other
>>> documentation on the Wiki. Attempts have been made to create the
>>> documentation but the level of information required has been varied and
>>> unclear.
>>>
>>> Confluence is the Apache tool for managing wiki but it does have its
>>> limits
>>> that have caused frustration in the past.
>>>
>>> *Proposal*
>>> Our community surveys show that we don't have a lot of typical 'End
>>> Users'
>>> in our Community Base. The users that we do have are more 'Key Users' or
>>> 'Application Experts'. What I mean here is that they are users that
>>> understand their own business flows and are interested in knowing how to
>>> setup OFBiz for their business.
>>>
>>> Rather than be focussed on End Users – I think this documentation
>>> could be
>>> focussed on the 'Key Users' and giving them the information they need to
>>> configure or setup OFBiz for a business. As a possible guide it  could
>>> contain the following:
>>>
>>> - business process flows
>>> - use cases
>>> - application guide (details and steps for implementing the process
>>> flow)
>>> - configuration instructions
>>> - tips and tricks
>>> - glossary
>>> - details about data loading (e.g seed or production data)
>>>
>>> *Key Benefit*
>>> Our user documentation has a clear purpose rather than trying to fulfill
>>> mulitple different roles
>>>
>>> Once again these are my initial thoughts so am very happy (and keen)
>>> to get
>>> feedback from the community (especially user) about this.
>>>
>>> Thanks
>>> Sharan
>>>
>>>
>>>
>>> -- 
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/DISCUSSION-OFBiz-End-User-Wiki-Documentation-tp4668872.html
>>>
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
> 
> 

Re: [DISCUSSION] OFBiz Online Documentation

[Todd Thorner]

I'm pretty much sitting this one out (seems to have jumped right into
the tech selection and I don't understand OFBiz well enough yet to be
useful as a writer-contributor so I wouldn't be able to offer much
quality input), but for what it's worth the most important
considerations for a typing architecture are:

1. The project's business needs (e.g. "No XML files!")
2. Making sure the single-sourced files can be puked out into as many
useful end user formats as possible (e.g. context-sensitive help, wiki,
etc.)
3. Making sure a maximum number of writer-contributors can hit the
proverbial ground running without needing to learn new processes

One thing I can offer for now is editing skills, but that involves
potential toe-stepping.  Perhaps I could transform that solid Prezi
presentation into Sozi format so its SVG output could be embedded into
any OFBiz web page.  If the original author is cool with that (can't
remember who it was), let me know.



On 15-05-28 04:44 AM, Jacques Le Roux wrote:
> And finally:
> Read theStandardization section at http://en.wikipedia.org/wiki/Markdown
> Also this one is maybe a bit biased (done by Dan Allen who supports
> AsciiDOc) but still an interesting comparison:
> https://gist.github.com/mojavelinux/5870367
> check
> Asciidoc
> https://gist.githubusercontent.com/mojavelinux/5870367/raw/014804bf061baad6983ade6878484b9c0931da5b/gfm-vs-asciidoc.asciidoc
> 
> vs
> Markdown
> https://github.github.com/github-flavored-markdown/sample_content.html
> 
> Jacques
> 
> Le 28/05/2015 13:24, Jacques Le Roux a écrit :
>> Another interesting opinion: http://www.neveruntilnow.com/asciidoctor/
>>
>> Jacques
>>
>> Le 28/05/2015 13:19, Jacques Le Roux a écrit :
>>> I'm still undecided on this, but I feel AsciiDoc is "slowly" gaining
>>> interest see
>>> http://www.artima.com/forums/flat.jsp?forum=106&thread=361787 It's
>>> the same spirit than Json againt XML...Though Markdown is not XML,
>>> but Dita is. Also AsciiDoc offers a lot of export possibilities, see
>>> http://en.wikipedia.org/wiki/Comparison_of_document_markup_languages
>>>
>>> Anyway we will need a community consensus...
>>>
>>> Jacques
>>>
>>> Le 28/05/2015 12:29, Taher Alkhateeb a écrit :
 Hi Jacques and all,

 If you want a simple documentation language then markdown comes to
 mind. It is simple, beautiful, mature and well supported in terms of
 tools and probably covers the 90% of cases needed by everyone. So
 throwing another suggestion in the mix.

 Taher Alkhateeb

 - Original Message -

 From: "Jacques Le Roux" 
 To: user@ofbiz.apache.org
 Sent: Thursday, 28 May, 2015 12:51:13 PM
 Subject: Re: [DISCUSSION] OFBiz Online Documentation

 That sounds quite an interesting way Ron.
 I also believe we should get rid of DocBook in favour of DITTA or
 maybe even AsciiDoc (the last smart guy) as we already discussed at
 the bottom of
 https://issues.apache.org/jira/browse/OFBIZ-4941
 I also like the idea of separating the documentation from the
 project (Yippee our 1st sub-project Ron ;) ).
 Finally, like I said in OFBIZ-4941 I HATE CONFLUENCE, but also, like
 outlined Sharan (damn can't find the link again), it has a lot of
 features,
 notably when it comes to transform formats... and anyway it's our
 wiki support...

 Jacques

 Le 27/05/2015 17:55, Ron Wheeler a écrit :
> On 27/05/2015 10:50 AM, Michael Brohl wrote:
>> Hi Sharan,
>>
>> I had not the time to think more about your proposal but I can
>> quickly answer your followup questions, see inline...
>>
>> Am 27.05.15 um 15:34 schrieb Sharan-F:
>>> Hi All
>>>
>>> I'm still looking for some community feedback on this proposal
>>> and approach
>>> and now I have a couple of extra questions.
>>>
>>> To any OFBiz Service providers out there – how do you manage the
>>> online help
>>> when you install or implement OFBiz? (Is it left as it is, do you
>>> remove it
>>> or do you create some new online help?)
>> In most of our projects, the existing online help is not used at
>> all. The nature of our projects are mostly eCommerce and portal
>> systems with
>> another ERP backend like SAP. So the OFBiz backend is either not
>> used at all or only a small part is used. We do trainings with the
>> end users then
>> and sometimes write some kind of manual which describes the
>> backend use in context to the customer specific processes.
>>
>> I think there was only one project in the past 13 years which used
>> the online help with partly modified texts.
> This is where DITA would be a big help since you could customize
> the topics that you need to change and leave the rest as is.
> I do this with our ADTransform product wherein I write a DITAMAP
> for a customer that pulls in common topics from the main manual
> libra

Re: [DISCUSSION] OFBiz Online Documentation

[Todd Thorner]

I have yet to take a look (or another look), but that seems about right
(I think the presentation was mainly about data models).  Is Mr. El
Omeiri still active on this ml?

Also, the anal part of me needs to edit my bit about editing skills to
read "editing skill."  Ha.



On 15-05-28 08:07 AM, Michael Brohl wrote:
> Todd,
> 
> do you mean this Prezi
> http://prezi.com/qqp54gt46pn_/apache-ofbiz-development/ from Jad El Omeiri?
> 
> 
> Am 28.05.15 um 16:52 schrieb Todd Thorner:
>> I'm pretty much sitting this one out (seems to have jumped right into
>> the tech selection and I don't understand OFBiz well enough yet to be
>> useful as a writer-contributor so I wouldn't be able to offer much
>> quality input), but for what it's worth the most important
>> considerations for a typing architecture are:
>>
>> 1. The project's business needs (e.g. "No XML files!")
>> 2. Making sure the single-sourced files can be puked out into as many
>> useful end user formats as possible (e.g. context-sensitive help, wiki,
>> etc.)
>> 3. Making sure a maximum number of writer-contributors can hit the
>> proverbial ground running without needing to learn new processes
>>
>> One thing I can offer for now is editing skills, but that involves
>> potential toe-stepping.  Perhaps I could transform that solid Prezi
>> presentation into Sozi format so its SVG output could be embedded into
>> any OFBiz web page.  If the original author is cool with that (can't
>> remember who it was), let me know.
>>
>>
> 
> 

Re: Example of creative use of DITA by software implementation company

[Todd Thorner]

Very nice, thanks for the link to such valuable info.



On 15-05-28 02:48 PM, Ron Wheeler wrote:
> http://intuillion.com/2015/05/27/how-we-used-dita-to-automate-generation-of-requirements-documents/
> 
> 
> This is an interesting read if you have to generate proposals that
> include custom requirements with costing.
> 
> 
> Ron
> 

Re: Beginner's Tutorial CRUD operations

[Todd Thorner]

Sorry to say that I am not a source of SME information, but I would like
to thank you for creating another tutorial.



On 15-08-12 03:22 AM, Tiwonge kawonga wrote:
> Hi all,
> I am working on the tutorial to become familiar with ofbiz development
> and I have encountered this:
> 
> in Controller.xml on createPracticePerson, when I set https to true, I
> get the following error after creating a person and only one record is
> created, which occurs when I click last on navigation buttons of the
> form list person which is just above the create person form:
> 
> Error calling event: org.ofbiz.webapp.event.EventHandlerException:
> Found URL parameter [firstName] passed to secure (https) request-map
> with uri [createPracticePerson] with an event that calls service
> [createPracticePerson]; this is not allowed for security reasons! The
> data should be encrypted by making it part of the request body (a form
> field) instead of the request URL. Moreover it would be kind if you
> could create a Jira sub-task of
> https://issues.apache.org/jira/browse/OFBIZ-2330 (check before if a
> sub-task for this error does not exist). If you are not sure how to
> create a Jira issue please have a look before at
> http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for
> your help.
> 
> But when I set https to false, the error disappears but now duplicate
> records are created with different user ID. I do not understand what
> is causing this. I am using ofbiz 13.07.02.
> 
> Thanks in advance for your help.
> 
> Regards
> Tiwonge kawonga
> 

Re: [MARKETING] OFBiz New Website Structure Proposals – Feedback Required

[Todd Thorner]

For what it's worth, I prefer Option B.  Consumers tend to seek
innovation from products themselves while expecting familiarity from the
product's web page navigation/design.

Is there any way to sneak the term "Entrepreneur" in there somewhere as
a sub-menu item?  Feature creep, yes, although I find that entrepreneurs
tend to become excited about a product when they see something at its
web site that makes them think "These people understand me and my dream."



On 15-09-08 12:56 AM, Sharan-F wrote:
> Hi Everyone
> 
> Thanks very much for the feedback on my thread about updating our current
> website. Based on suggestions from the community I've put together a couple
> of diagrams that show a proposed structure for the new OFBiz website. 
> 
> Please note that these proposals are only meant as guides so we are still
> open to getting feedback on any suggested changes.
> 
> The first option is :
> https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Website+Structure+-+Option+A
> 
> The second option is:
> https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Website+Structure+Option+B+-+Work+in+Progress
> 
> Next we need to get feedback from the community to understand which is the
> most preferred, so please can you respond back to this thread with your
> thoughts, suggestions, comments.
> 
> Thanks
> Sharan
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/MARKETING-OFBiz-New-Website-Structure-Proposals-Feedback-Required-tp4671926.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

Re: [MARKETING] OFBiz New Website Structure Proposals – Feedback Required

[Todd Thorner]

That's looking great, Sharan, thanks for the effort.

Does anyone like the idea of having one of those slideshow things as a
page header (right beneath the menu), sliding between images which
showcase the various items from the Solutions group?  I'm rather behind
the site development curve, so I don't know how far into the
architecture phase things are (e.g. Bootstrap or something similar?).

I agree that the Download option should be prominent, but also leave it
in its current menu position.  Offering surfers multiple ways to access
the download page is a good thing.

If you want to cram a ton of additional links into the footer (as per
Taher's latest suggestion), consider a drop-up menu which reflects the
functionality (if not the content) of the main menu.



On 15-09-19 02:49 AM, Sharan-F wrote:
> Hi Everyone
> 
> This is my latest update for the proposed website structure. I’ve removed
> the second level menus and added notes about included specific links.
> 
> https://cwiki.apache.org/confluence/display/OFBIZ/Revised+Website+Structure+v2
> 
> I’ve adjusted the menu sequence based on feedback from Taher and others, and
> also completely removed ‘Solutions’ as a menu option since we can
> incorporate this within the home page itself.
> 
> I hope that this latest revision will be acceptable to the community and we
> can start working towards reaching a consensus. As usual please let me have
> your comments and feedback.
> 
> Thanks
> Sharan
> 
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/MARKETING-OFBiz-New-Website-Structure-Proposals-Feedback-Required-tp4671926p4672228.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

W3C - Web Payments Working Group

[Todd Thorner]

Could someone less ignorant than I spill a few words regarding this W3C
initiative?  In what ways might it impact OFBiz's roadmap?

"It won't because OFBiz itself, with some help from third party
services, can do all those things"

"Implementers will be able to program OFBiz against its API"

"Project maintainers hope to integrate its functionality into a future
version of OFBiz"

"Not many of the project's maintainers have looked into it"

Is one of those close?  Is each of them sort of correct?  Here's a brief
article with an overview (contains a link to the group's official charter):

http://www.programmableweb.com/news/w3c-creates-working-group-to-develop-payments-standards-apis/2015/10/27?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ProgrammableWeb+%28ProgrammableWeb%3A+Blog%29


Thanks for any insights.

Re: [MARKETING] Who Owns the OFBiz Youtube Channel ?

[Todd Thorner]

Someone might have asked this already: would it be easier to set up a
new channel with a slightly different name?



On 15-11-10 12:50 PM, Sharan-F wrote:
> Hi All
> 
> Another update on this. I’ve contacted a few people including Bruno who set
> up the OFBiz Youtube channel originally but no one has been able to grant me
> access to manage the channel.  
> 
> All Youtube channels are now linked to the channel manager’s google account.
> The current  manager of the OFBiz Youtube channel (and we dont know who this
> is) needs to grant access for other people to login to it. If you can login
> to the OFBiz Youtube Channel then you are the manager so please contact me. 
> 
> Thanks
> Sharan
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://ofbiz.135035.n4.nabble.com/MARKETING-Who-Owns-the-OFBiz-Youtube-Channel-tp4673630p4674305.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
> 

W3C brief on Payment Request API

[Todd Thorner]

Hi all,

Once again, I'm not sure if something like this is appropriate to post
here, but it seems relevant to e-commerce (be sure to click through to
the FAQ).

https://www.w3.org/blog/wpwg/2016/04/21/first-public-working-drafts-of-payment-request-api/

Also, those with production-ready OFBiz implementations might consider
contributing to the "payment flows" information (might help with
establishing de facto standards of a W3C nature).

By way of cross-reference, I found this section of the OFBiz
documentation (I didn't perform more than a cursory search).

https://cwiki.apache.org/confluence/display/OFBENDUSER/Apache+OFBiz+Business+Setup+Guide#ApacheOFBizBusinessSetupGuide-storePaymentSettings

This is all FYI, since I have no idea whether the W3C stuff is relevant
enough to warrant an interface feature request for OFBiz (there is a
newbie reason why I'm not on the dev-ml).

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

[Todd Thorner]

Thanks for this, Mr. Foga.  The Downloads page of the ofbiz.apache.org 
site mentions 14.x and 15.x only as part of the project's tentative 
release schedule.  Would end user newcomers be wise to wait out the 
transition?




On 16-06-28 09:55 AM, Sharan Foga wrote:

Thanks Jacopo for the details and summary.

I know that some people might think it a bit strange that this discussion is 
happening on the user list rather than the dev list, but I think these topics 
are something that our users may have an opinion on and want to comment.

+1 for suggestion #1

13.07 has been around a while so I think that ending it now rather than next 
year will help us to focus on other work (e.g. refactoring and clean up)

+1 for suggestion #2

I think the work we are currently doing to improve the trunk build system isn't 
really that visible to our users, but it will make a big difference to 
developers and people who administer the system. Pushing those technical 
benefits back to 14.12 and 15.12 (if we still want to call them that!) will 
help.

Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were 
created. We've incorporated so much new functionality that it would be a good 
thing to try and get some of this into our next release. Essentially it would 
mean more functionality for our users.

Thanks
Sharan

On 2016-06-28 12:26 (+0200), Jacopo Cappellato 
 wrote:

Hi all,

as you may know we are working at migrating the build scripts of the OFBiz
trunk from Ant to Gradle.
Together with this important change we are also modifying, for policy
reasons, the way we distribute the external dependencies (i.e., the jar
files needed by OFBiz): the required jars will be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

1) anticipate the end of life of the release branch 13.07 at now; we would
not issue the fourth release as initially planned
2) once stabilized, backport to 14.12 and 15.12 all the changes required to
build the system and download its dependencies with Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo

Re: Update on Support for 14.12 and 15.12 branches

[Todd Thorner]

Thank you for this update.  Looking forward to 16.x and beyond.


On 16-07-12 07:08 AM, Sharan-F wrote:

Hi Everyone

A quick update following on from the discussions last week about the 14.12
and 15.12 branches. The final result of the community discussions were as
follows:

-   There will be no more releases from 13.07 (so the current release that 
is
out is the last one in that series)

- We are not backporting any of the gradle changes into the 14.12. or 15.12
branches because it will cause instability

- We are going to leave 14.12 and 15.12 as unreleased branches as they are
now (and not make them into releases as to do that we would need to remove
all the jar files and this would create instability).

- The benefits for leaving 14.12 and 15.12 as unreleased branches are that
developers and service providers will still have access to the complete
codebase for 14.12 and 15.12 including the special purpose components to be
able to support their client base.

After a recent discussion on the dev mailing list, it was agreed that the
14.12 and 15.12 branches will be supported until July 2017

*So what does this mean?*
It means that developers can checkout, use and install the OFBiz code from
the branches 14.12 and 15.12, and that these branches will be supported
until July 2017. This also means that we will backport bug fixes into both
branches until July 2017.

*When will the next OFBiz stable release be Available?*
At this stage we are working on stabilising the trunk with Gradle, and hope
to create a 16.x branch later in the year. Once this is done we will be able
to give a tentative release date.

I’ve also updated the website release information seciont with these
details. http://ofbiz.apache.org/download.html

Thanks
Sharan






--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Update-on-Support-for-14-12-and-15-12-branches-tp4688403.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: Ofbiz Cookbook

[Todd Thorner]

Thank you for the recommendation.  I read Ms. Hoffman's "OFBiz Ecommerce 
Out-Of-The-Box" as a primer of sorts, and based on that positive 
experience will consider saving my pennies so I can purchase her OFBiz 
cookbook.


Is there any reason to anticipate a need for an updated edition? Have 
there been many significant changes to OFBiz (or its complementary 
considerations like data modeling strategies) since 2010?




On 16-08-05 10:55 AM, Skip wrote:

I just got finished reading Apache OFBiz Cookbook (Open Source: Community
Experience Distilled) by Ruth Hoffman.

I have been writing Ofbiz code since before it was an Apache project.  This
book would have saved me six months of digging through Ofbiz code and
inspite of my nearly a decade of experience, I still learned several new
things in it.

I highly recommend this book to everyone, beginner and expert alike and
strongly recommend this book for anyone just getting started.  It is well
written and worth every penny.  When you get the Data Resource book, get
this one too and read it first.

Amazon has it here
https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i
e=UTF8&psc=1


I have never met or spoken to Ruth even though she posts on this forum from
time to time.

Thanks Ruth.

Skip

Re: Ofbiz Cookbook

[Todd Thorner]

Thanks very much, Skip, for the information.  Sounds like a great book.  
I haven't done Java since Struts 1.x, so I'll need to shake off some 
language rust (not the language Rust but just plain old ordinary 
language rust).



On 16-08-05 03:27 PM, Skip wrote:

There have been significant changes since this book was written.  However,
it covers topics where very little would need to be added to make it
current.  It does not cover the code in the applications tree where a great
deal has changed.  It focuses on the framework which is what you really want
when you are making new applications for hot-deploy.  I think with this
book, you are well prepared to write new applications assuming previous Java
experience.

-Original Message-----
From: Todd Thorner [mailto:tthor...@infotinuum.com]
Sent: Friday, August 05, 2016 1:00 PM
To: user@ofbiz.apache.org
Subject: Re: Ofbiz Cookbook


Thank you for the recommendation.  I read Ms. Hoffman's "OFBiz Ecommerce
Out-Of-The-Box" as a primer of sorts, and based on that positive
experience will consider saving my pennies so I can purchase her OFBiz
cookbook.

Is there any reason to anticipate a need for an updated edition? Have
there been many significant changes to OFBiz (or its complementary
considerations like data modeling strategies) since 2010?



On 16-08-05 10:55 AM, Skip wrote:

I just got finished reading Apache OFBiz Cookbook (Open Source: Community
Experience Distilled) by Ruth Hoffman.

I have been writing Ofbiz code since before it was an Apache project.

This

book would have saved me six months of digging through Ofbiz code and
inspite of my nearly a decade of experience, I still learned several new
things in it.

I highly recommend this book to everyone, beginner and expert alike and
strongly recommend this book for anyone just getting started.  It is well
written and worth every penny.  When you get the Data Resource book, get
this one too and read it first.

Amazon has it here


https://www.amazon.com/gp/product/1847199186/ref=oh_aui_detailpage_o05_s00?i

e=UTF8&psc=1


I have never met or spoken to Ruth even though she posts on this forum

from

time to time.

Thanks Ruth.

Skip

Re: OFBiz Blog - July 2016 Update

[Todd Thorner]

Yes, the work being accomplished is admirable.  There have been quite a 
few new contributor sign-ups lately, so hopefully the codebase will 
continue to progress & excel.


Here's a question: is there a process within the OFBiz project, beyond 
JIRA, for gathering feature requests from users?  A userbase survey 
might be helpful at this Gradle juncture (e.g. I noticed some 
over-my-head threads on this ml regarding things like minilang scripting).




On 16-08-09 11:08 AM, Sharan Foga wrote:

Hi Everyone

Our monthly blog update is now available at the link below

https://blogs.apache.org/ofbiz/entry/apache_ofbiz_news_july_2016

As always, big thanks to Michael and Jacques for their help in reviewing it and 
putting it together.

Taking a quick look at the list of improvements and bug fixes, the amount of 
work that has been done over the month has been amazing. Thanks to everyone 
that has worked (and is continuing to work :-) on making OFBiz even better.

Thanks
Sharan

Re: OFBiz Blog - July 2016 Update

[Todd Thorner]

Thanks for the reply, Sharan.

I like the idea of a formal survey, which might carry more gravitas in 
the medium term.  Mailing list threads tend to be informal, and ideas 
therein can get forgotten or even buried (not that it has happened here 
... but it's a classic bureaucratic trick to offer opinion polls to the 
plebes instead of referenda).  With a mailing list free-for-all, the 
thousandth or so feature request that comes in might cause people to 
forget about the first two or three threads from weeks previous.


Would it be possible for the OFBiz steering committee (or whatever it's 
called) to send out a ml call for feature requests every other year or 
so (aside: I see you did just that today so thanks), and then collate 
all the feature requests from the most recent ml cattle call into a more 
formal survey?  I wasn't following the recent "new logo" threads, but I 
got the impression that those involved were using a similar approach.


I agree with Taher Alkhateeb that a modular OFBiz featuring plugin 
functionality would be nice, although I'm just an amateur software 
developer so I don't understand the pros/cons of such a strategy or its 
potential need for refactoring.


In any case, my thanks go out to you and all the contributors for 
continuing efforts.




On 16-08-09 11:46 AM, Sharan Foga wrote:

Hi Todd

I think the mailing list is a good tool for talking about potential new 
features. If there is some functionality that someone wants then having a 
discussion about it on the mailing list helps to find others from the community 
with the same or similar requirements.

Do you already have something in mind? If so then please feel free to start a 
discussion thread on this list about the functionality you are looking for. 
(Sometimes it might already exist but not everyone knows about it :-).

On the survey side, I've run a few community surveys in the past so I'd be 
interested to hear your ideas about a potential user base one and the type of 
information it could collect. I will start a discussion thread about the 
survey, so please feel free to add your comments and feedback.

Thanks
Sharan

On 2016-08-09 20:28 (+0200), Todd Thorner  wrote:

Yes, the work being accomplished is admirable.  There have been quite a
few new contributor sign-ups lately, so hopefully the codebase will
continue to progress & excel.

Here's a question: is there a process within the OFBiz project, beyond
JIRA, for gathering feature requests from users?  A userbase survey
might be helpful at this Gradle juncture (e.g. I noticed some
over-my-head threads on this ml regarding things like minilang scripting).



On 16-08-09 11:08 AM, Sharan Foga wrote:

Hi Everyone

Our monthly blog update is now available at the link below

https://blogs.apache.org/ofbiz/entry/apache_ofbiz_news_july_2016

As always, big thanks to Michael and Jacques for their help in reviewing it and 
putting it together.

Taking a quick look at the list of improvements and bug fixes, the amount of 
work that has been done over the month has been amazing. Thanks to everyone 
that has worked (and is continuing to work :-) on making OFBiz even better.

Thanks
Sharan

Re: Proposal: sending the specialpurpose/oagis component to Attic

[Todd Thorner]

I did a quick search for a dog food solution within the ASF, and found 
this page:


https://cwiki.apache.org/confluence/plugins/viewsource/viewpagesrc.action?pageId=92973

It points toward a project hosted outside the ASF, and codehaus.org 
appears to be temporarily unresponsive (at least on my end), but that 
Smooks thing might represent an alternative.



On 16-09-28 10:52 AM, Mike wrote:

Great.  So everyone seems to agree to dump oagis.  Obviously someone took
the time to create this component.  My understanding it is used for
automating B2B communication for purchase orders, inventory, etc.  If you
want ofbiz to play with the big boys, you need this TYPE of Electronic Data
Interchange (EDI) functionality.

So:  If you want to dump oagis, please propose alternatives to make ofbiz
integrate with EDI.  All ERPs have this.

On Tue, Sep 27, 2016 at 9:39 PM, Paul Foxworthy  wrote:


+1



On Fri, Sep 23, 2016 at 2:14 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:


my proposal is to remove the "oagis" specialpurpose component from the
trunk and record the event in our Attic page [*].

Re: OFBiz 16.11.01 docker demo-data image

[Todd Thorner]

Great stuff, thanks.

Have you any opinion on leaping straight toward something like CoreOS?  
Is the difference mostly a matter of codebase maturity, or is it 
something more fundamental to the design/architecture which might leave 
docker as being more compatible with OFBiz?



- Todd



On 17-01-17 10:23 AM, Paul Mandeltort wrote:

Hey guys, thought you’d be interested in a side project I’ve been working on to 
smooth out our devops. One of the biggest pain points for me in OFbiz 
development and deployment (as an end user) is managing the complex 
dependencies and differences between JDK’s, OS’s, hardware platforms, etc. 
Docker solves all of these problems.

Even spinning up a demo of OFBiz is needlessly complicated in a world where I 
can hop on the app store and have an application as complex as Apple Xcode 
installed on my local with one click.

Docker is as big of a revolution as virtualization for development and 
deployment, and is taking over the IT dev-ops and development world.

I noticed several other OFBiz docker projects on dockerhub but none of them 
have been updated for the 16.11.01 release.

Have a look here - I preloaded a copy of the ofbiz 16.11.01 release with the 
demo data for immediate download and execution. You can start up ofbiz in under 
5 minutes now (Depending on your internet bandwidth). This is ideal for any 
folks evaluating ofbiz or want a quick copy to hack at.

https://hub.docker.com/r/marcopinball/ofbiz-demo/ 


If you already have docker installed,

docker run -d -p 8080:8080 -p 8443:8443 marcopinball/ofbiz-demo:latest

This downloads and runs a image preloaded with OpenJDK8, Debian Linux, and the 
out-of-the-box demo and derby database components pre-compiled and loaded, with 
the JVM pre-tweaked to 2GB Xmx.

Grab a cup of coffee while it loads, then

https://localhost:8443/ should be ready to roll!

Would love to see an official OFBiz repo w/ automated builds on Dockerhub.  I’m 
still experimenting and learning with which volumes to expose for data 
retention/configuration. Right now the entityengine.xml config path is expose 
so theoretically you can feed your own entityengine.xml in there and attach 
this instance to a different database.
  
—P

Re: OFBiz 16.11.01 docker demo-data image

[Todd Thorner]

That's some fantastic information, Mr. Mandeltort.  Thanks very much



- Todd


On 17-01-17 12:34 PM, Paul Mandeltort wrote:

CoreOS goes hand-in-hand with Docker - it’s designed for deploying Docker on 
production bare metal servers.

I’ve been experimenting with CoreOS for our internal servers and overall it’s 
an awesome OS simply because updates and security are architected in. Keep in 
mind it’s designed for cloud deployments so getting it going the first time is 
a bit tricky.

CoreOS is just a lightweight cloud-scalable replacement for your bare metal OS 
layer. It’s just as compatible with OFbiz as any other Linux OS. If it runs the 
JVM well, it’ll run OFBiz well (generally speaking, this is an optimistic 
simplification). I haven’t completed any significant validation testing on 
CoreOS yet but so far I don’t see any major showstoppers.

So a modern in-house stack might look like:
Bare Metal Server
Virtualization OS (Xen, VMware, VirtualBox, etc)
CoreOS for Docker Host OS (or Ubuntu or CentOS or RancherOS)
Docker
Application Docker Image
Debian/Ubuntu/Alpine essential OS components
JVM - OpenJDK
Tomcat
OFBiz Application Layer
Database Docker Image
Debian/Ubuntu/Alpine essential OS components
PostgreSQL
Data over NFS to NAS appliance or cloud hosting disk
Web Proxy Image (apache/nginx)
Debian/Ubuntu/Alpine essential OS components
Bare Metal NAS appliance (no point in virtualizing data stores, just adds 
overhead).
Sounds complex, but the major paradigm shift here is packaging up the OS 
specific components with your release and version-controlling the system as a 
whole rather than just the application layer component. In this new model, you 
deploy specific versions of OFBiz with a specific version of the JVM, a 
specific version of the application OS, and even a specific version of the 
database.  Moving a Docker image to a cloud host is very easy now, so you can 
easily have your developers working on the complete versioned stack on their 
machines, check the whole stack in to github/dockerhub, deploy it to your test 
servers, then just slap those docker images live on your cloud hosts once 
everything is verified with no surprises.

If I was working on a new deployment, going cloud-hosted for everything is a 
no-brainer these days.

The paradigm that the entire industry is rushing towards is treating IT 
resources (servers, OSs, deployments, etc) as cattle, not pets:
http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ 
<http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/>

If OFbiz were to get behind this paradigm (and this is a whole different 
discussion probably for the developers but I’m just advocating from an end 
user’s point of view), we could easily decouple the heavier components and have 
them versioned as docker images separately. For example, an OFBiz release would 
be a collection of docker images - one for SOLR, one for Postgres, one for 
Tomcat, and one for the OFBiz application layers.

—P


On Jan 17, 2017, at 1:41 PM, Todd Thorner  wrote:

Great stuff, thanks.

Have you any opinion on leaping straight toward something like CoreOS?  Is the 
difference mostly a matter of codebase maturity, or is it something more 
fundamental to the design/architecture which might leave docker as being more 
compatible with OFBiz?


- Todd



On 17-01-17 10:23 AM, Paul Mandeltort wrote:

Hey guys, thought you’d be interested in a side project I’ve been working on to 
smooth out our devops. One of the biggest pain points for me in OFbiz 
development and deployment (as an end user) is managing the complex 
dependencies and differences between JDK’s, OS’s, hardware platforms, etc. 
Docker solves all of these problems.

Even spinning up a demo of OFBiz is needlessly complicated in a world where I 
can hop on the app store and have an application as complex as Apple Xcode 
installed on my local with one click.

Docker is as big of a revolution as virtualization for development and 
deployment, and is taking over the IT dev-ops and development world.

I noticed several other OFBiz docker projects on dockerhub but none of them 
have been updated for the 16.11.01 release.

Have a look here - I preloaded a copy of the ofbiz 16.11.01 release with the 
demo data for immediate download and execution. You can start up ofbiz in under 
5 minutes now (Depending on your internet bandwidth). This is ideal for any 
folks evaluating ofbiz or want a quick copy to hack at.

https://hub.docker.com/r/marcopinball/ofbiz-demo/ 
<https://hub.docker.com/r/marcopinball/ofbiz-demo/><https://hub.docker.com/r/marcopinball/ofbiz-demo/
 <https://hub.docker.com/r/marcopinball/ofbiz-demo/>>

If you already have docker installed,

docker run -d -p 8080:8080 -p 8443:8443 marcopinball/ofbiz-demo:latest

This downloads and runs a image preloaded with OpenJDK8, Debian Linux, and the 
out-of-the-box demo and derby database components pre-compiled and load

Re: OFBiz 16.11.01 docker demo-data image

[Todd Thorner]

For those OFBiz end users who might be interested, there exists a free 
(with registration) e-book that covers containerizing traditional 
applications.  I haven't read it yet, so this can't be a direct endorsement.



http://info.nirmata.com/containerizing-traditional-apps-ebook?hsCtaTracking=09d8e4bd-2cfa-401f-8534-90f19e6ba312|3ddcaf2a-01e7-4ea7-9adb-2ba1c7033753&__hstc=52585783.0993e39ff53fa9e412248fb800e32a02.1485203112635.1485203112635.1485203112635.1&__hssc=52585783.1.1485203112635&__hsfp=null



On 17-01-17 12:34 PM, Paul Mandeltort wrote:

CoreOS goes hand-in-hand with Docker - it’s designed for deploying Docker on 
production bare metal servers.

I’ve been experimenting with CoreOS for our internal servers and overall it’s 
an awesome OS simply because updates and security are architected in. Keep in 
mind it’s designed for cloud deployments so getting it going the first time is 
a bit tricky.

CoreOS is just a lightweight cloud-scalable replacement for your bare metal OS 
layer. It’s just as compatible with OFbiz as any other Linux OS. If it runs the 
JVM well, it’ll run OFBiz well (generally speaking, this is an optimistic 
simplification). I haven’t completed any significant validation testing on 
CoreOS yet but so far I don’t see any major showstoppers.

So a modern in-house stack might look like:
Bare Metal Server
Virtualization OS (Xen, VMware, VirtualBox, etc)
CoreOS for Docker Host OS (or Ubuntu or CentOS or RancherOS)
Docker
Application Docker Image
Debian/Ubuntu/Alpine essential OS components
JVM - OpenJDK
Tomcat
OFBiz Application Layer
Database Docker Image
Debian/Ubuntu/Alpine essential OS components
PostgreSQL
Data over NFS to NAS appliance or cloud hosting disk
Web Proxy Image (apache/nginx)
Debian/Ubuntu/Alpine essential OS components
Bare Metal NAS appliance (no point in virtualizing data stores, just adds 
overhead).
Sounds complex, but the major paradigm shift here is packaging up the OS 
specific components with your release and version-controlling the system as a 
whole rather than just the application layer component. In this new model, you 
deploy specific versions of OFBiz with a specific version of the JVM, a 
specific version of the application OS, and even a specific version of the 
database.  Moving a Docker image to a cloud host is very easy now, so you can 
easily have your developers working on the complete versioned stack on their 
machines, check the whole stack in to github/dockerhub, deploy it to your test 
servers, then just slap those docker images live on your cloud hosts once 
everything is verified with no surprises.

If I was working on a new deployment, going cloud-hosted for everything is a 
no-brainer these days.

The paradigm that the entire industry is rushing towards is treating IT 
resources (servers, OSs, deployments, etc) as cattle, not pets:
http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/ 
<http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/>

If OFbiz were to get behind this paradigm (and this is a whole different 
discussion probably for the developers but I’m just advocating from an end 
user’s point of view), we could easily decouple the heavier components and have 
them versioned as docker images separately. For example, an OFBiz release would 
be a collection of docker images - one for SOLR, one for Postgres, one for 
Tomcat, and one for the OFBiz application layers.

—P


On Jan 17, 2017, at 1:41 PM, Todd Thorner  wrote:

Great stuff, thanks.

Have you any opinion on leaping straight toward something like CoreOS?  Is the 
difference mostly a matter of codebase maturity, or is it something more 
fundamental to the design/architecture which might leave docker as being more 
compatible with OFBiz?


- Todd



On 17-01-17 10:23 AM, Paul Mandeltort wrote:

Hey guys, thought you’d be interested in a side project I’ve been working on to 
smooth out our devops. One of the biggest pain points for me in OFbiz 
development and deployment (as an end user) is managing the complex 
dependencies and differences between JDK’s, OS’s, hardware platforms, etc. 
Docker solves all of these problems.

Even spinning up a demo of OFBiz is needlessly complicated in a world where I 
can hop on the app store and have an application as complex as Apple Xcode 
installed on my local with one click.

Docker is as big of a revolution as virtualization for development and 
deployment, and is taking over the IT dev-ops and development world.

I noticed several other OFBiz docker projects on dockerhub but none of them 
have been updated for the 16.11.01 release.

Have a look here - I preloaded a copy of the ofbiz 16.11.01 release with the 
demo data for immediate download and execution. You can start up ofbiz in under 
5 minutes now (Depending on your internet bandwidth). This is ideal for any 
folks evaluating ofbiz or want a quick copy to hack at.

https://hub.docker.com/r/marc

Re: Blog Post: How and Where to Get Started with OFBiz

[Todd Thorner]

Concise and informative.  Great job.



On 17-03-07 04:35 AM, Sharan Foga wrote:

Hi Everyone

Pranay has written a nice blog post about how and where to get started with 
OFBiz. It has been published on our OFBiz blog at the link below:

https://blogs.apache.org/ofbiz/entry/apache-ofbiz-how-and-where

Thanks very much to Pranay for doing this.

Thanks
Sharan

Re: Tutorial Videos

[Todd Thorner]

I haven't had a chance yet to take a look, but the effort is much 
appreciated.




On 17-03-09 04:48 AM, Deepak Dixit wrote:

Hi Everyone,

Pranay has created two video tutorials, these have been published on our
OFBiz YouTube channel :
1 - Apache OFBiz Mailing Lists 
2 - OFBiz Beginners Tutorial - Basic Setup Release16.11


Thanks Pranay for these helpful videos.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

Re: Permissions Profiling

[Todd Thorner]

Heck, I'd appreciate a table to that effect within the wiki.


Just saying.



On 17-03-30 04:23 PM, Ryan Moriarty wrote:

I've been asked to do a review of user permissions in our OFBiz
installation. Is there any good method (besides searching through the code
base one-by-one) of determining what services and screens a user has access
to, given a certain SecurityPermission?  Perhaps XPath queries against
service definitions and implementations? If anyone else has done this and
has ideas, I would appreciate the input.

Re: [SURVEY] Name for the task which load demo and all data

[Todd Thorner]

I'm in agreement with the last two posts of this thread.  I'm not a 
contributor, though, so there's that whole armchair QB thing going on 
from my end.



On 17-05-15 08:12 AM, Mike wrote:

gradlew "ofbiz --load-data readers=seed,seed-initial,ext,ext-demo"

Just leave it "as-is".  These are historical.  There is nothing gained but
more confusion and out-dating of existing documentation.


On Sun, May 14, 2017 at 10:34 PM, Paul Foxworthy 
wrote:


Hi all,

At the risk of bikeshedding...

The "data" is redundant. What else would you "load" but "data"?

loadAll 1 (best)
loadDefault 2
loadAllData 3
loadData 4 (worst)

loadData should be infinity. It's meaningless.

Cheers

Paul Foxworthy


On 13 May 2017 at 02:45, Paul Mandeltort  wrote:


Sorry, I’m being a jerk and not following your directions so feel free to
ignore me, but some unsolicited advice :-)

The proposed terms are still ambiguous. One of OFBiz’s biggest problems

is

there’s a lot of shorthand and ambiguity which makes it really hard for
someone who occasionally digs in (like me) to figure out what’s going on.

So I’m going to suggest a bit more verbosity:

Load-Data-All
Load-Data-Demo
Load-Data-Seed
Load-Data-Seed-Initial
Load-Data-External
Load-Data-External-Test
Load-Data-External-Demo

to parallel the concepts in the readme. Then at least you can follow the
concepts through the pipeline. Now the naming of those data loading tasks
is another function as they are still confusion (seed vs seed initial
description is confusing!).



• seed: OFBiz and External Seed Data - to be maintained along with source
and updated whenever a system deployment is updated
• seed-initial: OFBiz and External Seed Data - to be maintained along

with

source like other seed data, but only loaded initially and not updated

when

a system is updated except manually reviewing each line
• demo: OFBiz Only Demo Data
• ext: External General Data (custom)
• ext-test: External Test Data (custom)
• ext-demo: External Demo Data (custom)

While I’m hardly an expert, I’ve always appreciated the pattern of
parameters following a “Verb-Noun-Adjective” format.  So in this case,

Load

= Verb, Data = what, Adjective = what kind of data we’re loading.

“ext” is also confusing, since it could be confused for “Extension”, but
that’s another discussion probably.

If you’re a command-line warriors, you can add gradle autocomplete to

Bash

and Zsh:
https://github.com/gradle/gradle-completion

—P

On May 12, 2017, 10:35 AM -0500, Jacques Le Roux <
jacques.le.r...@les7arts.com>, wrote:

Hi,

Following the discussion in this thread https://s.apache.org/9PBV we

agreed to change the name of the Gradle task which load demo and all

data.

Before Gradle it was load-demo. It's currently loadDefault and in the

discussion came loadAll, loadData and loadAllData.

So I propose an informal vote, more a survey, to decide which name we

should use for this (important) task.

Please vote by giving a weight to each of 4 propositions:
loadDefault
loadAll
loadData
loadAllData

For instance, here is my choice
loadDefault 4
loadData 3
loadAll 2
loadAllData 1
which means that I prefer loadAllData over loadAll, etc.

So if we agree on the idea, we will pick the name with the smaller

cumulated number from participants

Thanks

Jacques




--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au