Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml

[Ron Wheeler]

1) Old version of Maven. running with the current version will make it 
easier to debug any problems


2) It looks like you have not built and deployed the parent project so 
the reference to the parent is not working.


Ron

On 28/04/2015 12:40 AM, Hans Bakker wrote:

Hi Adam,

tried it and found out on Ubuntu 14:04 the command is:
mvn package -DskipTests

and gives a number of errors

maven version:
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_65, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-48-generic", arch: "amd64", family: 
"unix"

hans@hans:~/svn/OFBIZ-6271$ sudo bash

errors:
hans@hans:~/svn/OFBIZ-6271$ mvn package -DskipTests
[INFO] Scanning for projects...
[ERROR] The build could not read 45 projects -> [Help 1]
[ERROR]
[ERROR]   The project org.apache.ofbiz:ofbiz-start:TRUNK 
(/home/hans/svn/OFBIZ-6271/framework/start/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for 
org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK in 
http://repo.maven.apache.org/maven2 was cached in the local 
repository, resolution will not be reattempted until the update 
interval of central has elapsed or updates are forced and 
'parent.relativePath' points at wrong local POM @ 
org.apache.ofbiz:ofbiz-component:TRUNK, 
/home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 
-> [Help 2]

[ERROR]
[ERROR]   The project org.apache.ofbiz:ofbiz-base:TRUNK 
(/home/hans/svn/OFBIZ-6271/framework/base/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for 
org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK in 
http://repo.maven.apache.org/maven2 was cached in the local 
repository, resolution will not be reattempted until the update 
interval of central has elapsed or updates are forced and 
'parent.relativePath' points at wrong local POM @ 
org.apache.ofbiz:ofbiz-component:TRUNK, 
/home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 
-> [Help 2]

[ERROR]
[Eand more

On 28/04/15 09:15, Adam Heath wrote:
With this commit, all optionally detected libraries/features during 
the compilation with ant are now being done with maven.  A "maven 
clean" and "maven package -DskipTests" is runnable with 
tools/startofbiz.sh.


I have not run system integration tests(aka, any test that requires a 
running ofbiz instance).  The startup code does proceed without any 
exceptions, so I think this is progressing rapidly.








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml

[Hans Bakker]

Hi Adam,

tried it and found out on Ubuntu 14:04 the command is:
mvn package -DskipTests

and gives a number of errors

maven version:
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_65, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-48-generic", arch: "amd64", family: 
"unix"

hans@hans:~/svn/OFBIZ-6271$ sudo bash

errors:
hans@hans:~/svn/OFBIZ-6271$ mvn package -DskipTests
[INFO] Scanning for projects...
[ERROR] The build could not read 45 projects -> [Help 1]
[ERROR]
[ERROR]   The project org.apache.ofbiz:ofbiz-start:TRUNK 
(/home/hans/svn/OFBIZ-6271/framework/start/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for 
org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK in 
http://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central 
has elapsed or updates are forced and 'parent.relativePath' points at 
wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, 
/home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 -> 
[Help 2]

[ERROR]
[ERROR]   The project org.apache.ofbiz:ofbiz-base:TRUNK 
(/home/hans/svn/OFBIZ-6271/framework/base/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for 
org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK in 
http://repo.maven.apache.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of central 
has elapsed or updates are forced and 'parent.relativePath' points at 
wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, 
/home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 -> 
[Help 2]

[ERROR]
[Eand more

On 28/04/15 09:15, Adam Heath wrote:
With this commit, all optionally detected libraries/features during 
the compilation with ant are now being done with maven.  A "maven 
clean" and "maven package -DskipTests" is runnable with 
tools/startofbiz.sh.


I have not run system integration tests(aka, any test that requires a 
running ofbiz instance).  The startup code does proceed without any 
exceptions, so I think this is progressing rapidly.

buildbot success in ASF Buildbot on ofbiz-trunk

[buildbot]

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/ofbiz-trunk/builds/851

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: lares_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1676303
Blamelist: doogie

Build succeeded!

Sincerely,
 -The Buildbot

[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code

[Adam Heath (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514317#comment-14514317
 ] 

Adam Heath commented on OFBIZ-6217:
---

Don't use UtilGenerics.cast() on an external lib call, if there is an update 
for that external lib that adds generics support.  Upgrading that external lib 
to a new generics-capable version is outside the scope of this issue, so in 
that case, just ignore the warnings.

File a separate issue, asking to get that external lib upgraded.  Cross-link 
the 2 issues.  When the lib is upgraded, then proceed with fixing the 
warnings(if they exist).  But, in theory, the other new issue would hit upon 
changes to the generics markup, so would need to fix it there.

As for the deprecation warnings, I've fixed all simple ones, except for any 
non-macro widget rendering.  I've made a branch with all my changes.  Please 
see the OFBIZ_6275 issue that Jacques mentioned.

> fix warnings in trunk on java source code
> -
>
> Key: OFBIZ-6217
> URL: https://issues.apache.org/jira/browse/OFBIZ-6217
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Taher Alkhateeb
>Assignee: Adrian Crum
>Priority: Minor
>  Labels: java, warning
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, 
> warnings_patch_2.patch, warnings_patch_2.patch
>
>
> Right now, we have 528 warnings on trunk out of which 238 are about raw types 
> and 118 never used imports. So we can already eliminate most of the warning 
> quite quickly.
> I will issue multiple patches to resolve most of these warnings. It might be 
> a bit of a challenge to eliminate the raw types because the generics are not 
> always deducable from the code especially when relying on external APIs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code

[Taher Alkhateeb (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514301#comment-14514301
 ] 

Taher Alkhateeb commented on OFBIZ-6217:


Hey guys, thank you for the heads up.

Adam what should I be careful about in terms of UtilGenerics.cast() and would 
you say it would be ill advised to convert Java built-in type (casting) to 
UtilGenerics.cast()? Would you mind taking a quick look at the latest patch and 
giving me your opinion where I might do things differently?

Jacques, OFBIZ-6275 seems to focus on deprecated method calls. I was not able 
to touch the deprecated warnings yet because they were difficult and require 
advanced knowledge in the core framework and/or external libraries which I am 
unable to debug without first downloading the sources to. Do you have any hints 
where I should be more careful / alert?

> fix warnings in trunk on java source code
> -
>
> Key: OFBIZ-6217
> URL: https://issues.apache.org/jira/browse/OFBIZ-6217
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Taher Alkhateeb
>Assignee: Adrian Crum
>Priority: Minor
>  Labels: java, warning
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, 
> warnings_patch_2.patch, warnings_patch_2.patch
>
>
> Right now, we have 528 warnings on trunk out of which 238 are about raw types 
> and 118 never used imports. So we can already eliminate most of the warning 
> quite quickly.
> I will issue multiple patches to resolve most of these warnings. It might be 
> a bit of a challenge to eliminate the raw types because the generics are not 
> always deducable from the code especially when relying on external APIs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposal: redefining the components' directory layout for source files

[Ron Wheeler]

On 27/04/2015 10:52 AM, Adam Heath wrote:


On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
You can already compile components separately by using the specific 
build files


Yeah, I know, and it's a pain in my side.  I actually like being able 
to *compile* each component separately, by changing to that folder, 
and running ant.  I haven't yet been able to get maven to make that 
possible.


What I think Ron meant, is that it'd be nice to be able to checkout 
out *just* one component, and have all it's 
dependants(jars/other-components) downloaded automatically.  Then, 
work can be done on *just* this component, in isolation.  For this, 
maven works great.


Yes. That is what I meant.



ps: Note Ron's phrase of "breaking the project up".

pps: But, even then, other projects have multiple released artifacts 
per checkout, so maybe all of framework is one repo, and each 
application/specialpurpose/hot-deploy component becomes separate.




Sounds about right.
I would also look at ways to separate the data from code so that could 
be easier to sort out required core seed data from customized entities 
and to build simple installation automated procedures. For example, an 
interactive iZPack installer that installs the OFBiz modules that you 
want and loads the seed data that you need and sets up the services.






Jacques

Le 24/04/2015 06:26, Ron Wheeler a écrit :

+1

Any change of breaking the project up into components that are 
compiled separately?


Ron

On 23/04/2015 11:42 PM, Scott Gray wrote:

+1

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:

In my opinion it would be nice to review how we organize the code 
in our
components and switch to a directory layout that is more inline 
with what

other projects are doing, for example:


http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 



More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

What do you think?

Jacopo









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code

[Adam Heath (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514269#comment-14514269
 ] 

Adam Heath commented on OFBIZ-6217:
---

And, be very very very careful about anything to do with generics.  Use of the 
UtilGenerics.cast() should be *extremely* minimized.

> fix warnings in trunk on java source code
> -
>
> Key: OFBIZ-6217
> URL: https://issues.apache.org/jira/browse/OFBIZ-6217
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Taher Alkhateeb
>Assignee: Adrian Crum
>Priority: Minor
>  Labels: java, warning
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, 
> warnings_patch_2.patch, warnings_patch_2.patch
>
>
> Right now, we have 528 warnings on trunk out of which 238 are about raw types 
> and 118 never used imports. So we can already eliminate most of the warning 
> quite quickly.
> I will issue multiple patches to resolve most of these warnings. It might be 
> a bit of a challenge to eliminate the raw types because the generics are not 
> always deducable from the code especially when relying on external APIs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[Martin Becker]

Generally I see three ways if I think of an combination of OFBiz and Moqui as 
already mentioned in the discussion so far:

1) „Replace“ the OFBiz Framework with Moqui

2) Replace parts of the OFBiz Framework with Moqui parts respectively update 
the OFBiz Framework in a Moqui manner

3) Migrate OFBiz applications and functionality, so that they be part of Mantle 
or standalone apps on base of Moqui

Numbers 1 and 3 could lead to the same result, maybe the steps between are 
different or the approach or just the headline is another. 
Number 2 is more like thinking of optimization of the current framework, maybe 
by looking at Moqui, but there would be no Moqui integration in the end, only 
an updated OFBiz Framework.


My vote for 1) is -1, because I don’t think it is a realistic project in terms 
of effort vs. benefit an with respect to the „customers“ of an „application 
framework OFBiz", this change could be an upgrade killer.

For 2) there is generally a +1 where optimizations are reasonable, but this 
might be much less than a Moqui framework switch

For 3) I say +1, also this would more be an parallel "next OFBiz“ thing


Martin Becker
ecomify GmbH



> Am 27.04.2015 um 03:20 schrieb Adam Heath :
> 
> "Begin replacing ..." is not an actional item.
> 
> How can we vote on something that is ill-defined?  Just saying.
> 
> On 04/26/2015 08:09 PM, Ron Wheeler wrote:
>> +1 for being too early.
>> -1 for going ahead as a project
>> +1 for a PoC and impact analysis
>> 
>> Ron
>> 
>> On 26/04/2015 6:46 PM, Pierre Smits wrote:
>>> First of all, a big thanks to Adrian for taking this step, this RtV
>>> (Request to Vote) to get clarity from the community. A lot has been said
>>> over the last week regarding adopting a new architecture for a future
>>> release.
>>> 
>>> When discussions, like fire, die down it is good to find out where the
>>> community stands. And it seems that a saturation point was reached, as the
>>> last posting before Adam started to test the water of consensus was already
>>> 6 days ago.
>>> 
>>> It seems that we are facing a chicken-and-egg situation here, as we can't
>>> vote on the new direction without knowing the impact of such path. And we
>>> can't establish insights about the impact without having tested the water
>>> and report about it.
>>> 
>>> A PoC is a means to gain the insights. Based on the output of such an
>>> action, the community can reach a well-founded decision. But a PoC is not
>>> the only means to establish the insight. An in-dept comparative study  of
>>> the two solutions (architecture, et all) might lead to such insights too.
>>> And a PoC can be done everywhere, even outside the OFBiz repository.
>>> 
>>> The result of the impact analysis (whether from PoC or comparative study)
>>> could be recorded as JIRA issues. And all the registered JIRA issues
>>> together will be the starting point of a dev branch when the community
>>> votes for the adoption of a new architecture or not (based on those issues
>>> and other information).
>>> 
>>> On the basis of current (high level) information regarding the impact, I
>>> say it is to early to vote for a migration.
>>> 
>>> Best regards,
>>> 
>>> Pierre Smits
>>> 
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>> 
>>> On Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl 
>>> wrote:
>>> 
 Thank you for the clarification.
 I'll stick to my vote and my arguments then.
 
 Michael Brohl
 ecomify GmbH
 www.ecomify.de
 
 Am 26.04.15 um 22:33 schrieb Adrian Crum:
 
  No, it is not a vote for a POC. If the community agrees we need to make a
> change, then we can create a Jira issue, branch, POC, etc.
> 
> No one is going to go to all that work if in the end the community says
> "Nope, don't want it."
> 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> 
 
>> 
>> 
> 

Re: Proposal: redefining the components' directory layout for source files

[Adam Heath]

On 04/27/2015 09:40 AM, Jacques Le Roux wrote:
You can already compile components separately by using the specific 
build files


Yeah, I know, and it's a pain in my side.  I actually like being able to 
*compile* each component separately, by changing to that folder, and 
running ant.  I haven't yet been able to get maven to make that possible.


What I think Ron meant, is that it'd be nice to be able to checkout out 
*just* one component, and have all it's 
dependants(jars/other-components) downloaded automatically.  Then, work 
can be done on *just* this component, in isolation.  For this, maven 
works great.


ps: Note Ron's phrase of "breaking the project up".

pps: But, even then, other projects have multiple released artifacts per 
checkout, so maybe all of framework is one repo, and each 
application/specialpurpose/hot-deploy component becomes separate.



Jacques

Le 24/04/2015 06:26, Ron Wheeler a écrit :

+1

Any change of breaking the project up into components that are 
compiled separately?


Ron

On 23/04/2015 11:42 PM, Scott Gray wrote:

+1

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:

In my opinion it would be nice to review how we organize the code 
in our
components and switch to a directory layout that is more inline 
with what

other projects are doing, for example:


http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html 



More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

What do you think?

Jacopo

Re: jira workflow

[Adam Heath]

On 04/27/2015 09:16 AM, Jacques Le Roux wrote:
Thanks Adam for the very detailed workflow... answers inline, mostly 
about vocabulary :) ...


Le 23/04/2015 07:56, Jacopo Cappellato a écrit :

On Apr 22, 2015, at 10:07 PM, Adam Heath  wrote:

So, I've started attempting to use JIRA and branches, to implement a 
new workflow.  Basically, I'm seeing what the capabilities of the 
systems are.  I've run into a bit of a mis-feature, I believe, so 
I'm asking here to see if anyone might help.


Here is the workflow I am attempting to follow.

1: Bug/feature/etc gets created.

2: Branch is made with the name set to the id from (1).

3: Sub-tasks are made, to split up the large amount of work from (1).

4: Each sub-task can be assigned to different people, and work 
proceeds in parallel. The state of the sub-task moves from OPEN to 
IN-PROGRESS.


There is also the important "Patch available" status...



With git, there is never a single patch.  It's a commit stream, a 
branch, a repo fork.  But yeah, I'll think about using this status.




5: Commits are done to the shared branch from (2), with each message 
tagged with the id(s) from (3).


Cool to put the name of the possible contributor too ;)



6: When a commit from (5) is pushed, the developer doing the work 
moves the issue state to RESOLVED.  This is not closed, as the 
change is not available for testing by the reported yet.  Nor has it 
been made available to the rest of the ecosystem.


A commit is not pushed it's committed :p.


Ok, not pushed, not committed.  How about, "when the change leaves the 
developer's system, and is somehow made available in the shared 
branch?"  This could be via a commit to a shared repo(ala svn), or a 
pull request(ala git/fork)?


In don't agree about the "the change is not available for testing by 
the reported yet." S/He can always checkout a branch. Anyway I agree 
not being "available to the rest of the ecosystem" is a status blocker.


The integration area(svn branch, git repo fork) may not be available for 
the original reporter to easily test.  There would need to be a download 
area for the resultant binaries, or the user would have to check out 
directly.  Not all end-users can or want to compile ofbiz.


7: Some code reviewer looks at the series of commits, and if they do 
what they set out to do, merges the branch to trunk/master/release. 
The issue state(s) change from RESOLVED to 


"Some code reviewer" here must be a committer to be able to merge and 
commit the branch, and it's not in "trunk/master/release", it's, so 
far, eventually in svn trunk HEAD.


For the rest I agree with you and Jacopo

Jacques



Let's not tie the workflow to svn-only terms.  Just because ofbiz 
primary is currently managed through svn, outside vendors might be using 
git, and can use more advanced push/pull/merge-request type workflows.





8: The original filer looks at trunk/master/release, and if the 
original report has been resolved, changes the issue state from  
to CLOSED.


I don't see an option in JIRA for the represenative state in 7.  The 
commits I have just sent into branch OFBIZ-6275 are currently at 
line (6) from above.



Thanks for the detailed workflow, this is a good topic.
For now, without adding statuses or customizing the workflow (we may 
have to contact the ASF Infra for this), I would suggest to use  
= CLOSED.
This means that the task will be closed in step 7 when the feature 
branch is merged into the trunk/master/release branches.
At step 8 the original reported will either add a comment confirming 
that the issue is resolved or reopen the task.


Jacopo

Re: Proposal: redefining the components' directory layout for source files

[Jacques Le Roux]

You can already compile components separately by using the specific build files

Jacques

Le 24/04/2015 06:26, Ron Wheeler a écrit :

+1

Any change of breaking the project up into components that are compiled 
separately?

Ron

On 23/04/2015 11:42 PM, Scott Gray wrote:

+1

Regards
Scott

On 21 January 2015 at 00:41, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:


In my opinion it would be nice to review how we organize the code in our
components and switch to a directory layout that is more inline with what
other projects are doing, for example:


http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

More specifically I would like to switch from, for example:

script/org/ofbiz/product/
src/org/ofbiz/product/
src/org/ofbiz/product/test/

to:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/

What do you think?

Jacopo

Re: move to git.

[Jacques Le Roux]

Le 23/04/2015 17:50, Adam Heath a écrit :

Ok, everything passes, git svn dcommit $HASH, flood the mailing list.

"flood the mailing list", you said it :p

Jacques

Re: move to git.

[Jacques Le Roux]

Le 23/04/2015 17:50, Adam Heath a écrit :

As for that last item I mentioned, if we do switch, I would *love* to include 
such ancient history.

That would be a plus indeed...

Jacques

Re: move to git.

[Jacques Le Roux]

Since Svn 1.7 (or 1.6?) the .svn files are no longer scattered all over but in 
a .svn folder at root of the WC

Jacques

Le 23/04/2015 17:50, Adam Heath a écrit :

Let's not forgot that the complete project history is available offline, that 
the .svn files are not scattered all over

Re: jira workflow

[Jacques Le Roux]

Thanks Adam for the very detailed workflow... answers inline, mostly about 
vocabulary :) ...

Le 23/04/2015 07:56, Jacopo Cappellato a écrit :

On Apr 22, 2015, at 10:07 PM, Adam Heath  wrote:


So, I've started attempting to use JIRA and branches, to implement a new 
workflow.  Basically, I'm seeing what the capabilities of the systems are.  
I've run into a bit of a mis-feature, I believe, so I'm asking here to see if 
anyone might help.

Here is the workflow I am attempting to follow.

1: Bug/feature/etc gets created.

2: Branch is made with the name set to the id from (1).

3: Sub-tasks are made, to split up the large amount of work from (1).

4: Each sub-task can be assigned to different people, and work proceeds in 
parallel. The state of the sub-task moves from OPEN to IN-PROGRESS.


There is also the important "Patch available" status...



5: Commits are done to the shared branch from (2), with each message tagged 
with the id(s) from (3).


Cool to put the name of the possible contributor too ;)



6: When a commit from (5) is pushed, the developer doing the work moves the 
issue state to RESOLVED.  This is not closed, as the change is not available 
for testing by the reported yet.  Nor has it been made available to the rest of 
the ecosystem.


A commit is not pushed it's committed :p.
In don't agree about the "the change is not available for testing by the reported yet." S/He can always checkout a branch. Anyway I agree not being 
"available to the rest of the ecosystem" is a status blocker.

7: Some code reviewer looks at the series of commits, and if they do what they 
set out to do, merges the branch to trunk/master/release. The issue state(s) 
change from RESOLVED to 


"Some code reviewer" here must be a committer to be able to merge and commit the branch, and it's not in "trunk/master/release", it's, so far, 
eventually in svn trunk HEAD.


For the rest I agree with you and Jacopo

Jacques



8: The original filer looks at trunk/master/release, and if the original report 
has been resolved, changes the issue state from  to CLOSED.

I don't see an option in JIRA for the represenative state in 7.  The commits I 
have just sent into branch OFBIZ-6275 are currently at line (6) from above.


Thanks for the detailed workflow, this is a good topic.
For now, without adding statuses or customizing the workflow (we may have to 
contact the ASF Infra for this), I would suggest to use  = CLOSED.
This means that the task will be closed in step 7 when the feature branch is 
merged into the trunk/master/release branches.
At step 8 the original reported will either add a comment confirming that the 
issue is resolved or reopen the task.

Jacopo

[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code

[Jacques Le Roux (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514138#comment-14514138
 ] 

Jacques Le Roux commented on OFBIZ-6217:


Maybe unrelated but beware of OFBIZ-6275

> fix warnings in trunk on java source code
> -
>
> Key: OFBIZ-6217
> URL: https://issues.apache.org/jira/browse/OFBIZ-6217
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Taher Alkhateeb
>Assignee: Adrian Crum
>Priority: Minor
>  Labels: java, warning
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, 
> warnings_patch_2.patch, warnings_patch_2.patch
>
>
> Right now, we have 528 warnings on trunk out of which 238 are about raw types 
> and 118 never used imports. So we can already eliminate most of the warning 
> quite quickly.
> I will issue multiple patches to resolve most of these warnings. It might be 
> a bit of a challenge to eliminate the raw types because the generics are not 
> always deducable from the code especially when relying on external APIs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: move to git.

[Jacopo Cappellato]

On Apr 27, 2015, at 3:16 PM, Jacques Le Roux  
wrote:

> Thanks Ean for letting us know, I was unaware this was needed. I just added 
> mine, but I'm still not in the contributors list, I guess it takes some time, 
> or is another step, like joigning something, needed?

Hi Jacques, just wait, it could take some hours.

Jacopo

Re: move to git.

[Jacques Le Roux]

Le 22/04/2015 19:31, Ean Schuessler a écrit :

That raises another irritating thing about the JIRA SVN workflow vs GIT
pull requests.

If you look at the contributor graph on GitHub for OFBiz you will see
that it currently has only 3 contributors. Foremost this is because the
project committers have mostly not configured their Apache addresses into
their GitHub accounts.


Thanks Ean for letting us know, I was unaware this was needed. I just added mine, but I'm still not in the contributors list, I guess it takes some 
time, or is another step, like joigning something, needed?


Something I'd like to add here. Github is using the successful Freemium business model http://en.wikipedia.org/wiki/Freemium. I doubt there will ever 
be issues with that, but you never know, see what happened to Apache-Extra ...
I know I can trust the ASF, even if, like everything else, it could disappear, that's even less likely than Github in foreseeable future. We live in a 
disruptive world...


Jacques


Secondly, however, it is caused by the fact that
all JIRA committed patches will show the name of the person who merged
the patch rather than its original author.

https://github.com/apache/ofbiz/graphs/contributors

We can make up stories about why this is desirable but I think any honest
assessment would conclude that it is an inconvenience at best and a hazard
at worst. Eventually if these dots are not connected the origins of some
OFBiz code could become as mysterious as the early CVS commits. With the
GIT pull request workflow we would not only know who wrote the code but
would still know who performed the merge. We could also sign the commits
so that their origin is cryptographically confirmed.

- Original Message -

From: "Gil Portenseigne" 
Subject: Re: move to git.
Yes, but these are commiters contributions, i mean non-commiters one should go
thru jira.

Re: Renaming OFBiz artefacts

[Jacques Le Roux]

Le 27/04/2015 13:08, Jacques Le Roux a écrit :
I agree with Adam moreover I don't see a real need to rename packages and what it would add to the project apart more efforts and confusion. So like 
Adam


Mmm, I was not clear, of course for the project it would be cool. I was more thinking about the project users, our beloved users We should not 
mistreat them when we can avoid... I see no plus in renaming packages!


Jacques



-1, even in the long term on my side, I'm not mad about having ALL "clean"!

Jacques

Le 22/04/2015 17:13, Adam Heath a écrit :

-1, but not permanently.

If we start renaming things, then it'll become hard to port changes back and forth between release branches and trunk.  We need to reduce the 
number of outstanding branches first, before this can even be started.


On 04/22/2015 10:09 AM, Ron Wheeler wrote:

I was thinking of something like an 8 hour sprint where several people divide 
up the task and do it and test it quickly.
divide up by application, code/XML, seed data, documentation, testing and what 
ever makes sense to get the change done in a few hours.

Ron
On 22/04/2015 5:01 AM, Pierre Smits wrote:

Ron,

Notwithstanding the appropriateness of the elements in your response,
everything done in the OFBiz project IS a community project (endeavour for
a better word).

Thank you for reiterating the invite for more collaboration. I
wholeheartedly agree and support.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


Definitely a good idea.
Should it be done as a community project over a short period of time?
It would seem to be easier to do as a sort of global "search and replace"
followed by testing rather than modifying a piece and looking for all of
the references to that code and changing them and testing and then picking
the next piece.

Adding a JIRA sounds like the best start.

Ron

On 22/04/2015 4:36 AM, Pierre Smits wrote:


Hi all,

In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian
proposed to rename our OFBiz artefacts from "org.ofbiz" to
"org.apache.ofbiz" to bring it more inline to conventions used by other
Apache projects/products.

Does this proposal need any further discussion? Or can we move forward by
creating a JIRA and work from there?

Best regards,


Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: move to git.

[Jacques Le Roux]

Le 23/04/2015 01:54, David E. Jones a écrit :

On 22 Apr 2015, at 16:49, Adam Heath  wrote:


On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:

On Apr 22, 2015, at 11:41 PM, Adam Heath  wrote:


When this happened, we had to relicense the entire project from GPL to Apache 
2.0.

Gr It was not GPL! :-)

It was something tho; I may be wrong on that, I didn't actually look it up.  I 
do recall that switching was quite the ordeal.

It was MIT, but that wasn't the real issue with all the CLAs... the ASF 
requires them but they are not generally required for other users of the Apache 
2 license.


I was expecting you to say it, thanks David!

Jacques



This was a pain... took months of effort. Even under the ASF we don't know who 
all code has come from, there is no way to get a list from SVN or any other 
tool... not even from Jira (though that's closer, but we only have associations 
between those who opened issues or attached a patch or those sorts of 
activities, doesn't always match exactly which patch gets committed, etc... AND 
not all commits get linked back to the Jira issues... oh and mentioning a name 
in a commit, pretty useless from a reporting perspective... parsing 
difficulties, data cleanliness/consistency issues... nightmare).

-David

Re: move to git.

[Jacques Le Roux]

Thanks Jacopo, from this point I was ready to jump, it was MIT!
I guess someone else already told me, just that I'm have not read it in my 1095 
initial emails backlog yet :/

Jacques

Le 23/04/2015 01:13, Jacopo Cappellato a écrit :

On Apr 22, 2015, at 11:41 PM, Adam Heath  wrote:


When this happened, we had to relicense the entire project from GPL to Apache 
2.0.

Gr It was not GPL! :-)

Jacopo

Re: Renaming OFBiz artefacts

[Jacques Le Roux]

I agree with Adam moreover I don't see a real need to rename packages and what 
it would add to the project apart more efforts and confusion. So like Adam

-1, even in the long term on my side, I'm not mad about having ALL "clean"!

Jacques

Le 22/04/2015 17:13, Adam Heath a écrit :

-1, but not permanently.

If we start renaming things, then it'll become hard to port changes back and forth between release branches and trunk.  We need to reduce the number 
of outstanding branches first, before this can even be started.


On 04/22/2015 10:09 AM, Ron Wheeler wrote:

I was thinking of something like an 8 hour sprint where several people divide 
up the task and do it  and test it quickly.
divide up by application, code/XML, seed data, documentation, testing and what 
ever makes sense to get the change done in a few hours.

Ron
On 22/04/2015 5:01 AM, Pierre Smits wrote:

Ron,

Notwithstanding the appropriateness of the elements in your response,
everything done in the OFBiz project IS a community project (endeavour for
a better word).

Thank you for reiterating the invite for more collaboration. I
wholeheartedly agree and support.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:


Definitely a good idea.
Should it be done as a community project over a short period of time?
It would seem to be easier to do as a sort of global "search and replace"
followed by testing rather than modifying a piece and looking for all of
the references to that code and changing them and testing and then picking
the next piece.

Adding a JIRA sounds like the best start.

Ron

On 22/04/2015 4:36 AM, Pierre Smits wrote:


Hi all,

In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian
proposed to rename our OFBiz artefacts from "org.ofbiz" to
"org.apache.ofbiz" to bring it more inline to conventions used by other
Apache projects/products.

Does this proposal need any further discussion? Or can we move forward by
creating a JIRA and work from there?

Best regards,


Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[jira] [Closed] (OFBIZ-6272) We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do w

[Jacques Le Roux (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-6272.
--
Resolution: Invalid

We don't answer questions on Jira, please use rather user ML, see why here 
http://ofbiz.apache.org/mailing-lists.html

You will get a better support and it's more fair to share with everybody
The wider the audience the better the answers you might get

Thanks

Jacques


> We want to use ofbiz for inventory management. Suppliers are the owners of 
> the inventoy item. We want to charge inventory cost per kilo and per day. Is 
> it possible to do with existing features in ofbiz
> -
>
> Key: OFBIZ-6272
> URL: https://issues.apache.org/jira/browse/OFBIZ-6272
> Project: OFBiz
>  Issue Type: Wish
>Reporter: Nuwan Koggalahewa
>
> We want to use ofbiz for inventory management. Suppliers are the owners of 
> the inventoy item. We want to charge inventory cost per kilo and per day. Is 
> it possible to do with existing features in ofbiz



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[Jacques Le Roux]

Le 22/04/2015 00:03, Adam Heath a écrit :


On 04/21/2015 04:30 PM, Jacques Le Roux wrote:

Le 21/04/2015 23:17, Adam Heath a écrit :


On 04/21/2015 04:06 PM, Nicolas Malin wrote:

Le 21/04/2015 22:37, Adam Heath a écrit :

My commit is not breaking anything. Why remove something that is harmless?

Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original 
committer will have to do more work to re-add what was removed. 
Definitely, all commiter try to have a positive attitude to improve OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven 
would be a good improvement.


Only, Jacopo start a discussion to improve OFBiz with Gradle 
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. 
If you explain before on this thread that maven is better and why, your commit would be appreciate in its just value.


Before your commit I had not idea on gradle or maven, but with my french 
mentality now I prefer Gradle ;) (completely not subjective!)



Gradle is a non-starter.  When I saw that mentioned, I actually did do some 
comparisons.

In google, search for maven, then gradle.  See how many responses each one gets.

Then, go to trends.google.com, compare the above 2 items, and then add ant.  You might want to say "apache ant" or "apache maven", and/or add java 
terms.


Then, also do a "A vs B vs C" search, aka, "maven vs gradle vs ant".

After doing this, maven is still the right choice.





Quantity is not quality



That seems to be a bit of an abrupt statement.  Do you have anything more substantive to say?  Did you actually attempt to dig down into the 
suggestions I gave?  Or was this a knee-jerk response to my attempt at actually investigating gradle?


It was just a lack of time, I was then just leaving for few days. I always had and still have a reluctance against statistics and the world it's 
creating around us (think big data). There is of course sound aspects but I fear the humanity will suffer of it in the long term. It relates to my 
experience in the context of IA where you have mostly 2 approaches: statistical vs logical (OK they are mixing/mixed now 
http://en.wikipedia.org/wiki/Artificial_intelligence )


So yes was more a knee-jerk response :) I have still not enough time to expand and be totally clear. I hope from my digression above I guess you get 
my point.


Jacques

Jacques

Re: A person is hired by a organization then this relationship is saved in party relationship entity or employment entity?

[Jacques Le Roux]

Please use rather user ML for such questions, see why here 
http://ofbiz.apache.org/mailing-lists.html
You will get a better support and it's more fair to share with everybody

The wider the audience the better the answers you might get

Thanks

Jacques


Le 27/04/2015 10:57, ThiepLV a écrit :

Hello everybody.

I am customizing HR component, and i need to save employment relationship. I
read in nine chapter of data model 1, then this relationship is saved in
employment entity, but i seen in demo trunk of Ofbiz, then it is save in
party relationship,

Can anybody explain for me? thank your for help?



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/A-person-is-hired-by-a-organization-then-this-relationship-is-saved-in-party-relationship-entity-or--tp4667556.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

A person is hired by a organization then this relationship is saved in party relationship entity or employment entity?

[ThiepLV]

Hello everybody.

I am customizing HR component, and i need to save employment relationship. I
read in nine chapter of data model 1, then this relationship is saved in
employment entity, but i seen in demo trunk of Ofbiz, then it is save in
party relationship, 

Can anybody explain for me? thank your for help?



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/A-person-is-hired-by-a-organization-then-this-relationship-is-saved-in-party-relationship-entity-or--tp4667556.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.