Sorry but what you committed did not even compile. And the dependencies in the build.xml was just a network of things.
I have fixed now the things back to what I thought would be the result of step 1 and 2. R1529374 is functional ready from my point of view. What on top of it do we need to do ? I mean if you have optimizations you can apply those. You can theoretically now simply create a separated project (for instance for the src/db folder), remove those sources and add openmeetings-db-3.0.0-SNAPSHOT.jar as dependency. And that was the goal. What on top of it would be needed ? Sebastian 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> > Your current approach will not lead you to multiproject structure :( > While refactoring build.xml I tried to compile each folder separately and > finally it was successfull > > > > On Sat, Oct 5, 2013 at 8:25 AM, Maxim Solodovnik <solomax...@gmail.com>wrote: > >> I'll try to explain what I did step by step: >> 1) create 6 folders for 6 types of sources >> 2) move java files >> Everything fine on this stage on the eclipse level >> 3) open build.xml >> 4) found multiple problems with it: >> 1. lots of 'relict' targets >> 2. combined naming style of targets: web.only, dist-bin, >> buildOnlyWebDoc etc. >> 3. lots of copy/paste: creating of each jar was made by copy/pasting >> certain code block >> 5) I have decided to unify build.xml file >> 6) due to file system changes are huge I have desided to commit first >> version partially mailfunctioning >> >> I believe the better option to commit my changes and fix/recreate >> missing/broken functionality. >> buld.xml as it is now is almost unreadable >> >> Please let me know what do you think >> >> >> On Sat, Oct 5, 2013 at 6:49 AM, seba.wag...@gmail.com < >> seba.wag...@gmail.com> wrote: >> >>> I removed the openmeetings-template-$VERSION.jar, it did not contain any >>> kind of needed files. >>> >>> Also by applying some filters to the existing "all-in-on" jar the file >>> size of the jar is 50% :) >>> >>> BTW: The .xml files for the Web-Installer is now copied into the >>> META-INF/classes directory (together with the other .html templates) and no >>> more compiled into the .jar file. >>> >>> Sebastian >>> >>> >>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>> >>> As far as I can see that JPQL error has nothing todo with the source >>>> code refactoring, I will commit now a fix that reverts the changes to the >>>> build.xml but makes the sources compile and build a package. >>>> >>>> I will suggest we first fix the existing issues and then simply package >>>> separated JARs files and put them into the lib folder for each of those >>>> source folders. >>>> >>>> If you want to re-apply further your changes to the build xml file, >>>> feel free to do so, but from my point of view those changes made it just >>>> more hard to read that file then making it more easy. >>>> >>>> Sebastian >>>> >>>> >>>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>>> >>>> Further there is a broken SQL query: >>>>> , @NamedQuery(name = "getFieldByIdAndLanguage", query = "SELECT fv >>>>> FROM Fieldvalues fv " + >>>>> "LEFT OUTER JOIN FETCH fv.fieldlanguagesvalues flv WHERE " + >>>>> " fv.fieldvalues_id = :id AND fv.deleted = false AND >>>>> flv.language_id = :lang") >>>>> >>>>> Throws the error: >>>>> >>>>> Caused by: <openjpa-2.2.2-r422266:1468616 nonfatal user error> >>>>> org.apache.openjpa.persistence.ArgumentException: Encountered "flv" at >>>>> character 77, but expected: [",", ".", "GROUP", "HAVING", "INNER", >>>>> "JOIN", "LEFT", "ORDER", "WHERE", <EOF>]. >>>>> at >>>>> org.apache.openjpa.kernel.jpql.JPQL.generateParseException(JPQL.java:13162) >>>>> >>>>> >>>>> >>>>> >>>>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>>>> >>>>> The more I edit this build.xml the more I think it is a good idea to >>>>>> move away from it :) >>>>>> Its a horrible historical grown file. >>>>>> This was one of the first versions: >>>>>> >>>>>> https://code.google.com/p/openmeetings/source/browse/trunk/webapp/build.xml?r=1329 >>>>>> >>>>>> And since then we just grow it :)) >>>>>> >>>>>> Sebastian >>>>>> >>>>>> >>>>>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>>>>> >>>>>> There are also some pre-existing issues with our JAR packaging. >>>>>>> If you download the existing openmeetings.jar (for example from the >>>>>>> last >>>>>>> https://builds.apache.org/view/M-R/view/OpenMeetings/job/openmeetings/610/and >>>>>>> unpack just unzip openmeetings-3.0.0-SNAPSHOT.jar) , you see a lot of >>>>>>> directories and files in that JAR file that have no meaning and/or are >>>>>>> duplicated. >>>>>>> >>>>>>> For example: Why there is a folder /main/webapp/ (and xx subfolders) >>>>>>> packaged into the JAR file ?! >>>>>>> >>>>>>> Sebastian >>>>>>> >>>>>>> >>>>>>> 2013/10/5 seba.wag...@gmail.com <seba.wag...@gmail.com> >>>>>>> >>>>>>> I did not intend to say that you need to immediatelly do everything >>>>>>>> in one flush. >>>>>>>> >>>>>>>> I also do not understand the full refactoring you have done, there >>>>>>>> are so many changes in the build.xml that it is impossible to follow up >>>>>>>> what exactly is wrong at the moment. >>>>>>>> >>>>>>>> It seems like there are several issues, if you run a "clean" you >>>>>>>> might see. >>>>>>>> >>>>>>>> I can try o fix that. But potentially you will need to reply some >>>>>>>> of those fixes that you have done on top of it (like the replace of "." >>>>>>>> with "-" in some of the build targets) >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>>> >>>>>>>> 2013/10/5 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>> >>>>>>>>> I'm going to commit the changes >>>>>>>>> Please let me know know if anything is broken >>>>>>>>> >>>>>>>>> Was unable to test everything :( >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Oct 4, 2013 at 11:59 AM, Maxim Solodovnik < >>>>>>>>> solomax...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I have started 1+2 >>>>>>>>>> everything is OK on Eclipse level BUT >>>>>>>>>> there are troubles on the ant level :( >>>>>>>>>> >>>>>>>>>> all modules you have mention are dependent on each other (except >>>>>>>>>> for screensharing). This mean modules can not be compiled separately >>>>>>>>>> :( >>>>>>>>>> Will try to resolve it somehow >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Oct 3, 2013 at 1:46 PM, seba.wag...@gmail.com < >>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> 1+2 now >>>>>>>>>>> >>>>>>>>>>> 3+4 after the release of version 3.0 >>>>>>>>>>> >>>>>>>>>>> Sebastian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>> >>>>>>>>>>>> OK >>>>>>>>>>>> in what version this should be implemented? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Oct 3, 2013 at 1:12 PM, seba.wag...@gmail.com < >>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> You just concentrate so much about "what can anybody do with >>>>>>>>>>>>> those jars". >>>>>>>>>>>>> The question is more: What can WE do with those jars. >>>>>>>>>>>>> >>>>>>>>>>>>> We can test functionality in isolation. >>>>>>>>>>>>> We can switch different versions without changing source code. >>>>>>>>>>>>> We can improve our build structure to a common standard that >>>>>>>>>>>>> makes it easier for 3rd parties to get involved >>>>>>>>>>>>> We can improve our build structure to a common standard that >>>>>>>>>>>>> makes it easier for us to maintain changes >>>>>>>>>>>>> We can benefit from the usage of Maven by having out of the >>>>>>>>>>>>> box support for the most common tasks in the software life-cycle >>>>>>>>>>>>> (distribution, dependency management, testing, ...) >>>>>>>>>>>>> >>>>>>>>>>>>> Just one example: In Maven you simply run "mvn >>>>>>>>>>>>> eclipse:eclipse" and it will build all the necessary project >>>>>>>>>>>>> files based on >>>>>>>>>>>>> your pom file that you need for Eclipse. >>>>>>>>>>>>> >>>>>>>>>>>>> So no back and forth about checking in Eclipse files with >>>>>>>>>>>>> "Apache Headers" in the SVN and syncing, and then Eclipse >>>>>>>>>>>>> overwrites it >>>>>>>>>>>>> again and all this kind of mucking around. You simply never check >>>>>>>>>>>>> those >>>>>>>>>>>>> files in, cause everybody that needs them simply runs "mvn >>>>>>>>>>>>> eclipse:eclipse". And that's it. That is why nobody else has >>>>>>>>>>>>> issues with >>>>>>>>>>>>> "checking in Eclipse files in SVN with Apache Headers". Maven >>>>>>>>>>>>> users just >>>>>>>>>>>>> wonder why anybody would do that if Maven already handles it for >>>>>>>>>>>>> you. >>>>>>>>>>>>> >>>>>>>>>>>>> My proposal would be to refactor in multiple steps to use >>>>>>>>>>>>> Maven for building the project. >>>>>>>>>>>>> Step 1 + 2 would not introduce Maven, it just prepares for it. >>>>>>>>>>>>> >>>>>>>>>>>>> 1) First step would be to identify/discuss possible artefact's >>>>>>>>>>>>> that can be build as a separated JAR. >>>>>>>>>>>>> That would be: >>>>>>>>>>>>> - Wicket >>>>>>>>>>>>> - Persistence >>>>>>>>>>>>> - Axis >>>>>>>>>>>>> - ScreenSharing >>>>>>>>>>>>> - Utils >>>>>>>>>>>>> - Core ("the rest", mainly business logic or things that are >>>>>>>>>>>>> too small or have no real scope) >>>>>>>>>>>>> >>>>>>>>>>>>> 2) Group them in a separated source-folders and package them >>>>>>>>>>>>> in a separated JAR >>>>>>>>>>>>> >>>>>>>>>>>>> -------- >>>>>>>>>>>>> >>>>>>>>>>>>> That would be it for the moment. >>>>>>>>>>>>> >>>>>>>>>>>>> At some later stage: >>>>>>>>>>>>> 3) Externalise, each of those JARs, step by step, into a >>>>>>>>>>>>> separated Maven build project. >>>>>>>>>>>>> Each of those Maven projects would have its own "test" source >>>>>>>>>>>>> folder. So the tests then move from the "core" to the sub >>>>>>>>>>>>> projects they >>>>>>>>>>>>> belong to. >>>>>>>>>>>>> >>>>>>>>>>>>> 4) At some stage we might only have the core project left over >>>>>>>>>>>>> that builds using ANT+Ivy. At that time we can then discuss >>>>>>>>>>>>> further on how >>>>>>>>>>>>> to refactor that project to Maven. >>>>>>>>>>>>> >>>>>>>>>>>>> Steps 3) or 4) depend more on individuals that are willing to >>>>>>>>>>>>> put time into that then on Release Cycles. >>>>>>>>>>>>> >>>>>>>>>>>>> It basically should not have any effect on how the application >>>>>>>>>>>>> works / functionality, its only a source code / build tools >>>>>>>>>>>>> refactoring. >>>>>>>>>>>>> However I would like to get step 1 and 2 done. Because those >>>>>>>>>>>>> are basically the ones that require consens. Steps 3+4 can be >>>>>>>>>>>>> done at any >>>>>>>>>>>>> time later. >>>>>>>>>>>>> >>>>>>>>>>>>> Sebastian >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think they wrong or we right >>>>>>>>>>>>>> I just can't see how one can use any of our jars without >>>>>>>>>>>>>> others :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you please propose the structure you would like? >>>>>>>>>>>>>> I believe we shouldn't switch to maven until 3.1 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Oct 3, 2013 at 11:48 AM, seba.wag...@gmail.com < >>>>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> But it is not about creating *standalone* artefacts. >>>>>>>>>>>>>>> It is just a different way of architecture. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For instance if we switch to a more Maven styled >>>>>>>>>>>>>>> architecture the openmeetings wicket related stuff could become >>>>>>>>>>>>>>> even a >>>>>>>>>>>>>>> standalone eclipse project. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And in the OpenMeetings "core" project the >>>>>>>>>>>>>>> openmeetings-wicket-$version.jar is simply a dependency that >>>>>>>>>>>>>>> you add and >>>>>>>>>>>>>>> update in your pom (or ivy) file. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That has several advantages, for instance that somebody that >>>>>>>>>>>>>>> has no idea about red5 can purely concentrate on editing and >>>>>>>>>>>>>>> writing test >>>>>>>>>>>>>>> cases for what he knows. And you might test things more in >>>>>>>>>>>>>>> isolation. The >>>>>>>>>>>>>>> same about the persistance/OpenJPA related stuff. You can simply >>>>>>>>>>>>>>> externalize that and add it as a dependency. >>>>>>>>>>>>>>> I mean externalizing things is a quite basic process that >>>>>>>>>>>>>>> you do with every string, code, class, it seems just natural >>>>>>>>>>>>>>> that you do >>>>>>>>>>>>>>> the same with organizing source code and grouping JARs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So it is really not about building standalone artefacts that >>>>>>>>>>>>>>> can be distributed. They have of course dependencies. But that >>>>>>>>>>>>>>> is what you >>>>>>>>>>>>>>> might manage then in your pom.xml or ivy file. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So having those kind of separation is one step in a bigger >>>>>>>>>>>>>>> process to organize our project and move to a more standardized >>>>>>>>>>>>>>> architecture in line with other Apache products. Instead of >>>>>>>>>>>>>>> having this >>>>>>>>>>>>>>> heavily customized build process. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> By having a more standardized process it will be also easier >>>>>>>>>>>>>>> for new committers to join the project and provide patches. >>>>>>>>>>>>>>> And for example having our JARs in the Maven repositories. I >>>>>>>>>>>>>>> doubt that we can really judge what others can do with those >>>>>>>>>>>>>>> JARs. There >>>>>>>>>>>>>>> might be not some user xyz out there that exactly could use >>>>>>>>>>>>>>> some part of >>>>>>>>>>>>>>> our code for his project. I mean its all about getting >>>>>>>>>>>>>>> connected with other >>>>>>>>>>>>>>> projects. We benefit from so many other projects, but we are >>>>>>>>>>>>>>> not willing to >>>>>>>>>>>>>>> switch our project to a more standardised architecture so that >>>>>>>>>>>>>>> others can >>>>>>>>>>>>>>> benefit from us. While we could very much benefit if we would >>>>>>>>>>>>>>> integrate our >>>>>>>>>>>>>>> project better in the Open Source landscape. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Take _any_ Apache project, they are all using Maven and they >>>>>>>>>>>>>>> all follow those principles. Do you really think that they are >>>>>>>>>>>>>>> all wrong ? >>>>>>>>>>>>>>> And is it really that good that we follow our very own way ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2013/10/3 Maxim Solodovnik <solomax...@gmail.com> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Sebastian, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We surely can add additional targets, but unfortunately the >>>>>>>>>>>>>>>> only pard able to live with no others is docs :) >>>>>>>>>>>>>>>> All other "jar"s will be dependent on each other. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you OK with it we can try to create more artifacts. >>>>>>>>>>>>>>>> Right now I can see no additional "standalone" artifacts :( >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Oct 3, 2013 at 11:02 AM, seba.wag...@gmail.com < >>>>>>>>>>>>>>>> seba.wag...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Maxim, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> just another example: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Look at what this project does release, they group it in >>>>>>>>>>>>>>>>> separated JAR packages. >>>>>>>>>>>>>>>>> Or have a look at: >>>>>>>>>>>>>>>>> http://www.apache.org/dist/sling/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I doubt that anybody could use the >>>>>>>>>>>>>>>>> org.apache.sling.junit.healthcheck-1.0.6 >>>>>>>>>>>>>>>>> without having the core or other JARs. However they split >>>>>>>>>>>>>>>>> it up, cause it is just makes it a lot more clear what is >>>>>>>>>>>>>>>>> what. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I still believe we should actually do that same. Package >>>>>>>>>>>>>>>>> for example the JPA related packages and the wicket related >>>>>>>>>>>>>>>>> packages in >>>>>>>>>>>>>>>>> separated JAR files. >>>>>>>>>>>>>>>>> A single "mega" jar just seems to be a quite outdated >>>>>>>>>>>>>>>>> distribution model. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sebastian >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ---------- Forwarded message ---------- >>>>>>>>>>>>>>>>> From: Bertrand Delacretaz <bdelacre...@apache.org> >>>>>>>>>>>>>>>>> Date: 2013/10/1 >>>>>>>>>>>>>>>>> Subject: [ANN] Apache Sling Health Check Tools released >>>>>>>>>>>>>>>>> To: dev <d...@sling.apache.org>, users < >>>>>>>>>>>>>>>>> us...@sling.apache.org>, Apache Announcements < >>>>>>>>>>>>>>>>> annou...@apache.org> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The Apache Sling team is pleased to announce the initial >>>>>>>>>>>>>>>>> release of >>>>>>>>>>>>>>>>> the Apache Sling Health Check Tools, which consist of the >>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>> modules: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> org.apache.sling.hc.core-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.hc.it-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.hc.jmx-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.hc.samples-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.hc.support-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.hc.webconsole-1.0.4 >>>>>>>>>>>>>>>>> org.apache.sling.junit.healthcheck-1.0.6 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Apache Sling is a web framework that uses a Java Content >>>>>>>>>>>>>>>>> Repository, >>>>>>>>>>>>>>>>> such as Apache Jackrabbit, to store and manage content. >>>>>>>>>>>>>>>>> Sling >>>>>>>>>>>>>>>>> applications use either scripts or Java servlets, selected >>>>>>>>>>>>>>>>> based on >>>>>>>>>>>>>>>>> simple name conventions, to process HTTP requests in a >>>>>>>>>>>>>>>>> RESTful way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Based on simple HealthCheck OSGi services, the Sling >>>>>>>>>>>>>>>>> Health Check >>>>>>>>>>>>>>>>> Tools ("hc" in short form) are used to check the health of >>>>>>>>>>>>>>>>> live Sling >>>>>>>>>>>>>>>>> systems, based on inputs like JMX MBean attribute values, >>>>>>>>>>>>>>>>> OSGi >>>>>>>>>>>>>>>>> framework information, Sling requests status, JUnit tests, >>>>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> See >>>>>>>>>>>>>>>>> http://sling.apache.org/documentation/bundles/sling-health-check-tool.html >>>>>>>>>>>>>>>>> for more information. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This release is available from >>>>>>>>>>>>>>>>> http://sling.apache.org/site/downloads.cgi and the usual >>>>>>>>>>>>>>>>> Maven >>>>>>>>>>>>>>>>> repositories. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Enjoy! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -The Apache Sling team >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> WBR >>>>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> WBR >>>>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sebastian Wagner >>>>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> WBR >>>>>>>>>>>> Maxim aka solomax >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Sebastian Wagner >>>>>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>>>>> http://www.webbase-design.de >>>>>>>>>>> http://www.wagner-sebastian.com >>>>>>>>>>> seba.wag...@gmail.com >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> WBR >>>>>>>>>> Maxim aka solomax >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> WBR >>>>>>>>> Maxim aka solomax >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sebastian Wagner >>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>> http://www.webbase-design.de >>>>>>>> http://www.wagner-sebastian.com >>>>>>>> seba.wag...@gmail.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sebastian Wagner >>>>>>> https://twitter.com/#!/dead_lock >>>>>>> http://www.webbase-design.de >>>>>>> http://www.wagner-sebastian.com >>>>>>> seba.wag...@gmail.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Wagner >>>>>> https://twitter.com/#!/dead_lock >>>>>> http://www.webbase-design.de >>>>>> http://www.wagner-sebastian.com >>>>>> seba.wag...@gmail.com >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> seba.wag...@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> seba.wag...@gmail.com >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> seba.wag...@gmail.com >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com seba.wag...@gmail.com
