Hello everyone!
I'm currently working on an "impersonate login" feature, that will allow
to an authorized user to see what another user can do, and that without
asking for his password. I currently managed to have something working out.
Did anyone already met this need and worked out somethin
Hi,
I noticed this error in trunk demo error.log
2017-05-16 03:05:38,898 |0.0.0.0-startStop-1 |StartupLoggingUtils |E|
Missing Java Option solr.log.dir. Logging may be missing or incomplete.
It's thrown by
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apac
Hi Jacques,
In ${ofbiz.home}/build.gradle, adding solr.log.dir and solr.log.level can
remove this error message, i.e.:
def jvmArguments = ['-Xms128M', '-Xmx1024M',
'-Dsolr.log.dir=runtime/logs',
'-Dsolr.log.level=INFO']
I tried defi
Hi All,
according to the discussion in [1] and the Jira issue [2] we decided to
deprecate mini lang and migrate it to Java and/or Groovy code.
To help contributors finding the right approach for the migration, we
should define which mini lang code should be migrated to Java code,
groovy or s
Groovy +1.
I think mini lang make ofbiz special in apache projects, it give a space to
business consultants to do more. I'm not sure whether groovy is as simple as
mini lang for the consultants, it's 'change and play', this is similar to mini
lang.
My 2 cents,
Shi Jinghai
-邮件原件-
发件人:
Hi Michael,
My preference go to convert the mini-lang to Groovy with the following
reason :
* Ensure the DSL cover all mini-lang functionnality and if not why
* Implement some services in groovy
* Do it manually at the beginning, convert automatically it's just a
nightmare if you are not su
The master build.gradle file should not point to any plugins
On Fri, May 19, 2017 at 1:10 PM, Shi Jinghai wrote:
> Hi Jacques,
>
> In ${ofbiz.home}/build.gradle, adding solr.log.dir and solr.log.level can
> remove this error message, i.e.:
> def jvmArguments = ['-Xms128M', '-Xmx1024M',
>
My recommendation if you want to achieve something significant for this
task is the following:
- Focus first on services and tests, the bulk of messy minilang is living
there
- Maybe we shouldn't reinvent the wheel. We already have the minilang
parsing logic, why not just use it to convert everyth
My preference is to migrate to the Groovy DSL, and enhance it if required.
The Groovy DSL is the natural evolution of the core concepts and strengths
of Minilang and is preferable, in my opinion, to plain Java for the
implementation of business logic.
Jacopo
On Fri, May 19, 2017 at 12:38 PM, Mic
Le 19/05/2017 à 15:15, Taher Alkhateeb a écrit :
- Maybe we shouldn't reinvent the wheel. We already have the minilang
parsing logic, why not just use it to convert everything to Java? Yeah it
might look a bit odd, but we can do a full migration of all minilang
scripts in one shot. Then we can sl
Nicely said, +1
Jacques
Le 19/05/2017 à 16:20, Jacopo Cappellato a écrit :
My preference is to migrate to the Groovy DSL, and enhance it if required.
The Groovy DSL is the natural evolution of the core concepts and strengths
of Minilang and is preferable, in my opinion, to plain Java for the
i
+1
I like the work done with the Groovy DSL and i see no drawback using it
compared to java.
Gil
Le 19/05/2017 à 16:20, Jacopo Cappellato a écrit :
My preference is to migrate to the Groovy DSL, and enhance it if required.
The Groovy DSL is the natural evolution of the core concepts and str
Hi Taher
I tend to prefer rewriting old and messy mini-lang to proper groovy DSL
or java.
I fear that code generation from poor designed minilang (beside the
technical interest :) ) could lead to have a lot of bad java with a lot
of cleaning required.
Gil
Le 19/05/2017 à 15:15, Taher Alk
Fair enough, your solution is cleaner for sure. I put forward my idea to
speedup the transition but no rush!
Java or Groovy or any other programming language is fine by me. I don't
think we need to restrict what people can write to replace minilang because
frankly all options are 1000% better than
14 matches
Mail list logo
