Re: Alternative UI using Vaadin as ofbiz user interface

[Nicolas Malin]

Hi Hans,

If it's too complicate for you to migrate your current works on the 
common-theme structure, please open an issue with your current patch I 
will check if it's possible to support it by common-theme or if the 
framework need some improvement to realize that.


Cheers,

Nicolas


Le 19/09/2017 à 08:49, Jacques Le Roux a écrit :

Hi Hans,

I'd then suggest to have a look at the common-theme Nicolas recently 
introduced and how to use it with your Vaadin effort in order to not 
have to change things in framework if possible


Please check https://issues.apache.org/jira/browse/OFBIZ-9138

Thanks

Jacques


Le 19/09/2017 à 03:56, Hans Bakker a écrit :

Hi Jacques,

we currently create it as a plugin with some patches, but it would be 
nice to integrate it in the framework, so it can be used by all 
components


regards,
Hans

On 08/08/17 20:10, Jacques Le Roux wrote:

Hi Hans,

I'm not interested in helping to implement (rather not enough spare 
time) but that could be contributed as a component I guess.


Could it be a plugins or does it need to be in framework? What would 
be the entailments for framework changes?


Thanks

Jacques


Le 07/08/2017 à 10:08, Hans Bakker a écrit :

Interest for co-operation?

We are looking here using vaadin (http://vaadin.com/) as user 
interface for OFBIz using existing OFBiz screens and forms


we have a proof of concept working here and are preparing a 
vadinDemo component for others to try.
 We implemented it creating an FTL macrolibrary generating Vaadin 
instead of HTML statements.


Please let me know here, if there is interest helping to implement 
this.


The license of Vaadin is in general Apache 2.0 or compatible.

Re: Rule to deprecated a service

[Nicolas Malin]

Thanks for the work Jacques.

Nicolas


Le 29/09/2017 à 09:49, Jacques Le Roux a écrit :

Done at https://s.apache.org/12Uq

Jacques


Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :

Thanks Nicolas :)

It's with mine at least and I guess Jacopo's, Scott's and Deepak's, 
right guys?


W/o answers I will soon consider the status quo a consensus ans will 
write the rules in wiki


Jacques


Le 14/08/2017 à 14:51, Nicolas Malin a écrit :

Le 14/08/2017 à 07:48, Deepak Dixit a écrit :

Thank Jacques,

The code that has been deprecated before December 2014 will be 
released
in the releases of the 14.12 branch: in this way users will be 
notified

about deprecated methods/code.

I am also on same page . We tag code deprecated as a part of 
release and

these code will be removed from next release.
Lets say we set Release 17.XX as deprecated for an service, this 
service

will be part of Release17.XX and will be removed in next Release 18.XX
Sometime it would be good to stop my work when I'm tired :) I 
restart my example because it's wrong with my brain :
Imagine we are the 30 december 2019 and we decide to create a new 
release.

We have on trunk :
 * addCatalogMember deprecated since="next release"
 * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
 * addCatalogMember deprecated since="19.12"
 * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
 * addCatalogMember deprecated since="19.12"

It's in coherence with your remark Deepak ?

Nicolas

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

On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Nicolas,

Actually when I read OFBIZ-6273 it seems Jacopo are on the same 
page than

me:

The code that has been deprecated before December 2014 will be 
released
in the releases of the 14.12 branch: in this way users will be 
notified

about deprecated methods/code.

For this reason we can proceed and remove all the deprecated code 
from

trunk, deprecated before December 2014.

Anyway I'd like to have more opinions about *when to remove 
deprecated

code before writing definitive rules about it*.

It seems Jacopo, Scott and I are on the same page (please confirm 
guys).


And you Nicolas propose something which lets more time to users. 
This is

maybe not a bad idea, our users are our most important assets!

Jacques



Le 11/08/2017 à 20:52, Nicolas Malin a écrit :

Imagine we are the 30 december 2019 and we decide to create a new 
release.

We have on trunk :
  * addCatalogMember deprecated since="next release"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
  * addCatalogMember deprecated since="19.12"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
  * addCatalogMember deprecated since="19.12"
  * deleteWorkEffortAssignment depraceted since="18.12"

I hope this example is less confused that the sentence :)

Nicolas

Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :


Hi Nicolas,

I'm unsure about your point

"remove all element contains with a since not on the last stable 
branch

on trunk"

I guess you mean

"to remove on trunk all elements which contains a
'since=releaseBranchNumber' with releaseBranchNumber being 
different from

the last stable branch just created"

For instance in your example we would remove all elements 
deprecated but

not those marked with deprecated with 'since=17.11'

Right?

Please confirm and others please raise a hand if you disagree.

IMO we could remove all deprecated code from trunk at this 
moment. I

mean, we would not even keep services with 'since=17.11'

So to be totally clear, my take is to remove all deprecated code 
(not
only services) when we release a branch. In other words just 
after the 1st
release of a branch the trunk should no longer contain any 
deprecated code.

Is that too much and early ?
Another possibility would be to remove all the deprecated code 
from the
trunk when releasing the last release of the last branch (ie 
when a branch

get to its End Of Life/Support)

Would be the rule Nicolas proposes better ? ie, if I have well
understood, we keep in trunk the deprecated code deprecated 
between the

creation of the "old" (previous stable) and the (new) stable branch

I guess whether rule we pick we all agree that it must apply to 
all code

not only services, or Java code, etc.

Some suggest to keep the deprecated code during 2-3 versions 
(OFBiz code

can be considered an API): https://softwareengineering.st
ackexchange.com/questions/67837/when-to-deprecate-and-when-
to-delete-in-java

So what are your opinions :) ?

Jacques


Le 11/08/2017 à 12:08, Nicolas Malin a écrit :


Hello,

I 

Re: All roleType entities should maintain lifespan

[Nicolas Malin]

Add lifespan to PartyRole seems to me just to complex perhaps 
impossible. If you want indicate (as example) that a party is a customer 
from / to with a lifespan on PartyRole they missing the information 
customer from who ?


PartyRole is a technical entity as functional entity (it's border line 
:) ). Prefer to manage this role lifespan information with 
PartyRelationship and hidden PartyRole value to end user.


A party with "bill to customer" role associate to an order would be for 
the system always a "bill to customer" and not only for the life order 
time. But in the other case, you can consider that this "bill to 
customer" is finish for your company and you can indicate this through 
PartyRelationship


Nicolas


Le 29/09/2017 à 10:00, Scott Gray a écrit :

Hi Suraj,

I still haven't seen an example of a useful use case for adding
from/thruDate fields to the PartyRole table.  Did you have anything in mind
that it might help with?

I'd honestly prefer to remove it rather than expand it.

Regards
Scott

On 29 September 2017 at 20:41, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:


Hello,

There has been already a discussion under OFBIZ-5959
 regarding this.
I would like to bring this point again into attention and would like to
suggest that we should introduce lifespan to all such entities.
Also, PartyRole FK constraint should be removed while adding a record of
that party in any other role entity, earlier it was also discussed that it
becomes cumbersome to manage that and there is not any specific need to
have that in real time as well.

Let me know your thoughts on this.
--
Thanks and Regards
*Suraj Khurana* | Sr. Enterprise Software Engineer
*HotWax Commerce*  by  *HotWax Systems*
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010

Re: Security group permission association must have date range

[Nicolas Malin]

No objection on this +1

Nicolas


Le 28/09/2017 à 10:05, Suraj Khurana a écrit :

Hello,

There might be many scenarios in the real business that you need to
maintain specific permission to a specific group for some specified time
only. Like at the time of business expansion, permission related work
allotment to current employees, so maintaining history becomes important
here.

IMO, there should be *fromDate* and *thruDate* fields on
*SecurityGroupPermission* entity as well with *fromDate* as part of primary
key.

Please let me know your thoughts on this.

--
Thanks and Regards,
*Suraj Khurana* | Sr. Enterprise Software Engineer
*HotWax Commerce*  by  *HotWax Systems*
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010

Re: Security group permission association must have date range

[Aditya Sharma]

+1

Thanks and Regards,

*Aditya Sharma* | Enterprise Software Engineer
HotWax Systems 


On Fri, Sep 29, 2017 at 2:38 PM, Devanshu Vyas 
wrote:

> +1 Suraj.
>
> Thanks & Regards,
> Devanshu Vyas.
>
> On Fri, Sep 29, 2017 at 2:34 PM, Vaibhav Jain <
> vaibhav.j...@hotwaxsystems.com> wrote:
>
> > +1 Suraj
> >
> > Vaibhav Jain
> > Hotwax Systems,
> > vaibhav.j...@hotwaxsystems.com
> >
> > On Thu, Sep 28, 2017 at 1:35 PM, Suraj Khurana <
> > suraj.khur...@hotwaxsystems.com> wrote:
> >
> > > Hello,
> > >
> > > There might be many scenarios in the real business that you need to
> > > maintain specific permission to a specific group for some specified
> time
> > > only. Like at the time of business expansion, permission related work
> > > allotment to current employees, so maintaining history becomes
> important
> > > here.
> > >
> > > IMO, there should be *fromDate* and *thruDate* fields on
> > > *SecurityGroupPermission* entity as well with *fromDate* as part of
> > primary
> > > key.
> > >
> > > Please let me know your thoughts on this.
> > >
> > > --
> > > Thanks and Regards,
> > > *Suraj Khurana* | Sr. Enterprise Software Engineer
> > > *HotWax Commerce*  by  *HotWax Systems*
> > > Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
> > >
> >
>

Re: Security group permission association must have date range

[Devanshu Vyas]

+1 Suraj.

Thanks & Regards,
Devanshu Vyas.

On Fri, Sep 29, 2017 at 2:34 PM, Vaibhav Jain <
vaibhav.j...@hotwaxsystems.com> wrote:

> +1 Suraj
>
> Vaibhav Jain
> Hotwax Systems,
> vaibhav.j...@hotwaxsystems.com
>
> On Thu, Sep 28, 2017 at 1:35 PM, Suraj Khurana <
> suraj.khur...@hotwaxsystems.com> wrote:
>
> > Hello,
> >
> > There might be many scenarios in the real business that you need to
> > maintain specific permission to a specific group for some specified time
> > only. Like at the time of business expansion, permission related work
> > allotment to current employees, so maintaining history becomes important
> > here.
> >
> > IMO, there should be *fromDate* and *thruDate* fields on
> > *SecurityGroupPermission* entity as well with *fromDate* as part of
> primary
> > key.
> >
> > Please let me know your thoughts on this.
> >
> > --
> > Thanks and Regards,
> > *Suraj Khurana* | Sr. Enterprise Software Engineer
> > *HotWax Commerce*  by  *HotWax Systems*
> > Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
> >
>

Re: Security group permission association must have date range

[Vaibhav Jain]

+1 Suraj

Vaibhav Jain
Hotwax Systems,
vaibhav.j...@hotwaxsystems.com

On Thu, Sep 28, 2017 at 1:35 PM, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

> Hello,
>
> There might be many scenarios in the real business that you need to
> maintain specific permission to a specific group for some specified time
> only. Like at the time of business expansion, permission related work
> allotment to current employees, so maintaining history becomes important
> here.
>
> IMO, there should be *fromDate* and *thruDate* fields on
> *SecurityGroupPermission* entity as well with *fromDate* as part of primary
> key.
>
> Please let me know your thoughts on this.
>
> --
> Thanks and Regards,
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> *HotWax Commerce*  by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>

Missing/Incomplete View Order Image Feature

[Devanshu Vyas]

Hello Devs,

I found (View Image) buttons on order view page on demo instance
,
and I was curious to find no such UI in the application to associate an
image to order. I explored the button history and tried to find the purpose
behind this, and didn't find any way to add an image(content) to the order
except via Webtools.
FYI, I also found a ticket in JIRA for this button, OFBIZ-7257
, and here also the
button functionality is found broken.

I would like to propose making this feature generic, i.e. a feature where a
user will be able to add different types of content(image, document, URL,
etc.) to an order. Also, the order image feature is not exactly available
in the order workflow, so we can improve it this way.

I would like to know your thoughts on it and tell me if I missed anything
here.
Waiting for your replies.


Thanks & Regards,
Devanshu Vyas.

Re: svn commit: r1810056 [1/2] - in /ofbiz: ofbiz-framework/trunk/build.gradle tools/security/dependency-check/dependency-check-report.html

[Jacques Le Roux]

Ha sorry,

These are unsuccessful WIP

Just noticed it also on my side while reviewing (again) my last commits, 
removed at r1810062

Jacques


Le 29/09/2017 à 09:32, Taher Alkhateeb a écrit :

Why did you apply the jdeps and codenarc plugins? Why did you add
commented out code? What's this all about?

On Fri, Sep 29, 2017 at 9:59 AM,   wrote:

Author: jleroux
Date: Fri Sep 29 06:59:45 2017
New Revision: 1810056

URL: http://svn.apache.org/viewvc?rev=1810056=rev
Log:
No functional change

Updates xstream from 1.4.9 to 1.4.10 to fixes a vulnerability reported by
Dependency Check
Updates the dependency-check-report.html

There are more to do, but my time is limited...

Modified:
 ofbiz/ofbiz-framework/trunk/build.gradle
 ofbiz/tools/security/dependency-check/dependency-check-report.html

Modified: ofbiz/ofbiz-framework/trunk/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/build.gradle?rev=1810056=1810055=1810056=diff
==
--- ofbiz/ofbiz-framework/trunk/build.gradle (original)
+++ ofbiz/ofbiz-framework/trunk/build.gradle Fri Sep 29 06:59:45 2017
@@ -28,12 +28,15 @@ buildscript {
  }
  dependencies {
classpath "at.bxm.gradleplugins:gradle-svntools-plugin:latest.release"
+  classpath "org.kordamp.gradle:jdeps-gradle-plugin:0.2.0"
  }
  }
  apply plugin: 'java'
  apply plugin: 'eclipse'
  apply plugin: 'maven-publish'
  apply plugin: "at.bxm.svntools"
+apply plugin: 'org.kordamp.jdeps'
+apply plugin: 'codenarc'

  apply from: 'common.gradle'

@@ -103,7 +106,7 @@ dependencies {
  compile 'com.lowagie:itext:2.1.7'
  compile 'com.sun.mail:javax.mail:1.5.1'
  compile 'com.sun.syndication:com.springsource.com.sun.syndication:0.9.0'
-compile 'com.thoughtworks.xstream:xstream:1.4.9'
+compile 'com.thoughtworks.xstream:xstream:1.4.10'
  compile 'commons-cli:commons-cli:1.3.1'
  compile 'commons-net:commons-net:3.3'
  compile 'commons-validator:commons-validator:1.5.1'
@@ -1006,3 +1009,21 @@ def gradlewSubprocess(commandList) {
  fullCommand.addAll(commandList)
  exec { commandLine fullCommand }
  }
+
+//codenarcMain {
+//ignoreFailures false
+//configFile file('config/codenarc/codenarc-main.rules')
+//
+//maxPriority1Violations 0
+//maxPriority2Violations 10
+//maxPriority3Violations 20
+//}
+//
+//codenarcTest {
+//ignoreFailures true
+//configFile file('config/codenarc/codenarc-test.rules')
+//
+//maxPriority1Violations 0
+//maxPriority2Violations 10
+//maxPriority3Violations 20
+//}
\ No newline at end of file

Re: All roleType entities should maintain lifespan

[Scott Gray]

Hi Suraj,

I still haven't seen an example of a useful use case for adding
from/thruDate fields to the PartyRole table.  Did you have anything in mind
that it might help with?

I'd honestly prefer to remove it rather than expand it.

Regards
Scott

On 29 September 2017 at 20:41, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

> Hello,
>
> There has been already a discussion under OFBIZ-5959
>  regarding this.
> I would like to bring this point again into attention and would like to
> suggest that we should introduce lifespan to all such entities.
> Also, PartyRole FK constraint should be removed while adding a record of
> that party in any other role entity, earlier it was also discussed that it
> becomes cumbersome to manage that and there is not any specific need to
> have that in real time as well.
>
> Let me know your thoughts on this.
> --
> Thanks and Regards
> *Suraj Khurana* | Sr. Enterprise Software Engineer
> *HotWax Commerce*  by  *HotWax Systems*
> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>

Re: Rule to deprecated a service

[Jacques Le Roux]

Done at https://s.apache.org/12Uq

Jacques


Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :

Thanks Nicolas :)

It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys?

W/o answers I will soon consider the status quo a consensus ans will write the 
rules in wiki

Jacques


Le 14/08/2017 à 14:51, Nicolas Malin a écrit :

Le 14/08/2017 à 07:48, Deepak Dixit a écrit :

Thank Jacques,


The code that has been deprecated before December 2014 will be released

in the releases of the 14.12 branch: in this way users will be notified
about deprecated methods/code.

I am also on same page . We tag code deprecated as a part of release and
these code will be removed from next release.
Lets say we set Release 17.XX as deprecated for an service, this service
will be part of Release17.XX and will be removed in next Release 18.XX

Sometime it would be good to stop my work when I'm tired :) I restart my 
example because it's wrong with my brain :
Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
 * addCatalogMember deprecated since="next release"
 * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
 * addCatalogMember deprecated since="19.12"
 * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
 * addCatalogMember deprecated since="19.12"

It's in coherence with your remark Deepak ?

Nicolas

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

On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Thanks Nicolas,

Actually when I read OFBIZ-6273 it seems Jacopo are on the same page than
me:

The code that has been deprecated before December 2014 will be released
in the releases of the 14.12 branch: in this way users will be notified
about deprecated methods/code.

For this reason we can proceed and remove all the deprecated code from
trunk, deprecated before December 2014.

Anyway I'd like to have more opinions about *when to remove deprecated
code before writing definitive rules about it*.

It seems Jacopo, Scott and I are on the same page (please confirm guys).

And you Nicolas propose something which lets more time to users. This is
maybe not a bad idea, our users are our most important assets!

Jacques



Le 11/08/2017 à 20:52, Nicolas Malin a écrit :


Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
  * addCatalogMember deprecated since="next release"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
  * addCatalogMember deprecated since="19.12"
  * deleteRateAmount deprecated since="17.11"
  * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
  * addCatalogMember deprecated since="19.12"
  * deleteWorkEffortAssignment depraceted since="18.12"

I hope this example is less confused that the sentence :)

Nicolas

Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :


Hi Nicolas,

I'm unsure about your point

"remove all element contains with a since not on the last stable branch
on trunk"

I guess you mean

"to remove on trunk all elements which contains a
'since=releaseBranchNumber' with releaseBranchNumber being different from
the last stable branch just created"

For instance in your example we would remove all elements deprecated but
not those marked with deprecated with 'since=17.11'

Right?

Please confirm and others please raise a hand if you disagree.

IMO we could remove all deprecated code from trunk at this moment. I
mean, we would not even keep services with 'since=17.11'

So to be totally clear, my take is to remove all deprecated code (not
only services) when we release a branch. In other words just after the 1st
release of a branch the trunk should no longer contain any deprecated code.
Is that too much and early ?
Another possibility would be to remove all the deprecated code from the
trunk when releasing the last release of the last branch (ie when a branch
get to its End Of Life/Support)

Would be the rule Nicolas proposes better ? ie, if I have well
understood, we keep in trunk the deprecated code deprecated between the
creation of the "old" (previous stable) and the (new) stable branch

I guess whether rule we pick we all agree that it must apply to all code
not only services, or Java code, etc.

Some suggest to keep the deprecated code during 2-3 versions (OFBiz code
can be considered an API): https://softwareengineering.st
ackexchange.com/questions/67837/when-to-deprecate-and-when-
to-delete-in-java

So what are your opinions :) ?

Jacques


Le 11/08/2017 à 12:08, Nicolas Malin a écrit :


Hello,

I imagine the following process :
* deprecated on trunk an element and indicate
since="$NextReleaseBranch" (or somethink like that)
* When 

All roleType entities should maintain lifespan

[Suraj Khurana]

Hello,

There has been already a discussion under OFBIZ-5959
 regarding this.
I would like to bring this point again into attention and would like to
suggest that we should introduce lifespan to all such entities.
Also, PartyRole FK constraint should be removed while adding a record of
that party in any other role entity, earlier it was also discussed that it
becomes cumbersome to manage that and there is not any specific need to
have that in real time as well.

Let me know your thoughts on this.
--
Thanks and Regards
*Suraj Khurana* | Sr. Enterprise Software Engineer
*HotWax Commerce*  by  *HotWax Systems*
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010

Re: svn commit: r1810056 [1/2] - in /ofbiz: ofbiz-framework/trunk/build.gradle tools/security/dependency-check/dependency-check-report.html

[Taher Alkhateeb]

Why did you apply the jdeps and codenarc plugins? Why did you add
commented out code? What's this all about?

On Fri, Sep 29, 2017 at 9:59 AM,   wrote:
> Author: jleroux
> Date: Fri Sep 29 06:59:45 2017
> New Revision: 1810056
>
> URL: http://svn.apache.org/viewvc?rev=1810056=rev
> Log:
> No functional change
>
> Updates xstream from 1.4.9 to 1.4.10 to fixes a vulnerability reported by
> Dependency Check
> Updates the dependency-check-report.html
>
> There are more to do, but my time is limited...
>
> Modified:
> ofbiz/ofbiz-framework/trunk/build.gradle
> ofbiz/tools/security/dependency-check/dependency-check-report.html
>
> Modified: ofbiz/ofbiz-framework/trunk/build.gradle
> URL: 
> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/build.gradle?rev=1810056=1810055=1810056=diff
> ==
> --- ofbiz/ofbiz-framework/trunk/build.gradle (original)
> +++ ofbiz/ofbiz-framework/trunk/build.gradle Fri Sep 29 06:59:45 2017
> @@ -28,12 +28,15 @@ buildscript {
>  }
>  dependencies {
>classpath "at.bxm.gradleplugins:gradle-svntools-plugin:latest.release"
> +  classpath "org.kordamp.gradle:jdeps-gradle-plugin:0.2.0"
>  }
>  }
>  apply plugin: 'java'
>  apply plugin: 'eclipse'
>  apply plugin: 'maven-publish'
>  apply plugin: "at.bxm.svntools"
> +apply plugin: 'org.kordamp.jdeps'
> +apply plugin: 'codenarc'
>
>  apply from: 'common.gradle'
>
> @@ -103,7 +106,7 @@ dependencies {
>  compile 'com.lowagie:itext:2.1.7'
>  compile 'com.sun.mail:javax.mail:1.5.1'
>  compile 'com.sun.syndication:com.springsource.com.sun.syndication:0.9.0'
> -compile 'com.thoughtworks.xstream:xstream:1.4.9'
> +compile 'com.thoughtworks.xstream:xstream:1.4.10'
>  compile 'commons-cli:commons-cli:1.3.1'
>  compile 'commons-net:commons-net:3.3'
>  compile 'commons-validator:commons-validator:1.5.1'
> @@ -1006,3 +1009,21 @@ def gradlewSubprocess(commandList) {
>  fullCommand.addAll(commandList)
>  exec { commandLine fullCommand }
>  }
> +
> +//codenarcMain {
> +//ignoreFailures false
> +//configFile file('config/codenarc/codenarc-main.rules')
> +//
> +//maxPriority1Violations 0
> +//maxPriority2Violations 10
> +//maxPriority3Violations 20
> +//}
> +//
> +//codenarcTest {
> +//ignoreFailures true
> +//configFile file('config/codenarc/codenarc-test.rules')
> +//
> +//maxPriority1Violations 0
> +//maxPriority2Violations 10
> +//maxPriority3Violations 20
> +//}
> \ No newline at end of file
>
>