Sure but we cant rely on the container for SE case (why we need to discuss it later IMO) Le 3 janv. 2015 23:32, "Mark Struberg" <[email protected]> a écrit :
> agree, but this is not the goal of Tamaya afaik. We are no logger > framework project ;) > > This will be dealt with in the integration code. Parts we simply don't > know yet. > > LieGrue, > strub > > > > > > > On Saturday, 3 January 2015, 23:28, Romain Manni-Bucau < > [email protected]> wrote: > > > Yeah and confirm but nthg opposed to have JUL integration with other > > frameworks... > > > > To be honest id like to have it in a common jar at apache. At least 3 or > 4 > > apache projects forked them and much more could benefit from it (factory > + > > delegate logger impls) > > > > Le 3 janv. 2015 23:25, "Mark Struberg" <[email protected]> a > > écrit : > > > >> Romain, please see the mail from today in the morning with the topic > >> > >> '[DISCUSS] logging in core' > >> That was way before I committed and pushed it. > >> > >> You even gave your +1 ;) > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > On Saturday, 3 January 2015, 23:04, Romain Manni-Bucau < > >> [email protected]> wrote: > >> > > I didnt say i like it just it doesnt add any mandatory dep and > > solves a > >> > need. Issue with it is the same as what you did: no discussion - was > >> surely > >> > too early. > >> > > >> > Le 3 janv. 2015 22:54, "Mark Struberg" > > <[email protected]> a > >> > écrit : > >> > > >> >> Romain, explain me why you like the logging stuff? It introduces > >> >> dependencies to 3 other libs without adding anything. jul is > > totally > >> enough > >> >> as everyone can route it to any other logging framework himself > > very > >> > easily. > >> >> > >> >> LieGrue, > >> >> strub > >> >> > >> >> > >> >> > >> >> > >> >> > On Saturday, 3 January 2015, 22:34, Romain Manni-Bucau < > >> >> [email protected]> wrote: > >> >> > > We didnt discuss it so +1 for removal - btw you removed > > legal > >> > code as > >> >> well > >> >> > (logging stuff) > >> >> > > >> >> > Le 3 janv. 2015 22:32, "Werner Keil" > >> > <[email protected]> a > >> >> > écrit : > >> >> > > >> >> >> It's hard do judge by files that were already > > removed, > >> > what's the > >> >> > evidence > >> >> >> they should be from Spring? > >> >> >> > >> >> >> If the effort can be overseen rather easily, I think > > I'm fine > >> > with > >> >> >> +1 for B > >> >> >> but in future cases I really would like to know and > > learn why > >> > such > >> >> files > >> >> >> are an issue and which of them. > >> >> >> > >> >> >> Werner > >> >> >> > >> >> >> On Sat, Jan 3, 2015 at 10:13 PM, Reinhard Sandtner < > >> >> >> [email protected]> wrote: > >> >> >> > >> >> >> > +1 for B > >> >> >> > > >> >> >> > keep it simple ;-) > >> >> >> > > >> >> >> > lg > >> >> >> > reini > >> >> >> > > >> >> >> > > Am 03.01.2015 um 22:02 schrieb Mark Struberg > >> >> > <[email protected]>: > >> >> >> > > > >> >> >> > > As you might have read in the previous mail I > > did > >> > remove some > >> >> > code > >> >> >> which > >> >> >> > has no clean IP provenance. The code seems to have > > been > >> > taken from > >> >> the > >> >> >> > Spring project. Although it is ALv2 and so the > > license is > >> > fine we > >> >> > still > >> >> >> > don't own the copyright and there was no IP > > check done > >> > for this > >> >> > code. > >> >> >> > > > >> >> >> > > This all would be resolvable by going into > > the Spring > >> > SCM > >> >> > history, > >> >> >> check > >> >> >> > who wrote the code parts and patches, make sure it > > was not > >> > e.g. taken > >> >> >> from > >> >> >> > a GPL source, etc. After that we would need to ask > > Spring > >> > for a code > >> >> >> grant. > >> >> >> > > > >> >> >> > > > >> >> >> > > All this is doable but a certain amount of > > work. And > >> > thus I > >> >> > really > >> >> >> > suggest to do this only if we really need that > > code. > >> >> >> > > > >> >> >> > > 1.) do we really need those code parts? Do we > > need most > >> > of the > >> >> >> > spring-ant integration? What for? > >> >> >> > > 2.) Wouldn't it be easier to write the > >> > functionality > >> >> > ourselves and be > >> >> >> > able to only implement the pieces we really need? > > Currently > >> > all we > >> >> > need > >> >> >> is > >> >> >> > ClassLoader.getResources() and be done. > >> >> >> > > > >> >> >> > > Thus please VOTE on > >> >> >> > > > >> >> >> > > > >> >> >> > > A.) Go through the IP clearing and try to get > > the > >> > rights for the > >> >> > Spring > >> >> >> > code > >> >> >> > > > >> >> >> > > B.) Simply write those pieces ourselves. > > It's no > >> > rocket > >> >> > science, > >> >> >> really! > >> >> >> > > > >> >> >> > > > >> >> >> > > +1 for B from me. > >> >> >> > > > >> >> >> > > > >> >> >> > > LieGrue, > >> >> >> > > strub > >> >> >> > > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > > >
