On 14/12/2015 4:40 PM, Jacques Le Roux wrote:
Hi Ron,
It's interesting, and I agree with you we must organise the project
and ourselves "more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for
now, this one is about specialpurpose c
Hi Ron,
It's interesting, and I agree with you we must organise the project and ourselves
"more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for now, this
one is about specialpurpose components :)
Note that another baby step we ha
It seems that this discussion is just dancing around the core problem
with the current structure of OFBiz.
There seems to be a natural set of almost separate projects that are
lumped together into a rather tangled object.
This discussion is nibbling around the edge of the problem rather than
Le 08/12/2015 20:59, Nicolas Malin a écrit :
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
Could we list, apart the well known Birt issue, special components which
are overriding main applications?
Directly by memory, the scrum components has defined new seca on cust
request to send email
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
Could we list, apart the well known Birt issue, special components
which
are overriding main applications?
Directly by memory, the scrum components has defined new seca on cust
request to send email that break the standard customer request syst
Sorry Nicolas, I'm not sure I totally get your points :)
Could you elaborate please?
Thanks
Jacques
Le 03/12/2015 23:33, Nicolas Malin a écrit :
Jacques I understand.
We can find a compromise if each specialpurpose components would be identify by meta-data like : demo, util, contrib, buisnes
Le 05/12/2015 13:47, Pierre Smits a écrit :
I suggest to fix such with separate JIRA issues for each.
Best regards,
Pierre Smits
*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/
On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin
wrote:
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
I suggest to fix such with separate JIRA issues for each.
Best regards,
Pierre Smits
*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/
On Thu, Dec 3, 2015 at 11:05 PM, Nicolas Malin
wrote:
> Le 19/11/2015 11:45, Jacques Le Roux a écrit :
>
>> Could we list, apart the well known Bir
Jacques I understand.
We can find a compromise if each specialpurpose components would be
identify by meta-data like : demo, util, contrib, buisness specific to
help the end user to load ofbiz with some component like he can load the
data with load-seed or load-demo.
But it's a second big st
Le 19/11/2015 11:45, Jacques Le Roux a écrit :
Could we list, apart the well known Birt issue, special components
which are overriding main applications?
Directly by memory, the scrum components has defined new seca on cust
request to send email that break the standard customer request system
The old joke:
Why is it more important for women to be beautiful than smart?
Because men see better than they think!
If you need any help, let me know.
Ron
On 24/11/2015 10:37 AM, Jacques Le Roux wrote:
We know you like visual graphics ;) And it's a good idea!
Jacques
Le 24/11/2015 15:40,
We know you like visual graphics ;) And it's a good idea!
Jacques
Le 24/11/2015 15:40, Ron Wheeler a écrit :
Would it be possible create a graphic in the docs identifying what overrides
what as you find this out?
A description would be great but at least a visual summary would help the next
p
Would it be possible create a graphic in the docs identifying what
overrides what as you find this out?
A description would be great but at least a visual summary would help
the next person.
Ron
On 24/11/2015 8:31 AM, Jacques Le Roux wrote:
Yes I see, as suggested by Nicolas. But it seems not
Yes I see, as suggested by Nicolas. But it seems not obvious for a non technical person, and they are often those who assess the product by simply
running the fasted and easiest ways (I do that also with other software, who don't? ;))
Like "Start" section at http://ofbiz.apache.org/download.html
Hi Jacques,
what about a parameter using -D for the build script. we can also do something
programmatic in the ./tools directory.
Regards,
--
Taher Alkhateeb
> On Nov 21, 2015, at 12:53 PM, Jacques Le Roux
> wrote:
>
> I'd veto something which would blindly applies to all specialpurpose
>
I'd veto something which would blindly applies to all specialpurpose
components, see my last post about that
Jacques
Le 21/11/2015 09:22, Jacopo Cappellato a écrit :
Taher,
I like your proposal; in fact this feature would be useful not only for
automated deployments/tests but also to end user
Taher,
I like your proposal; in fact this feature would be useful not only for
automated deployments/tests but also to end users to easily enable the
components they like.
Jacopo
On Sat, Nov 21, 2015 at 8:53 AM, wrote:
> Hi Jacopo,
>
> I would make a distinction between two things: a) preserve
Hi Jacopo,
I would make a distinction between two things: a) preserve what exists and b)
prepare for the future.
Doubtless what you are saying below makes perfect sense as a design decision to
allow for better future developments. I am concerned however with what
currently exists in specialpur
My opinion is we should do so for concerned component but not all others
blindly. For instance the POS it out of scope and so are many others.
So we should better name those which are concerned, current or future...
Jacques
Le 19/11/2015 14:36, Jacopo Cappellato a écrit :
I was actually thinki
I was actually thinking to Birt as an example of this behavior: but in the
future we may add other special purpose applications that need to override
applications screens (in fact overriding screens and other artifacts to
specialize them is a best practice in OFBiz) and the problem will happen
agai
Could we list, apart the well known Birt issue, special components which are
overriding main applications?
Then depending on cases we could be more surgical...
Jacques
Le 19/11/2015 09:46, Jacopo Cappellato a écrit :
I agree with Taher when he says that we should strive to move small steps
in
Niche specific demos of OFBiz can be facilitated with more niche specific
demo data. Associating documentation will help in building the desired
expectations.
For now I don't believe this project will ever be able to showcase every
niche specific demo. But it will be able to showcase a few generic
I agree with Taher when he says that we should strive to move small steps
in the direction of having a lean lightweight framework with pluggable
components.
But I think that Nicolas' proposal is actually one of these steps.
The fact that currently some of our specialized components are overriding
t
Hi Nicolas,
I think If your finger hurts you don't cut it off. The project has too many
pages, documentations, email threads and time dedicated to the special
purpose components. They existed for a long, long time in the history of
OFBiz.
Some attempts were made in the past to reduce the size of
Do you mean that we are going create ant tasks for every special purpose?
Best regards,
Pierre Smits
*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/
On Wed, Nov 18, 2015 at 9:22 PM, Nicolas Malin
wrote:
> Le 10/11/2015 05:54, slidingfilame...@gmail.com a écrit :
>
>> This topic w
Le 10/11/2015 05:54, slidingfilame...@gmail.com a écrit :
This topic was heavily discussed in the past and I think a solution like
turning off the components is very quick indeed but not ideal.
Completely, I'm sure a better ideal exist but difficult to reach.
A second step, easy to reach woul
Le 10/11/2015 23:26, Jacques Le Roux a écrit :
I made another proposition earlier but not too long ago
http://markmail.org/message/ypmrbqkb7y2gh4f5
But it seems nobody was interested :/ (OK, the thread referenced in
the reference above is really long to read :D, but the message is not)
I won
I made another proposition earlier but not too long ago
http://markmail.org/message/ypmrbqkb7y2gh4f5
But it seems nobody was interested :/ (OK, the thread referenced in the
reference above is really long to read :D, but the message is not)
I wonder why. It seems ideal to me: we don't release c
Hi Nicolas,
I like your proposal.
Jacopo
On Mon, Nov 9, 2015 at 10:40 PM, Nicolas Malin
wrote:
> Hello,
>
> With some latest great discussion about keep or not keep specialpurpose
> components on branch, I some inconvenience come from that a specialpurpose
> can be overload the definition (ser
The r13.07 branch and its releases are painful to everybody (and more
importantly our new adopters) as they don't find in the releases what is
advertised elsewhere in projects web and wiki pages. This has been shown in
various threads in the user ml. And this keeps going on as long as we keep
r13.0
Hi Nicolas,
The 13.07 to me was a painful release to deal with because of stripping out the
specialpurpose components. Also disabling these components means lower quality,
no testing and no guarantee of being compatible with the current version of
trunk. So i would imagine this to be sort of eq
Hello,
With some latest great discussion about keep or not keep specialpurpose
components on branch, I some inconvenience come from that a
specialpurpose can be overload the definition (service, entity or
something like that) present on application component.
It's easier, we can comment all
32 matches
Mail list logo