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...@apache.org> on 2005/09/15 08:59:57 UTC

Re: [m2 build] status update

Great work, Jorg! Thanks!

The beta-1 of m2 will be available very soon, so when that's available
we can try to stick to that version instead of using something from svn.

One feature of m2 is transitive dependencies. Although this is a nice
feature - in theory - there are some caveats with this: it only works
100% if all projects have correct poms! Unfortunately most don't today -
if you find a project with a bad pom, please report it into the MEV
module of m2s jira.
With bad poms you end up with too many jars in your final application.
Therefore I think we should add all blocks as dependencies to the webapp
module and see which jars are there and then fix the poms one after the
other. When all poms are correct, we can remove the dependencies again.
I'll have a look into this over the weekend - if noone beats me in this.

Jorg, you turn off tests in your example below. Is this because most
tests in the blocks are failing? If so, we should really try to fix the
tests or remove them (as discussed recently).

Carsten

Jorg Heymans wrote:
> Hi,
> 
> I have just finished putting all blocks under m2 pom control, which
> means that we are able to compile the whole of trunk using m2 - yay!
> 
> If you would like to test this, update your local copies, install a
> recent SVN version of m2 [1], then from $COCOON_HOME directory do
> 
> "m2 -Dmaven.skip.test=true install"
> 
> This will compile core, webapp + all blocks and place them in your local
> repository. Instead of "install" you can also do "package", which
> packages the jars without putting them in your local repo.
> 
> Ignore all the warnings for now, but please report any dependency errors
> that may have slipped through.
> 
> Note that its possible that you'll get an OOM exception, I'm still
> looking into this.
> 
> My next steps will be
> - understand exactly what the RBGs (Real Block Guys) expect from maven
> - get the webapp going
> - see how m2 handles inclusion/exclusion of blocks
> 
> 
> Thanks,
> Jorg
> 
> [1] http://maven.apache.org/maven2/developers/building.html
> 
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [m2 build] status update

Posted by Carsten Ziegeler <cz...@apache.org>.
Jorg Heymans wrote:
> Carsten Ziegeler wrote:
> 
> 
> There were some tests in core or webapp failing yes, making it
> impossible to do a build. (is there a switch that says "continue even if
> tests fail" ?)
> 
Hmm, the tests in core run every second time for me and every other
second time one tests (I think for the thread manager) fails.
You can use maven.test.failure.ignore to ignore test failures.

> Note that I did not add a <testSourceDirectory> to the blocks yet,
> should be trivial however.
> 
Ah, ok, yeah we should do this.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [m2 build] status update

Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Le 15 sept. 05, à 09:39, Jorg Heymans a écrit :
> 
>>...There were some tests in core or webapp failing yes, making it
>>impossible to do a build. (is there a switch that says "continue even 
>>if
>>tests fail" ?)..
> 
> 
> If there's not, it would be good to *move* failing tests to a specific 
> subdirectory instead of removing them, so as to not lose them and avoid 
> them messing up the m2 build.
> 
> Tests are sooooooo precious, I'd hate us to simply delete them ;-)
> 
Yeah, in general I agree - but if noone cares about failing tests they
are pretty useless :(
Anyways, let's move them for now and see if the m2 build helps us in
looking after tests as they are run by default.

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [m2 build] status update

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 15 sept. 05, à 09:39, Jorg Heymans a écrit :
> ...There were some tests in core or webapp failing yes, making it
> impossible to do a build. (is there a switch that says "continue even 
> if
> tests fail" ?)..

If there's not, it would be good to *move* failing tests to a specific 
subdirectory instead of removing them, so as to not lose them and avoid 
them messing up the m2 build.

Tests are sooooooo precious, I'd hate us to simply delete them ;-)

-Bertrand

Re: [m2 build] status update

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 15 sept. 05, à 09:39, Jorg Heymans a écrit :
> ...There were some tests in core or webapp failing yes, making it
> impossible to do a build. (is there a switch that says "continue even 
> if
> tests fail" ?)...

Someone just sent me this link, maybe it helps, it shows how to exclude 
some tests from the pom (but I guess it's for maven 1?):

http://jroller.com/page/carlossg?entry=maven_tips_and_tricks_running

-Bertrand

Re: [m2 build] status update

Posted by Jorg Heymans <jh...@domek.be>.
Carsten Ziegeler wrote:

> One feature of m2 is transitive dependencies. Although this is a nice
> feature - in theory - there are some caveats with this: it only works
> 100% if all projects have correct poms! Unfortunately most don't today -
> if you find a project with a bad pom, please report it into the MEV
> module of m2s jira.

Initially I added poms for our dependencies at cvs.apache.org , but gave
up somewhere along the way. Indeed, running the m2 build returns many
faulty or missing poms, I'll see about reporting/adding them.

> With bad poms you end up with too many jars in your final application.
> Therefore I think we should add all blocks as dependencies to the webapp
> module and see which jars are there and then fix the poms one after the
> other. When all poms are correct, we can remove the dependencies again.
> I'll have a look into this over the weekend - if noone beats me in this.

good approach!

> 
> Jorg, you turn off tests in your example below. Is this because most
> tests in the blocks are failing? If so, we should really try to fix the
> tests or remove them (as discussed recently).

There were some tests in core or webapp failing yes, making it
impossible to do a build. (is there a switch that says "continue even if
tests fail" ?)

Note that I did not add a <testSourceDirectory> to the blocks yet,
should be trivial however.


Regards
Jorg