There was actually a discussion about this on this mailing list.
The consensus seemed to be in favour of what Ganath proposed. I though that was
unfortunate because have non-source directories under an src directory is an
annoying practice IMO, and I HATE to see that going into the project. I
On Jul 13, 2011, at 10:23 PM, Adam Heath wrote:
On 07/13/2011 03:17 PM, David E Jones wrote:
There was actually a discussion about this on this mailing list.
The consensus seemed to be in favour of what Ganath proposed.
I though that was unfortunate because have non-source
directories
I've been doing a little more research on Maven, and I'm guessing that the
pattern that Ganath is proposing is at least partly based on the convention for
src directories in Maven (which appears to be required for use of Maven, BTW...
ie with their convention over configuration approach, which
[
https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068828#comment-13068828
]
David E. Jones commented on OFBIZ-4346:
---
Adding a class per database
[
https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068996#comment-13068996
]
David E. Jones commented on OFBIZ-4346:
---
The concern of the attribute is not so much
We have a general precedence for not removing things people might be using,
which is anything in the project, especially without reasonable notice (like
waiting a while for comment).
On the other hand, if the company behind these services no longer existed or
something like that (I don't know
On Aug 21, 2011, at 2:56 AM, Adrian Crum wrote:
I know we have discussed this before, but I'm trying to use the OFBiz party
classification entities for another client and I'm running into the same
problem I've had before - the current party classification data model just
doesn't work.
[
https://issues.apache.org/jira/browse/OFBIZ-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092927#comment-13092927
]
David E. Jones commented on OFBIZ-4379:
---
Why not just use the [] syntax to get
There was an old thread about this with a few complaints, but it looks like it
stands.
Maybe more discussion and/or a commit war is in order? ;)
-David
On Aug 30, 2011, at 9:15 PM, Jacques Le Roux wrote:
widget.properties's widget.verbose setting has precedence over web.xml's
, David E Jones d...@me.com
wrote:
Every single *Type entity in OFBiz is a deviation from
the
book (ie the *Type entities are an OFBiz pattern to
avoid
redundant entities and keep track of entity extensions
like
the Party - PartyGroup,Person thingy), as are
dozens of
other entities
Do we even have a policy about supporting releases, let alone a policy about
which releases to support?
In other words, what can a user of Apache OFBiz expect to get as part of this
official support?
-David
On Sep 6, 2011, at 9:28 AM, Jacques Le Roux wrote:
Thanks Hans,
Yes of course
My favorite is the FishEye UI, provided by Atlassian:
https://fisheye6.atlassian.com/browse/ofbiz
-David
On Sep 11, 2011, at 5:19 PM, Scott Gray wrote:
As a side note, if anything seems in the least bit strange to me the first
thing I ALWAYS do is to check the revision history for the
No one agrees with which approach? The approach that if you pass a
widgetVerbose=true HTTP parameter that it should override the widget.properties
setting? I agree with that approach…
-David
On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
That's the problem - no one agrees with that
Did you consider that changing this seed data will make ALL current production
data that depends on this data suddenly break?
In fact for existing systems, by this change alone, you'll be adding new
records and not modifying the existing records because the PK (geoId) is being
changed.
in
the widget.properties file overrides any other setting.
-Adrian
On 9/12/2011 6:19 PM, David E Jones wrote:
No one agrees with which approach? The approach that if you pass a
widgetVerbose=true HTTP parameter that it should override the
widget.properties setting? I agree with that approach
a window to fix this data...
Should not better concerned systems update and fix data? Then maybe we
could provide a mean for that?
Jacques
From: David E Jones d...@me.com
Did you consider that changing this seed data will make ALL current
production data that depends on this data
/2011 6:19 PM, David E Jones wrote:
No one agrees with which approach? The approach that if you pass a
widgetVerbose=true HTTP parameter that it should override the
widget.properties setting? I agree with that approach…
-David
On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
That's
, but I wonder then if
we will never find a window to fix this data...
Should not better concerned systems update and fix data? Then maybe we
could provide a mean for that?
Jacques
From: David E Jones d...@me.com
Did you consider that changing this seed data will make ALL current
production
[
https://issues.apache.org/jira/browse/OFBIZ-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588403#action_12588403
]
David E. Jones commented on OFBIZ-1716:
---
The NSF retry stuff can be used for any
[
https://issues.apache.org/jira/browse/OFBIZ-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588474#action_12588474
]
David E. Jones commented on OFBIZ-1189:
---
What you're describing is a difference
or questions on his commits.
Should we revert this commit?
Jacopo
On Apr 9, 2008, at 4:29 AM, David E Jones wrote:
Actually, transactions ARE important for reading as well as
writing, and should pretty much always be used.
What was the problem you had that this change is supposed to solve
released about
an year
ago, we should have next release soon!
BTW I think that using JIRA release management features (roadmap,
change
log
and issue fix version) will be of great help to the community.
Take this
as
just a suggestion from a JIRA fun ;-).
-Bruno
2008/4/10, David E Jones
[
https://issues.apache.org/jira/browse/OFBIZ-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David E. Jones closed OFBIZ-1755.
-
Resolution: Invalid
Assignee: David E. Jones
The error mentioned is saying that you cannot
That is part of the reason, but technically we could do that with
OFBiz running inside of Tomcat instead of Tomcat embedded in OFBiz.
Actually, in the first few years of OFBiz it wasn't too hard to
checkout, build, deploy, and run OFBiz when it was running inside
another app server. The
I recently noticed the following lines in the AccountingTypeData.xml
file (starting around line 511):
!-- An Enumeration to identify the taxable invoice item types. For
these, the only important fields are enumId and enumTypeId. --
EnumerationType description=Taxable Invoice Item Types
One thing to consider is that the TechDataCalendarWeek entity may
eventually be deprecated in favour of using the WorkEffort (with
workEffortTypeId=AVAILABLE) and Recurrence* entities.
-David
On Apr 23, 2008, at 4:26 AM, Bilgin Ibryam wrote:
Hi all,
I just created new happy hour
Usually for join entities with effective dates (from/thru dates)
(like PartyRelationship) the delete service does actually delete the
record. If you want to expire the record, just use the update service.
-David
On Apr 24, 2008, at 12:08 AM, Sumit Pandit wrote:
Hello all,
I saw the
On Apr 24, 2008, at 1:45 AM, Jacopo Cappellato wrote:
What is the meaning of the SettlementTerm entity?
Is it an old entity or something created during the very initial GL
design and never implemented.
By looking at its seed data it seems to me a duplication of the
payment terms as already
Why not just use a view-entity to reduce round-trips to the database
and select by the productId and the relevant feature ids?
-David
On Apr 24, 2008, at 8:44 PM, Hans Bakker wrote:
The new feature explosion is now most implemented and shows , in speed
as a big improvement. However
of productFeatureAppl
any idea how this view would look like?
so i want a variant from product assoc which has all the selected
features on the screen as standard features in productFeatureAppl
On Thu, 2008-04-24 at 20:57 -0600, David E Jones wrote:
Why not just use a view-entity to reduce
that if they were different fields...but these are
the same fields with different values on different records.
regards,
Hans
On Thu, 2008-04-24 at 22:44 -0600, David E Jones wrote:
You would need to join the ProductFeatureAppl entity into the view
multiple times (once for each feature selected
[
https://issues.apache.org/jira/browse/OFBIZ-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592941#action_12592941
]
David E. Jones commented on OFBIZ-1525:
---
Not sure what Jacques was going
The design intent going forward is still to deprecate the
TechDataCalendarWeek entity and make sure that the Recurrence*
entities can handle those sorts of time period definitions.
Sooner or later someone needs to go through and figure that out,
extending the entity and the generic
On Apr 29, 2008, at 2:54 PM, Ean Schuessler wrote:
David E Jones wrote:
This is a great tool. The problem with the tool and the approach in
general to this sort of release management is that it assumes top-
down management of a project.
In the Release Plan document it starts out
On Apr 29, 2008, at 11:25 PM, Bruno Busco wrote:
David,
I totally agree with your vision, the purpose of my original
proposal to use
the JIRA roadmap feature was just to have a clear understanding of
your
points 1), 2) and 3)
So that, day by day, everyone can clearly see what the community
Ltd.
在 2008-04-29二的 22:06 -0600，David E Jones写道：
On Apr 29, 2008, at 2:54 PM, Ean Schuessler wrote:
David E Jones wrote:
This is a great tool. The problem with the tool and the approach in
general to this sort of release management is that it assumes top-
down management of a project
Yes, I'd say remove them... it's kind of evil in the first place to
have style names in the XSD file... ;)
Let's move away from that practice ASAP!
-David
On May 1, 2008, at 9:43 AM, Adrian Crum wrote:
I was going through the widget-menu.xsd file - intending to update
the default values
to coordinate it for now,
but there is certainly room for public credit and mention of
contributors to the relevant materials.
-David
On Apr 29, 2008, at 10:06 PM, David E Jones wrote:
On Apr 29, 2008, at 2:54 PM, Ean Schuessler wrote:
David E Jones wrote:
This is a great tool. The problem
spend some time going through the UI and make sure it's
compatible with the latest IE. I was planning on doing that anyway.
Plus, I have experience with preparing press releases.
-Adrian
David E Jones wrote:
Any other comments on this? I'd really love to get the framework
shaped up
, 2008, at 9:15 PM, David E Jones wrote:
Any other comments on this? I'd really love to get the framework
shaped up and cleaned up as much as we plan to for the near future
so we can release something and keep it stable for a while...
Related to this, when we release the framework I really
A few months ago I spent some time discussing and adding some new find
methods to the GenericDelegator, namely the find, findList, and
findOne methods.
As part of the effort to refine and improve things in the framework in
preparation for a GA binary release I took the next step on this
Could you be more specific? I don't understand the question.
-David
On May 3, 2008, at 10:17 AM, BJ Freeman wrote:
what will happen to the effort to keep the applications working with
the
frame work?
David E Jones sent the following on 5/2/2008 1:09 PM:
Yes, exactly.
The main intent
the framwork.
is this accruate?
David E Jones sent the following on 5/3/2008 10:44 AM:
Could you be more specific? I don't understand the question.
-David
On May 3, 2008, at 10:17 AM, BJ Freeman wrote:
what will happen to the effort to keep the applications working
with the
frame work
to see the cool effects and improved response
implemented without any additional work on the widget XML files.
What do you think?
-Adrian
David E Jones wrote:
I guess this is a continuation of the discussion in the thread
uilabels and screenlet widget, and is related somewhat to part
have seen the Ajax work done in the Example component.
Regarding the alternate HTML rendering classes, I don't think
those will be needed. My thinking right now is to just evolve the
existing HTML rendering classes.
-Adrian
David E Jones wrote:
Adrian,
This sounds great for the elements
done in the Example component.
Regarding the alternate HTML rendering classes, I don't think those
will be needed. My thinking right now is to just evolve the existing
HTML rendering classes.
-Adrian
David E Jones wrote:
Adrian,
This sounds great for the elements that have some sort
It might be good to simplify it a little and use a changeTypeEnumId
(or the like) instead of the type field and related entity. There is
probably nothing special we would want to add to the type entity, so
the Enumeration, with a special EnumeractionType, is adequate.
-David
On May 10,
Good point Scott... I was a little ahead of myself on that one. I've
removed that in SVN rev 655242.
-David
On May 10, 2008, at 8:12 PM, Scott Gray wrote:
Hi David,
How would I go about replacing calls to this method? find() only
takes an
entity name.
Thanks
Scott
/** Finds
This does seem like a really funny reason to not do pagination,
especially if paginate is set to true
I would say yes, a default page size more than makes sense, and it
actually seems odd that there isn't one!
On many pages we use a size of 20, but maybe something like 10 is more
Lookin' good Adrian.
-David
On May 12, 2008, at 10:29 AM, [EMAIL PROTECTED] wrote:
Author: adrianc
Date: Mon May 12 09:29:30 2008
New Revision: 60
URL: http://svn.apache.org/viewvc?rev=60view=rev
Log:
Implemented page size defaults for the form widget lists. Some code
was already
I
was working on it!)
David, if you want to deprecate some more of the delegator's methods
I'm
happy to carry on.
Regards
Scott
2008/5/3 David E Jones [EMAIL PROTECTED]:
As part of the effort to refine and improve things in the framework
in
preparation for a GA binary release I took
...
-David
On May 13, 2008, at 3:51 AM, Jacopo Cappellato wrote:
I guess that another task in this direction is cleaning up the
Minilang code as well... for example, transform find-by-primary-key/
into entity-one/
etc...
Jacopo
On May 13, 2008, at 6:45 AM, David E Jones wrote:
Wow
On May 13, 2008, at 8:31 AM, Adrian Crum wrote:
David E Jones wrote:
Does anyone have other ideas for things here (or in other parts of
the framework) to clean up?
-David
I have some ideas for cleaning up screen widget code, but they
probably won't go over very well. ;-)
Do you mean
Stepping back a little (to hopefully make it easier to see what needs
to be done here), from a business perspective does it mean and what
needs to happen when you cancel an ItemIssuance?
When an item is issued from inventory (usually to a shipment), it
represents a stock-out and
Hans: thanks for your attention and this, and sorry for delaying the
fix. Login not working after a password change is a pretty serious bug!
The problem was that in the LoginServices.userLogin method/service it
wasn't removing the prefix from both the password entered and the
password
[
https://issues.apache.org/jira/browse/OFBIZ-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David E. Jones closed OFBIZ-1779.
-
Resolution: Fixed
Assignee: David E. Jones
Thanks Joe, this is now in SVN (following your
This is a good idea, and an easy way to improve ecommerce with mostly
existing functionality.
I like #c personally... the most flexible and transparent/visible to
the customer.
-David
On May 15, 2008, at 11:21 PM, Jacopo Cappellato wrote:
Using the backend order entry application
the comparison look like?
Thanks in advance,
Regards,
Hans
On Fri, 2008-04-25 at 00:40 -0600, David E Jones wrote:
Yes, exactly, and that is what including the same entity multiple
times as different member-entities with different aliases in a view-
entity is all about.
For some nice complex
Thanks to some recent work from Joe Eckard OFBiz now has pretty good
support for the Groovy scripting language.
While this is kind of interesting on its own, what was really
interesting was to find out (after not looking at groovy for probably
about 4 years) that it supports nearly all
It's been a few years since we made the switch, so Jetty may have
caught up in that time. During that switch the biggest issue was that
Jetty only supported session replication (for fail-over purposes) if
run with JBoss, and Tomcat had a much better/cleaner implementation
that didn't
[
https://issues.apache.org/jira/browse/OFBIZ-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David E. Jones closed OFBIZ-1756.
-
Resolution: Fixed
Fix Version/s: SVN trunk
Assignee: Bilgin Ibryam
This approach
On May 21, 2008, at 6:10 AM, Jacopo Cappellato wrote:
When a customer return of type store credit is approved, OFBiz
creates a new Billing Account and 'stores' the credit in a payment
associated to the billing account.
I'm wondering if we should use a FinAccount instead of a billing
On May 21, 2008, at 10:51 PM, Jacopo Cappellato wrote:
I'm completing my tests for the upgrade from Tomcat 5 to Tomcat 6
and, in this process I will have to upgrade some of the api jars in
the base/lib/j2eespecs folder with the new ones bundled with Tomcat 6:
Usually these modified BSD/MIT/X/etc licenses are just fine. We do
have to review anything added or removed to make sure they don't
require anything of the software user that the Apache 2.0 license
doesn't require, considering that attribution and such which is fine
(and what the NOTICE
On May 22, 2008, at 9:11 AM, Adrian Crum wrote:
2) If a screen has a list and add form, what should be the order of
these
forms (I have seen in your recent work that add form should come on
top and
I completely
agree with this).
I believe the form should be on top of the list.
21, 2008, at 2:08 AM, David E Jones wrote:
This is a vote based on the recent discussion thread for changing
the OFBiz best practice tool for writing data preparation scripts
from using Beanshell to using Groovy, and more generally making
Groovy the standard scripting language wherever
Yes that's a good idea Adrian... would be more generic.
I saw an email between Anil and Jacopo (off-list) related to this and
commented on something that is quite important and concerning: if we
allow the client/browser to send an entity name and other such fields
we are basically opening
.
Regards
Scott
2008/5/23 David E Jones [EMAIL PROTECTED]:
On May 22, 2008, at 9:11 AM, Adrian Crum wrote:
2) If a screen has a list and add form, what should be the order of
these
forms (I have seen in your recent work that add form should come
on top
and
I completely
agree with this).
I
consuming (especially in Firefox). This is currently a major
inconvenience for Lookups and Calendar for instance
Jacques
From: David E Jones [EMAIL PROTECTED]
Since we're entering the world of using more javascript in the
browser, why not have the add form on the top but hidden by
default
Let's just kill the ECA rule that calls it. I'm not sure what it was
originally intended for anyway, and I just moved it away from the
service I wanted to test (the bsh test service) so I could test it.
It is supposed to cause an error, so we should probably just comment
out the ECA and
As part of the effort to do a GA release of the framework
documentation can play a big role in how much it is adopted and how
well it is used. This is of course true for OFBiz in general as well,
related to the framework specifically for the point of this email.
Anyway, the more
code and see if we can derive our own thread-safe
classes from some of their code. Let me know if you think it is
worth pursuing.
-Adrian
David E Jones [EMAIL PROTECTED] wrote:
A quick look at the GroovyUtil.java file revealed why this is
happening. I apologize for not reviewing this better
Yes, please go for it then.
-David
On May 27, 2008, at 1:05 PM, Adrian Crum wrote:
David,
I'd like to work on it. I have some time here and there over the
next week or two. I you have more time to devote to it, then go
ahead. Either way works for me.
-Adrian
David E Jones wrote:
Yes
, in SVN rev 660695 we now have a parsed script cache working.
-David
On May 27, 2008, at 1:13 PM, Adrian Crum wrote:
Will do!
David E Jones wrote:
Yes, please go for it then.
-David
On May 27, 2008, at 1:05 PM, Adrian Crum wrote:
David,
I'd like to work on it. I have some time here and there over
[
https://issues.apache.org/jira/browse/OFBIZ-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600568#action_12600568
]
David E. Jones commented on OFBIZ-1806:
---
You don't need to explicitly specify
Yes, I agree with this approach. The most ideal thing is to always
write as directly to the writer as possible, and this even allows the
servlet container to progressively stream results to the client. Of
course, that means instead of using creating a StringWriter to use
temporarily the
On May 31, 2008, at 10:03 AM, Jacques Le Roux wrote:
Just one point : I'm not sure it's good to have forms collapsed by
default when there are results. If we would really want to have
something like that, whe should at least have an indicator to let
know the user that the list is not empty.
I'll third the appreciation Adrian, especially for being so thorough
and keeping an eye on this.
-David
On May 31, 2008, at 10:13 AM, Jacques Le Roux wrote:
Yes, thanks for the clear explanation Adrian. I think I will put
something in the FAQ page (about clear and no-clear usage). This
I did some work on this years ago doing a prototype of sorts in the
newcustomer.ftl page. This is for single type forms only, as for list
and multi forms a CSS layout doesn't make sense (given the tabular
nature of that layout).
The important CSS classes are form-row, form-label, and
.
Table layout is NOT evil - it is ideal for laying out columns and
rows (like forms).
CSS can be used to make tables look cool too. I'd rather see Ajax
efforts put into smart table headers that, when clicked, change
the sort order of the table.
-Adrian
David E Jones [EMAIL PROTECTED] wrote
On Jun 3, 2008, at 9:30 AM, Bilgin Ibryam wrote:
David,
Bilgin: is planning before hand what you had in mind?
Yes, I want to use Timesheet and TimeEntry entities to plan in advance
the working hours of employees. These two entities looks like enough
for
this purpose?
You are right, this
Yes, that's an interesting point Hans. Bilgin: is planning before hand
what you had in mind?
My thoughts reading this were that the shift they are part of is
redundant information because they can specify the starting and ending
times as opposed to just a number of hours (using the
Wow, thanks for doing this Adrian. This code has been neglected for a
long time, really from the beginning I'd say. I worked with Al a bit
on the design of the XML file for it, and he implemented the whole
thing and I haven't really looked at it since then. I'm glad there
were just a few
[
https://issues.apache.org/jira/browse/OFBIZ-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602196#action_12602196
]
David E. Jones commented on OFBIZ-1791:
---
I agree it would be good to do... the Jetty
On Jun 4, 2008, at 8:35 AM, Jacopo Cappellato wrote:
Hi all,
I would like to add support for the status for non serialized
inventory items (right now the status is used only for serialized
items).
The idea is to add a new status item for Damaged inventory (and
maybe On Hold for
On Jun 4, 2008, at 11:51 AM, Adrian Crum wrote:
It appears to me that there is a one-to-one relationship between a
fixed asset maintenance and a work effort to perform the
maintenance. Wouldn't it be better if there was a one-to-many
relationship?
Let's say I have a company truck fixed
On Jun 4, 2008, at 12:47 PM, Adrian Crum wrote:
One thing to keep in mind: the way WorkEfforts are designed a
single WorkEffort as a task or whatever can have various sub-
WorkEfforts associated with it.
Then there would have to be code to create sub tasks when intervals
are passed. That
Some quick feedback on the location/naming of things:
1. this code doesn't really have much to do with assetmaint and
instead is for Product and InventoryItem, so being fairly low-level it
should go in the product component where someone looking for it might
actually expect to find it
Thanks Ashish, this looks much more clear.
-David
On Jun 5, 2008, at 8:28 AM, [EMAIL PROTECTED] wrote:
Author: ashish
Date: Thu Jun 5 07:28:42 2008
New Revision: 663627
URL: http://svn.apache.org/viewvc?rev=663627view=rev
Log:
Moved the files to product component suggested by David.
Also
In the form widget something similar to what you describe exists.
After the field elements you can have a sort-order element which has a
sort-field element in it for each field in the order you want it.
Those sort-field elements can be put inside a field-group element, and
the
This seems to need some more review...
At the very least do NOT change the entity engine or other more
critical/used framework pieces without careful review.
In this case the long field type is really unnecessary and should
not be added to OFBiz, the existing numeric type should be used
to
increase above (19,0) (which was roughly retained by Sergey because
it was the following number, I guess), this was a good start.
Jacques
From: David E Jones [EMAIL PROTECTED]
This seems to need some more review...
At the very least do NOT change the entity engine or other more
critical/used
Does the groovy ? operator thrown in different places solve this
problem?
It seems like it's kind of like the ?if_exists in FTL, and may help
with things like this.
-David
On Jun 5, 2008, at 4:06 AM, Scott Gray wrote:
Hi Jacopo
I just ran a quick test and Groovy seems to throw an
: David E Jones [EMAIL PROTECTED]
I'm happy to go remove it myself... just let me know.
The point of a data dictionary is to keep things pretty minimal so
that it is fairly easy to remember the options and know what
each option means in Java and the physical database.
At the minute the long
Ashish,
When considering what to put in the HR application please keep in mind
the general pattern for the OFBiz base applications: they are meant to
be generic user interfaces that are mostly organized around the data
and not around a process or role and with minimal redundancy around
On Jun 9, 2008, at 12:59 AM, Harmeet Bedi wrote:
How stable are schemas in Ofbiz ?
At this point in time they are very stable. New entities and fields
are occasionally added, but very few other changes are done and the
basic entities have not changed for many years.
Are there any plans
I can think of two main ways of doing this:
1. list explicitly/inline the roles you want to show (instead of doing
a query)
2. create a parent role and put the roles you want under it and query
by the parent ID
As for which roles to use, and whether to create or not, it's totally
okay
This has been discussed before and decided against.
An easier solution would be to just put all of the configuration
properties in a single file, except that:
1. different components need different configuration and we don't want
to assume in this way which components or combinations of
On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
David E Jones wrote:
On side note I should mention that the direction has been discussed
and generally agreed on that application level properties should be
done away with (like payment.properties, and many others) and that
information
On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
David E Jones wrote:
On side note I should mention that the direction has been discussed
and generally agreed on that application level properties should be
done away with (like payment.properties, and many others) and that
information
901 - 1000 of 2419 matches
Mail list logo
