> > They also impled the bda differently than us making it only usable for > single bda apps and created arc@quarkus which violates that, so not sure > we > should copy what others do. I tend to prefer to add thinking on top of that > in the context of our project which is diff than the RI (by design and by > workforce). > This is not copying but not going into discussion more.
> I can agree that in one year we reverse the pattern, shade becoming javax. > But since we cant enforce anyone to do the sync between branches and due to > past years contributions stats, we must not go that way IMHO, it would > either make us expose 2 bad branches or kill our resources for no user > gains. Indeed that is my opinion but from the stats i have today it is my > conclusion. You have concerns about the community, understanding. Please discuss it on G, it does not impact OWB - and btw this is not what > had been said ;). > Thanks for the pointer Regards. Gurkan On Sun, Jun 7, 2020 at 9:50 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Le dim. 7 juin 2020 à 20:39, Gurkan Erdogdu <cgurkanerdo...@gmail.com> a > écrit : > > > > > > > So to conclude on this point not belonging to OWB, we still need our > fork > > > and eclipse always answered saying "yes we want OSGi [but we don't > really > > > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't > > > work on that factually so OSGi is done at minimal cost. > > > > OK thanks for the clarification. I am not an OSGI expert. > > > > Ok Gurkan, let's be concrete, do you - you as you personally - accept and > > > commit yourself to port any commit to one of the two branches to the > > other > > > for all the time the project is at apache? > > > if so fine, if not -1 to create us unneeded (+ still unjustified by > > facts) > > > work. > > > > :=) > > Hey, I'm just proposing what I think about. If nobody cares about it or > is > > not beneficial, it is ok, and also there is no need to VOTE (This is why > > I'd like to get more opinions on it). > > > It is fine, just wanted to emphasis the consequence and what it means for > the project. > > But look at Weld, they did the > > update, https://github.com/weld and full of updating their pom to use > > jakarta.* > > > > They also impled the bda differently than us making it only usable for > single bda apps and created arc@quarkus which violates that, so not sure > we > should copy what others do. I tend to prefer to add thinking on top of that > in the context of our project which is diff than the RI (by design and by > workforce). > > > > > Currently all of the OWB modules (webbeans-ee, webbeans-el22 etc), use > > geronimo-...specs which depend on javax.*. Today or tomorrow, we will > > eventually move to jakarta.* namespace. Instead of working with such > > shading plugin stuff as a workaround, I just offer to take the master to > > jakarta.* and update all OWB modules' dependency from javax.* to > jakarta.* > > official APIS. This is not related to who will maintain the branches. You > > know that ASF works as a voluntary based approach. You can not push > anybody > > to work on anything as in commercial companies. > > > > I can agree that in one year we reverse the pattern, shade becoming javax. > But since we cant enforce anyone to do the sync between branches and due to > past years contributions stats, we must not go that way IMHO, it would > either make us expose 2 bad branches or kill our resources for no user > gains. Indeed that is my opinion but from the stats i have today it is my > conclusion. > > > > Also, regarding the cost and energy you mention to maintain the branch, > via > > Geronimo specs, you will need to update all of the Geronimo Specs and > > maintain them. I think this is not rational because now, jakarta.* > official > > API license is EPL and Apache friendly. Why do I need to maintain for > > example Geronimo EL? > > > > Please discuss it on G, it does not impact OWB - and btw this is not what > had been said ;). > > > > > Regards. > > Gurkan > > > > > > > > > > > > On Sun, Jun 7, 2020 at 9:25 PM Romain Manni-Bucau <rmannibu...@gmail.com > > > > wrote: > > > > > Le dim. 7 juin 2020 à 20:20, Gurkan Erdogdu <cgurkanerdo...@gmail.com> > a > > > écrit : > > > > > > > Hi David > > > > > > > > I’m not sure exactly how it impacts this decision, but IIUC the > > geronimo > > > > > cdi spec jar is rather essential for some uses as it has OSGI > support > > > > > whereas IIUC the eclipse/jakarta one doesn’t. > > > > > > > > > No, it is not correct. It has OSGI support. GlassFish is an OSGI > based > > > > server.You can grap the code from > https://github.com/eclipse-ee4j/cdi > > > and > > > > build. It has OSGI enabled MANIFEST.MF file. > > > > > > > > > > Not, it is not correct Gurkan ;). > > > jakarta does NOT support OSGi properly, it does it the old way and > break > > > several rules. For instance last CDI spec jar contains: > > > > > > Manifest-Version: 1.0 > > > Bundle-Description: APIs for CDI (Contexts and Dependency Injection fo > > > r Java) > > > Bundle-License: https://repository.jboss.org/licenses/apache-2.0.txt > > > Bundle-SymbolicName: jakarta.enterprise.cdi-api > > > Built-By: default > > > Bnd-LastModified: 1590678420932 > > > Bundle-ManifestVersion: 2 > > > Bundle-DocURL: https://jboss.org > > > Bundle-Vendor: JBoss by Red Hat, Inc. > > > Import-Package: jakarta.el;version="4.0",jakarta.inject;version="[2.0, > > > 3)",jakarta.interceptor;version="[2.0,3)" > > > Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" > > > Tool: Bnd-2.4.1.201501161923 > > > Originally-Created-By: Apache Maven Bundle Plugin > > > Export-Package: jakarta.decorator;version="3.0";uses:="jakarta.enterpr > > > ise.inject",jakarta.enterprise.context;version="3.0";uses:="jakarta.e > > > nterprise.util,jakarta.inject",jakarta.enterprise.context.control;ver > > > sion="3.0";uses:="jakarta.enterprise.context,jakarta.interceptor",jak > > > arta.enterprise.context.spi;version="3.0",jakarta.enterprise.event;ve > > > rsion="3.0";uses:="jakarta.enterprise.util",jakarta.enterprise.inject > > > ;version="3.0";uses:="jakarta.enterprise.context,jakarta.enterprise.u > > > til,jakarta.inject",jakarta.enterprise.inject.literal;version="3.0";u > > > ses:="jakarta.enterprise.util,jakarta.inject",jakarta.enterprise.inje > > > ct.se;version="3.0";uses:="jakarta.enterprise.inject,jakarta.enterpri > > > se.inject.spi",jakarta.enterprise.inject.spi;version="3.0";uses:="jak > > > arta.el,jakarta.enterprise.context.spi,jakarta.enterprise.event,jakar > > > ta.enterprise.inject,jakarta.enterprise.inject.spi.configurator,jakar > > > ta.interceptor",jakarta.enterprise.inject.spi.configurator;version="3 > > > .0";uses:="jakarta.enterprise.context.spi,jakarta.enterprise.event,ja > > > karta.enterprise.inject,jakarta.enterprise.inject.spi,jakarta.enterpr > > > ise.util",jakarta.enterprise.util;version="3.0" > > > Bundle-Name: CDI APIs > > > Bundle-Version: 3.0.0.M4 > > > Build-Jdk-Spec: 1.8 > > > Created-By: Apache Maven Bundle Plugin > > > Build-Jdk: 1.8.0_202 > > > > > > Where are the osgi.serviceloader and osgi.contract ? > > > This is important and used by OSGi-CDI for example (even if it can be > > > worked around). > > > > > > So to conclude on this point not belonging to OWB, we still need our > fork > > > and eclipse always answered saying "yes we want OSGi [but we don't > really > > > know]" - and I know eclipse+EE has a lot of OSGi experts but they don't > > > work on that factually so OSGi is done at minimal cost. > > > > > > > > > > > > > > Gurkan’s proposal will only add difficulty for developers and > probably > > > > > users. > > > > > > > > > What is the difficulty? The change will only affect maintaining the > > > javax.* > > > > branch and fully renamed jakarta.* dependencies in master. > > > > > > > > > > Ok Gurkan, let's be concrete, do you - you as you personally - accept > and > > > commit yourself to port any commit to one of the two branches to the > > other > > > for all the time the project is at apache? > > > if so fine, if not -1 to create us unneeded (+ still unjustified by > > facts) > > > work. > > > > > > > > > > > > > > Regards. > > > > Gurkan > > > > > > > > On Sun, Jun 7, 2020 at 8:58 PM David Jencks < > david.a.jen...@gmail.com> > > > > wrote: > > > > > > > > > I’m not sure exactly how it impacts this decision, but IIUC the > > > geronimo > > > > > cdi spec jar is rather essential for some uses as it has OSGI > support > > > > > whereas IIUC the eclipse/jakarta one doesn’t. > > > > > > > > > > Personally I’m afraid I’m totally on Romain’s side so far, AFAICT > > > > Gurkan’s > > > > > proposal will only add difficulty for developers and probably > users. > > > > > Although I haven’t been active here for years I might even vote. > > > > > > > > > > thanks > > > > > David Jencks > > > > > > > > > > > On Jun 7, 2020, at 10:46 AM, Gurkan Erdogdu < > > > cgurkanerdo...@gmail.com> > > > > > wrote: > > > > > > > > > > > >> > > > > > >> Tomcat works with branches since years without any issue. > > > > > >> All projects we tried to use branches we abandoned branches just > > > after > > > > > >> having done them. > > > > > >> It is fine if the old branch is no more used but here we know we > > > will > > > > > >> maintain javax branch more than jakarta one for some time so I > > think > > > > we > > > > > >> should avoid it while it is not justified or one of the 2 > branches > > > > > (javax) > > > > > >> is "almost dead". > > > > > > > > > > > > Working with branches always happens in all open source projects. > > > And > > > > > > there are times when it is logical to create the branch. Jakarta > > EE 9 > > > > API > > > > > > migration is the best time to create such a branch. Eventually, > we > > > will > > > > > > create such a branch in Jakarta EE 10. > > > > > > > > > > > > Fact there will be no more javax is useless IMHO, only question > we > > > > should > > > > > >> care about is "do we have javax users?" and should we work on > > javax > > > > > branch > > > > > >> enough to care about having 2 duplicate branches. Answer is > > > obviously > > > > > yes > > > > > >> and more than jakarta users today, therefore I think for some > > months > > > > > (maybe > > > > > >> a few years) we should stick to javax as our primary branch and > > > ensure > > > > > the > > > > > >> alignments and bugfixes can trivially - == without any action > from > > > dev > > > > > - be > > > > > >> ported. It is what we have today. > > > > > >> > > > > > > What could be more natural than maintaining branches (with > > > backporting > > > > > from > > > > > > master only if necessary). With Jakarta EE 10, we will eventually > > > > create > > > > > > the branch for supporting the EE 8. Also, for the release > > versioning, > > > > it > > > > > is > > > > > > nice to have a 3.x release. The community will notice that 3.x is > > the > > > > > > starting point of Jakarta EE support. Will you release 2.x with > the > > > > > > intention of supporting Jakarta EE 9? I am personally not > positive > > on > > > > > this. > > > > > > I think, 3.x release will also get more interest even if the > > > > > functionality > > > > > > and API stay the same. We can prepare the press release for it. > > > > > > > > > > > > Note we shouldn't depend on jakarta/javax api anyway (neither as > > > > groupId > > > > > >> nor as transitive dep so this change must stay a noop for > > > consumers). > > > > > >> > > > > > > What is the problem of depending on the official Jakarta EE CDI > > API? > > > It > > > > > is > > > > > > an Apache friendly license. Instead of maintaining the Geronimo > CDI > > > API > > > > > > internally, it is more logical to use Jakarta EE official CDI API > > and > > > > > > maintain this API with EE4J community. > > > > > > > > > > > > would also appreciate if you do a vote if you can point out the > > > > breaking > > > > > >> changes - except the package renaming - justifying to fork > ourself > > > and > > > > > what > > > > > >> does not work with current solution, can ease the decision/vote. > > > > > >> Today using jakarta/EE9 API is quite easy ( > > > > > >> > > > > > > > > > > > > > > > https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt > > > > > >> ). > > > > > >> We should absolutely enhance the pom experience though but it is > > > > > trivial to > > > > > >> do at maven level - I was envisionning to do it in shade plugin > to > > > be > > > > > more > > > > > >> precise. > > > > > >> > > > > > > I know that there will be no functional change. But, I am also > > > against > > > > > > shading for jakarta.*. If there will be no change on Jakarta EE > 10, > > > > will > > > > > we > > > > > > continue to shade? What happens when there will be a change in > > EJB, > > > > JMS > > > > > > etc specifications but no change in CDI in Jakarta EE 10? Also, > > > VOTING > > > > is > > > > > > the natural thing to do for the community decision. If the > > community > > > > > would > > > > > > like to keep it as it is via shading, it is fine. > > > > > > > > > > > >> > > > > > >> To try to rephrase/clarify my questionning today: you ask for > > > jakarta > > > > > >> support, we already have it in a dev and project efficient way > so > > > why > > > > > >> should we change since I don't hink there is anything new - once > > > again > > > > > if > > > > > >> API starts to fully break discussion is different but github > > doesnt > > > > > reflect > > > > > >> that? > > > > > >> > > > > > > This is not just for Jakarta EE 9 support. As we know, there will > > be > > > no > > > > > API > > > > > > (functional) change, only package renaming. But, I want to > > emphasize > > > > that > > > > > > with such turning points, it is so logical to integrate official > > > > Jakarta > > > > > > CDI API into our master (removing the geronimo-cdi), and release > > our > > > > new > > > > > > 3.x version and let the public know that OWB supports official > CDI > > > API > > > > > > beginning with 3.x release. Yeah, shading is an option for > package > > > > > renaming > > > > > > but think long term. Also, I am really against the shading. It > > really > > > > > > disturbs the users which depend on OWB implementation. For > example, > > > > > > currently Glassfish supports Weld integration but one can also > > > > implement > > > > > > OWB to replace Weld in Glassfish. Therefore, instead of using the > > > > shaded > > > > > > version, it is really important to have the full Jakarta EE CDI > API > > > in > > > > > our > > > > > > poms. You will still have javax.* dependency in ur POMs even if > > > doing a > > > > > > shade. This is not good idea to still maintain javax.* in our POM > > > > files. > > > > > > > > > > > > What are other opinions before formal voting? > > > > > > Regards. > > > > > > Gurkan > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 7, 2020 at 8:02 PM Romain Manni-Bucau < > > > > rmannibu...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > >> Le dim. 7 juin 2020 à 18:49, Gurkan Erdogdu < > > > cgurkanerdo...@gmail.com > > > > > > > > > > a > > > > > >> écrit : > > > > > >> > > > > > >>> Tomcat created branch 10 for jakarta ee 9. Glassfish is also on > > > > master. > > > > > >>> > > > > > >> > > > > > >> Tomcat works with branches since years without any issue. > > > > > >> All projects we tried to use branches we abandoned branches just > > > after > > > > > >> having done them. > > > > > >> It is fine if the old branch is no more used but here we know we > > > will > > > > > >> maintain javax branch more than jakarta one for some time so I > > think > > > > we > > > > > >> should avoid it while it is not justified or one of the 2 > branches > > > > > (javax) > > > > > >> is "almost dead". > > > > > >> > > > > > >> > > > > > >>> sorry but not understand the resistance on this? will you > always > > > > shade > > > > > ? > > > > > >>> > > > > > >> > > > > > >> As mentionned, until API needs changes we can't easily handle - > > > today > > > > > there > > > > > >> is no change. > > > > > >> > > > > > >> > > > > > >>> creating the new master and maintain the 2.x branch, is the > best > > > > > logical > > > > > >>> way. there will be no javax.* any more. Tomcat maintains 3 > > > branches > > > > > and > > > > > >> 1 > > > > > >>> master. only maintains 1 branch and 1 master is totally fine. > > > > > >>> > > > > > >> > > > > > >> Fact there will be no more javax is useless IMHO, only question > we > > > > > should > > > > > >> care about is "do we have javax users?" and should we work on > > javax > > > > > branch > > > > > >> enough to care about having 2 duplicate branches. Answer is > > > obviously > > > > > yes > > > > > >> and more than jakarta users today, therefore I think for some > > months > > > > > (maybe > > > > > >> a few years) we should stick to javax as our primary branch and > > > ensure > > > > > the > > > > > >> alignments and bugfixes can trivially - == without any action > from > > > dev > > > > > - be > > > > > >> ported. It is what we have today. > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> I will propose a vote shortly to decide on to create a master > > with > > > > 3.x > > > > > >> with > > > > > >>> fully support of jakarta with a normal pom dependency with > > jakarta > > > > api. > > > > > >>> > > > > > >> > > > > > >> Note we shouldn't depend on jakarta/javax api anyway (neither as > > > > groupId > > > > > >> nor as transitive dep so this change must stay a noop for > > > consumers). > > > > > >> I would also appreciate if you do a vote if you can point out > the > > > > > breaking > > > > > >> changes - except the package renaming - justifying to fork > ourself > > > and > > > > > what > > > > > >> does not work with current solution, can ease the decision/vote. > > > > > >> Today using jakarta/EE9 API is quite easy ( > > > > > >> > > > > > > > > > > > > > > > https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt > > > > > >> ). > > > > > >> We should absolutely enhance the pom experience though but it is > > > > > trivial to > > > > > >> do at maven level - I was envisionning to do it in shade plugin > to > > > be > > > > > more > > > > > >> precise. > > > > > >> > > > > > >> To try to rephrase/clarify my questionning today: you ask for > > > jakarta > > > > > >> support, we already have it in a dev and project efficient way > so > > > why > > > > > >> should we change since I don't hink there is anything new - once > > > again > > > > > if > > > > > >> API starts to fully break discussion is different but github > > doesnt > > > > > reflect > > > > > >> that? > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> Regs > > > > > >>> Gurkan > > > > > >>> > > > > > >>> > > > > > >>> On 7 Jun 2020 Sun at 18:05 Romain Manni-Bucau < > > > rmannibu...@gmail.com > > > > > > > > > > >>> wrote: > > > > > >>> > > > > > >>>> Today we don't need, tomorrow I don't know but while API does > > not > > > > > >> change > > > > > >>>> (except the package) we shouldn't fork ourself IMHO (cause it > is > > > > what > > > > > >> you > > > > > >>>> propose as a consequence). > > > > > >>>> If it becomes necessary let's do it but my vote is to stay > lazy > > on > > > > > >> that. > > > > > >>>> > > > > > >>>> > > > > > >>>> side note for G API discussion belongs to dev@G but it is > less > > an > > > > > >> issue > > > > > >>> to > > > > > >>>> fork from now since we rarely update the API, the side note > here > > > is > > > > > >> that > > > > > >>>> CDI SE is already fully runnable on ASF stack with jakarta > > package > > > > > >> since > > > > > >>>> some weeks or months, we did all the needed releases. > > > > > >>>> > > > > > >>>> Romain Manni-Bucau > > > > > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > > > > > >>>> <http://rmannibucau.wordpress.com> | Github < > > > > > >>>> https://github.com/rmannibucau> | > > > > > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > >>>> < > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > >>>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> Le dim. 7 juin 2020 à 16:42, Thomas Andraschko < > > > > > >>>> andraschko.tho...@gmail.com> > > > > > >>>> a écrit : > > > > > >>>> > > > > > >>>>> AFAIR we dont need it as we shade a -jakarta.jar via our > build. > > > > > >>>>> As EE9 just changes the namespace, it's perfectly fine. > > > > > >>>>> > > > > > >>>>> I'm actually also a supporter of doing a hard cut but it's > not > > > > > >> required > > > > > >>>> and > > > > > >>>>> we can do it for EE 10. > > > > > >>>>> > > > > > >>>>> < > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > >>>>>> > > > > > >>>>> Virenfrei. > > > > > >>>>> www.avast.com > > > > > >>>>> < > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > > >>>>>> > > > > > >>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > >>>>> > > > > > >>>>> Am So., 7. Juni 2020 um 16:35 Uhr schrieb Gurkan Erdogdu < > > > > > >>>>> cgurkanerdo...@gmail.com>: > > > > > >>>>> > > > > > >>>>>> We need to maintain two branches > > > > > >>>>>> > > > > > >>>>>> EE 8 for javax.* package 2.x branch > > > > > >>>>>> EE 9 for jakarta.* package 3.x master > > > > > >>>>>> > > > > > >>>>>> On 7 Jun 2020 Sun at 16:25 Romain Manni-Bucau < > > > > > >> rmannibu...@gmail.com > > > > > >>>> > > > > > >>>>>> wrote: > > > > > >>>>>> > > > > > >>>>>>> Hi, > > > > > >>>>>>> > > > > > >>>>>>> I'll probably restate my position on that: if EE 9 brings > > > > > >>>>> significatively > > > > > >>>>>>> new API yes - a quick review shows it is 1-1 with EE 8 but > I > > > can > > > > > >>> have > > > > > >>>>>>> missed sthg, looked quite fast. if EE9==EE8 then we can > stay > > as > > > > > >> we > > > > > >>>> are > > > > > >>>>> I > > > > > >>>>>>> think avoiding to maintain two branches we can't merge > > > regularly. > > > > > >>>>>>> > > > > > >>>>>>> Romain Manni-Bucau > > > > > >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog > > > > > >>>>>>> <http://rmannibucau.wordpress.com> | Github < > > > > > >>>>>>> https://github.com/rmannibucau> | > > > > > >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > >>>>>>> < > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> Le dim. 7 juin 2020 à 10:26, Gurkan Erdogdu < > > > > > >>>> cgurkanerdo...@gmail.com> > > > > > >>>>> a > > > > > >>>>>>> écrit : > > > > > >>>>>>> > > > > > >>>>>>>> Hi > > > > > >>>>>>>> After the 2.x release, can we get the master to 3.0.0 to > > > > > >> support > > > > > >>>>>> upcoming > > > > > >>>>>>>> Jakarta EE 9 release with jakarta.* namespace? > > > > > >>>>>>>> > > > > > >>>>>>>> I also favor to use the Jakarta EE CDI API instead of > using > > > the > > > > > >>>>> Apache > > > > > >>>>>>>> based api. > > > > > >>>>>>>> Regards > > > > > >>>>>>>> Gurkan > > > > > >>>>>>>> > > > > > >>>>>>>> -- > > > > > >>>>>>>> Gurkan Erdogdu > > > > > >>>>>>>> http://gurkanerdogdu.blogspot.com > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> -- > > > > > >>>>>> Gurkan Erdogdu > > > > > >>>>>> http://gurkanerdogdu.blogspot.com > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> -- > > > > > >>> Gurkan Erdogdu > > > > > >>> http://gurkanerdogdu.blogspot.com > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > > > > Gurkan Erdogdu > > > > > > http://gurkanerdogdu.blogspot.com > > > > > > > > > > > > > > > > > > -- > > > > Gurkan Erdogdu > > > > http://gurkanerdogdu.blogspot.com > > > > > > > > > > > > > -- > > Gurkan Erdogdu > > http://gurkanerdogdu.blogspot.com > > > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
