Hi Gerhard

Does somebody reviewed if the site documentation is generated
correctly? Isn't any problem with @JSFWebConfigParam? has anybody
debugged something with the proposed code?. That's the unresolved
questions I want to solve before apply it (I already mention that
without response, right?), but if somebody can answer those questions
could speed it up.

I'm not asking for a loooooot of time. But note there are other issues
right now ( improve error logging and exception handling,
MYFACES-3216, fix #{component} refs and isRendered(), improve site
documentation ), that takes priority over this one.

regards,

Leonardo Uribe

2011/7/11 Gerhard Petracek <gerhard.petra...@gmail.com>:
> hi leo,
> right now i don't see a reason why it should take a lot of time. in the end
> you just have to look at the resulting artifacts.
> the javadoc plugin is no blocker (if there is no official release, we can do
> an external release. as soon as there is an official release of it, we can
> switch back to it).
> please provide a bit more information about the "other issues".
> regards,
> gerhard
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/7/11 Leonardo Uribe <lu4...@gmail.com>
>>
>> Hi
>>
>> Please don't commit the changes until I do a final review. That will
>> take some time, so please be patient, there are other issues on core
>> right now that we need to solve too. Anyway we can't commit the code
>> without a release of javadoc plugin.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/7/11 Jakob Korherr <jakob.korh...@gmail.com>:
>> > Hi,
>> >
>> >> right - there are no entries in the manifest. they will be generated
>> >> for the separated osgi bundle/s during the build (based on the build
>> >> config).
>> >
>> > Jep! That was the idea in the first place (look at the branch and
>> > you'll see no bundle plugin in myfaces-api or myfaces-impl, but in
>> > myfaces-bundle).
>> >
>> > @Leo: From my point of view, the branch is complete. In addition, Mark
>> > committed my patch for MJAVADOC-320, thus the javadoc generation does
>> > already work too (if you use the latest 2.8.1-SNAPSHOT of the
>> > javadoc-plugin).
>> >
>> > Here is a short summary of the proposed changes:
>> >
>> > - remove felix bundle plugin executions from myfaces-api and
>> > myfaces-impl (we have myfaces-bundle for OSGi).
>> > - use maven-shade-plugin with package relocation (shared to
>> > shared_impl) in myfaces-impl instead of
>> >  a) ant-task to rename source from shared to shared_impl
>> > (myfaces-shared-impl project)
>> >  b) dependency plugin to unpack shared-impl-sources.jar in
>> > myfaces-impl and build-helper-plugin to add these sources as a new
>> > source folder
>> > - use maven-javadoc-plugin with includeSourceDependencies=true for
>> > shared (and impl-ee6) in order to include the javadocs of shared in
>> > the myfaces-impl javadocs
>> >
>> > These changes have the following implications:
>> >
>> > - all imports of myfaces-shared code in myfaces-impl will go to
>> > org.apache.myfaces.shared.* instead of
>> > org.apache.myfaces.shared_impl.*, because relocation is done on
>> > class-file-basis instead of source-file-basis.
>> > - myfaces-shared-core will be a direct dependency of myfaces-impl at
>> > development time, thus enabling hot-deployments,... when changing
>> > stuff in shared at development time.
>> > - myfaces-shared-impl project will be obsolete (b/c - as already
>> > mentioned - myfaces-impl uses shared-core instead of shared-impl).
>> >
>> >
>> > If there are no objections, I will merge in the changes from the branch
>> > soon!
>> >
>> > Regards,
>> > Jakob
>> >
>> > 2011/7/8 Leonardo Uribe <lu4...@gmail.com>:
>> >> Hi Gerhard
>> >>
>> >> Ok, now that part has sense.
>> >>
>> >> There are still some things to check before apply the change. Please
>> >> let me know when all code is on the branch and I'll do a final in-deep
>> >> check.
>> >>
>> >> regards,
>> >>
>> >> Leonardo Uribe
>> >>
>> >> 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> >>> hi leo,
>> >>> right - there are no entries in the manifest. they will be generated
>> >>> for the
>> >>> separated osgi bundle/s during the build (based on the build config).
>> >>> regards,
>> >>> gerhard
>> >>> http://www.irian.at
>> >>>
>> >>> Your JSF powerhouse -
>> >>> JSF Consulting, Development and
>> >>> Courses in English and German
>> >>>
>> >>> Professional Support for Apache MyFaces
>> >>>
>> >>>
>> >>>
>> >>> 2011/7/8 Leonardo Uribe <lu4...@gmail.com>
>> >>>>
>> >>>> Hi
>> >>>>
>> >>>> Ok, I agree it is not a problem, but if that so, shouldn't we remove
>> >>>> OSGi entries on the manifests in myfaces-api and impl jars? just to
>> >>>> prevent possible confusions about that.
>> >>>>
>> >>>> regards,
>> >>>>
>> >>>> Leonardo Uribe
>> >>>>
>> >>>> 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> >>>> > +1!
>> >>>> > regards,
>> >>>> > gerhard
>> >>>> >
>> >>>> > http://www.irian.at
>> >>>> >
>> >>>> > Your JSF powerhouse -
>> >>>> > JSF Consulting, Development and
>> >>>> > Courses in English and German
>> >>>> >
>> >>>> > Professional Support for Apache MyFaces
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > 2011/7/8 Mark Struberg <strub...@yahoo.de>
>> >>>> >>
>> >>>> >> Leo, SpringDM does much more work usually to tweak something for
>> >>>> >> their
>> >>>> >> needs!
>> >>>> >> They can just use the myfaces-bundle.jar as each and every other
>> >>>> >> OSGi
>> >>>> >> user
>> >>>> >> does too.
>> >>>> >>
>> >>>> >> What I meant was more: we shall _not_ do something ugly just to
>> >>>> >> make
>> >>>> >> OSGi
>> >>>> >> happy ^^
>> >>>> >>
>> >>>> >> So using the maven-shade-plugin is perfectly fine and will be a
>> >>>> >> big
>> >>>> >> benefit for cleaning up the shared project!
>> >>>> >>
>> >>>> >> LieGrue,
>> >>>> >> strub
>> >>>> >>
>> >>>> >> --- On Fri, 7/8/11, Leonardo Uribe <lu4...@gmail.com> wrote:
>> >>>> >>
>> >>>> >> > From: Leonardo Uribe <lu4...@gmail.com>
>> >>>> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate code -
>> >>>> >> > revisited
>> >>>> >> > To: "MyFaces Development" <dev@myfaces.apache.org>
>> >>>> >> > Date: Friday, July 8, 2011, 3:20 PM
>> >>>> >> > Hi
>> >>>> >> >
>> >>>> >> > I don't think the OSGi mention is off-topic. In theory it
>> >>>> >> > is possible
>> >>>> >> > to setup myfaces-api and myfaces-impl jars in a OSGi
>> >>>> >> > container using
>> >>>> >> > SpringDM. The changes proposed just prevents that possible
>> >>>> >> > setup to
>> >>>> >> > work, but that one was the first known successful
>> >>>> >> > environment to use.
>> >>>> >> > Note in this case the are no problems with FactoryFinder,
>> >>>> >> > because
>> >>>> >> > Spring DM provide a thread context classloader (TCCL) that
>> >>>> >> > fix that.
>> >>>> >> >
>> >>>> >> > The changes proposed impose the restriction that anyone who
>> >>>> >> > wants to
>> >>>> >> > use OSGi should use myfaces-bundle jar instead. But from
>> >>>> >> > other point
>> >>>> >> > of view it is clear that in such environment users could
>> >>>> >> > want to use
>> >>>> >> > mojarra api and myfaces impl, even if that is not really
>> >>>> >> > possible.
>> >>>> >> >
>> >>>> >> > Note the previous arguments are questionable of course,
>> >>>> >> > because in
>> >>>> >> > practice people will use myfaces-bundle jar, keeping things
>> >>>> >> > simple
>> >>>> >> > because you have to deal only with one bundle. So it does
>> >>>> >> > not suppose
>> >>>> >> > a problem, just a "side effect" to keep in mind.
>> >>>> >> >
>> >>>> >> > I think it is required to specify in more details which are
>> >>>> >> > the "side
>> >>>> >> > effects" of the changes proposed. Note on a previous mail i
>> >>>> >> > said "...
>> >>>> >> > I haven't look the code provided in deep ...", but I guess
>> >>>> >> > the patch
>> >>>> >> > proposed will prevent @JSFWebConfigParam annotations to be
>> >>>> >> > scanned for
>> >>>> >> > myfaces builder plugin and consequently break this
>> >>>> >> > generated site
>> >>>> >> > page:
>> >>>> >> >
>> >>>> >> > http://myfaces.apache.org/core20/myfaces-impl/webconfig.html
>> >>>> >> > http://myfaces.apache.org/core21/myfaces-impl/webconfig.html
>> >>>> >> >
>> >>>> >> > I don't see very clear the "benefits" of the change. I
>> >>>> >> > suppose it
>> >>>> >> > enhance debugging in some way, but is that true? can I do a
>> >>>> >> > change on
>> >>>> >> > shared, and do not have to recompile to see the change? If
>> >>>> >> > I set a
>> >>>> >> > break point on shared-core, the debugger will stop there? I
>> >>>> >> > would like
>> >>>> >> > to see a strong (and maybe heavier and tedious but
>> >>>> >> > necessary)
>> >>>> >> > argumentation before do the change.
>> >>>> >> >
>> >>>> >> > regards,
>> >>>> >> >
>> >>>> >> > Leonardo Uribe
>> >>>> >> >
>> >>>> >> > 2011/7/8 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> >>>> >> > > hi mark,
>> >>>> >> > > that's a bit off-topic ;) we already (have to) provide
>> >>>> >> > osgi bundles. we just
>> >>>> >> > > continue to do the same with the shade-plugin.
>> >>>> >> > > regards,
>> >>>> >> > > gerhard
>> >>>> >> > >
>> >>>> >> > > http://www.irian.at
>> >>>> >> > >
>> >>>> >> > > Your JSF powerhouse -
>> >>>> >> > > JSF Consulting, Development and
>> >>>> >> > > Courses in English and German
>> >>>> >> > >
>> >>>> >> > > Professional Support for Apache MyFaces
>> >>>> >> > >
>> >>>> >> > >
>> >>>> >> > >
>> >>>> >> > > 2011/7/8 Mark Struberg <strub...@yahoo.de>
>> >>>> >> > >>
>> >>>> >> > >> Hi folks!
>> >>>> >> > >>
>> >>>> >> > >> There are 2 problems with JSF under OSGi
>> >>>> >> > >>
>> >>>> >> > >> a) OSGi is in reality a _big_ mess and not really
>> >>>> >> > worth the troubles ;)
>> >>>> >> > >> It _should_ make it possible to elegantly switch
>> >>>> >> > implementations, but in
>> >>>> >> > >> practice you need to import/export all packages
>> >>>> >> > explicitly, even those which
>> >>>> >> > >> are only used indirectly.
>> >>>> >> > >>
>> >>>> >> > >> b) the design of the JSF-api could be more clear
>> >>>> >> > with separation (hey,
>> >>>> >> > >> it's 10 years old!). It is not possible to use a
>> >>>> >> > MyFaces-impl with a
>> >>>> >> > >> mojarra-api and vice versa, because methods like
>> >>>> >> > >> FacesContext#getCurrentInstance() (and similar)
>> >>>> >> > access impl classes from the
>> >>>> >> > >> API package. This makes it pretty hard to work
>> >>>> >> > OSGi.
>> >>>> >> > >>
>> >>>> >> > >> LieGrue,
>> >>>> >> > >> strub
>> >>>> >> > >>
>> >>>> >> > >> --- On Fri, 7/8/11, Jakob Korherr <jakob.korh...@gmail.com>
>> >>>> >> > wrote:
>> >>>> >> > >>
>> >>>> >> > >> > From: Jakob Korherr <jakob.korh...@gmail.com>
>> >>>> >> > >> > Subject: Re: Use maven-shade-plugin to
>> >>>> >> > prevent duplicate code -
>> >>>> >> > >> > revisited
>> >>>> >> > >> > To: "MyFaces Development" <dev@myfaces.apache.org>
>> >>>> >> > >> > Date: Friday, July 8, 2011, 1:09 PM
>> >>>> >> > >> > Hi Leo,
>> >>>> >> > >> >
>> >>>> >> > >> > Yes, I remember that you did some work
>> >>>> >> > related to this
>> >>>> >> > >> > stuff. Some
>> >>>> >> > >> > comments about your problems:
>> >>>> >> > >> >
>> >>>> >> > >> > 1) If you use myfaces-impl, the packages
>> >>>> >> > really are
>> >>>> >> > >> > *.shared_impl.*
>> >>>> >> > >> > (shade does the relocation on the classes).
>> >>>> >> > But a part of
>> >>>> >> > >> > this
>> >>>> >> > >> > statement is still true - we need to check
>> >>>> >> > config files
>> >>>> >> > >> > with
>> >>>> >> > >> > references to shared and shared_impl.
>> >>>> >> > >> >
>> >>>> >> > >> > 2) That's not true. We solved this problem in
>> >>>> >> > CODI, as
>> >>>> >> > >> > described.
>> >>>> >> > >> > Please take a look at the code ;)
>> >>>> >> > >> >
>> >>>> >> > >> > 3) We don't need to execute felix bundle
>> >>>> >> > plugin directly
>> >>>> >> > >> > in
>> >>>> >> > >> > myfaces-impl, b/c it won't work in an OSGi
>> >>>> >> > environment
>> >>>> >> > >> > anyway (see
>> >>>> >> > >> > e.g. FactoryFinder problems). We have
>> >>>> >> > myfaces-bundle for
>> >>>> >> > >> > this matter!
>> >>>> >> > >> >
>> >>>> >> > >> > Regards,
>> >>>> >> > >> > Jakob
>> >>>> >> > >> >
>> >>>> >> > >> > 2011/7/7 Leonardo Uribe <lu4...@gmail.com>:
>> >>>> >> > >> > > Hi
>> >>>> >> > >> > >
>> >>>> >> > >> > > I haven't look the code provided in
>> >>>> >> > deep, but long
>> >>>> >> > >> > time ago I tried
>> >>>> >> > >> > > it. In that time I saw the following
>> >>>> >> > problems:
>> >>>> >> > >> > >
>> >>>> >> > >> > > 1. There are some classes on shared that
>> >>>> >> > are used
>> >>>> >> > >> > outside it. For
>> >>>> >> > >> > > example, see
>> >>>> >> > >> >
>> >>>> >> > org.apache.myfaces.shared.webapp.webxml.DelegatedFacesServlet.
>> >>>> >> > >> > > We need to detect all similar cases and
>> >>>> >> > move those
>> >>>> >> > >> > classes to
>> >>>> >> > >> > > myfaces-impl, but renaming shared with
>> >>>> >> > shared-impl, or
>> >>>> >> > >> > just create
>> >>>> >> > >> > > classes that extends from the ones in
>> >>>> >> > shared, to
>> >>>> >> > >> > preserve backward
>> >>>> >> > >> > > behavior. In theory, the affected
>> >>>> >> > packages are:
>> >>>> >> > >> > >
>> >>>> >> > >> > >
>> >>>> >> >  org.apache.myfaces.shared_impl.webapp.webxml
>> >>>> >> > >> > >
>> >>>> >> >  org.apache.myfaces.shared_impl.taglib
>> >>>> >> > >> > >
>> >>>> >> >  org.apache.myfaces.shared_impl.taglib.core
>> >>>> >> > >> > >
>> >>>> >> > >> > > 2. Generated artifacts (-sources.jar,
>> >>>> >> > -javadoc.jar)
>> >>>> >> > >> > has problems. It
>> >>>> >> > >> > > is clear javadoc and source jars will
>> >>>> >> > not have
>> >>>> >> > >> > shared-impl.
>> >>>> >> > >> > > 3. shade plugin and felix maven bundle
>> >>>> >> > plugin does not
>> >>>> >> > >> > play well. By
>> >>>> >> > >> > > default bundle plugin is executed before
>> >>>> >> > shade plugin,
>> >>>> >> > >> > but what you
>> >>>> >> > >> > > want is the opposite, so the information
>> >>>> >> > on
>> >>>> >> > >> > MANIFEST.MF could be
>> >>>> >> > >> > > generated taking into account all
>> >>>> >> > classes. Note if we
>> >>>> >> > >> > solve 1, this
>> >>>> >> > >> > > should not be a problem, because classes
>> >>>> >> > inside shared
>> >>>> >> > >> > are myfaces
>> >>>> >> > >> > > internals (remember why spi interfaces
>> >>>> >> > are on impl
>> >>>> >> > >> > package and not in
>> >>>> >> > >> > > shared).
>> >>>> >> > >> > >
>> >>>> >> > >> > > I'll keep an eye on the resulting work.
>> >>>> >> > >> > >
>> >>>> >> > >> > > regards,
>> >>>> >> > >> > >
>> >>>> >> > >> > > Leonardo Uribe
>> >>>> >> > >> > >
>> >>>> >> > >> > > 2011/7/7 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> >>>> >> > >> > >> hi jakob,
>> >>>> >> > >> > >> great - thx!
>> >>>> >> > >> > >> regards,
>> >>>> >> > >> > >> gerhard
>> >>>> >> > >> > >>
>> >>>> >> > >> > >> http://www.irian.at
>> >>>> >> > >> > >>
>> >>>> >> > >> > >> Your JSF powerhouse -
>> >>>> >> > >> > >> JSF Consulting, Development and
>> >>>> >> > >> > >> Courses in English and German
>> >>>> >> > >> > >>
>> >>>> >> > >> > >> Professional Support for Apache
>> >>>> >> > MyFaces
>> >>>> >> > >> > >>
>> >>>> >> > >> > >>
>> >>>> >> > >> > >>
>> >>>> >> > >> > >> 2011/7/7 Jakob Korherr <jakob.korh...@gmail.com>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> Hi guys,
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> I committed a working draft to
>> >>>> >> > the branch at
>> >>>> >> > >> > [1]. However, there are
>> >>>> >> > >> > >>> some issues with the
>> >>>> >> > javadoc-plugin (see [2])
>> >>>> >> > >> > that must be fixed first
>> >>>> >> > >> > >>> in order to get the expected
>> >>>> >> > javadoc. The
>> >>>> >> > >> > other stuff (shading of
>> >>>> >> > >> > >>> shared and impl-ee6) already
>> >>>> >> > works as
>> >>>> >> > >> > expected!
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> Feel free to try it out
>> >>>> >> > yourself. Comments and
>> >>>> >> > >> > suggestions are welcome!
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> Regards,
>> >>>> >> > >> > >>> Jakob
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> [1]
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/
>> >>>> >> > >> > >>> [2] https://jira.codehaus.org/browse/MJAVADOC-320
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> 2011/7/7 Werner Punz <werner.p...@gmail.com>:
>> >>>> >> > >> > >>> > Excellent news ++1, the
>> >>>> >> > shared as we have
>> >>>> >> > >> > it is a bad design decision I
>> >>>> >> > >> > >>> > hope
>> >>>> >> > >> > >>> > shade will get rid of our
>> >>>> >> > debugging
>> >>>> >> > >> > issues we have with our current
>> >>>> >> > >> > >>> > shared.
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> > Werner
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> > Am 07.07.11 11:04, schrieb
>> >>>> >> > Jakob
>> >>>> >> > >> > Korherr:
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> Hi Gerhard,
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> Thx for (re-)opening
>> >>>> >> > this thread. I
>> >>>> >> > >> > already created a jira issue [1]
>> >>>> >> > >> > >>> >> and a core-branch [2]
>> >>>> >> > for
>> >>>> >> > >> > prototyping.
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> Currently I am
>> >>>> >> > struggling a little
>> >>>> >> > >> > bit with the javadoc-plugin, but
>> >>>> >> > >> > >>> >> this stuff should be
>> >>>> >> > fixed soon
>> >>>> >> > >> > (maybe even today).
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> I'll let you guys know
>> >>>> >> > when I am done
>> >>>> >> > >> > with the configuration, so that
>> >>>> >> > >> > >>> >> you can try it out
>> >>>> >> > yourselves!
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> Regards,
>> >>>> >> > >> > >>> >> Jakob
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> [1]
>> >>>> >> > >> > >>> >> https://issues.apache.org/jira/browse/MYFACES-3205
>> >>>> >> > >> > >>> >> [2]
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >> 2011/7/7 Gerhard
>> >>>> >> > Petracek<gerhard.petra...@gmail.com>:
>> >>>> >> > >> > >>> >>>
>> >>>> >> > >> > >>> >>> hi @ all,
>> >>>> >> > >> > >>> >>> the goal (as we
>> >>>> >> > discussed before)
>> >>>> >> > >> > is to get rid of the shared-impl
>> >>>> >> > >> > >>> >>> module
>> >>>> >> > >> > >>> >>> and move to the
>> >>>> >> > shade-plugin for
>> >>>> >> > >> > maven.
>> >>>> >> > >> > >>> >>> issues with javadoc
>> >>>> >> > and osgi
>> >>>> >> > >> > bundles prevented us from doing this
>> >>>> >> > >> > >>> >>> step.
>> >>>> >> > >> > >>> >>> however, with codi
>> >>>> >> > v1 we have a
>> >>>> >> > >> > project(-configuration) which fixes
>> >>>> >> > >> > >>> >>> all
>> >>>> >> > >> > >>> >>> the
>> >>>> >> > >> > >>> >>> issues we had with
>> >>>> >> > the
>> >>>> >> > >> > shade-plugin.
>> >>>> >> > >> > >>> >>> ->  imo we can
>> >>>> >> > (and should)
>> >>>> >> > >> > use it also for myfaces-core.
>> >>>> >> > >> > >>> >>> regards,
>> >>>> >> > >> > >>> >>> gerhard
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >>
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>> >
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> --
>> >>>> >> > >> > >>> Jakob Korherr
>> >>>> >> > >> > >>>
>> >>>> >> > >> > >>> blog: http://www.jakobk.com
>> >>>> >> > >> > >>> twitter: http://twitter.com/jakobkorherr
>> >>>> >> > >> > >>> work: http://www.irian.at
>> >>>> >> > >> > >>
>> >>>> >> > >> > >>
>> >>>> >> > >> > >
>> >>>> >> > >> >
>> >>>> >> > >> >
>> >>>> >> > >> >
>> >>>> >> > >> > --
>> >>>> >> > >> > Jakob Korherr
>> >>>> >> > >> >
>> >>>> >> > >> > blog: http://www.jakobk.com
>> >>>> >> > >> > twitter: http://twitter.com/jakobkorherr
>> >>>> >> > >> > work: http://www.irian.at
>> >>>> >> > >> >
>> >>>> >> > >
>> >>>> >> > >
>> >>>> >> >
>> >>>> >
>> >>>> >
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Jakob Korherr
>> >
>> > blog: http://www.jakobk.com
>> > twitter: http://twitter.com/jakobkorherr
>> > work: http://www.irian.at
>> >
>
>

Reply via email to