from:"Adam Heath"

Re: proposal to remove cobertura and sonar from ofbiz

2016-05-26 Thread Adam Heath


Let me restate, do not remove the code coverage tool; fix the integration.

Every single time I used code coverage to design more tests, I *always* 
found bugs.  Real bugs.  And, I also found unreachable code.  I'll give 
an example:


==
public void printMap(Map value) {
  if (value == null) {
return;
  }
  String foo = safeToString(value);
  System.err.println(foo);
}

private String safeToString(Object value) {
  if (value == null) {
return null;
  }
  return value.toString();
}
==

Granted, the above unreachable code in safeToString *code* be discovered 
with deep study, but an *automated* tool makes it much easier to find.  
And, the above example is a *very* simple example. Please take a look at 
the test cases for UtilCache.


On 05/26/2016 11:26 AM, Adam Heath wrote:
Not to Pierre, but ugly and broken?  How so?  Please expand with 
concrete issues.


ps: I'm the original integrator of cobertura into ofbiz.

pps: I have a local branch that converted ofbiz to maven, and actually 
produced a runnable output.  Should I revive that?


On 05/26/2016 07:54 AM, Pierre Smits wrote:

+1 as it never got off the ground properly. We can always revisit later
when desire to do so rises again.

I use Sonar, but that is another subject.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, May 26, 2016 at 2:46 PM, Taher Alkhateeb 
<slidingfilame...@gmail.com

wrote:
Hello everyone,

As part of the refactoring process, I suggest to completely remove
cobertura and sonar from the framework. My proposal is based on the
following:

- The startup logic is more complex because of the existence of legacy
classes (Instrumenter, InstrumenterWorker, etc ...).
- No one (AFAIK) is actively using cobertura or sonar, and the 
targets in

build.xml are actually broken
- The way cobertura is integrated with ofbiz is poor and ugly
- Before integrating cobertura, ofbiz first needs a better testing
framework that allows for TDD and red-green-refactor. Otherwise, 
this whole

issue with test coverage is a moot point
- Too much complexity and legacy code in build.xml, common.xml, 
ivy.xml,

macros.xml and others. It's just really ugly

All the code that I saw for cobertura is just ugly and broken. Now it's
perfectly fine to reintroduce cobertura cleanly in the future, but I 
would
not use the existing code anyway, I would just wipe it all out and 
start

fresh.

I'm not sure whether we need to vote on this? Appreciate your feedback.

Taher Alkhateeb

Re: proposal to remove cobertura and sonar from ofbiz

2016-05-26 Thread Adam Heath

Not to Pierre, but ugly and broken?  How so?  Please expand with 
concrete issues.


ps: I'm the original integrator of cobertura into ofbiz.

pps: I have a local branch that converted ofbiz to maven, and actually 
produced a runnable output.  Should I revive that?


On 05/26/2016 07:54 AM, Pierre Smits wrote:

+1 as it never got off the ground properly. We can always revisit later
when desire to do so rises again.

I use Sonar, but that is another subject.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, May 26, 2016 at 2:46 PM, Taher Alkhateeb

Re: git commit workflow for ofbiz

2015-05-12 Thread Adam Heath

Nice. This is quite thorough. There is an option missing. SVN
committers who use git offline. In this case, their changes can be
published as primary SVN branches, for collaboration.. See OFBIZ-6271
in JIRA, and as an SVN branch, for an example.

I've read through most of what follows, and am in agreement, but I'm
dealing with hardware problems, so I need to let it sink in first.

On 05/12/2015 04:43 AM, Taher Alkhateeb wrote:

Hi everyone,

This email refers to the thread for voting to move to git (link at bottom) in
which the vote decision was to delay and elaborate on the workflow first. I am
not well versed in ASF guidelines and appreciate any help and feedback and also
please note some of the below is my opinion and not necessarily 100% factual.

## First, identified problems

1. patches can quickly be outdated if not applied quickly
2. big patches are hard to audit and not desired nor preferred and It is hard
to break big patches to smaller ones because if any of those patches is
outdated or modified then everything needs to be re-patched
3. to collaborate with other people (non-committers) freely on big features, we
need a separate branch. On svn this is lengthy and heavily controlled. If we
create a git repository then we need to constantly update from svn and merge .
Another solution is to clone the ofbiz read-only git repository but then there
are some patch issues to convert them to clean svn patches (I faced a few
including things like white space)
4. a lot of _local_ offline freedom to branch, merge, commit, share and
experiment cannot be easily done without initiating a local git repository
which triggers the other problems identified above.
6. There are too many public branches in the repositoy. Some are not active nor
complete and quite old

## Second, how does git provide solutions

So, adopting git in relation to the above mentioned problems solves them as
follows:

1. even if a patch gets outdated, I can easily recreate it by switching to a
branch that I created and has the work (e.g. OFBIZ-12345), merging everything
from trunk and re-patching
2. to allow for proper feedback by community, a pull request can replace a big
patch and that request can hold an X amount of commits each with its own message
and diff details. If changes happen to any of the commits, then reconciling that
into the code base is minor, you just branch again, do it, and merge. Furthermore,
I suggest to follow the guidelines which recommend rebasing before pushing to a
shared repository to keep a nice linear history as much as possible as shown here
- https://git-wip-us.apache.org/docs/committer-practices.html
3. large features can be done in a remote repository in github or bitbucket
with pull requests when complete and ready for review.
4. the issue is immediately solved with git which is not only local but much,
much faster
6. We do not need to pollute the main repository with branches if we decide on
a distributed model like git with remote repositories to contribute to the
project with pull requests.

## Third, proposed workflow

I will make a distinction between small features / bug fixes and large features.

### small features

Small features follow the exact same workflow that currently exists in svn. You
do your work, diff it, and attach the patch to a JIRA and request a commit from
one of the committers.

### large features

For large features usually multiple people need to collaborate on a separate
branch. Here is where git shines and the distributed model kicks in:
1. A JIRA is created for a large feature
2. The team (not necessarily having a committer) creates a remote repository
which itself may have many branches with the master branch having all the work
agreed upon and merged (actually, rebased)
3. The collaboration for this branch happens in the JIRA including discussions,
comments, and even links to the commits etc ...
4. A request is made to a committer to make a pull request from the repository
after reaching a certain milestone with consensus from the community of course
5. Here, for extra safety, the branch model may have a trunk and a develop
branches. Everything is pulled to the develop branch and trickles down to the
master branch after thorough and proper testing.

The above workflow can also adhere to the now famous Vincent Driessen git
branching model found here -
http://nvie.com/posts/a-successful-git-branching-model/

I am not sure whether this proposal is enough or correct so I appreciate your
guidance and feedback to fix whatever needs fixing.

Taher Alkhateeb

original voting thread:
http://ofbiz.markmail.org/search/?q=move%20to%20git#query:move%20to%20git+page:1+mid:p62ofojcbb3oyoi4+state:results

Re: Java 8 and functional programming in trunk

2015-05-07 Thread Adam Heath

Not a reply to Jacques, but if an absolutely java-8-only feature is 
used, be sure to update the regex in ${ofbiz.home}/macros.xml, then the 
source/target values in common.xml in the same folder.


ps: I'm fine with moving towards 1.8.  It's not a choice that we can 
make, actually.


On 05/07/2015 01:46 AM, Jacques Le Roux wrote:

Yes (lazy) consensus over vote ;)

Jacques

Re: Addons for OFBiz

2015-05-07 Thread Adam Heath




On 05/07/2015 05:48 AM, Julien NICOLAS wrote:
I see a lot of debate about adding new functionality that allow to 
improve development, compile, manage sources, merge with another 
framework, but the debate on the division of project extensions seems 
not to interest. It seems to me extremely important to facilitate 
development and therefore, ultimately, the visibility of the project 
in the developers community.


You don't understand the force behind my work then. That's the goal, to 
be able to require only just what we(Brainfood) need for a deployment.  
For reference, we don't write our frontends in any of the widget systems.


The built-in build system, the use of svn, are holding the project 
back.  It's not just about switching because of switching, but the new 
tools open the door for everything you are talking about.


So, please be patient.

Re: Addons for OFBiz

2015-05-07 Thread Adam Heath




On 05/07/2015 11:02 AM, Jacopo Cappellato wrote:

On May 7, 2015, at 5:32 PM, Adam Heath doo...@brainfood.com wrote:


... and Jacopo's own graphs have shown ofbiz in decline(namely, the number of 
commits to the project).

I completely disagree with your analysis.


Well, that's a wonderfully informative response.

Re: Addons for OFBiz

2015-05-07 Thread Adam Heath




On 05/07/2015 09:42 AM, Julien NICOLAS wrote:

Hi Adam,

I'm not talking about how to do it but to answer the question : is the 
community want to do it ?


Is the community want to maintain only a framework and not an ERP ? 
Split the project in several part.


Maven could be a solution, but before choosing a solution, we must be 
sure that it is a common decision.

Then we can define action plan on how to do it and go ahead :)



No more endless talk.  That's the status quo.  It's a dead end. That's 
how things have been going, and Jacopo's own graphs have shown ofbiz in 
decline(namely, the number of commits to the project).  It may not have 
been apparent, but when I saw that slide, my heart sank.  It was obvious 
to me, that something had to change. The downturn in the graph was long, 
it wasn't something recent.  It appeared that no one in the community 
was doing anything towards solving that problem.  What I took away from 
that is a whole new way needed to be applied.  Sorry if that ruffles 
feathers, but that's how I feal.


I'm creating actual code, in isolated branches, in the public, where 
everyone can see, with incremental, small changes(not one huge patch, 
which is the jira way).  I'm not working in isolation. Please join the 
effort.


What I am doing is actually good, I'm giving of my time to ofbiz.  I had 
been doing nothing for so long, so even if what I have started isn't 
used, I'll keep giving more time, and doing other things. Maven(and/or 
gradle, still haven't decided that) is just the start of ideas I've been 
sitting on.


ps: In the graph I mention, there are 2 large spike, outside of the 
average.  The first was because of Jacques, the second was me.  I 
cross-references the graphs from github for the same timeframe.

Re: survey: what version(s) of gradle are available on your systems?

2015-05-06 Thread Adam Heath

Gradle has to be installed before building ofbiz, so you couldn't use 
gradle to install gradle.  And I'd prefer not to embed it directly.  And 
custom compiling every single library that one uses day to day isn't 
scalable either(let's ignore gentoo).  And some like to only install 
what is available in the stable release of whatever OS they are using.  
Hence the question.


On 05/06/2015 05:25 AM, Michael Brohl wrote:

Hi Adam,

I don't know much about Gradle and maybe I misunderstand the survey, 
but isn't it platform independent and can be installed in the desired 
version on every Java supported system? 
(http://gradle.org/docs/current/userguide/installation.html)


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 05.05.15 um 18:42 schrieb Adam Heath:
I'm considering investigating gradle, but have discovered that it's 
not even available for debian wheezy(nor in backports).  So, I 
currently interested in what other people have available for 
installation.


In jessie, the version of gradle is 1.5.

Re: svn commit: r1678076 [2/3] - in /ofbiz/trunk/applications/product/config: ProductEntityLabels.xml ProductErrorUiLabels.xml

2015-05-06 Thread Adam Heath

Except that byte site is not equal to in-memory site.  Java doesn't use 
utf-8 internally to store character data.  I believe each char is 4 
bytes in size.  Then you have all the extra string objects with their 
char array pointing into the large shared blob.


On 05/06/2015 03:57 PM, Michael Brohl wrote:

- Posting in dev because I have no permission for commits -

Yes, thought about that recently when doing the german translations.

The drawback is that you have no overview about missing translations. 
It's easy to go through the files as they are now and add missing 
translations.


I quick checked the size of the *UILabels.xml files, they are about 
10.2 megs for all modules - not too much for today's servers with 
gigabytes of RAM.


So I think it is not worth the effort...

Michael

Am 06.05.15 um 21:50 schrieb Adam Heath:

Well, hmm.  Nothing at all wrong with this change, but I'd like to
discuss the pattern.

So, the way alternative languages are implemented, is that if I am
only concerned with *one* language, *all* languages have to be loaded
in memory.  Wouldn't it make more sense to split all these files into
per-language-specific versions, so that only languages that an
end-customer needs would have to be loaded into memory?

Then, the name of the file ends up using the very same fallback
mechanism for normal *.properties resources.

On 05/06/2015 02:35 PM, chr...@apache.org wrote:

Modified:
ofbiz/trunk/applications/product/config/ProductEntityLabels.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/config/ProductEntityLabels.xml?rev=1678076r1=1678075r2=1678076view=diff 

== 



--- ofbiz/trunk/applications/product/config/ProductEntityLabels.xml
(original)
+++ ofbiz/trunk/applications/product/config/ProductEntityLabels.xml
Wed May  6 19:35:24 2015
@@ -388,6 +388,7 @@
  value xml:lang=zh-TWååº«/value
  /property
  property key=GoodIdentificationType.description.GOOGLE_ID
+value xml:lang=deGoogle Id/value
  value xml:lang=enGoogle Id/value
  value xml:lang=itCodice Google/value
  value xml:lang=jaGoogle ID/value
@@ -396,6 +397,7 @@
  value xml:lang=zh-TWè°·æç¨æ¶å/value
  /property
  property key=GoodIdentificationType.description.ISBN
+value xml:lang=deISBN/value
  value xml:lang=enISBN/value
  value xml:lang=esISBN/value
  value xml:lang=frISBN/value

Re: survey: what version(s) of gradle are available on your systems?

2015-05-06 Thread Adam Heath


apt-get install gradle
yum install gradle
emerge gradle

Let's assume downloading random things that haven't been vetted against 
one's OS of choice is frowned upon by the powers that be at a particular 
company.  It's a matter of not having to understand each and every 
single downloadable software package, and assuming that the OS developer 
can integrate it more properly.


On 05/06/2015 10:19 AM, Taher Alkhateeb wrote:

Hi Adam,

Maybe I do not understand your point exactly, but I find it very trivial to 
install gradle with the following steps on _any_ platform:

1) Download the latest binary gradle release from their website. The current 
version is 2.4
2) Set $JAVA_HOME to the correct java version on your computer
3) add $GRADLE_HOME/bin to your path
and enjoy!

I hardly see a problem in lack of gradle release as a Debian package. It 
definitely exists for Ubuntu and Linux Mint which combined takes most of the 
linux users base. Again maybe I missed something in the thread?

Taher Alkhateeb

- Original Message -

From: Adam Heath doo...@brainfood.com
To: dev@ofbiz.apache.org
Sent: Wednesday, 6 May, 2015 5:57:56 PM
Subject: Re: survey: what version(s) of gradle are available on your systems?



On 05/06/2015 09:52 AM, Jacopo Cappellato wrote:

On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote:


Gradle has to be installed before building ofbiz, so you couldn't use gradle to 
install gradle. And I'd prefer not to embed it directly.

The Groovy project has some scripts for this:

https://github.com/apache/incubator-groovy/blob/master/gradlew

To restate, the reason I don't want maven, gradle, or ant embedded into
ofbiz, is that there has been, um, issues, when it comes to using
eclipse, and other tools, that *also* embed ant.

On this same vein, we don't embed the approved version of the jdk into
ofbiz either.

With maven, gradle, and ivy, and more modern systems, the target has
been to move away from embedding dependencies. It's even a best
practice from ASF, as it then reduces the load on mirrors. So, take it
to the logical conclusion, and don't embed the build system either.

Re: survey: what version(s) of gradle are available on your systems?

2015-05-06 Thread Adam Heath




On 05/06/2015 10:34 AM, Jacopo Cappellato wrote:

On May 6, 2015, at 4:57 PM, Adam Heath doo...@brainfood.com wrote:



On 05/06/2015 09:52 AM, Jacopo Cappellato wrote:

On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote:


Gradle has to be installed before building ofbiz, so you couldn't use gradle to 
install gradle.  And I'd prefer not to embed it directly.

The Groovy project has some scripts for this:

https://github.com/apache/incubator-groovy/blob/master/gradlew

To restate, the reason I don't want maven, gradle, or ant embedded into ofbiz, 
is that there has been, um, issues, when it comes to using eclipse, and other 
tools, that *also* embed ant.

On this same vein, we don't embed the approved version of the jdk into ofbiz 
either.

With maven, gradle, and ivy, and more modern systems, the target has been to 
move away from embedding dependencies.  It's even a best practice from ASF, as 
it then reduces the load on mirrors.  So, take it to the logical conclusion, 
and don't embed the build system either.

Groovy doesn't embed gradle, this is the reason I was pointing you to that 
example.

Here are the notes from Groovy:

==
At the top directory of your unpacked source, you need to run the command:
 gradle
This sets up the Gradle wrapper and from then on you just need the `gradlew` 
command instead of `gradle`.
==


That's bad too.  So when the embedded script/docs in the checkout become 
invalid, due to the external location having been changed(aka, a project 
has to move away from codehaus, because they are out of money), then all 
previous versions that have already shipped will no longer work.


These kind of docs should be listed separate along side the actual 
download/checkout process.

Re: survey: what version(s) of gradle are available on your systems?

2015-05-06 Thread Adam Heath




On 05/06/2015 12:10 PM, Jacopo Cappellato wrote:

On May 6, 2015, at 6:09 PM, Adam Heath doo...@brainfood.com wrote:


That's bad too.

By the way, Adam, you're as bitter as an old spinster today! :-)


Just express issues we've had interacting with clients.  It's all about 
placing blame.  If I have to download source and compile myself, I have 
to take on that mantle.  However, if the OS has done it, I can shift the 
target away from me.


But placing blame sounds bad.  So, let's rephrase.

Random upstream pre-compiling source, may not fully understand the 
policies required by $chosen_OS at $company.  So, use the version of 
$upstream already available for $chosen_OS.  This is called using a 
support contract.


I thought this was just a simple question when I asked it initially. :(

Re: survey: what version(s) of gradle are available on your systems?

2015-05-06 Thread Adam Heath




On 05/06/2015 09:52 AM, Jacopo Cappellato wrote:

On May 6, 2015, at 4:45 PM, Adam Heath doo...@brainfood.com wrote:


Gradle has to be installed before building ofbiz, so you couldn't use gradle to 
install gradle.  And I'd prefer not to embed it directly.

The Groovy project has some scripts for this:

https://github.com/apache/incubator-groovy/blob/master/gradlew


To restate, the reason I don't want maven, gradle, or ant embedded into 
ofbiz, is that there has been, um, issues, when it comes to using 
eclipse, and other tools, that *also* embed ant.


On this same vein, we don't embed the approved version of the jdk into 
ofbiz either.


With maven, gradle, and ivy, and more modern systems, the target has 
been to move away from embedding dependencies.  It's even a best 
practice from ASF, as it then reduces the load on mirrors.  So, take it 
to the logical conclusion, and don't embed the build system either.

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-05 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528535#comment-14528535
 ] 

Adam Heath commented on OFBIZ-6271:
---

Um, do you fully understand maven?  This is not the right approach.

Maven has a distribute mirror network; your suggestion of an ofbiz-hosted 
private repo would preclude that.

Ofbiz is no different than any other big project, why do you think INFRA would 
allow us to host this repo?

When defining a dependency in a pom, it's possible to tell maven to *not* pull 
in *any* transitive deps, or to override the version of a dep, or to exclude 
just one transitive dep.

Also, a private external repo is not needed.  I already have the 
currently-checked-in jar files being used, without defining a top-level 
repository in a pom.  Plus, having a top-level repository defined is very 
much bad form.

There are so many things wrong with your paragraph, do you actually understand 
what maven can actually do?

 build management with maven
 ---

 Key: OFBIZ-6271
 URL: https://issues.apache.org/jira/browse/OFBIZ-6271
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
 Attachments: console.log


 This is a new build system; the primary goal will be to not require any 
 changes to existing ofbiz layouts(for backwards compatibility, at least 
 initially).
 These pom.xml files are completely new; the existing build.xml infrastructure 
 will continue to exist.  The existing build.xml will never call into 
 maven(which is what processes the pom.xml), and maven will never call into 
 build.xml either.
 I have already committed a working pom.xml for the top level, and 
 framework/start.  Shortly, I will be adding framework/base and 
 framework/entity, but into this branch.



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

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-05 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528552#comment-14528552
]

Adam Heath commented on OFBIZ-6271:
---

Hahaha. That guy is an idiot. Seriously. Don't blame the tool for bad
developers.

I gave a talk at ApacheCon just recently, showing how to use ofbiz and docker
together. Do you think I just randomly download stuff from the internet, every
single time? I don't, because I understand the point of trusted build, and
security.

Docker itself is really really really bad for security on downloaded image
layers. It has a message that says verified when it has fetched remote data,
but the data was retrieved over http, and the hashsum in the metadata is *not*
checked. All that verified message means is that the metadata was
syntactically correct!

I rebuild my base image layers using debootstrap(I don't trust the debian or
ubuntu image flavors). This is all based on apt-get stuff. The only thing I
download is wp-cli, but that's not being fully utilized, and I don't actually
download it automatically(it's a manual step, so could be verified by the
developer).

So, I've taken this tool(docker), and used the parts that are good, and not the
parts that are bad.

ps: This is not a rant at you, Jacques.

pps: I'm close to having my docker+ofbiz scripts ready. I have a repo already
with most of my stuff on github, it just needs a bit of documentation.

build management with maven
---

Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log

This is a new build system; the primary goal will be to not require any
changes to existing ofbiz layouts(for backwards compatibility, at least
initially).
These pom.xml files are completely new; the existing build.xml infrastructure
will continue to exist. The existing build.xml will never call into
maven(which is what processes the pom.xml), and maven will never call into
build.xml either.
I have already committed a working pom.xml for the top level, and
framework/start. Shortly, I will be adding framework/base and
framework/entity, but into this branch.

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

Re: Vote: move to git.

2015-05-05 Thread Adam Heath

That's my point as well.  These most recent votes have not had concrete 
actions attached to them.  Without a concrete plan, any kind of +# vote 
is not definitive; a +1 could mean anything in these cases.


I chose +0 instead of -0 or -1, as I do believe git is the right 
approach, but we need more time to figure out what will change.


* How does the submit-as-patch workflow change with Jira(still allow for 
patch, but also allow for fork(clone)/push/merge-request)?


* How to deal with empty directories(svn allows them, git does not)?

* Do we try to support signed commits?

* Should Acked-By, Signed-off-By, etc be adopted as pseudo tags(see the 
linux-kernel's use of git)?


* Use pseudo tags for Jira issues?

* What about CLA for all those fork/clone above?

* Who are the Lieutenants, and who is the Dictator(the linux kernel way, 
not a suggestion for us)?


* What about line-ending changes?  Git has a feature(.gitattributes, 
.git/info/attributes) that allow for many different flags to be set; 
what would those values be?


These are just off the top of my head.

On 05/05/2015 08:06 AM, Jacopo Cappellato wrote:

-1

not because I don't like Git or because I don't think it wouldn't be a good fit 
for OFBiz; the reason for my negative vote is that in the vote there is no 
mention to the workflow the project will adopt; at the ASF there are some 
limitations due to Infrastructure and/or license/legal reasons and not all the 
way Git could be used are allowed (for example I don't think we will be allowed 
to accept Pull Requests from GitHub).

There are several ASF projects that have switched to Git 
(https://git-wip-us.apache.org/repos/asf ) but the workflows they have adopted 
are different from the ones implied by some of the comments in this mailing 
list; see for example:
http://karaf.apache.org/index/community/contributing.html (this is very similar 
to our current svn-based workflow)
http://wiki.apache.org/hadoop/GitAndHadoop (patch based contributions)

I have mentioned a few times that until someone will take time to review what 
others do and what can be done @ASF with Git and come up with a proposal for 
OFBiz, my vote will be negative because it doesn't make any sense to vote for a 
tool or the other.

Jacopo

On May 5, 2015, at 5:01 AM, Hans Bakker h.bak...@antwebsystems.com wrote:


As the discussions seem to end, can i propose a vote?

The question : should we convert the master SVN repository of Apache OFBIz to a 
GIT version?
The possible answers are according the apache voting guidelines at: 
https://www.apache.org/foundation/voting.html

*

   +1: 'Yes lets do it'

* +0: 'I don't feel strongly about it, but I'm okay with this.'
*

   -0.5: 'I don't like this idea, but I can't find any rational
   justification for my feelings.'

*

   ++1: 'Wow! I like this! Let's /do/ it!'

*

   -0.9: 'I /really/ don't like this, but I'm not going to stand in the
   way if everyone else wants to go ahead with it.'

*

   +0.9: 'This is a cool idea and i like it, but I don't have time/the
   skills necessary to help out.'

* -1 'I do not want this.'


Votes will be possible for one week from today.

Regards,
Hans

On 20/04/15 11:38, Hans Bakker wrote:

As discussed at apachecon in Austin, i propose to switch from svn to git for 
the ofbiz repository. The main reason being that all major contributors are 
using git and contributions are cumbersome, further, git allows for better 
branching and merging.

Regards,
Hans

survey: what version(s) of gradle are available on your systems?

2015-05-05 Thread Adam Heath

I'm considering investigating gradle, but have discovered that it's not 
even available for debian wheezy(nor in backports).  So, I currently 
interested in what other people have available for installation.


In jessie, the version of gradle is 1.5.

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-04 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526790#comment-14526790
]

Adam Heath commented on OFBIZ-6271:
---

What Jacques is asking about, are all the other non-build targets in the
build.xml. Aka, load-demo, start, etc.

I've been struggling(not with the implementation, but with the where) on how to
deal with those targets in a maven world. Maven is a *build system*, while
ant's build.xml is just a series of commands(targets) that have names and do
something, and might also require other things to run first(depends).

There really isn't a simple way to just add callable commands to maven's
pom.xml structures. I've played with making each called target from ant by a
non-default-activated profile. I then attempted to inline each target body
using maven-antrun-plugin, but that was ugly. I then have switched to moving
the special targets to a separate external build.xml snippet, which is then
called by both ant and maven.

This latter method actually seems like it would be generally useful, even
without maven in use. Aka, the top-level build.xml, and all the internal
component build.xml, should just be for building/deploying ofbiz. The extra
cli targets at the top-level should be in a separate location(similar to how we
have that top-level tools folder).

For backwards compatibility, top-level would need to call the external targets
for a time being.

Does that make sense?

build management with maven
---

Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log

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

Re: svn commit: r1677597 - in /ofbiz/trunk: .classpath LICENSE framework/base/lib/commons/commons-cli-1.2.jar macros.xml

2015-05-04 Thread Adam Heath



On 05/04/2015 12:29 PM, Jacopo Cappellato wrote:

On May 4, 2015, at 6:36 PM, Adam Heath doo...@brainfood.com wrote:


Why are antlr and asm removed, but not mentioned in the log?

Antlr and asm jars were not removed, just the classpath entries for the 
groovy.class.path path id: the classes are included in the groovy-all jar; one 
of the entries (commons-cli-1.0.jar) was old and was pointing to an invalid jar.


But the commit log didn't say that.

Re: Vote: move to git.

2015-05-04 Thread Adam Heath

This may be the nail in the coffin, at least for now, but +0, needs more 
discussion/planning.  I've been using git-svn for longer than most with 
ofbiz, and would really love it if we were already using git, but it's 
just too soon.


Just because git is decentralized, doesn't mean that there is no longer 
a center. *Someone* has to be pulling/merging all the branches, and who 
would step up to that plate?  Who would want to take on the mantel?  I 
don't think we as a community are ready to require that of someone.


Of course, we need to start planning for this eventuality, imho, but we 
are still a long ways off.


ps: I, and others, will continue to use git in our upstream svn 
interactions, as that seems to work well enough


pps: as per Adrian's vote call, there is nothing actionable here.

On 05/04/2015 10:01 PM, Hans Bakker wrote:

As the discussions seem to end, can i propose a vote?

The question : should we convert the master SVN repository of Apache 
OFBIz to a GIT version?
The possible answers are according the apache voting guidelines at: 
https://www.apache.org/foundation/voting.html


 *

   +1: 'Yes lets do it'

 * +0: 'I don't feel strongly about it, but I'm okay with this.'
 *

   -0.5: 'I don't like this idea, but I can't find any rational
   justification for my feelings.'

 *

   ++1: 'Wow! I like this! Let's /do/ it!'

 *

   -0.9: 'I /really/ don't like this, but I'm not going to stand in the
   way if everyone else wants to go ahead with it.'

 *

   +0.9: 'This is a cool idea and i like it, but I don't have time/the
   skills necessary to help out.'

 * -1 'I do not want this.'


Votes will be possible for one week from today.

Regards,
Hans

On 20/04/15 11:38, Hans Bakker wrote:
As discussed at apachecon in Austin, i propose to switch from svn to 
git for the ofbiz repository. The main reason being that all major 
contributors are using git and contributions are cumbersome, further, 
git allows for better branching and merging.


Regards,
Hans

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-04 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527418#comment-14527418
]

Adam Heath commented on OFBIZ-6271:
---

Yes, no, both.

I want maven to be have the ability to call load-demo, create-tenant, etc. I
want ant to be able to call into maven, for the actual build.

So, as a plan, the special non-build targets in the top-level build.xml get
extracted out, to be placed into a single file, shared by both build systems.
Then, both systems can call into this shared file.

For a time, both build systems are maintained in parallel, with mostly
identical features. This to give developers a time to acclimate.

After a time, switch ant to call into maven for the build targets, but still
leave the targets in build.xml. Add a deprecation message.

Even more time, remove the build.xml from all of ofbiz.

build management with maven
---

Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log

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

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-04 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527421#comment-14527421
]

Adam Heath commented on OFBIZ-6271:
---

I also struggled with moving the list of tasks from top-level build.xml into
some piece of compiled code. However, those top-level tasks are really short
scriptlets, batch files, shell scripts, whatever. So, making full-on java code
doesn't really work either, and would be harder to maintain(in theory).

This is still a bit of an open-ended issue.

And, honestly, now that I am here, I'm actually kind of curious about that
other elephant, aka, gradle.

build management with maven
---

Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log

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

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-05-01 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524204#comment-14524204
]

Adam Heath commented on OFBIZ-6271:
---

Ok, quick update.

Building a single component is not possible, by going into
applications/product, and doing a mvn clean compile. However, there is a
maven way to do it:

==
mvn -pl org.apache.ofbiz:ofbiz-product compile
==

Doing this from the top-level will then deal with just the list of
artifacts(you can give several). Also, you can use -am which will also run
the goals against everything the project list *depends* on, which is actually
way cool.

==
mvn -am -pl org.apache.ofbiz:ofbiz-product clean package
==

The above command will not only deal with product, but base, entity, security,
service, common, content, party, webapp. Note, that widget and entityext(and
others) are not included.

build management with maven
---

Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-30 Thread Adam Heath



On 04/30/2015 12:22 AM, Jacopo Cappellato wrote:

On Apr 29, 2015, at 9:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

avalon-framework(4.2.0 in ofbiz) is no longer available. avalon.apache.org is 
closed(!).

This was introduce with 
http://svn.apache.org/viewvc?view=revisionrevision=746645 and is no longer used


Avalon is a dependency for FOP.


jdom in ofbiz is 1.1, but 2.0.6 is available.

Only JDOMException is used in images related classes


Several jars have dependencies on jdom: Freemarker, Rome, Ant Contrib, Xstreams

Jacopo


Neither of these should be required by ofbiz, but should be 
auto-installed by a dependency resolver.  Maven brings that to the table.

Re: move to git.

2015-04-29 Thread Adam Heath



On 04/29/2015 02:26 PM, Jacques Le Roux wrote:
Related to this thread but not with previous discussions, see how 
Github is used at the ASF https://wiki.apache.org/commons/UsingGIT ; 
notably for Applying Pull Requests (for svn based components)


Jacques


Yeah, that's actually troubling.  The recommended procedure for merging 
git changes is to apply a patch.  There is no recommendation on how to 
attribute the original contributor.


The next section that talks about merging github into projects that use 
git also doesn't mention anything about CLA of the code being merged 
either.  But at least the attribution is maintained automatically.

off-topic: Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-29 Thread Adam Heath



On 04/29/2015 02:17 PM, Jacques Le Roux wrote:

[snip]



Finally Maven proved to be useful :)  [snip]


Everything always has at least one use; physical things can be paper 
weights; virtual things can take up disk space.


jk

Re: Milestone redux: Re: svn commit: r1676613 - in /ofbiz/branches/OFBIZ-6271: assembly/LICENSE+NOTICE.xml framework/service/pom.xml pom.xml poms/assembly/ poms/assembly/LICENSE+NOTICE.xml poms/compon

2015-04-29 Thread Adam Heath



On 04/29/2015 01:34 AM, Hans Bakker wrote:

ok is working fine on Ubuntu 14.04 and maven 3.0.5



Thanks Hans.  It's nice knowning one's code is at least working for one 
other person.


ps: I do remember that initial report of it not working on windows; I 
still haven't had time to try it there myself.

Re: [jira] [Issue Comment Deleted] (OFBIZ-6271) build management with maven

2015-04-29 Thread Adam Heath

I assume you deleted it because you realized you hadn't yet updated the 
branch?  Line 34 in framework/start/pom.xml is different in the latest 
version of that file.


On 04/29/2015 12:53 PM, Adrian Crum (JIRA) wrote:

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

Adrian Crum updated OFBIZ-6271:
---
 Comment: was deleted

(was: Windows 8.1:

[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-start:jar:TRUNK
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-compiler-plugin is missing. @ 
org.apache.ofbiz:ofbiz-parent:TRUNK, C:\Develop\ofbiz\pom.xml, line 58, column 
15
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-jar-plugin is missing. @ 
org.apache.ofbiz:ofbiz-start:[unknown-version], 
C:\Develop\ofbiz\framework\start\pom.xml, line 34, column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 58, column 15
[WARNING] The expression ${artifactId} is deprecated. Please use 
${project.artifactId} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING]
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] ofbiz-parent
[INFO] ofbiz-start
[INFO]
[INFO] 
[INFO] Building ofbiz-parent TRUNK
[INFO] 
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-parent ---
[INFO]
[INFO] 
[INFO] Building ofbiz-start TRUNK
[INFO] 
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-start ---
[INFO] Deleting C:\Develop\ofbiz\framework\start\build\lib
[INFO] Deleting C:\Develop\ofbiz\framework\start\build\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
ofbiz-start ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] Copying 7 resources
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ofbiz-start ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. 
build is platform dependent!
[INFO] Compiling 10 source files to 
C:\Develop\ofbiz\framework\start\build\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
ofbiz-start ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
C:\Develop\ofbiz\framework\start\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
ofbiz-start ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ofbiz-start ---
[INFO] Tests are skipped.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ ofbiz-start ---
[INFO] Building jar: C:\Develop\ofbiz\framework\start\build\lib\ofbiz.jar
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (default) @ ofbiz-start ---
[INFO] Executing tasks
  [copy] Copying 1 file to C:\Develop\ofbiz
[INFO] Executed tasks
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] ofbiz-parent ... SUCCESS [  0.203 s]
[INFO] ofbiz-start  SUCCESS [  2.855 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 3.214 s
[INFO] Finished at: 2015-04-29T18:49:01+01:00
[INFO] Final Memory: 15M/219M
[INFO] 
)


build management with maven
---

 Key: OFBIZ-6271
 URL: https://issues.apache.org/jira/browse/OFBIZ-6271
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor

This is a new build system; the primary goal will be to not require any changes 
to existing ofbiz layouts

[jira] [Commented] (OFBIZ-6271) build management with maven

2015-04-29 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519855#comment-14519855
 ] 

Adam Heath commented on OFBIZ-6271:
---

THANK YOU ADRIAN!

So, this seems to work.  All those scary warnings at the top about the 
systemPath are normal; maven does *not* like using pre-installed files, and it 
doesn't know that ${user.home} ends up being in the local checkout.  The 
warnings will go away once the jars are actually downloaded.

 build management with maven
 ---

 Key: OFBIZ-6271
 URL: https://issues.apache.org/jira/browse/OFBIZ-6271
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
 Attachments: console.log


 This is a new build system; the primary goal will be to not require any 
 changes to existing ofbiz layouts(for backwards compatibility, at least 
 initially).
 These pom.xml files are completely new; the existing build.xml infrastructure 
 will continue to exist.  The existing build.xml will never call into 
 maven(which is what processes the pom.xml), and maven will never call into 
 build.xml either.
 I have already committed a working pom.xml for the top level, and 
 framework/start.  Shortly, I will be adding framework/base and 
 framework/entity, but into this branch.



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

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

2015-04-29 Thread Adam Heath

What you are looking to define here is relativeness.  If a non-absolute 
path is found in a file, then resolve the full path against the absolute 
path of the file it was found in.


I'm for this, btw.

On 04/29/2015 05:02 AM, Pierre Smits wrote:

Currently many widgets are referenced in other widgets (e.g. forms, etc) by
incorporating the location to the widget.

e.g. In a screen file following the following can occur:

- include-form name=form1
location=component://componentName/widget/forms/Forms.xml/
- include-screen name=Screen1
location=component://componentName/widget/AnotherScreens.xml/
- include-menu name=Menu1
location=component://componentName/widget/Menus.xml'/
- script  location=component://componentName/scripts/script.groovy/

And in controller.xml:

- view-map name=optionsetting type=screen page=
component://order/widget/OrderEntryOrderScreens.xml#OptionSettings/
- event type=simple path=
component://commonext/script/org/ofbiz/setup/SetupEvents.xml invoke=
createProductStoreWithDefaultSetting/

And in the ofbiz-component.xml file of the component:


- entity-resource type=model reader-name=main loader=main location
=entitydef/entitymodel.xml/
- entity-resource type=eca reader-name=main loader=main location=
entitydef/eecas.xml/
- entity-resource type=data reader-name=seed loader=main location=
data/WorkEffortTypeData.xml/



However, having to type the location path everywhere is quite tedious and
error prone.

Couldn't it be possible to add a layer of flexibility, so that widgets in
the same component can be referenced in an easier way? Like for screens:

- include-form name=form1 location=Forms.xml/
- include-screen name=Screen1 location=AnotherScreens.xml/
- include-menu name=Menu1 location=Menus.xml'/
- script  location=script.groovy/

And for controller.xml:

- event type=simple path=SetupEvents.xml invoke=
createProductStoreWithDefaultSetting/
- view-map name=optionsetting type=screen page=
OrderEntryOrderScreens.xml#OptionSettings/

And for ofbiz-component.xml:


- entity-resource type=model reader-name=main loader=main location
=entitymodel.xml/
- entity-resource type=eca reader-name=main loader=main location=
eecas.xml/
- entity-resource type=data reader-name=seed loader=main location=
WorkEffortTypeData.xml/


Of course, such would require that the default paths to the various widget
locations must be known on the moment of loading the component (especially
the entitymodel and ecas/secas - I migt be forgetting some).
This could be done by references in a record in the SystemProperty entity,
and as a fallback the system.properties file in the component.

Such an improvement would, I believe, make both development of new
applications and migration regarding future framework changes easier.

What do you think?

Best regards,


Pierre Smits

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-29 Thread Adam Heath



On 04/29/2015 01:39 AM, Jacques Le Roux wrote:

Le 28/04/2015 16:42, Adam Heath a écrit :


On 04/28/2015 03:39 AM, David E. Jones wrote:
+1 - with the clarification that to me begin replacing implies a 
PoC effort in a branch.



I just saw this thread and need a little time to think over the best 
approach, but off the top of my head it would look something like:


- add the moqui-framework-version.jar file and all dependent jars 
to a component directory under ofbiz/framework (these could go in 
the base or common components, but might be best separate for 
clarity); if needed update jars currently used in OFBiz where an 
older version is used (don't know if this is the case for any, 
mention for the sake of completeness)


There are 2 separate items in this bullet point.  I'll talk about the 
second, updating jar versions.


HAHAHAHAHAHAHA!

I have discovered that ofbiz is using hc.apache.org(HttpClient), and 
commons-httpclient.  The former is the newer, rewritten, 
rearchitected, replacement for the latter.


hc.apache.org(HttpClient) was introduced with 
https://issues.apache.org/jira/browse/OFBIZ-3180. I also created 
https://issues.apache.org/jira/browse/OFBIZ-4430

Never got a chance to seriously work on it



The rest of the versioned jars are just as bad.


Which ones?

Jacques



org.springframework seems to be at some 4.x version.  Ofbiz has 3.1.

birt is using date-based jars from 2010 and 2013.

ant is at 1.9.4, we have 1.9.0.

avalon-framework(4.2.0 in ofbiz) is no longer available. 
avalon.apache.org is closed(!).


jdom in ofbiz is 1.1, but 2.0.6 is available.

junit is 4.10, but 4.12 is available.

resolver in base is 2.9.1, resolver in birt is 1.2.0(with a date), but 
these may be different libs.


serializer is base is 2.9.1, serializer in birt is 2.7.1(with a date).

httpunit was last release in May 2008; xpp3 was last released in 
November 2006.


I could go on.  This is based on reading the top-level pom.xml in 
OFBIZ-6271, then doing some quick google searches and finding the 
download pages.


There are also many jars that have no version at all in their name.

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

2015-04-28 Thread Adam Heath

1) I'm using maven 3.0.4.  I don't use the latest and greatest of 
everything.  We(Brainfood) are currently utilizing Debian Wheezy, with 
backports, as are release platform target.


2) If I rm -rf $HOME/.m2/, I get the same problem.  Issue confirmed.

Thanks guys.  I should have done step 2 before announcing.

On 04/27/2015 11:57 PM, Ron Wheeler wrote:
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.

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-28 Thread Adam Heath



On 04/28/2015 03:39 AM, David E. Jones wrote:

+1 - with the clarification that to me begin replacing implies a PoC effort 
in a branch.


I just saw this thread and need a little time to think over the best approach, 
but off the top of my head it would look something like:

- add the moqui-framework-version.jar file and all dependent jars to a 
component directory under ofbiz/framework (these could go in the base or common 
components, but might be best separate for clarity); if needed update jars currently 
used in OFBiz where an older version is used (don't know if this is the case for any, 
mention for the sake of completeness)


There are 2 separate items in this bullet point.  I'll talk about the 
second, updating jar versions.


HAHAHAHAHAHAHA!

I have discovered that ofbiz is using hc.apache.org(HttpClient), and 
commons-httpclient.  The former is the newer, rewritten, rearchitected, 
replacement for the latter.


The rest of the versioned jars are just as bad.


- add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui 
uses this for various things); this would contain the Moqui tools components 
(with the Tools and System apps) so we have a UI to look at Moqui internals, 
OFBiz data, etc


Do each of the separate moqui sub-tools need their own runtime folder?  
How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, 
runtime/$tool2, etc?



- either in the Moqui runtime directory or as an OFBiz component add a 
webroot webapp; Moqui is designed to run in a single webapp, and I'd 
recommend this be separate from the existing OFBiz webapps for now; when this webapp 
loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy 
it


Wait.  The webapp initializes the context factory?  There isn't a 
separate way to do this?  Does that mean Moqui is tied to a webapp? What 
kind of webapp?  I hope it isn't servlets.


You mention it as weboot.  Does that mean it runs at the root of the 
webserver?  This might be a noob question.



- because initializing Moqui when the webroot webapp starts may not be 
adequate, make sure the Moqui static init stuff is in place and working (in the 
Moqui.java class)
Ah.  So that means that means that moqui-component needs a container 
definition.  Ignore the above then.


I have never liked that ofbiz startup delays initialization of certain 
components until they are magically called from some random bit of java 
code, aka, the web container starting up.



- run my little templates to transform current OFBiz data model XML files into 
Moqui ones and put those in a Moqui component in the Moqui runtime directory


Sorry for the noob question, but does that mean that both ofbiz 
entityengine and moqui could talk to the same database backend(s), at 
the same time?



This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the 
real PoC of either a thunk layer as Adrian proposed, probably accessing the 
statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes 
are statically initialized, or using the more dynamic initialization through the Moqui 
webroot webapp.


Actually, a bit simpler, would be to just see if moqui can be added to 
the classpath, and loaded, before translating any datamodels. Once that 
is done, then have a method that translates the model definitions 
dynamically at load time, so that they are always kept in sync.


Once this has proven, then that dynamic translation can be removed, and 
the output of it can become the new static definition of the model.


The reason I suggest this way, is so that hot-deploy components(or other 
file modifications) that alter the entity definitions 
dynamically(extends-entity, whole new entity definitions) can also work 
transparently.



For those who want a brief introduction to some of the differences between OFBiz 
Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? 
section at:

http://www.moqui.org/framework/index.html

That is an older document and isn't meant to be any sort of exhaustive list of 
the features of Moqui versus the features of OFBiz Framework, but gives a 
general idea about how some of the similar tools are different.

For those who want to dive a bit deeper the Tutorial may be helpful:

http://www.moqui.org/framework/docs/Tutorial.html

For those who want to dive in neck deep the Making Apps with Moqui book is 
the more exhaustive reference to Moqui (though about 8 months old now and there are many 
new features, summarized in the ReleaseNotes.txt file for those curious):

http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt

I would be happy to participate in this effort... if nothing else should be an 
interesting technical diversion.

-David

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

2015-04-28 Thread Adam Heath



On 04/28/2015 02:31 AM, Jacques Le Roux wrote:

Le 27/04/2015 16:52, Adam Heath a écrit :

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. 


Yikes, that would be a Maven only solution (no Ant) blocker :/



If each component were released separately, then it becomes a non-problem.

I haven't yet given up on this, tho.

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

2015-04-28 Thread Adam Heath

On 04/28/2015 03:16 AM, Jacques Le Roux wrote:

Le 24/04/2015 17:01, Adam Heath a écrit :

On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:

On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote:

src/main/java/org/ofbiz/product/
src/main/minilang/org/ofbiz/product/
src/main/groovy/...
src/test/java/org/ofbiz/product/
I haven't yet gotten to integrating a groovy compiler plugin, I see
only one .groovy in framework/service/src, for the entire project.
When I proposed this I was also thinking about to move the groovy
(data preparation) scripts that are currently under WEB-INF/actions
folders; most of them could be used in non web applications.

Hmm, right. Good idea. We(Brainfood) would love it if all the
action code was turned into services. But, even in that case,
src/main/scripts would be used, as I think src/main/groovy is for
groovyc. I'll find out today if that is the case.

So you would like to suppress the concept of event? What about the
validation and conversion with the map-processor (only in
simple-method) and the convenience of events in some cases?
https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService

Way way way too much business logic is embedded and tied to events that
*require* javax.servlet. This makes it hard to use ofbiz soley as a
backend api layer.

Not all servlet code can be removed. Aka, the aforementioned parameter
validation/conversion logic. However, all such input methods should
just pass the munged data stream(s) to the service engine, for
processing. This includes the ShoppingCart code.

Re: move to git.

2015-04-28 Thread Adam Heath



On 04/28/2015 03:39 AM, Jacques Le Roux wrote:

Le 25/04/2015 01:14, Adam Heath a écrit :


On 04/23/2015 06:00 PM, David E. Jones wrote:
An FYI for all committers: create an account on GitHub (if you don't 
already have one) and add your @apache.org email address to it, and 
within a few hours you'll show up in the contributor graphs. I tried 
this and am now showing up there:


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

If nothing else it's entertaining, I had no idea that I had this 
volume of commits since OFBiz joined the ASF (750k lines added, 135k 
lines removed; note that changes to lines show up in both counts).


Come on, everyone.  It's a competition!  See if you can beat Jacopo!


No chances, guys, you are far behind me :D



I was waiting for you to do that; I already new you were way out in 
front.  I saw it last night.  You're a machine(I mean that in the nicest 
way).




Useless metrics are fun sometimes.  Number of commits, number of 
lines added/removed, don't really mean anything.  I've seen stupid 
code that had the same 30 lines cut and pasted 20 times, instead of 
making a helper method, and of course a single line per commit can 
also inflate numbers.


Yes, hence my comments about quality and quantity, big data and our 
world ;)



But, it's fun to play with gui graph libraries.




What are we w/o fun? I dare to ask the question ;)

Jacques
PS: robots will do better...


Something about the 3 laws?

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

2015-04-28 Thread Adam Heath



On 04/28/2015 03:27 AM, Jacopo Cappellato wrote:

On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:


So you would like to suppress the concept of event?

Most of the events are currently implemented in Java and are already under src 
folder.


Not what I mean.  The following method definition pattern is the problem:

==
public static String $methodName(HttpServletRequest request, 
HttpServletResponse response) {
  Integer pageNum = 
NumberParsingUtil.parseInt(request.getParameter(page));

  ...
  // core logic starts here
  ListMapString, Object searchDataResults = 
dispatcher.runSync(doSearch, context);

  MapString, Object parsedData = new HashMap();
  int largeSizeCount = 0, smallSizeCount = 0;
  for (MapString, Object data: searchDataResults) {
if (data.size()  10) largeSizeCount++;
if (data.size()  5) smallSizeCount++;
  }
  parsedData.put(largeSizeCount, largeSizeCount);
  parsedData.put(smallSizeCount, smallSizeCount);
  parsedData.put(totalCount, searchDataResults.size());
  parsedData.put(results, searchDataResults);
  ..
  request.setAttribute(search:parsedData, parsedData);
  return success;
}
==

There are 3 things going on here.  The first part reads the incoming 
request data, fetching whatever it needs.  The second does some kind of 
business logic.  The third then places the results of that back into the 
request for later processing by further code.


The middle part needs to be extracted into a separate location that is 
callable through the service engine.


ps: this is pseudo code

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

2015-04-28 Thread Adam Heath



On 04/28/2015 08:22 AM, Ron Wheeler wrote:

On 28/04/2015 3:31 AM, Jacques Le Roux wrote:

Le 27/04/2015 16:52, Adam Heath a écrit :

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. 


Yikes, that would be a Maven only solution (no Ant) blocker :/

Jacques



Why would Ant have trouble with a different project structure?



You mis-parsed Jacques' statement.  Remove the (no Ant) part, and it 
becomes: that would be a Maven only solution blocker.  It is an issue 
with maven, not ant.

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

2015-04-28 Thread Adam Heath



On 04/28/2015 10:17 AM, Ron Wheeler wrote:
1) is probably not a problem but it does make it harder to get support 
if you run into a bug that has already been fixed. I find it hard to 
imagine a reason to use a piece of software that is known to be 
defective when there are several newer versions with those defects 
fixed (and perhaps some new ones added)  :-)  .


2) Removing your local repo will not add the parent pom to the repo.
The message is pretty clear. You do not have 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK in your local repo and it is 
not in Maven Central so Maven has no way to get it.

You need to build and deploy the parent into your local repo.



Ok, this is wrong.  The issue you and Hans have reported has nothing to 
do at all with running install locally.  I actually had bad relative 
paths. See r1676572.


On a plus, running mvn at framework/start, applications/product, etc, is 
now also working(!).  So, one actual sour point for maven has been dealt 
with.  See r1676573.


I still have an issue with the LICENSE+NOTICE stuff I'm doing, not being 
installed into the local repo.  I'm attempting to see if there is 
another way to do that.


ps: running mvn at the top level issues no dependency warnings. Running 
it at a sub level issues warnings about systemPath for deps.  This is 
actually a bug with maven that it doesn't issue the warnings at the top 
level.  These warnings will go away once we start downloading dependencies.

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

2015-04-27 Thread 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 :

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

Ron

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

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

2015-04-27 Thread 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 doo...@brainfood.com 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

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

2015-04-27 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)

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

2015-04-27 Thread Adam Heath (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-26 Thread Adam Heath


On 04/26/2015 09:44 AM, Adrian Crum wrote:
As was discussed last week, there is some interest in replacing some 
(or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html).


To the scope reasonable, I propose that we begin by converting0 the 
following parts of the OFBiz framework with Moqui:


Entity Engine
Service Engine
Security

Other parts of the OFBiz framework could be converted as well, but I 
think this would be a good starting point, and if is successful, then 
more of OFBiz can be converted later.


I believe we can create a thunk component to help solve compatibility 
problems, but that is a separate discussion. I only mention it here in 
case compatibility concerns might influence a vote.




0: needs more discussion.

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-26 Thread Adam Heath


On 04/26/2015 02:27 PM, Adrian Crum wrote:
No one is going to invest their time and effort in a POC unless they 
have the approval and support of the community. I don't think you're 
going to see a POC before a vote.




I would.

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-26 Thread Adam Heath


On 04/26/2015 06:13 PM, Adam Heath wrote:

On 04/26/2015 02:27 PM, Adrian Crum wrote:
No one is going to invest their time and effort in a POC unless they 
have the approval and support of the community. I don't think you're 
going to see a POC before a vote.




I would.

I haven't yet looked at Moqui either, so I'd be starting with a fresh 
view.  This would also be a good way to get my feet wet.


And, without even looking at the code, the first goal would be to have 
both running at the same time, in the same instance, with both being 
able to call each others service engines, and both database layers 
talking to the exact same structure.  That would allow for services to 
be implemented in both, and would give a much clear incremental switchover.

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-26 Thread 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 http://www.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 
michael.br...@ecomify.de

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: move to git.

2015-04-24 Thread Adam Heath



On 04/23/2015 06:00 PM, David E. Jones wrote:

An FYI for all committers: create an account on GitHub (if you don't already 
have one) and add your @apache.org email address to it, and within a few hours 
you'll show up in the contributor graphs. I tried this and am now showing up 
there:

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

If nothing else it's entertaining, I had no idea that I had this volume of 
commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note 
that changes to lines show up in both counts).


Come on, everyone.  It's a competition!  See if you can beat Jacopo!

Useless metrics are fun sometimes.  Number of commits, number of lines 
added/removed, don't really mean anything.  I've seen stupid code that 
had the same 30 lines cut and pasted 20 times, instead of making a 
helper method, and of course a single line per commit can also inflate 
numbers.


But, it's fun to play with gui graph libraries.

[jira] [Assigned] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

2015-04-24 Thread Adam Heath (JIRA)


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

Adam Heath reassigned OFBIZ-6300:
-

Assignee: Adam Heath

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath

 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

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

2015-04-24 Thread Adam Heath

+0.5 (see below, comment inline)

Yes, I agree. I even have a way forward, if you've been paying
attention to the maven branch(OFBIZ-6271).

I have maven working with the *existing* layout in ofbiz. My plan for
migration has been this:

* Get maven working with existing structure. Ie, maven can compile all
the code, can create all the jars, basically, it can do everything that
the build.xml files do. This is a little tricky, as the top-level
build.xml contains several custom targets; I'll probably just use the
antrun plugin for these.

* Add top-level properties in ofbiz-parent.pom, that define all the
folders we might need to move; update ofbiz-component-pom.xml to use
these variables.

* Switch each component one at a time, setting variables in the local
pom.xml(s) with the new location. Each one of these should be a
separate commit.

* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code
compiled by the test phase. Aka, there is no way to know if src/test/*
is getting correct coverage. I think I can fix this, as we really
should verify not only the baseline code, but the testing code, for
correctness.

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

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/

Altho, actually, I think this layout is because maven is stupid, and the
plugins and fileset api does not allow for different type files in
different folders. Aka, the groovyc and javac hooks have a hard time
compiling .groovy and .java when they exist together in src/, so maven
authors decided to split them into src/*/groovy and src/*/java.

I haven't yet gotten to integrating a groovy compiler plugin, I see only
one .groovy in framework/service/src, for the entire project.

java 1.8 features: Re: [jira] [Commented] (OFBIZ-6298) Java collection use optimized

2015-04-24 Thread Adam Heath

Not putting this into the jira issue, as it's not related, but with java 
1.8, construction of generic objects is nicer.


==
MapString, ListMapString, Object myVar = new HashMap();
==

Re: Maven and Git providing build into at run-time

2015-04-24 Thread Adam Heath



On 04/24/2015 07:45 AM, Ron Wheeler wrote:
An interesting article about how git and Maven can be used to 
automatically make the build revision and other info available at 
run-time for logging or display in an About display.




The top-level build.xml has a rule to update the svn build revision; 
this number is monotomically increasing.  A git based $revhash isn't, so 
there's a little bit of information lost there.  But I think that's minor.


http://www.petrikainulainen.net/programming/spring-framework/spring-from-the-trenches-returning-git-commit-information-as-json/ 



Not a compelling reason to move to Maven or git but a nice addition to 
OFBiz to make support and bug reporting a bit easier.


Also just a nice bit of reading if you enjoy reading about clever 
programming.


Ron

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

2015-04-24 Thread Adam Heath



On 04/24/2015 10:05 AM, Ron Wheeler wrote:

+1
Looks like Adam has the right approach.



Thanks.

However, I'm thinking of adding a few steps.  See below.


Ron
On 24/04/2015 10:36 AM, Adam Heath wrote:

+0.5 (see below, comment inline)

Yes, I agree.  I even have a way forward, if you've been paying 
attention to the maven branch(OFBIZ-6271).


I have maven working with the *existing* layout in ofbiz. My plan for 
migration has been this:


* Get maven working with existing structure.  Ie, maven can compile 
all the code, can create all the jars, basically, it can do 
everything that the build.xml files do.  This is a little tricky, as 
the top-level build.xml contains several custom targets; I'll 
probably just use the antrun plugin for these.


* Add top-level properties in ofbiz-parent.pom, that define all the 
folders we might need to move; update ofbiz-component-pom.xml to use 
these variables.




* Add top-level properties in common.xml(and/or macros.xml), same as 
maven/pom.


* Switch each component one at a time, setting variables in the local 
pom.xml(s) with the new location.  Each one of these should be a 
separate commit.




* Do this to each component's build.xml as well.  This change should be 
part of the commit above.



* Announce(!)

* ??? Profit?

ps: The standard maven test hooks do *not* run coverage against code 
compiled by the test phase.  Aka, there is no way to know if 
src/test/* is getting correct coverage.  I think I can fix this, as 
we really should verify not only the baseline code, but the testing 
code, for correctness.

[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

2015-04-24 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511204#comment-14511204
 ] 

Adam Heath commented on OFBIZ-6300:
---

I have been getting additional generics warnings when using 1.8 to compile in 
1.7 mode; I'm not surprised if there are actual errors in 1.8 mode as well.

I had been meaning to create a 1.8 compile target top-level issue, but hadn't 
yet gotten to it.  So, before the patch promised is accepted, I'd like to 
create a top-level catch-all, and link this into it, maybe.

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath

 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

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

2015-04-24 Thread Adam Heath



On 04/24/2015 09:57 AM, Jacopo Cappellato wrote:

On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote:


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

I haven't yet gotten to integrating a groovy compiler plugin, I see only one 
.groovy in framework/service/src, for the entire project.

When I proposed this I was also thinking about to move the groovy (data 
preparation) scripts that are currently under WEB-INF/actions folders; most of 
them could be used in non web applications.


Hmm, right.  Good idea.  We(Brainfood) would love it if all the action 
code was turned into services.  But, even in that case, src/main/scripts 
would be used, as I think src/main/groovy is for groovyc.  I'll find out 
today if that is the case.

Re: move to git.

2015-04-23 Thread Adam Heath



On 04/23/2015 04:22 AM, Scott Gray wrote:

I'm just saying my current project has been using it for 18 months and it's
been a long time now since we've lost any changes.  This is 15-30 devs
that were all new to git.

In my experience most issues come from:
- Reverting merge commits and picking the wrong mainline


Yeah, I've had issues here too.  I generally don't do git reset HEAD^ 
when it's a merge, instead I do git branch save-current; git checkout 
save-current; git branch -F master $HASH; git checkout master.  If all 
went well, then I can delete that save-current branch, and continue on.



- Pushing to the wrong remote branch


If caught before anyone else pulls, git push +local-ref:remote-ref can fix.

- Incorrectly handling conflicts


This single item was a cause for much head-ache, at least for me. Merge 
conflicts, and rebase conflicts, are given different markup as well, 
which doesn't help the situation.


Conflicts happen with both git and svn based workflows.  If you attempt 
to commit with svn, and someone else modified the files first, svn says 
no.  So then you pull in the upstream changes, and attempt to fix 
locally.  It's still possible to pick the wrong code.  The issue now is 
that when you commit back to svn, it's not recorded as a merge, there is 
no special text saying which files had conflict, so you are left to 
assume the developer meant to change the code.



- Trying to force pushes


Also related, is pushing to a remote repo, that is also checked out(aka, 
has a $working_directory), and the remote branch being pushed to is what 
is checked out.



The most important thing is to stop when you mess something up and seek
help.  Trying to fix things on the remote repo without understanding what
has gone wrong can make a bigger mess.


When I had problems earlier on, I got very frustrated.  After a bit, I 
realized I could abuse the garbage-collection nature of git, and create 
a temporary branch against HEAD, before I changed anything. Git would 
ensure that the content referenced by that branch would stay around, 
while I made mistakes.


Eventually, I started to make use of reflog directly, and no longer need 
that temporary branch.



On second thought I'm almost hesitant to say git would be a good idea for
OFBiz because we have so many committers that would have access to the
master branch without an adequate level of git experience.  I can imagine
the mess someone might make trying to rewrite history on the remote repo.


The linux-kernel does not have all developers world-wide pushing to the 
single repo that is responsible for producing the tarballs hosted at 
kernel.org.  Only one guy does that, Linus Torvalds.


Implicit in a svn-git switch, would be finding someone willing to be 
that person.  Which, is a whole other thread of discussion.



Regardless, I highly recommend git-svn for basic local development
or forking the git mirror if you want to go deeper.


I've been saying that for years.

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

2015-04-23 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509305#comment-14509305
 ] 

Adam Heath commented on OFBIZ-6291:
---

int i = foo... isn't the part that is slower.  The instanceOf pattern is 
slower.

Good debuggers can check the return value of the expression before returnning, 
without the need for a local variable.  It introduces additional noise.

Also, I'm differing to Adrian here, who has a bit more familiarity with that 
code; I have added this to my list of things to check, but I'm working on 
several other branches right now against trunk, so please be patient.

 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch, 
 minilang_compare_r1675655.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



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

[jira] [Commented] (OFBIZ-6291) Update code to check for types rather than throw ClassCastException

2015-04-23 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509267#comment-14509267
 ] 

Adam Heath commented on OFBIZ-6291:
---

* The patch introduces new blank lines; that should be done separately.

* int i = foo.compareTo(baz); return i = 0;  this is an anti-pattern.  Remove 
the use of the local variable.

Also, doing if (foo instanceof Bar), then casting with (Bar), is slower, than 
just attempting the cast, and catching an exception.  If the fast-path items 
are done first, then no throw ever happens, and you don't waste cycles on the 
instanceOf operator, and the jump that happens.

I haven't attempted to apply the patch, I was just reading it, but a smell test 
seems to say -1.

Also, I have done some unit tests against ObjectType in the past; I don't know 
how current they still are.  The change to an instanceOf condiitional needs to 
pass those tests, and, should also be done with cobertura, and the code 
coverage should stay the same before and after.  But that all hinges on the 
currentness of the unit testing.


 Update code to check for types rather than throw ClassCastException
 ---

 Key: OFBIZ-6291
 URL: https://issues.apache.org/jira/browse/OFBIZ-6291
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Gareth Carter
Priority: Trivial
 Attachments: LocalizedConverters.patch, minilang_compare.patch


 framework/minilang/src/org/ofbiz/minilang/method/conditional/Compare.java
 framework/base/src/org/ofbiz/base/util/ObjectType.java
 framework/minilang/src/org/ofbiz/minilang/MiniLangUtil.java
 all throw ClassCastExceptions and are ignored instead of checking types
 This caused issues in debugging when adding a ClassCastException breakpoint



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

Re: Fwd: Re: Maven

2015-04-23 Thread Adam Heath

As for deploying of artifacts, I've already done a mvn install 
locally, which copies the built files into $HOME/.m2/; so I know that 
eventually when everything is done, we could deploy into the global 
shared repo.



On 04/22/2015 09:03 PM, Ron Wheeler wrote:


Just to let everyone know that we are not the only people working on a 
switch to Maven.
The Apache FOP team is also trying to see what the impact would be of 
switching to Maven.


Being able to put libraries in Maven Central more easily seems to be a 
hot topic.
Building the appropriate artifacts seems to be hard using their 
existing build tools.




 Forwarded Message from FOP mailing List



On Wed, Apr 22, 2015 at 2:03 PM, Luis Bernardo lmpmberna...@gmail.com 
mailto:lmpmberna...@gmail.com wrote:



   Maybe I only spoke for myself, but I am in: +1

From what I understand publishing the source jars to maven central
   would be automatic then, since there is some plugin for that. Given
   the fact that I have spent many hours adapting the Batik ant file to
   produce the source jars for maven central (I am still in the process
   of checking the result is correct) any steps that help with that in
   the future (be either for FOP or Batik) are welcome.


that's my exact thinking; one reason we have historically done a poor 
job of maven deployment is because we aren't using maven; switching to 
maven will make that a no-brainer and ensure correct deployment




   On 4/22/15 6:35 PM, Glenn Adams wrote:



On Wed, Apr 22, 2015 at 10:31 AM, Luis Bernardo
lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote:


I think that maven will be embraced as soon as there is a
volunteer to do the transition.


A few years ago I went through the process of creating a full
maven configuration for FOP; however, the group was not ready to
make the transition at that time.

I have recently converted another multiple-module internal project
to maven from ant, and would be able to repeat the process on fop.
However, I don't want to do it unless there is support to switch 
over.




On 4/22/15 6:13 PM, Glenn Adams wrote:

on another point, when can we transition to maven? our ant
configurations are difficult to maintain and understand; we
should modernize

Re: move to git.

2015-04-23 Thread Adam Heath



On 04/23/2015 03:28 AM, Scott Gray wrote:

I am thoroughly familiar with Git.
Git always screws things up.


If git always screwed things up, then those other 3 projects wouldn't be 
using it.


ps: I realize this was a quote from Adrian, and not Scott.


These two statements are complete contradictions.  Outcomes in git only
appear strange while you're still unfamiliar with it.

I've been using the git-svn bridge to commit to OFBiz for about 4 years and
using a git repo on my current project for the last 18 months or so.
Strange occurrences stopped happening for me after a couple of months and
generally stopped once all developers either stopped using git client UIs
that used settings they didn't understand or they started using the command
line (which is exceedingly simple for basic workflows).


I also had strangeness happen earlier on, when I first started. What I 
can surmise happened, after all these years, is that I used git in the 
wrong way, and git did exactly what I told it to do.  But then, since I 
was a noob, I didn't know what I had done was wrong, only that what I 
was seeing was not what I expected.


It's the same kind of thing when you go rm -rf $HOME.  Of course all 
your files are now gone, but that's not the fault of rm.



The value of feature branches and pull requests over patches cannot be
overstated IMO.  The ability to easily multi-task on features, review pull
requests, keep a real commit history for contributed features, to
collaborate outside of the main repo puts git miles ahead of svn for
collaborative incremental software development.


Let's not forgot that the complete project history is available offline, 
that the .svn files are not scattered all over(which makes grepping for 
stuff difficult, as you have to exclude those files from results), that 
you can include ancient history from previous project lifespans(I have 
added svn.ofbiz.org history in one of my git-svn ofbiz clones, so I can 
see history going back to 2003, well before the switch to apache, and 
even when Andrew created a new repo with the mostly current component 
structure).


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


Then, how do you(not you Scott) thing I can commit 15 changes all at 
once?  I do all that work in a single commit.  Then I save it. Then, I 
use git rebase, and split the commit into smaller chunks. Woops, that's 
a new feature, let's change the order of the commits, moving that one 
first.  Oh, my bad, I have a typo in a commit message, let's change 
that.  Ok, I'm happy now, time to run all tests against every single 
commit(while I switch jobs and work on something else).  Ok, everything 
passes, git svn dcommit $HASH, flood the mailing list.


In the svn workflow, only a single patch can be committed at a time, and 
you have to manually save local work, to build up the patch history.  
Git actually allows me to produce more stable code, when I am splitting 
up single-large-commits.



Regards
Scott


On 20 April 2015 at 22:19, Adrian Crum adrian.c...@sandglass-software.com
wrote:


I am thoroughly familiar with Git. I've used it on on three projects, and
that is why I don't like it.

I have a far easier time merging branches with Subversion. Git always
screws things up.

I don't need to be convinced of anything. I have my experience and my
opinion. But still, I'm not opposed to switching to Git.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:


One of the most difficult and challenging issue with branches is _merging_
them. Git is a tool that is far more advanced in its feature set in that
area.

It seems some of the opinions expressed against git are due to
unfamiliarity. The only way to be convinced is to try it on an advanced
level as i don't think an email thread would be enough for convincing
anyone of the merits.

My 2 cents

Taher Alkhateeb
On Apr 20, 2015 12:54 PM, Pierre Smits pierre.sm...@gmail.com wrote:

  If we only want GIT for multiple local development branches, then we are

doing for the wrong reasons. SVN doesn't hinder you in doing that today.

Best 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 Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux 
jacques.le.r...@les7arts.com wrote:

  Like Adrian and mostly for the same reasons, I don't believe we need

Git.

But there is one other major reason which has already been discussed in
the other common ASF MLs.  As Taher exulted, it's possible to create


local


branches. So people are able to do a lot of work alone without
exchanging
before committing or submitting. It will certainly not help to have this
possibility. Remember our recent discussion on the lack or core commits
reviews. With Git you end with commits bursts or big patches and it's


then


hard to review and too

Re: move to git.

2015-04-23 Thread Adam Heath



On 04/23/2015 06:00 PM, David E. Jones wrote:

An FYI for all committers: create an account on GitHub (if you don't already 
have one) and add your @apache.org email address to it, and within a few hours 
you'll show up in the contributor graphs. I tried this and am now showing up 
there:

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

If nothing else it's entertaining, I had no idea that I had this volume of 
commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note 
that changes to lines show up in both counts).


I only did this myself yesterday, after Ean mentioned it.  I've actually 
been on github for a bit now.  But, with my @apache.org email attached 
to my account, it might actually improve my standings.


FYI, I believe that large spike that is at the start of my graph(I'm 
eigood, which is doogie backwards), is when I was committing the 
generics markup.



On a side note, my commit count is relatively low... ie most commits with a 
larger number of changes. I remember working more than way before using git... 
perhaps with its explicit approach to saying which files to include it 
encourages that more (unless you use git commit -a), or perhaps for other 
reasons my habits have changed.


It's not just that you can selectively pick which files; git add -i 
allows you to selectively choose chunks.



I don't get nearly as fancy as what Adam described recently with his rebase 
approach, but to his point I find my commits being much cleaner and better 
organized.


I split up my work into smaller commits(lines-per-commit is smaller), so 
that it allows others to review it easier.



-David

[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507350#comment-14507350
 ] 

Adam Heath commented on OFBIZ-6290:
---

  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/pos/src/org/ofbiz/pos/config/ButtonEventConfig.java:55:
 warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been 
deprecated
  [javac17] Element root = 
ResourceLoader.getXmlRootElement(ButtonEventConfig.BUTTON_EVENT_CONFIG);
  [javac17]  ^


 ButtonEventConfig uses getXmlRootElement which has been deprecated
 --

 Key: OFBIZ-6290
 URL: https://issues.apache.org/jira/browse/OFBIZ-6290
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/pos
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor

 ResourceLoader.getXmlRootElement() caches its return value; however, DOM 
 elements are memory intensive, and the returned value tends to only be used 
 once.  So, this is a poor pattern.



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

[jira] [Created] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6289:
-

 Summary: Oagis classes are making use of the deprecated html 
rendering system
 Key: OFBIZ-6289
 URL: https://issues.apache.org/jira/browse/OFBIZ-6289
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/oagis
Reporter: Adam Heath
Priority: Minor


More of the same; oagis classes are using the deprecated html rendering system.



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

[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507321#comment-14507321
 ] 

Adam Heath commented on OFBIZ-6289:
---

  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17] 
   ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:193:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] ScreenRenderer screens = new ScreenRenderer(writer, 
bodyParameters, new HtmlScreenRenderer());
  [javac17] 
^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17] 
   ^


 Oagis classes are making use of the deprecated html rendering system
 

 Key: OFBIZ-6289
 URL: https://issues.apache.org/jira/browse/OFBIZ-6289
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/oagis
Reporter: Adam Heath
Priority: Minor

 More of the same; oagis classes are using the deprecated html rendering 
 system.



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

[jira] [Created] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6290:
-

 Summary: ButtonEventConfig uses getXmlRootElement which has been 
deprecated
 Key: OFBIZ-6290
 URL: https://issues.apache.org/jira/browse/OFBIZ-6290
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/pos
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor


ResourceLoader.getXmlRootElement() caches its return value; however, DOM 
elements are memory intensive, and the returned value tends to only be used 
once.  So, this is a poor pattern.



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

Re: [jira] [Created] (OFBIZ-6275) OFBiz code seems make use of other deprecated OFBiz features

2015-04-22 Thread Adam Heath

Ok, all issues created.  Hang back a bit before anyone starts taking 
ownership of stuff, I've need to make time to commit the ones I've 
already got fixed.


On 04/22/2015 10:11 AM, Adam Heath wrote:
I've got some changes already for the sub-tasks I will be filing 
shortly; as before, a separate branch will be made.


On 04/22/2015 10:08 AM, Adam Heath (JIRA) wrote:

Adam Heath created OFBIZ-6275:
-

  Summary: OFBiz code seems make use of other deprecated 
OFBiz features

  Key: OFBIZ-6275
  URL: https://issues.apache.org/jira/browse/OFBIZ-6275
  Project: OFBiz
   Issue Type: Bug
   Components: ALL COMPONENTS
 Affects Versions: Trunk
 Reporter: Adam Heath
 Priority: Minor


Add compilerarg value=-Xlint:deprecation/ to macros.xml.  Do a 
clean, then a build.  See the warnings.


This task should be an umbrella over any possible sub-tasks, as 
people find and discover these issues, and come up with fixes.




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

[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507330#comment-14507330
 ] 

Adam Heath commented on OFBIZ-6270:
---

Because I plan on also adding test cases(which were also removed); they will 
probably even be based on the removed test case classes.  And, since I haven't 
yet done the work, and I am following the release-first/release-often workflow, 
I created a branch early, and committed code early, in case anyone else wants 
to work with me.

 base/json/JSON has been removed, with no deprecation window
 ---

 Key: OFBIZ-6270
 URL: https://issues.apache.org/jira/browse/OFBIZ-6270
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk, 12.04.04
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Critical

 The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last 
 October(2014-10-27).  However, no backwards-compatible class was left in 
 place, with a proper @Deprecation tag applied.
 The proper approach should have been to leave the class in place, adding 
 @Deprecation, and leaving the json-lib.jar in place.  Then, after one 
 successful release, removing the actual code.



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

[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507342#comment-14507342
 ] 

Adam Heath commented on OFBIZ-6289:
---

These need to be switched to a macro system.

 Oagis classes are making use of the deprecated html rendering system
 

 Key: OFBIZ-6289
 URL: https://issues.apache.org/jira/browse/OFBIZ-6289
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/oagis
Reporter: Adam Heath
Priority: Minor

 More of the same; oagis classes are using the deprecated html rendering 
 system.



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

[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507352#comment-14507352
 ] 

Adam Heath commented on OFBIZ-6290:
---

Same problem, don't use a cached version of this method.

 ButtonEventConfig uses getXmlRootElement which has been deprecated
 --

 Key: OFBIZ-6290
 URL: https://issues.apache.org/jira/browse/OFBIZ-6290
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/pos
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor

 ResourceLoader.getXmlRootElement() caches its return value; however, DOM 
 elements are memory intensive, and the returned value tends to only be used 
 once.  So, this is a poor pattern.



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

[jira] [Created] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6276:
-

 Summary: Fix deprecation issues in framework/entity
 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor


It appears that the storeAll() variants are being refactor; basically, the 
useCache parameter is being removed.  However, this has caused the
entity engine to have deprecation with itself.



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

[jira] [Assigned] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement

2015-04-22 Thread Adam Heath (JIRA)


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

Adam Heath reassigned OFBIZ-6278:
-

Assignee: Adam Heath

 JNDIConfigUtil makes use of deprecated getXmlRootElement
 

 Key: OFBIZ-6278
 URL: https://issues.apache.org/jira/browse/OFBIZ-6278
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Adam Heath

 ResourceLoader.getXmlRootElement caches it's return value; this has been 
 deprecated, because DOM objects are memory intensive, and generally are only 
 needed once.



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

[jira] [Created] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6278:
-

 Summary: JNDIConfigUtil makes use of deprecated getXmlRootElement
 Key: OFBIZ-6278
 URL: https://issues.apache.org/jira/browse/OFBIZ-6278
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath


ResourceLoader.getXmlRootElement caches it's return value; this has been 
deprecated, because DOM objects are memory intensive, and generally are only 
needed once.



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

[jira] [Commented] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507256#comment-14507256
 ] 

Adam Heath commented on OFBIZ-6281:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import 
org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:82:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] writer.append(FoScreenRenderer.getFoStyle(widgetStyle));
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:208:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] 
writer.append(FoScreenRenderer.getFoStyle(areaStyle));
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:290:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] writer.append(FoScreenRenderer.getFoStyle(areaStyle));
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:132:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] ScreenRenderer screens = new ScreenRenderer(writer, 
null, new HtmlScreenRenderer());
  [javac17] 
  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/html/HtmlTreeRenderer.java:337:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated

[jira] [Updated] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement

2015-04-22 Thread Adam Heath (JIRA)


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

Adam Heath updated OFBIZ-6278:
--
Priority: Minor  (was: Major)

 JNDIConfigUtil makes use of deprecated getXmlRootElement
 

 Key: OFBIZ-6278
 URL: https://issues.apache.org/jira/browse/OFBIZ-6278
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor

 ResourceLoader.getXmlRootElement caches it's return value; this has been 
 deprecated, because DOM objects are memory intensive, and generally are only 
 needed once.



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

[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings

2015-04-22 Thread Adam Heath (JIRA)


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

Adam Heath updated OFBIZ-6279:
--
Component/s: framework

 UtilDateTime has an ImmutableDate inner class that has deprecation warnings
 ---

 Key: OFBIZ-6279
 URL: https://issues.apache.org/jira/browse/OFBIZ-6279
 Project: OFBiz
  Issue Type: Sub-task
  Components: ALL COMPONENTS, framework
Reporter: Adam Heath
Assignee: Adam Heath

 When extending/implementing a class/interface, where methods in the parent 
 have been marked deprecated, sub-instances also get deprecation warnings.  
 The fix here is to also mark the sub-instances deprecated(with @Deprecated or 
 /** @deprecated */



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

[jira] [Updated] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated

2015-04-22 Thread Adam Heath (JIRA)


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

Adam Heath updated OFBIZ-6280:
--
Priority: Minor  (was: Major)

 SecurityFactory implements methods that have been deprecated
 

 Key: OFBIZ-6280
 URL: https://issues.apache.org/jira/browse/OFBIZ-6280
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor

 This class implements Security, which has methods that have been deprecated.  
 As such, it gets deprecation warnings when implementing those methods.



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

[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings

2015-04-22 Thread Adam Heath (JIRA)


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

Adam Heath updated OFBIZ-6279:
--
Component/s: (was: ALL COMPONENTS)

 UtilDateTime has an ImmutableDate inner class that has deprecation warnings
 ---

 Key: OFBIZ-6279
 URL: https://issues.apache.org/jira/browse/OFBIZ-6279
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Adam Heath

 When extending/implementing a class/interface, where methods in the parent 
 have been marked deprecated, sub-instances also get deprecation warnings.  
 The fix here is to also mark the sub-instances deprecated(with @Deprecated or 
 /** @deprecated */



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

[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507279#comment-14507279
 ] 

Adam Heath commented on OFBIZ-6285:
---

Same type of problems.

 OutputServices uses the deprecated fo widget rendering system
 -

 Key: OFBIZ-6285
 URL: https://issues.apache.org/jira/browse/OFBIZ-6285
 Project: OFBiz
  Issue Type: Sub-task
  Components: content
Reporter: Adam Heath
Priority: Minor

 Yet again, another instance of hard-coded rendering being used instead of 
 macro rendering.



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

Re: Renaming OFBiz artefacts

2015-04-22 Thread Adam Heath


-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 http://www.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 http://www.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] [Commented] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507250#comment-14507250
 ] 

Adam Heath commented on OFBIZ-6279:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1197:
 warning: [deprecation] setYear(int) in Date has been deprecated
  [javac17] public void setYear(int year) {
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1202:
 warning: [deprecation] setMonth(int) in Date has been deprecated
  [javac17] public void setMonth(int month) {
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1207:
 warning: [deprecation] setDate(int) in Date has been deprecated
  [javac17] public void setDate(int date) {
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1212:
 warning: [deprecation] setHours(int) in Date has been deprecated
  [javac17] public void setHours(int hours) {
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1217:
 warning: [deprecation] setMinutes(int) in Date has been deprecated
  [javac17] public void setMinutes(int minutes) {
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1222:
 warning: [deprecation] setSeconds(int) in Date has been deprecated
  [javac17] public void setSeconds(int seconds) {
  [javac17] ^


 UtilDateTime has an ImmutableDate inner class that has deprecation warnings
 ---

 Key: OFBIZ-6279
 URL: https://issues.apache.org/jira/browse/OFBIZ-6279
 Project: OFBiz
  Issue Type: Sub-task
  Components: ALL COMPONENTS
Reporter: Adam Heath
Assignee: Adam Heath

 When extending/implementing a class/interface, where methods in the parent 
 have been marked deprecated, sub-instances also get deprecation warnings.  
 The fix here is to also mark the sub-instances deprecated(with @Deprecated or 
 /** @deprecated */



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

[jira] [Created] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6280:
-

 Summary: SecurityFactory implements methods that have been 
deprecated
 Key: OFBIZ-6280
 URL: https://issues.apache.org/jira/browse/OFBIZ-6280
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Adam Heath


This class implements Security, which has methods that have been deprecated.  
As such, it gets deprecation warnings when implementing those methods.



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

[jira] [Commented] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507268#comment-14507268
 ] 

Adam Heath commented on OFBIZ-6284:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:96:
 warning: [deprecation] getAllEntityNamesUsed() in SimpleMethod has been 
deprecated
  [javac17] SetString allEntityNameSet = 
simpleMethodToCall.getAllEntityNamesUsed();
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:156:
 warning: [deprecation] getAllServiceNamesCalled() in SimpleMethod has been 
deprecated
  [javac17] SetString allServiceNameSet = 
simpleMethodToCall.getAllServiceNamesCalled();
  [javac17]   ^


 ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
 -

 Key: OFBIZ-6284
 URL: https://issues.apache.org/jira/browse/OFBIZ-6284
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor

 I can't comment to much on this; the methods that have been marked deprecated 
 have no javadocs, nothing to indicate why they should no longer be used.  I 
 haven't checked the commit log, however.



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

[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507284#comment-14507284
 ] 

Adam Heath commented on OFBIZ-6287:
---

  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = 
new HtmlScreenRenderer();
  [javac17] 
   ^


 BirtEmailServices uses the deprecated html rendering system
 ---

 Key: OFBIZ-6287
 URL: https://issues.apache.org/jira/browse/OFBIZ-6287
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/birt
Reporter: Adam Heath
Priority: Minor

 Yet another instance of html rendering being used instead of macro rendering.



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

[jira] [Created] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6287:
-

 Summary: BirtEmailServices uses the deprecated html rendering 
system
 Key: OFBIZ-6287
 URL: https://issues.apache.org/jira/browse/OFBIZ-6287
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/birt
Reporter: Adam Heath
Priority: Minor


Yet another instance of html rendering being used instead of macro rendering.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507231#comment-14507231
 ] 

Adam Heath commented on OFBIZ-6276:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
 warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in 
Delegator has been deprecated
  [javac17] public int storeAll(ListGenericValue values, boolean 
doCacheClear, boolean createDummyFks) throws GenericEntityException {
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
 warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in 
Delegator has been deprecated
  [javac17] delegator.storeAll(valuesToWrite, doCacheClear, 
createDummyFks);
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
 warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in 
Delegator has been deprecated
  [javac17] 
delegator.removeAll(valuesToDelete, doCacheClear);
  [javac17]  ^


 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor

 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Commented] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507248#comment-14507248
 ] 

Adam Heath commented on OFBIZ-6278:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/config/JNDIConfigUtil.java:39:
 warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been 
deprecated
  [javac17] return 
ResourceLoader.getXmlRootElement(JNDIConfigUtil.JNDI_CONFIG_XML_FILENAME);
  [javac17]  ^



 JNDIConfigUtil makes use of deprecated getXmlRootElement
 

 Key: OFBIZ-6278
 URL: https://issues.apache.org/jira/browse/OFBIZ-6278
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath

 ResourceLoader.getXmlRootElement caches it's return value; this has been 
 deprecated, because DOM objects are memory intensive, and generally are only 
 needed once.



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

[jira] [Created] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6281:
-

 Summary: Many classes in framework/widget are still using 
html-based renderers, instead of macro-based
 Key: OFBIZ-6281
 URL: https://issues.apache.org/jira/browse/OFBIZ-6281
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor


The html renderers had hard-coded output.  A new system had been developed, 
which uses macros; this allowed for swapping the output with something more or 
less advanced, without having to change the code.

However, many classes are still using the old rendering system.



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

[jira] [Created] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6283:
-

 Summary: A few classes in webtools make use of the html widget 
rendering system
 Key: OFBIZ-6283
 URL: https://issues.apache.org/jira/browse/OFBIZ-6283
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor


The html rendering system is deprecated in favor of a macro-based approach.  
These classes should be updated to use the new system.



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

[jira] [Created] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6286:
-

 Summary: SagePay classes make use of deprecated httpclient features
 Key: OFBIZ-6286
 URL: https://issues.apache.org/jira/browse/OFBIZ-6286
 Project: OFBiz
  Issue Type: Sub-task
  Components: accounting
Reporter: Adam Heath
Priority: Minor


I have not checked httpclient upstream to see what should be used in place of 
the deprecated classes/methods.



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

[jira] [Commented] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507282#comment-14507282
 ] 

Adam Heath commented on OFBIZ-6286:
---

  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41:
 warning: [deprecation] DefaultHtt
pClient in org.apache.http.impl.client has been deprecated
  [javac17] import org.apache.http.impl.client.DefaultHttpClient;
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43:
 warning: [deprecation] BasicHttpP
arams in org.apache.http.params has been deprecated
  [javac17] import org.apache.http.params.BasicHttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44:
 warning: [deprecation] HttpParams
 in org.apache.http.params has been deprecated
  [javac17] import org.apache.http.params.HttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41:
 warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has 
been deprecated
  [javac17] import org.apache.http.impl.client.DefaultHttpClient;
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43:
 warning: [deprecation] BasicHttpParams in org.apache.http.params has been 
deprecated
  [javac17] import org.apache.http.params.BasicHttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44:
 warning: [deprecation] HttpParams in org.apache.http.params has been deprecated
  [javac17] import org.apache.http.params.HttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41:
 warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has 
been deprecated
  [javac17] import org.apache.http.impl.client.DefaultHttpClient;
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43:
 warning: [deprecation] BasicHttpParams in org.apache.http.params has been 
deprecated
  [javac17] import org.apache.http.params.BasicHttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44:
 warning: [deprecation] HttpParams in org.apache.http.params has been deprecated
  [javac17] import org.apache.http.params.HttpParams;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:282:
 warning: [deprecation] getConnectionManager() in HttpClient has been deprecated
  [javac17] httpClient.getConnectionManager().shutdown();
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:378:
 warning: [deprecation] getConnectionManager() in HttpClient has been deprecated
  [javac17] httpClient.getConnectionManager().shutdown();
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:472:
 warning: [deprecation] getConnectionManager() in HttpClient has been deprecated
  [javac17] httpClient.getConnectionManager().shutdown();
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:564:
 warning: [deprecation] getConnectionManager() in HttpClient has been deprecated
  [javac17] httpClient.getConnectionManager().shutdown();
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:675:
 warning: [deprecation] getConnectionManager() in HttpClient has been deprecated
  [javac17] httpClient.getConnectionManager().shutdown();
  [javac17]   ^
  [javac17] 
/srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:164:
 warning: [deprecation] HttpParams in org.apache.http.params has been deprecated
  [javac17] HttpParams params = new BasicHttpParams();
  [javac17] ^
  [javac17] 
/srv/ofbiz/apache-git

[jira] [Commented] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507239#comment-14507239
 ] 

Adam Heath commented on OFBIZ-6277:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379:
 warning: [deprecation] Configuration() in Configuration has been deprecated
  [javac17] Configuration config = new Configuration();
  [javac17]^


 framework/entity makes use of deprecated class Configuration
 

 Key: OFBIZ-6277
 URL: https://issues.apache.org/jira/browse/OFBIZ-6277
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor

 EntitySaxReader makes use of freemarker.template.Configuration, which seems 
 to be deprecated.



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

[jira] [Created] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6277:
-

 Summary: framework/entity makes use of deprecated class 
Configuration
 Key: OFBIZ-6277
 URL: https://issues.apache.org/jira/browse/OFBIZ-6277
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor


EntitySaxReader makes use of freemarker.template.Configuration, which seems to 
be deprecated.



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

[jira] [Commented] (OFBIZ-6282) EmailServices is making use the html widget rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507260#comment-14507260
 ] 

Adam Heath commented on OFBIZ-6282:
---

These 2 issues have similar problems.

 EmailServices is making use the html widget rendering system
 

 Key: OFBIZ-6282
 URL: https://issues.apache.org/jira/browse/OFBIZ-6282
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor

 The html rendering system has been replaced by a macro version; EmailServices 
 still uses the old form.  This should be fixed.



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

[jira] [Created] (OFBIZ-6282) EmailServices is making use the html widget rendering system

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6282:
-

 Summary: EmailServices is making use the html widget rendering 
system
 Key: OFBIZ-6282
 URL: https://issues.apache.org/jira/browse/OFBIZ-6282
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor


The html rendering system has been replaced by a macro version; EmailServices 
still uses the old form.  This should be fixed.



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

[jira] [Commented] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507264#comment-14507264
 ] 

Adam Heath commented on OFBIZ-6283:
---

  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer;
  [javac17]  ^
  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new 
HtmlScreenRenderer();
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49:
 warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html 
has been deprecated
  [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new 
HtmlScreenRenderer();
  [javac17]^


 A few classes in webtools make use of the html widget rendering system
 --

 Key: OFBIZ-6283
 URL: https://issues.apache.org/jira/browse/OFBIZ-6283
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor

 The html rendering system is deprecated in favor of a macro-based approach.  
 These classes should be updated to use the new system.



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

[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507277#comment-14507277
 ] 

Adam Heath commented on OFBIZ-6285:
---

  [javac17] 
/srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer;
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer;
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer;
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] protected static final FoScreenRenderer foScreenRenderer = new 
FoScreenRenderer();
  [javac17]^
  [javac17] 
/srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77:
 warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has 
been deprecated
  [javac17] protected static final FoScreenRenderer foScreenRenderer = new 
FoScreenRenderer();
  [javac17]^


 OutputServices uses the deprecated fo widget rendering system
 -

 Key: OFBIZ-6285
 URL: https://issues.apache.org/jira/browse/OFBIZ-6285
 Project: OFBiz
  Issue Type: Sub-task
  Components: content
Reporter: Adam Heath
Priority: Minor

 Yet again, another instance of hard-coded rendering being used instead of 
 macro rendering.



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

[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507285#comment-14507285
 ] 

Adam Heath commented on OFBIZ-6287:
---

More instances

 BirtEmailServices uses the deprecated html rendering system
 ---

 Key: OFBIZ-6287
 URL: https://issues.apache.org/jira/browse/OFBIZ-6287
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/birt
Reporter: Adam Heath
Priority: Minor

 Yet another instance of html rendering being used instead of macro rendering.



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

[jira] [Created] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6288:
-

 Summary: ExamplePrintServices uses the deprecated html rendering 
system
 Key: OFBIZ-6288
 URL: https://issues.apache.org/jira/browse/OFBIZ-6288
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/example
Reporter: Adam Heath
Priority: Minor


Another case of html rendering in use instead of macro rendering.



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

Re: [jira] [Created] (OFBIZ-6275) OFBiz code seems make use of other deprecated OFBiz features

2015-04-22 Thread Adam Heath

I've got some changes already for the sub-tasks I will be filing 
shortly; as before, a separate branch will be made.


On 04/22/2015 10:08 AM, Adam Heath (JIRA) wrote:

Adam Heath created OFBIZ-6275:
-

  Summary: OFBiz code seems make use of other deprecated OFBiz 
features
  Key: OFBIZ-6275
  URL: https://issues.apache.org/jira/browse/OFBIZ-6275
  Project: OFBiz
   Issue Type: Bug
   Components: ALL COMPONENTS
 Affects Versions: Trunk
 Reporter: Adam Heath
 Priority: Minor


Add compilerarg value=-Xlint:deprecation/ to macros.xml.  Do a clean, then 
a build.  See the warnings.

This task should be an umbrella over any possible sub-tasks, as people find and 
discover these issues, and come up with fixes.



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

[jira] [Created] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings

2015-04-22 Thread Adam Heath (JIRA)

Adam Heath created OFBIZ-6279:
-

 Summary: UtilDateTime has an ImmutableDate inner class that has 
deprecation warnings
 Key: OFBIZ-6279
 URL: https://issues.apache.org/jira/browse/OFBIZ-6279
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Adam Heath
Assignee: Adam Heath


When extending/implementing a class/interface, where methods in the parent have 
been marked deprecated, sub-instances also get deprecation warnings.  The fix 
here is to also mark the sub-instances deprecated(with @Deprecated or /** 
@deprecated */



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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2178 matches

Mail list logo