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
