You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@googlemail.com> on 2006/02/28 21:55:18 UTC
Building trunk - Maven is your friend
After some thinking I think I have a simple solution to our problem
about how to build trunk with m2: it's simple, Maven can do this for us!
The Maven war plugin is able to assemble the webapp by combining the
contents of several war projects. So if we change all of our blocks
projects (that have samples or web resources) from "jar" to "war" and
then add the dependency to the war project in the pom in cocoon-webapp,
Maven does everything for us. I just tried this with the
cocoon-session-fw-sample block and it seems to work. Though I did not
get everything working. See below
Now - as always - there are some (minor) problems:
- Currently Maven requires that a war has a web.xml: This requires to
add a dummy web.xml to each sample block; this web.xml is later on
ignored as the web.xml from the cocoon-webapp is used. I guess if we go
this way, we can ask the maven guys to provide some option to make
web.xml optional.
- We have to restructure the directory layout of our blocks a little
bit: all resources for the webapp should go to src/main/webapp. So, for
example a block with a configuration (no sample block) has:
src/main/webapp/WEB-INF/conf with the configuration files while a sample
block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
- This seems to require the development version of the webapp plugin and
I wasn't able to include two webapps (session-fw-impl and session-fw).
Though looking at the code, it should work, m2 refused to do this, but
I had a week network connection, so it might be due to this?; I don't
have time today to invest here further, but I'm sure it should work,
so this should be a viable solution.
I think someone recently raised the question, how we distinguish between
sample and and functionality blocks. I think for now we can go with a
naming convention: if you want the sample, you depend on the sample
project, if not you depend on the impl.
WDYT?
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Building trunk - Maven is your friend
Posted by sandra200 <sa...@yahoo.com>.
Hello
Good Day
My name is sandra i saw your profile today at (nabble.com) and became
intrested
in you,i will also like to know you the more, and i want you
to send an email to my email address, so i can give you my picture for you
to know whom i believe we can move from here to next level I am waiting for
your mail to my maill address (sandra.johnson82@yahoo.com )
Remeber the distance or colour does not matter but love matters alot
in life with love sandra please reply to my email,
(sandra.johnson82@yahoo.com) so i can give you my picture and will can move
from here to next love. my lovely one,
Remeber love and understading matters alot in life one love;
Awaiting to hear from you soonest,
Thanks and God bless you,
Form sandra
--
View this message in context: http://www.nabble.com/Building-trunk---Maven-is-your-friend-tp3171723p18021063.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: Building trunk - Maven is your friend
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz schrieb:
> Daniel Fagerstrom wrote:
>
>> OTH we badly need to get some limited samples working for trunk ASAP. So
>> that the community can get its faith in trunk back. And so that the
>> threshold for getting involved in trunk development and testing becomes
>> lower.
>
> Yes, right. Please guys, give me time till Sunday to come up with something
> useful. If I don't get it working (for whatever reason) we can go the way
> Carsten proposed _for now_.
>
Ok, sure - I didn't know that you're that close to a solution; take your
time, we can wait some more days. If you need any help just let us know
- I might have some time over the weekend as well.
So, let's give Reinhard more time, we can come back to this solution
whenever we want.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Building trunk - Maven is your friend
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> OTH we badly need to get some limited samples working for trunk ASAP. So
> that the community can get its faith in trunk back. And so that the
> threshold for getting involved in trunk development and testing becomes
> lower.
Yes, right. Please guys, give me time till Sunday to come up with something
useful. If I don't get it working (for whatever reason) we can go the way
Carsten proposed _for now_.
--
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: Building trunk - Maven is your friend
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Carsten Ziegeler wrote:
>> After some thinking I think I have a simple solution to our problem
>> about how to build trunk with m2: it's simple, Maven can do this for us!
>>
>> The Maven war plugin is able to assemble the webapp by combining the
>> contents of several war projects. So if we change all of our blocks
>> projects (that have samples or web resources) from "jar" to "war" and
>
> please don't do this, I will explain later
>
>> then add the dependency to the war project in the pom in cocoon-webapp,
>> Maven does everything for us. I just tried this with the
>> cocoon-session-fw-sample block and it seems to work. Though I did not
>> get everything working. See below
>>
>> Now - as always - there are some (minor) problems:
>> - Currently Maven requires that a war has a web.xml: This requires to
>> add a dummy web.xml to each sample block; this web.xml is later on
>> ignored as the web.xml from the cocoon-webapp is used. I guess if we go
>> this way, we can ask the maven guys to provide some option to make
>> web.xml optional.
>> - We have to restructure the directory layout of our blocks a little
>> bit: all resources for the webapp should go to src/main/webapp. So, for
>> example a block with a configuration (no sample block) has:
>> src/main/webapp/WEB-INF/conf with the configuration files while a sample
>> block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
>
> no, please don't do this either. We need our resources in
> src/main/resources/COB-INF to make them 'real blocks'. Doing something
> different, would be a step into the wrong direction.
I agree with Reinhard to a large part, and would also like to add that
the proposed solution will be quite heavy as each block will need a copy
of cocoon-core and all its dependencies.
OTH we badly need to get some limited samples working for trunk ASAP. So
that the community can get its faith in trunk back. And so that the
threshold for getting involved in trunk development and testing becomes
lower.
So I suggest that we follow Carstens suggestion for a few important
samples like forms and portal samples. And make the cocoon-webapp
dependent on these samples. But instead of moving the configuration
files from src/main/resources, we should just copy them to the samples.
Copying is of course not ideal, but it will only be for a few samples,
so it shouldn't be that much work to keep in synch, and it is only for a
limited time.
I'm totally against moving the configuration files, as it will disturb
the blocks work, and we are close to be able to deliver something much
more usable than the above solution.
/Daniel
Re: Building trunk - Maven is your friend
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> After some thinking I think I have a simple solution to our problem
> about how to build trunk with m2: it's simple, Maven can do this for us!
>
> The Maven war plugin is able to assemble the webapp by combining the
> contents of several war projects. So if we change all of our blocks
> projects (that have samples or web resources) from "jar" to "war" and
please don't do this, I will explain later
> then add the dependency to the war project in the pom in cocoon-webapp,
> Maven does everything for us. I just tried this with the
> cocoon-session-fw-sample block and it seems to work. Though I did not
> get everything working. See below
>
> Now - as always - there are some (minor) problems:
> - Currently Maven requires that a war has a web.xml: This requires to
> add a dummy web.xml to each sample block; this web.xml is later on
> ignored as the web.xml from the cocoon-webapp is used. I guess if we go
> this way, we can ask the maven guys to provide some option to make
> web.xml optional.
> - We have to restructure the directory layout of our blocks a little
> bit: all resources for the webapp should go to src/main/webapp. So, for
> example a block with a configuration (no sample block) has:
> src/main/webapp/WEB-INF/conf with the configuration files while a sample
> block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
no, please don't do this either. We need our resources in
src/main/resources/COB-INF to make them 'real blocks'. Doing something
different, would be a step into the wrong direction.
> - This seems to require the development version of the webapp plugin and
> I wasn't able to include two webapps (session-fw-impl and session-fw).
> Though looking at the code, it should work, m2 refused to do this, but
> I had a week network connection, so it might be due to this?; I don't
> have time today to invest here further, but I'm sure it should work,
> so this should be a viable solution.
>
> I think someone recently raised the question, how we distinguish between
> sample and and functionality blocks. I think for now we can go with a
> naming convention: if you want the sample, you depend on the sample
> project, if not you depend on the impl.
>
> WDYT?
The problem is that the solution doesn't handle dependencies and we don't get a
wiring.xml. Both problems are solved by the block-deployer.
Please have a look at my both tutorials
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
to get an idea how I think block deployment (and the creation of web
applications) should worl.
The first one already works and I will make the second one work ASAP (hopefully
this week) so that we can create a web application that consists of more than
one block.
--
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: Building trunk - Maven is your friend
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> After some thinking I think I have a simple solution to our problem
> about how to build trunk with m2: it's simple, Maven can do this for us!
>
> The Maven war plugin is able to assemble the webapp by combining the
> contents of several war projects. So if we change all of our blocks
> projects (that have samples or web resources) from "jar" to "war" and
> then add the dependency to the war project in the pom in cocoon-webapp,
> Maven does everything for us. I just tried this with the
> cocoon-session-fw-sample block and it seems to work. Though I did not
> get everything working. See below
>
> Now - as always - there are some (minor) problems:
> - Currently Maven requires that a war has a web.xml: This requires to
> add a dummy web.xml to each sample block; this web.xml is later on
> ignored as the web.xml from the cocoon-webapp is used. I guess if we go
> this way, we can ask the maven guys to provide some option to make
> web.xml optional.
> - We have to restructure the directory layout of our blocks a little
> bit: all resources for the webapp should go to src/main/webapp. So, for
> example a block with a configuration (no sample block) has:
> src/main/webapp/WEB-INF/conf with the configuration files while a sample
> block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
> - This seems to require the development version of the webapp plugin and
> I wasn't able to include two webapps (session-fw-impl and session-fw).
> Though looking at the code, it should work, m2 refused to do this, but
> I had a week network connection, so it might be due to this?; I don't
> have time today to invest here further, but I'm sure it should work,
> so this should be a viable solution.
>
> I think someone recently raised the question, how we distinguish between
> sample and and functionality blocks. I think for now we can go with a
> naming convention: if you want the sample, you depend on the sample
> project, if not you depend on the impl.
I like it. Still I have one big issue with m2 webapp approach:
mvn war:inplace copies all resources to cocoon-webapp/src/webapp
directory. There is no mvn clean for that and no easy way to tell which
file really belongs to cocoon-webapp/src/webapp/** and which one is
copied over from another module (and under no circumstances should be
commited to the repository).
--
Leszek Gawron lgawron@mobilebox.pl
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: Building trunk - Maven is your friend
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> After some thinking I think I have a simple solution to our problem
> about how to build trunk with m2: it's simple, Maven can do this for us!
>
> The Maven war plugin is able to assemble the webapp by combining the
> contents of several war projects. So if we change all of our blocks
> projects (that have samples or web resources) from "jar" to "war" and
please don't do this, I will explain later
> then add the dependency to the war project in the pom in cocoon-webapp,
> Maven does everything for us. I just tried this with the
> cocoon-session-fw-sample block and it seems to work. Though I did not
> get everything working. See below
>
> Now - as always - there are some (minor) problems:
> - Currently Maven requires that a war has a web.xml: This requires to
> add a dummy web.xml to each sample block; this web.xml is later on
> ignored as the web.xml from the cocoon-webapp is used. I guess if we go
> this way, we can ask the maven guys to provide some option to make
> web.xml optional.
> - We have to restructure the directory layout of our blocks a little
> bit: all resources for the webapp should go to src/main/webapp. So, for
> example a block with a configuration (no sample block) has:
> src/main/webapp/WEB-INF/conf with the configuration files while a sample
> block might have a src/main/webapp/samples/blocks/BLOCKNAME/ directory.
no, please don't do this either. We need our resources in
src/main/resources/COB-INF to make them 'real blocks'. Doing something
different, would be a step into the wrong direction.
> - This seems to require the development version of the webapp plugin and
> I wasn't able to include two webapps (session-fw-impl and session-fw).
> Though looking at the code, it should work, m2 refused to do this, but
> I had a week network connection, so it might be due to this?; I don't
> have time today to invest here further, but I'm sure it should work,
> so this should be a viable solution.
>
> I think someone recently raised the question, how we distinguish between
> sample and and functionality blocks. I think for now we can go with a
> naming convention: if you want the sample, you depend on the sample
> project, if not you depend on the impl.
>
> WDYT?
The problem is that the solution doesn't handle dependencies and we don't get a
wiring.xml. Both problems are solved by the block-deployer.
Please have a look at my both tutorials
http://cocoon.zones.apache.org/daisy/documentation/g2/796.html
http://cocoon.zones.apache.org/daisy/documentation/g2/797.html
to get an idea how I think block deployment (and the creation of web
applications) should worl.
The first one already works and I will make the second one work ASAP (hopefully
this week) so that we can create a web application that consists of more than
one block.
--
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