Emmanuel Bourg schrieb:
Oliver Heger a écrit :
The main reason for the restructuring of the packages was to increase
modularity, which is especially important in environments like OSGi
where you have fine control over the packages to import. An "all
configurations in the main package" approach
Oliver Heger a écrit :
The main reason for the restructuring of the packages was to increase
modularity, which is especially important in environments like OSGi
where you have fine control over the packages to import. An "all
configurations in the main package" approach won't help here.
By "in
Emmanuel Bourg wrote:
> Oliver Heger a écrit :
>
>>> XMLConfiguration and XMLPropertiesConfiguration remain in the main
>>> package.
>>
>> Why?
>
>
> The purpose of the package is to group only the SAX readers as they form
> a hierarchy providing a specific feature, just like the BeanUtils brid
Oliver Heger a écrit :
XMLConfiguration and XMLPropertiesConfiguration remain in the main
package.
Why?
The purpose of the package is to group only the SAX readers as they form
a hierarchy providing a specific feature, just like the BeanUtils bridge
in the beanutils package. I don't know i
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
Would XMLConfiguration also go into this package?
XMLConfiguration and XMLPropertiesConfiguration remain in the main
package.
Why?
Oliver
In this regard the package name o.a.c.c.sax would make more sense.
Emmanuel Bourg
-
Oliver Heger a écrit :
Would XMLConfiguration also go into this package?
XMLConfiguration and XMLPropertiesConfiguration remain in the main
package. In this regard the package name o.a.c.c.sax would make more sense.
Emmanuel Bourg
---
Emmanuel Bourg schrieb:
Oliver Heger a écrit :
I would like to keep main package pretty small, so that it only
contains the basic interfaces and abstract base classes.
Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I am
Oliver Heger a écrit :
I would like to keep main package pretty small, so that it only contains
the basic interfaces and abstract base classes.
Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I am not sure how to
handle
Oliver Heger a écrit :
Sub packages would group classes with similar functionality. The plist
and web packages are good examples for that, but I am not sure how to
handle specific implementations consisting of only one or two classes
(e.g. INIConfiguration). Putting them in their own package pr
Emmanuel Bourg schrieb:
+1 for removing the old configurations, otherwise that would be
confusing for the users.
Regarding the package structure do you have other plans besides the
'flat' package ?
I would like to keep main package pretty small, so that it only contains
the basic interfaces
+1 for removing the old configurations, otherwise that would be
confusing for the users.
Regarding the package structure do you have other plans besides the
'flat' package ?
Emmanuel Bourg
Agreed. After refactoring of the hierarchical file-based configurations
is complete, it shows that t
Oliver Heger wrote:
[snip]
< about the naming: If all our configurations are hierarchical (at least
> this is the plan currently), there does not seem to be much point in
> calling a concrete implementation
> "HierarchicalConfiguration". Therefore
> I used the name "InMemoryConfiguration" for the r
Jörg Schaible wrote:
> Oliver Heger wrote:
>
>>I have added new hierarchical configuration implementations
>>based on the
>>node handler approach.
>>
>>There is now a new AbstractHierarchicalConfiguration class
>>providing basic functionality for dealing with hierarchical
>>structures.
>>
>>Deriv
Oliver Heger wrote:
> I have added new hierarchical configuration implementations
> based on the
> node handler approach.
>
> There is now a new AbstractHierarchicalConfiguration class
> providing basic functionality for dealing with hierarchical
> structures.
>
> Derived from that is InMemoryCo
I have added new hierarchical configuration implementations based on the
node handler approach.
There is now a new AbstractHierarchicalConfiguration class providing
basic functionality for dealing with hierarchical structures.
Derived from that is InMemoryConfiguration, which is almost equiva
15 matches
Mail list logo
