You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by jh...@apache.org on 2005/12/14 17:01:30 UTC

svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Author: jheymans
Date: Wed Dec 14 08:00:57 2005
New Revision: 356791

URL: http://svn.apache.org/viewcvs?rev=356791&view=rev
Log:
disable allways failing tests

Modified:
    cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Modified: cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml?rev=356791&r1=356790&r2=356791&view=diff
==============================================================================
--- cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml (original)
+++ cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml Wed Dec 14 08:00:57 2005
@@ -46,6 +46,7 @@
               <value>3</value>
             </property>
           </systemProperties>
+          <testFailureIgnore>true</testFailureIgnore>
         </configuration>
       </plugin>
     </plugins>
@@ -343,4 +344,4 @@
       <version>20040329</version>
     </dependency>
   </dependencies>
-</project>
\ No newline at end of file
+</project>



Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Jorg Heymans <jh...@domek.be>.

Ralph Goers wrote:

> I don't use Eclipse. I ran the idea plugin and it did create a project,
> but it generated a single module project which was not what I expected.

dunno that, the eclipse plugin is more actively developed i guess at the
moment. It generates a separate project per pom and links them together
via eclipse project dependencies.

> 
>> You have some experience using maven1, maybe you could help out on the
>> assembly part ? It should be fairly straightforward to come up with a
>> descriptor, give or take a few bugs along the way. Basically the
>> assembly descriptor builds a full binary distribution of a project, you
>> just tell it which format and what should go in it.
>>  
>>
> Are you talking about creating the pom.xml for each project or is this
> some other descriptor?
> 

http://maven.apache.org/guides/mini/guide-assemblies.html

>>
>> The repository won't contain any ready to mount webapps as such. That
>> should go in the archetype really. I have the archetype working again
>> locally, i'll go and commit this right now.
>>  
>>
> Aren't archetypes just templates? (from my minimal review of maven2). 
> What about the sample site? I would expect that to be a project somewhere.
> 

an archetype is a template directory structure yes. Each file in that
structure is potentially a template in the sense that it could contain
placeholder variables that are replaced upon archetype creation.
Now it is exactly this template substitution mechanism that is causing
probs at the moment :
a) it searches binary files as well, often resulting in NPEs [1]
b) it mangles special characters eg the copyright character we have in
each license header [2]


I've created issues for both problems, unless i find some time to look
at the actual code we will have to wait for them to fix this. The
easiest thing to do would be to just disable template substition
completely - maybe you can nag Jason or Brett about it when you see them ;)

Another problem, which is supposedly fixed in the latests snapshots, is
that you can't load archetypes from a server other than the central
repository [3].


Jorg

[1] http://jira.codehaus.org/browse/ARCHETYPE-3
[2] http://jira.codehaus.org/browse/ARCHETYPE-19
[3] http://jira.codehaus.org/browse/MNG-1670


Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> 
> 
> Jorg Heymans wrote:
> 
>>
>> Try and run the eclipse target as well and see how you find the eclipse
>> project structure (it's described in the readme).
>>  
>>
> I don't use Eclipse. I ran the idea plugin and it did create a project, 
> but it generated a single module project which was not what I expected.
> 
>> You have some experience using maven1, maybe you could help out on the
>> assembly part ? It should be fairly straightforward to come up with a
>> descriptor, give or take a few bugs along the way. Basically the
>> assembly descriptor builds a full binary distribution of a project, you
>> just tell it which format and what should go in it.
>>  
>>
> Are you talking about creating the pom.xml for each project or is this 
> some other descriptor?

A pom.xml is required in every in any case. Probably we will need more at the 
beginning (block.xml) as I don't see a useful way to get the deployment 
information that is covered by block.xml into pom.xml. I know of the 
"properties" part of poms but this scatters information across different locations.

I will get in contact with the Maven folks if there is a chance of adding a 
property element to the dependency element as it was possible in Maven 1.x

I stop the discussion at this point as working code will make further 
discussions less academic ;-)

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Ralph Goers <Ra...@dslextreme.com>.

Jorg Heymans wrote:

>
>Try and run the eclipse target as well and see how you find the eclipse
>project structure (it's described in the readme).
>  
>
I don't use Eclipse. I ran the idea plugin and it did create a project, 
but it generated a single module project which was not what I expected.

>You have some experience using maven1, maybe you could help out on the
>assembly part ? It should be fairly straightforward to come up with a
>descriptor, give or take a few bugs along the way. Basically the
>assembly descriptor builds a full binary distribution of a project, you
>just tell it which format and what should go in it.
>  
>
Are you talking about creating the pom.xml for each project or is this 
some other descriptor?

>
>The repository won't contain any ready to mount webapps as such. That
>should go in the archetype really. I have the archetype working again
>locally, i'll go and commit this right now.
>  
>
Aren't archetypes just templates? (from my minimal review of maven2).  
What about the sample site? I would expect that to be a project somewhere.

>
>
>Regards,
>Jorg
>  
>
Ralph

Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Jorg Heymans <jh...@domek.be>.

Ralph Goers wrote:

> First, I apologize for mispronouncing your name at least a dozen times
> in the last 3 days. I'm really sorry you weren't here - we missed you!

no worries, I'll start saving up for next year :)

> Second, I have sucessfully built what you just checked into the
> whiteboard.  Thanks!  What more can we do to help?

Try and run the eclipse target as well and see how you find the eclipse
project structure (it's described in the readme).

You have some experience using maven1, maybe you could help out on the
assembly part ? It should be fairly straightforward to come up with a
descriptor, give or take a few bugs along the way. Basically the
assembly descriptor builds a full binary distribution of a project, you
just tell it which format and what should go in it.

> Now the next step seems to be to try to run it.  Do we need another
> project to build the sample Jetty server with the webapp installed?
>

The repository won't contain any ready to mount webapps as such. That
should go in the archetype really. I have the archetype working again
locally, i'll go and commit this right now.



Regards,
Jorg


Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Jorg,
> 
> First, I apologize for mispronouncing your name at least a dozen times 
> in the last 3 days. I'm really sorry you weren't here - we missed you!
> 
> Second, I have sucessfully built what you just checked into the 
> whiteboard.  Thanks!  What more can we do to help? 
> 
> I've noticed that many unit tests fail.  These really need to pass to 
> get a formal build out (I don't expect you to fix that - this is 
> something we should all help with).
> 
There is at least one unit test in core which will definitly fail as
there is imho a bug in ECM++ (which is also in ECM). The role handling
with nested service managers is wrong. We never noticed this, as we only
had one roles file at the root service manager. Now, with the
possibility to include role files and xconf files at a sitemap level,
the bug affects us.

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

Re: svn commit: r356791 - /cocoon/whiteboard/maven2/cocoon-flat-layout/trunk/cocoon-core/pom.xml

Posted by Ralph Goers <Ra...@dslextreme.com>.
Jorg,

First, I apologize for mispronouncing your name at least a dozen times 
in the last 3 days. I'm really sorry you weren't here - we missed you!

Second, I have sucessfully built what you just checked into the 
whiteboard.  Thanks!  What more can we do to help? 

I've noticed that many unit tests fail.  These really need to pass to 
get a formal build out (I don't expect you to fix that - this is 
something we should all help with).

Now the next step seems to be to try to run it.  Do we need another 
project to build the sample Jetty server with the webapp installed?

Ralph