I would say we can add alt-dd as a module (simply adds another overriding
property source).
The name is just "historically grown", we can discuss it ,)

2015-03-25 10:14 GMT+01:00 Romain Manni-Bucau <[email protected]>:

> From a spec perspective we should support altdd (even if I never used it)
> and hardcoded name. If you want another name you register another property
> source (that said a default provider adding one if this property is set can
> work).
>
> Side question: why don't we use tamaya.properties while project is tamaya
> and not javaconfiguration?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-03-25 10:11 GMT+01:00 Werner Keil <[email protected]>:
>
> > From Cologne or even Düsseldorf?;-O
> >
> > After my DeviceMap talk in Rome I also fly back with Germanwings on
> Sunday
> > btw.
> >
> > About META-INF/javaconfiguration.properties will have a look at the user
> > guide, but out of curiosity, since I deal with java.util.logging in other
> > places, is there a way to override default properties via something like
> > -Dtamaya.config.properties=<path of file> already?
> > If not, how do you feel about such option?
> >
> > Werner
> >
> >
> >
> > On Tue, Mar 24, 2015 at 10:46 PM, Anatole Tresch <[email protected]>
> > wrote:
> >
> > > Dear all
> > >
> > > I committed a big update some minutes ago containing:
> > >
> > >
> > >    - I created a sandbox module directory moving many of the
> unfinished,
> > >    unstable, empty parts into it.
> > >    - I implemented a default behaviour and adapted the minimal
> > >    implementation in core, that adds System Props and all files found
> on
> > >    META-INF/javaconfiguration.properties (as already described by the
> > > current
> > >    user guide).
> > >    - I fixed some design issues in formats and adapte all code
> affected.
> > >    - I was going through a lot of code (not all) of existing modules
> and
> > >    reduced API footprint, things exposed, where I find it not
> necessary.
> > > E.g.
> > >    where URL is taken as resource input, it is not necessary to have
> > files
> > > on
> > >    top of it.
> > >    - Removed code that duplicates aspects already solved in other
> > modules,
> > >    e.g. formats. In one case I extended the formats module with a
> method
> > >    removed, hereby extending the (already existing) generic
> functionality
> > >    instead of reimplementing a non generic approach.
> > >    - I added an *examples *folder and created a first couple of
> isolated
> > >    examples illustrating some of the features we have now in place,
> > > starting
> > >    from simple, writing your own PropertySource, using resources,
> > resolver
> > > and
> > >    events module. I used them during my talk today. Beside the events
> > > example
> > >    (there is an issue in the events module I have to fix), everything
> > > should
> > >    work.
> > >
> > > Please review the modules that were not written by me for changes done.
> > If
> > > you have deep disagrees let us discuss things here on the mailing list,
> > > what we can do.
> > >
> > > @Oliver The current build will fail, because FindBugs again comes up
> > with a
> > > useless false positive (can you switch that rule out completely ;) ):
> > > The class org.apache.tamaya.metamodel.simple.SimpleConfigProvider$1
> could
> > > be refactored into a named _static_ inner class
> > > ["org.apache.tamaya.metamodel.simple.SimpleConfigProvider$1"] At
> > > SimpleConfigProvider.java:[lines 67-72]
> > >
> > > I also commented out Arquilian deps on core, because I had issues with
> it
> > > during test execution. Perhaps somebody can have a look at that so we
> can
> > > reenable/readd these tests again...
> > >
> > > Thanks and have a good night.
> > >
> > > Cheers,
> > > Anatole
> > >
> > > PS.: Be with me, I have to fly back tomorrow with GermanWings...
> > >
> >
>



-- 
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon

*Switzerland, Europe Zurich, GMT+1*
*Twitter:  @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*

*Google: atsticksMobile  +41-76 344 62 79*

Reply via email to