tbd. But basically an option to do so. That was also the reason, why in the default resolver I have written the ant-style resolution was added only as a last option, so it can be refactored out easily...
2015-01-03 23:20 GMT+01:00 Mark Struberg <[email protected]>: > That sounds like a really good feature for a config extension. A > PropertySource base class which gets a reg-exp (or ant-style) to pick up > various configurations. > > > But I would not do that in Tamaya core. Here we probably just need to > pickup a property files with a single well defined name. All other > PropertySources can be added by the customer himself. > > We could add this in the extension/modules part and depend on the original > ant jar to pick those resources up. > > LieGrue, > strub > > > > On Saturday, 3 January 2015, 23:00, Anatole Tresch <[email protected]> > wrote: > >I already explained that. I often have the case where I have > locations/Folders defined in cp or on disk, where I have config files. And > simply do not know how the files are named exactly in advance. And I want > to be able as spi programmer to simply descriptivly define what I want to > to be included... > > > >Mark Struberg <[email protected]> schrieb am Sa., 3. Jan. 2015 um 22:55: > > > >Rewriting the TestPropertySource with the exact same content was exactly > 11 lines of code. > >> > >> > >>Why would we need something like the ant-resource DSL? We don't have > jelly or XML scripting (like maven1, ant and spring). We can simply do that > stuff ourselves with ClassLoader.getResources() or file lookup etc. All in > pure java. All the spring-ant stuff is really not needed in Tamaya. This is > just needed for dynamic scripting. I fail to see where we would need > scripting. We have plain Java so far. > >> > >>LieGrue, > >>strub > >> > >> > >>On Saturday, 3 January 2015, 22:31, Anatole Tresch <[email protected]> > wrote: > >> > >> > >>> > >>> > >>>Look at the test property source providers. They support ant styled > lookup of config files from cp and file system. > >>> > >>>Second is the separation of a resource (suppöier<inputstream>) of the > code parsing the input (the format). > >>> > >>>Mark Struberg <[email protected]> schrieb am Sa., 3. Jan. 2015 um > 22:08: > >>> > >>>Hi Anatole! > >>>> > >>>>Sorry if I removed any of the code YOU wrote. I simply just deleted > all classes which had the Spring copyright in them. > >>>> > >>>>Which changes/functionality did you apply on top of those classes? > Happy to keep those! > >>>> > >>>>LieGrue, > >>>>strub > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> On Saturday, 3 January 2015, 21:52, Anatole Tresch < > [email protected]> wrote: > >>>>> > Hi Mark, > >>>>> > >>>>> Thats not the point. You removed much more than was necessary. > Basically > >>>>> you removed all my work of today as well. The Spring part is > something i > >>>>> want to see from a functionaliy perspective, but this would be only > a small > >>>>> part of what you removed. > >>>>> Just pointing me to the licence issue, would be enough. You could > also > >>>>> provide that super easy code, so I could replace the stuff. That > would be > >>>>> real collaboration imo. > >>>>> > >>>>> So I appologize for being too naive about licencing, but I still > expect > >>>>> more interaction and respect about contributions done before just > deleting > >>>>> others work. If not, I recommend you do the work on your own. > >>>>> > >>>>> Best > >>>>> Anatole > >>>>> Mark Struberg <[email protected]> schrieb am Sa., 3. Jan. 2015 um > 21:28: > >>>>> > >>>>>> This is really straight forward. Apache doesn't copy code from > other > >>>>>> projects where we don't have all the full rights. And for those > sources > >>>>> we > >>>>>> clearly do not own the copyright! > >>>>>> > >>>>>> > >>>>>> How do you know that those sources are IP clean? You simply cannot > be sure > >>>>>> because you didn't write it yourself. > >>>>>> > >>>>>> This would have required a formal donation to the ASF an own IP > check > >>>>>> (going through all the history, etc) and of course mentioning in > the NOTICE > >>>>>> files. > >>>>>> > >>>>>> > >>>>>> And there is a second important point: this code is just not > needed! > >>>>> It's > >>>>>> from the spring-ant integration it seems. What do we need that > for? It is > >>>>>> totally simple to write this ourselves EXACTLY as we need it. > There is just > >>>>>> no need for 20 additional classes which we barely can use. > >>>>>> > >>>>>> Btw we also need to review all the LICENSE and NOTICE files. > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Saturday, 3 January 2015, 21:17, Anatole Tresch > >>>>> <[email protected]> > >>>>>> wrote: > >>>>>> > >>>>>> >Hi Mark > >>>>>> > > >>>>>> > > >>>>>> >once more: I would expect to ask/discuss things first before just > >>>>>> removing: > >>>>>> > > >>>>>> > > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/formats/ConfigurationFormat.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/formats/PropertiesFormat.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/formats/PropertiesXmlFormat.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/logging/ > >>>>>> AbstractDelegatingLogger.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/logging/ > >>>>>> Log4j2Logger.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/logging/ > >>>>>> Log4jLogger.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/logging/ > >>>>>> Slf4jLogger.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> AbstractFileResolvingResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> AntPathMatcher.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> ClassPathResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> DefaultResourceLoader.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> FileSystemResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> InputStreamResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> PathMatchingDefaultResourceLoader.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> PathMatchingResourcePatternResolver.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> ReflectionUtils.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> ResourceUtils.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> UrlResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/internal/resource/ > >>>>>> VfsResource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/internal/resource/VfsUtils.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/PathBasedPropertySourceProvide > >>>>>> r.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/ResourcePropertySourceProvider > >>>>>> .java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/resources/InputStreamSource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/resources/Resource.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> > core/src/main/java/org/apache/tamaya/core/resources/ResourceLoader.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/util/ClassUtils.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/main/java/org/apache/tamaya/core/util/StringUtils.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/test/java/org/apache/tamaya/core/testdata/ > >>>>>> TestPropertyDefaultSourceProvider.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/test/java/org/apache/tamaya/core/testdata/ > >>>>>> TestPropertySourceProvider.java > >>>>>> > * file://C:/Users/Anatole/IdeaProjects/incubator-tamaya/ > >>>>>> core/src/test/resources/META-INF/services/org.apache.tamaya.spi. > >>>>>> PropertySourceProvider > >>>>>> >-> Parts of it may be rewritten, OK. Fair enough. > >>>>>> >-> Actually I dont understand, why we cannot reuse some of the > code > >>>>> here: > >>>>>> it is Apache licencsed as well. We just have to mention it. > >>>>>> >-> Basically only 8 artifacts (more or less) would be afftected, > by > >>>>> far > >>>>>> not all. > >>>>>> > > >>>>>> > > >>>>>> >I am really thinking of stopping my work here. Mark., I aüpreciate > >>>>>> discussing things, but simply throwing away things within in > minutes is not > >>>>>> a collaboration model I will support. It is not worth my time! > >>>>>> > > >>>>>> > > >>>>>> >Cheers, > >>>>>> >Anatole > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >2015-01-03 18:45 GMT+01:00 Mark Struberg <[email protected]>: > >>>>>> > > >>>>>> >Just check what is NOT Copyright Apache but something else. Sadly > this > >>>>> is > >>>>>> actually quite a lot. > >>>>>> >> > >>>>>> >>LieGrue, > >>>>>> >>strub > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >>On Saturday, 3 January 2015, 18:33, John D. Ament > >>>>> <[email protected]> > >>>>>> wrote: > >>>>>> >> > >>>>>> >> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>I'll be curious to see this when pushed. > >>>>>> >>> > >>>>>> >>> > >>>>>> >>>On Sat Jan 03 2015 at 12:18:10 PM Mark Struberg > >>>>> <[email protected]> > >>>>>> wrote: > >>>>>> >>> > >>>>>> >>>Hi! > >>>>>> >>>> > >>>>>> >>>>I now removed the logging parts: it is not our job to > >>>>> integrate with > >>>>>> various logger frameworks. This should be done by the > container/program who > >>>>>> uses us as dependency. > >>>>>> >>>> > >>>>>> >>>>I also removed quite a few classes which are taken from the > >>>>> spring > >>>>>> framework. They are copyrighted to the original authors and we > don't > >>>>> have > >>>>>> all rights for it! Those classes are trivial anyway and it would > be simple > >>>>>> to put code from commons or write it ourselves. > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>>LieGrue, > >>>>>> >>>>strub > >>>>>> >>>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >> > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> >-- > >>>>>> > > >>>>>> >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/ > >>>>>> >Google: atsticks > >>>>>> >Mobile +41-76 344 62 79 > >>>>>> > > >>>>>> > > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > -- *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*
