I wouldn't say it was hijacked, deprecating classes vs. removing them seems
pretty pertinent to the discussion and has a direct impact on version
compatibility.
Regards
Scott
On 20/02/2010, at 12:47 AM, Adrian Crum wrote:
This thread is in no way similar to moving a component. I'm suggesting
Who suggested removing them? They are being moved to a different package. As I
already said - an existing installation can do a simple search and replace to
accommodate that. Plus, as I have also pointed out, changes like this have been
done in the past with no regard to release version
You do it however you feel is right, I don't feel like making any rules.
I'm only asking you to consider the downstream user, if you choose not to then
that's fine too.
Regards
Scott
On 20/02/2010, at 1:17 AM, Adrian Crum wrote:
Who suggested removing them? They are being moved to a
There is no reason for you to pack up your marbles and go home.
The question is: There are classes in org.ofbiz.base.util that don't belong
there because they are data types, not utility classes. What do you think about
moving them to a different package?
And I *have* considered the downstream
The reality is that I don't care enough about the change to continue arguing
about it.
I like the idea of putting things in their logical place.
I like the idea of maintaining backwards compatibility wherever it is feasible
to do so.
I value the latter over the former even if it isn't currently
This is just my opinion, but unless we move to a structures of limited external
interfaces separate from the internal implementations of those interfaces, it's
going to be tough to maintain backward compatibility. The problem is every line
of Java, XML, etc, etc in the project is subject to
--- On Sat, 2/20/10, David E Jones d...@me.com wrote:
I've actually been working for the last few weeks on
something to fix this, and provide a much more solid
foundation for applications like those in OFBiz, but I'm not
sure how much people will like the approach... I guess time
will tell.
--- On Sat, 2/20/10, Scott Gray scott.g...@hotwaxmedia.com wrote:
The reality is that I don't care
enough about the change to continue arguing about it.
I like the idea of maintaining backwards compatibility
wherever it is feasible to do so.
As do I. Please see the XmlSerializable thread.
On Feb 20, 2010, at 2:51 AM, Adrian Crum wrote:
--- On Sat, 2/20/10, David E Jones d...@me.com wrote:
I've actually been working for the last few weeks on
something to fix this, and provide a much more solid
foundation for applications like those in OFBiz, but I'm not
sure how much people
Yes, it's already existed. We have developed such a solution, OpenCms as
frontend to serve multiwebsite and OFBiz as ecommerce backoffice. Each
website has a store and a catalog.
Regards,
Shi Yusen/Beijing Langhua Ltd.
在 2010-02-19五的 21:56 -0800，nikunjsurati写道：
Hi to all,
I am new to apache
Adrian Crum wrote:
Who suggested removing them? They are being moved to a different package. As
I already said - an existing installation can do a simple search and replace
to accommodate that. Plus, as I have also pointed out, changes like this have
been done in the past with no regard to
Adrian Crum wrote:
There is no reason for you to pack up your marbles and go home.
The question is: There are classes in org.ofbiz.base.util that don't belong
there because they are data types, not utility classes. What do you think
about moving them to a different package?
And I *have*
David E Jones wrote:
This is just my opinion, but unless we move to a structures of limited
external interfaces separate from the internal implementations of those
interfaces, it's going to be tough to maintain backward compatibility. The
problem is every line of Java, XML, etc, etc in the
Adam,
what you say is right but it is also true that if a development team was able
to create a custom application on OFBiz, it should also be able to figure this
out quite easily.
Everyone in the software industry is aware that after an upgrade the
tools/framework used to build a custom
Jacopo Cappellato wrote:
Adam,
what you say is right but it is also true that if a development team was able
to create a custom application on OFBiz, it should also be able to figure
this out quite easily.
Everyone in the software industry is aware that after an upgrade the
On 20/02/2010, at 12:01 PM, Jacopo Cappellato wrote:
On Feb 20, 2010, at 6:49 PM, Adam Heath wrote:
Jacopo Cappellato wrote:
Adam,
what you say is right but it is also true that if a development team was
able to create a custom application on OFBiz, it should also be able to
figure
On Feb 20, 2010, at 8:10 PM, Scott Gray wrote:
Again, I agree with you and I also agree that documenting this change is a
good idea.
But I still think that this specific issue could be discovered and fixed
(even without documentation) by a decent developer in less than 20 minutes
after a
lekt...@apache.org wrote:
Author: lektran
Date: Sat Feb 20 20:19:35 2010
New Revision: 912212
URL: http://svn.apache.org/viewvc?rev=912212view=rev
Log:
Removed unneccesary deprecation warning suppression
Congrats on your use of git!
On 20/02/2010, at 1:23 PM, Adam Heath wrote:
lekt...@apache.org wrote:
Author: lektran
Date: Sat Feb 20 20:19:35 2010
New Revision: 912212
URL: http://svn.apache.org/viewvc?rev=912212view=rev
Log:
Removed unneccesary deprecation warning suppression
Congrats on your use of git!
==
--- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
(original)
+++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
Sat Feb 20 22:53:18 2010
@@ -59,9 +59,10 @@
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
==
--- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
(original)
+++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
lekt...@apache.org wrote:
Author: lektran
Date: Sat Feb 20 23:04:51 2010
New Revision: 912248
URL: http://svn.apache.org/viewvc?rev=912248view=rev
Log:
Reverting r912247, not all methods removed had been deprecated prior to 9.04
When deprecation is added, in addition to adding @Deprecated
Scott Gray wrote:
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
==
---
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
(original)
+++
On 20/02/2010, at 4:21 PM, Adam Heath wrote:
lekt...@apache.org wrote:
Author: lektran
Date: Sat Feb 20 23:04:51 2010
New Revision: 912248
URL: http://svn.apache.org/viewvc?rev=912248view=rev
Log:
Reverting r912247, not all methods removed had been deprecated prior to 9.04
When
Scott Gray wrote:
On 20/02/2010, at 4:24 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
==
---
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/model/ModelEntity.java
On 20/02/2010, at 4:34 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:24 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
==
---
Scott Gray wrote:
On 20/02/2010, at 4:34 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:24 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
==
---
==
[java] 2010-02-20 17:59:00,328 (main) [
SequenceUtil.java:339:INFO ] Got bank of sequenced IDs for
[EntityAuditLog]; curSeqId=14430, maxSeqId=14440, bankSize=10
[java] 2010-02-20 17:59:00,463 (main) [
SequenceUtil.java:339:INFO ] Got bank of sequenced IDs for
[EntitySyncRemove];
On 20/02/2010, at 4:44 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:34 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:24 PM, Adam Heath wrote:
Scott Gray wrote:
On 20/02/2010, at 4:18 PM, Adam Heath wrote:
bus...@apache.org wrote:
Author: buscob
Date: Sun Feb 21 00:56:11 2010
New Revision: 912269
URL: http://svn.apache.org/viewvc?rev=912269view=rev
Log:
Better dropdown menu handling in tomahawk theme.
The menus are not shown during page loading.
Replaced hide/show toggling with explicit
oops,
sorry, you are right. I'll do better next time.
-Bruno
2010/2/21 Adam Heath doo...@brainfood.com:
bus...@apache.org wrote:
Author: buscob
Date: Sun Feb 21 00:56:11 2010
New Revision: 912269
URL: http://svn.apache.org/viewvc?rev=912269view=rev
Log:
Better dropdown menu handling in
Fixed in trunk at revision 912269
Thank you Scott for reporting.
-Bruno
2010/2/20 Scott Gray scott.g...@hotwaxmedia.com:
An additional issue (which is probably related to the menu being exposed
during page load):
If I click on a menu item directly underneath the mega menu (or whatever they
doo...@apache.org wrote:
Author: doogie
Date: Sun Feb 21 01:30:59 2010
New Revision: 912279
URL: http://svn.apache.org/viewvc?rev=912279view=rev
Log:
Lots and lots of tests for FSE; not 100% coverage, there are some bugs
that need to be fixed.
You'll note that doing problem testing is
33 matches
Mail list logo
