You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cz...@apache.org on 2006/10/06 11:06:32 UTC
svn commit: r453534 -
/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Author: cziegeler
Date: Fri Oct 6 02:06:31 2006
New Revision: 453534
URL: http://svn.apache.org/viewvc?view=rev&rev=453534
Log:
Deployer plugin will run automatically
Modified:
cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Modified: cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml?view=diff&rev=453534&r1=453533&r2=453534
==============================================================================
--- cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml (original)
+++ cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml Fri Oct 6 02:06:31 2006
@@ -37,6 +37,14 @@
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-deployer-plugin</artifactId>
<version>1.0.0-M2-SNAPSHOT</version>
+ <executions>
+ <execution>
+ <phase>package</phase>
+ <goals>
+ <goal>deploy</goal>
+ </goals>
+ </execution>
+ </executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
Re: Deploying without copying
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>> a) search for all relevant jar files containing a COB-INF directory and
>> all the other directories we usually extract during deployment. This can
>> be done using the class loader which returns urls for each jar file.
>
> Which method in the classloader does that? Otherwise we know what
> directories to search for jars anyway.
>
Its the getResources(String) method we could use. It returns urls to the
jars. This avoids scanning all jars by hand and should also work if
people are not putting their jars into WEB-INF/lib but for example
commons/lib of the servlet container.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Deploying without copying (was: svn commit: r453534)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Short background:
In 2.2 blocks can contain configuration files for the components that
they provide (in subdirectories of META-INF) and webapp resources,
sitemap etc (in COB-INF). While building a Cocoon webapp there is a
separate deploy step where the Maven plugin cocoon-deployer-plugin is
used. This plugin scan all the jars that the webapp depends on and look
for certain directories (under META-INF and COB-INF) and copy the
contents of these files to directories in the resulting webapp.
An advantage with this copying process is of course that it is easy to
see what the resulting webapp consists of. But a great disadvantage is
that fast prototyping not works for blocks.
So we discussed how we could get rid of the compile time deployment step
and instead read the needed resources directly from the (possibly
zipped) blocks.
(comments in the end)
Carsten Ziegeler skrev:
> Carsten Ziegeler wrote:
>> Reinhard Poetz wrote:
>>>>> Currently the deployer extracts the files from COB-INF and META-INF into
>>>>> the file system (into the web application). We talked about skipping
>>>>> this step and adding a mechanism to the core of Cocoon which allows to
>>>>> access the information from within the jar without extracting it.
>>>>> This should be doable by using the class loader and some detection
>>>>> mechanism and avoids the deployer plugin. And more important it means
>>>> Seems like cocoon solutions are always a step ahead my comprehension. Is
>>>> this really feasible?
>>> Why not?
>>>
>> Giacomo and I talked a little bit about this at the GT and to be honest,
>> we are not sure if it's 100% feasible, but it should! (I really love
>> such answers).
>>
>> We are able to find all jar files containing a COB-INF directory through
>> the class loader and we should be able to get a stream to this jar.
>> Then we can just go through the archive, find the files, and register
>> them somewere.
>>
> Actually we are looking for a volunteer to implement this asap :) (If
> noone has
> done it until the end of October I will herhaps have some time by then).
>
> So, currently Cocoon is setup through Spring by using the namespace
> authoring stuff. We currently have a "cocoon:settings" element which
> will sets up the settings object of Cocoon and does some minor other stuff.
> We could hook up there and:
> a) search for all relevant jar files containing a COB-INF directory and
> all the other directories we usually extract during deployment. This can
> be done using the class loader which returns urls for each jar file.
Which method in the classloader does that? Otherwise we know what
directories to search for jars anyway.
> b) Once we have all relevant jar files we can scan them using the usual
> zip stuff (we got the url of the jar file in a) ) and get hold of all
> relevant files contained in the COB-INF directory (and other locations).
> c) We have to extend the various configuration implementations (for
> properties, for spring config files and for avalon files) to include the
> stuff from b)
>
> I think this is more or less the first step; we talk about some more
> details which I can't remember right now. Perhaps Reinhard or Daniel can
> fill in here.
>
> Carsten
Using what Carsten describe above we could create a (transversable)
block context protocol:
blockcontext:/<jarname>/<path>
instead of jarname it would be preferable to use the Maven artifact id,
it seem like Maven is storing that within the jar, so maybe we could
extract that. The blockcontext protocol would only need to take care of
the first level in the path hierarchy, for the next level a
(transversable) ZipSource or FileSource is returned.
For fast prototyping the blockcontext Source could also be configured
with a file that connects the block id to the file path of the version
you are working on.
Probably, much of the code from cocoon-deployer-plugin can be reused.
--- o0o ---
With such a block conext protocol we could handle the various
configuration needs.
The cocoon.xconf could include all
blockcontext:/*/META-INF/legacy/xconf/*.xconf
and
blockcontext:/*/META-INF/legacy/sitemap-aditions/*.xconf
and the Spring configurations
blockcontext:/*/META-INF/spring/*.xml
could be included by from the appropriate "Spring in Cocoon" mechanism.
This would probably require that the wildcard mechanism for the the
configuration includes is extended.
The samples would contain things like:
<map:match pattern="*/**">
<map:mount uri-prefix="{1}" src="blockcontext:/{1}/COB-INF/"/>
</map:match>
In the BlockServlet configuration for e.g. the forms sample the
blockContextURL property would be set to:
blockcontext:/cocoon-forms-sample/COB-INF/
--- o0o ---
With such a protocol we would, AFAICS, get rid of the need for copying
files.
/Daniel
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>>>> Currently the deployer extracts the files from COB-INF and META-INF into
>>>> the file system (into the web application). We talked about skipping
>>>> this step and adding a mechanism to the core of Cocoon which allows to
>>>> access the information from within the jar without extracting it.
>>>> This should be doable by using the class loader and some detection
>>>> mechanism and avoids the deployer plugin. And more important it means
>>> Seems like cocoon solutions are always a step ahead my comprehension. Is
>>> this really feasible?
>> Why not?
>>
> Giacomo and I talked a little bit about this at the GT and to be honest,
> we are not sure if it's 100% feasible, but it should! (I really love
> such answers).
>
> We are able to find all jar files containing a COB-INF directory through
> the class loader and we should be able to get a stream to this jar.
> Then we can just go through the archive, find the files, and register
> them somewere.
>
Actually we are looking for a volunteer to implement this asap :) (If
noone has
done it until the end of October I will herhaps have some time by then).
So, currently Cocoon is setup through Spring by using the namespace
authoring stuff. We currently have a "cocoon:settings" element which
will sets up the settings object of Cocoon and does some minor other stuff.
We could hook up there and:
a) search for all relevant jar files containing a COB-INF directory and
all the other directories we usually extract during deployment. This can
be done using the class loader which returns urls for each jar file.
b) Once we have all relevant jar files we can scan them using the usual
zip stuff (we got the url of the jar file in a) ) and get hold of all
relevant files contained in the COB-INF directory (and other locations).
c) We have to extend the various configuration implementations (for
properties, for spring config files and for avalon files) to include the
stuff from b)
I think this is more or less the first step; we talk about some more
details which I can't remember right now. Perhaps Reinhard or Daniel can
fill in here.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>>> Currently the deployer extracts the files from COB-INF and META-INF into
>>> the file system (into the web application). We talked about skipping
>>> this step and adding a mechanism to the core of Cocoon which allows to
>>> access the information from within the jar without extracting it.
>>> This should be doable by using the class loader and some detection
>>> mechanism and avoids the deployer plugin. And more important it means
>> Seems like cocoon solutions are always a step ahead my comprehension. Is
>> this really feasible?
>
> Why not?
>
Giacomo and I talked a little bit about this at the GT and to be honest,
we are not sure if it's 100% feasible, but it should! (I really love
such answers).
We are able to find all jar files containing a COB-INF directory through
the class loader and we should be able to get a stream to this jar.
Then we can just go through the archive, find the files, and register
them somewere.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>> Leszek Gawron wrote:
>>>>> Hmm, that's bad - I don't see a solution for this now. But we
>>>>> discussed
>>>>> at the GT an alternative handling of our blocks which would make the
>>>>> cocoon:deploy plugin obsolete.
>>>> which is ?
>>> :)
>>>
>>> Currently the deployer extracts the files from COB-INF and META-INF into
>>> the file system (into the web application). We talked about skipping
>>> this step and adding a mechanism to the core of Cocoon which allows to
>>> access the information from within the jar without extracting it.
>>> This should be doable by using the class loader and some detection
>>> mechanism and avoids the deployer plugin. And more important it means
>>
>> Seems like cocoon solutions are always a step ahead my comprehension.
>> Is this really feasible?
>
> Why not?
By asking "is this really feasible" I hoped someone would say exactly how :)
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>> Leszek Gawron wrote:
>>>> Hmm, that's bad - I don't see a solution for this now. But we discussed
>>>> at the GT an alternative handling of our blocks which would make the
>>>> cocoon:deploy plugin obsolete.
>>> which is ?
>> :)
>>
>> Currently the deployer extracts the files from COB-INF and META-INF into
>> the file system (into the web application). We talked about skipping
>> this step and adding a mechanism to the core of Cocoon which allows to
>> access the information from within the jar without extracting it.
>> This should be doable by using the class loader and some detection
>> mechanism and avoids the deployer plugin. And more important it means
>
> Seems like cocoon solutions are always a step ahead my comprehension. Is
> this really feasible?
Why not?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Leszek Gawron <lg...@apache.org>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>>> Hmm, that's bad - I don't see a solution for this now. But we discussed
>>> at the GT an alternative handling of our blocks which would make the
>>> cocoon:deploy plugin obsolete.
>> which is ?
> :)
>
> Currently the deployer extracts the files from COB-INF and META-INF into
> the file system (into the web application). We talked about skipping
> this step and adding a mechanism to the core of Cocoon which allows to
> access the information from within the jar without extracting it.
> This should be doable by using the class loader and some detection
> mechanism and avoids the deployer plugin. And more important it means
Seems like cocoon solutions are always a step ahead my comprehension. Is
this really feasible?
--
Leszek Gawron
lgawron@apache.org
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>> Hmm, that's bad - I don't see a solution for this now. But we discussed
>> at the GT an alternative handling of our blocks which would make the
>> cocoon:deploy plugin obsolete.
>
> which is ?
:)
Currently the deployer extracts the files from COB-INF and META-INF into
the file system (into the web application). We talked about skipping
this step and adding a mechanism to the core of Cocoon which allows to
access the information from within the jar without extracting it.
This should be doable by using the class loader and some detection
mechanism and avoids the deployer plugin. And more important it means
that adding a block is just dropping a jar file into the WEB-INF/lib
directory which makes using Cocoon even easier - especially if you don't
want to use Maven (I can't imagine that someone does not want to use
maven but anyway...).
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> my bad .. I had cocoon:deploy plugin defined at parent pom so it ran
>> twice (still seems like a maven bug to me).
>>
>> other problems still apply
>>
> Hmm, that's bad - I don't see a solution for this now. But we discussed
> at the GT an alternative handling of our blocks which would make the
> cocoon:deploy plugin obsolete.
which is ?
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
> my bad .. I had cocoon:deploy plugin defined at parent pom so it ran
> twice (still seems like a maven bug to me).
>
> other problems still apply
>
Hmm, that's bad - I don't see a solution for this now. But we discussed
at the GT an alternative handling of our blocks which would make the
cocoon:deploy plugin obsolete.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> cziegeler@apache.org wrote:
>> Author: cziegeler
>> Date: Fri Oct 6 02:06:31 2006
>> New Revision: 453534
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=453534
>> Log:
>> Deployer plugin will run automatically
>>
>> Modified:
>>
>> cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
>>
>>
>> Modified:
>> cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml?view=diff&rev=453534&r1=453533&r2=453534
>>
>> ==============================================================================
>>
>> ---
>> cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
>> (original)
>> +++
>> cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
>> Fri Oct 6 02:06:31 2006
>> @@ -37,6 +37,14 @@
>> <groupId>org.apache.cocoon</groupId>
>> <artifactId>cocoon-deployer-plugin</artifactId>
>> <version>1.0.0-M2-SNAPSHOT</version>
>> + <executions>
>> + <execution>
>> + <phase>package</phase>
>> + <goals>
>> + <goal>deploy</goal>
>> + </goals>
>> + </execution>
>> + </executions>
>> </plugin>
>> <plugin>
>> <groupId>org.mortbay.jetty</groupId>
>
> This does not as expected. Probably because you are not able to specify
> the order of goals to be executed. So the order is:
>
> war:war
> cocoon:deploy
> cocoon:deploy (again .. have no idea where that comes from)
my bad .. I had cocoon:deploy plugin defined at parent pom so it ran
twice (still seems like a maven bug to me).
other problems still apply
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r453534 - /cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
Posted by Leszek Gawron <lg...@mobilebox.pl>.
cziegeler@apache.org wrote:
> Author: cziegeler
> Date: Fri Oct 6 02:06:31 2006
> New Revision: 453534
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=453534
> Log:
> Deployer plugin will run automatically
>
> Modified:
> cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
>
> Modified: cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml
> URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml?view=diff&rev=453534&r1=453533&r2=453534
> ==============================================================================
> --- cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml (original)
> +++ cocoon/trunk/tools/archetypes/cocoon-22-archetype-block/src/main/resources/archetype-resources/pom.xml Fri Oct 6 02:06:31 2006
> @@ -37,6 +37,14 @@
> <groupId>org.apache.cocoon</groupId>
> <artifactId>cocoon-deployer-plugin</artifactId>
> <version>1.0.0-M2-SNAPSHOT</version>
> + <executions>
> + <execution>
> + <phase>package</phase>
> + <goals>
> + <goal>deploy</goal>
> + </goals>
> + </execution>
> + </executions>
> </plugin>
> <plugin>
> <groupId>org.mortbay.jetty</groupId>
This does not as expected. Probably because you are not able to specify
the order of goals to be executed. So the order is:
war:war
cocoon:deploy
cocoon:deploy (again .. have no idea where that comes from)
see my log of 'mvn clean package':
> [INFO] Scanning for projects...
> [INFO] ----------------------------------------------------------------------------
> [INFO] Building GeminiSmart Webapp
> [INFO] task-segment: [clean, package]
> [INFO] ----------------------------------------------------------------------------
> [INFO] [clean:clean]
> [INFO] Deleting directory c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target
> [INFO] Deleting directory c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\classes
> [INFO] Deleting directory c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\test-classes
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING]
> Artifact junit:junit:jar:3.8.1:test retains local scope 'test' overriding broader scope 'compile'
> given by a dependency. If this is not intended, modify or remove the local scope.
>
> [INFO] [compiler:compile]
> [INFO] No sources to compile
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] No tests to run.
> [INFO] [war:war]
> [INFO] Exploding webapp...
> [INFO] Copy webapp resources to c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Assembling webapp geminismart-server-webapp in c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Generating war c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT.war
> [INFO] Building war: c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT.war
> [INFO] [cocoon:deploy {execution: default}]
> [INFO] Exploding webapp...
> [INFO] Copy webapp resources to c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Assembling webapp geminismart-server-webapp in c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Deploying icu4j
[...]
> [INFO] Deploying nekohtml
> [INFO] Copy webapp resources to c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] [cocoon:deploy {execution: default}]
> [INFO] Exploding webapp...
> [INFO] Copy webapp resources to c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Assembling webapp geminismart-server-webapp in c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] Deploying icu4j
[...]
> [INFO] Deploying nekohtml
> [INFO] Copy webapp resources to c:\dev\projects\gemini-smart\server\geminismart-server-webapp\target\geminismart-server-webapp-1.0.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 25 seconds
> [INFO] Finished at: Fri Oct 06 12:48:56 CEST 2006
> [INFO] Final Memory: 9M/17M
> [INFO] ------------------------------------------------------------------------
so in the end you have proper web application in
\target\geminismart-server-webapp-1.0.0-SNAPSHOT but the war is not
cocoon:deploy'ed !
if you remove execution binding you can simply do:
mvn clean cocoon:deploy - to get a properly built webapp
mvn clean cocoon:deploy-war - to get a good war
still no way to make 'mvn clean package' working though.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65