Cocoon 2.2 without tears

[Ken Starks <ke...@lampsacos.demon.co.uk>]

mostly FAO Hugh Sparks

Hi Hugh,

I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
but it isn't working for me.

This is with a completley fresh .m2/repository as I mentioned in the thread
Cocoon 2.2 classic webapp


I have attached the output, and I wonder if you (or anyone else) could 
suggest what I should do next.

Re: Cocoon 2.2 without tears

[Ken Starks <ke...@lampsacos.demon.co.uk>]

Ken Starks wrote:
> Hugh Sparks wrote:
>>> Ken Starks writes:
>>> [...]
>>> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
>>> but it isn't working for me.
>>> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules 
>>> for project:
>>> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0
>>
>> I'll try to get you going in this letter, but if this takes
>> any further correspondence, we should probably switch
>> to private email because I don't want to irritate users
>> who aren't interested in this topic.
>>
>> I just tried the download myself and it worked for me.
>> There's evidently something missing in your local .m2
>> repository. I think the problem is with the parent element
>> in the pom. It looks like the cocoon-core-modules artifact
>> is not being maintained in the central maven repository
>> or I don't know how to use it properly.
>>
>> Do you have Subversion installed? I keep a checkout of
>> the cocoon 2.2 trunk that I update and build every day.
>> I think that's why it works for me and not for you.
>>
>> A quick fix is to checkout and build the cocoon 2.2 truck.
>> Then the reference to cocoon-core-modules 6-SNAPSHOT
>> will be correctly resolved.
>>
>> Otherwise, you'll have to discard the parent element
>> from the pom and dig up a consistent set of version
>> elements for the individual dependences.
>>
>> In light of your difficulty, I'll update my website
>> so others won't have this problem, but I'm not able
>> to do this immediately.
>>
>> If you don't intend to use blocks at all, I like the cocoon classic
>> method recently published by Reinhard Pötz.
>> My write-up is for uses who want to combine open content
>> but keep the option of using blocks as well.
>>
>> -Hugh Sparks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
> Hi Hugh,
>
> Thanks for your reply.
>
> Yes, I do have Subversion installed, and I shall try the quick fix you 
> suggest.
>
> " Otherwise, you'll have to discard the parent element
>   from the pom and dig up a consistent set of version
>   elements for the individual dependences."
> This is beyond my present skill level with  Maven, I'm afraid.  
> Anyway, it
> rather begs the real question, 'How can the Central Maven Repository be
> maintained in perfect working order?'
>
> I agree that there must be something missing from my .m2 repository. 
> In fact
> the reason  I deliberately emptied it was as a test that the project 
> really would
> be 'without tears' for a new user. I did not do it to irritate anyone, 
> I assure you;
> 'testing' is your friend, remember.
>
> I should be able to build 2.2 trunk without any private email advice, 
> I hope. If there
> are any further problems, particularly if they might improve the 
> excellent article on your
> website, I shall be in touch.
>
> I do expect to use blocks, but nearly all of my projects continue 
> their development after they have been
> deployed to Tomcat. This is neither second-best nor amateurish, it is 
> the correct strategy for my needs.
>
> We now have all three options:
> a. No blocks
> b. A mixture
> c. Nothing but blocks.
>
> In my opinion, your option (b), should be part of the mainstream, not 
> merely an independent effort.
> This is because it could then come with a set of unit-tests and 
> functional tests against which the
> developers could tweak their bleeding-edge and  stable releases before 
> committing them to their
> repository. Or, in the absence of such automated tests, the developers 
> would at least feel a duty
> not to break your sub-project, once it was  part of  mainstream Cocoon.
>
> Bye for now,
>
> Ken
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
I have downloaded quite a few things from the Cocoon Subversion 
Repository, and the
compile,  install, package, and clean targets all work for your project.

However, the jetty:run target does not work.

-------------------------------------------------------------------------------

(The jetty:run target does work on the block archetypes provided on the 
cocoon site
in the normal 2.2 way, as does cocoon:prepare which does not work on your
webapp either.)

The actual items I downloaded (just in case i missed any vital ones) 
were from
http://svn.eu.apache.org/repos/asf/

cocoon/branches/cocoon2.2 
  (Three builds, 'mvn install' all succesful)

cocoon/trunk 
  ( First build. mvn -P allblocks install, one missing artifact
    later build. mvn -P allblocks package install, build successful )

I included the 'package target because your webapp (mvn install) complained
of missing jars when I had the  right stuff, but not in jars.

I enclose the output (OK) for mvn on your project. the first file came
from mvn install > install-report.txt, and the second (not OK) from
mvn jetty:run > jetty_run_report.txt

 Bye for now,
Ken.

Re: Cocoon 2.2 without tears

[Ken Starks <ke...@lampsacos.demon.co.uk>]

Hugh Sparks wrote:
>> Ken Starks writes:
>> [...]
>> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
>> but it isn't working for me.
>> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules for 
>> project:
>> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0
>
> I'll try to get you going in this letter, but if this takes
> any further correspondence, we should probably switch
> to private email because I don't want to irritate users
> who aren't interested in this topic.
>
> I just tried the download myself and it worked for me.
> There's evidently something missing in your local .m2
> repository. I think the problem is with the parent element
> in the pom. It looks like the cocoon-core-modules artifact
> is not being maintained in the central maven repository
> or I don't know how to use it properly.
>
> Do you have Subversion installed? I keep a checkout of
> the cocoon 2.2 trunk that I update and build every day.
> I think that's why it works for me and not for you.
>
> A quick fix is to checkout and build the cocoon 2.2 truck.
> Then the reference to cocoon-core-modules 6-SNAPSHOT
> will be correctly resolved.
>
> Otherwise, you'll have to discard the parent element
> from the pom and dig up a consistent set of version
> elements for the individual dependences.
>
> In light of your difficulty, I'll update my website
> so others won't have this problem, but I'm not able
> to do this immediately.
>
> If you don't intend to use blocks at all, I like the cocoon classic
> method recently published by Reinhard Pötz.
> My write-up is for uses who want to combine open content
> but keep the option of using blocks as well.
>
> -Hugh Sparks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
Hi Hugh,

Thanks for your reply.

Yes, I do have Subversion installed, and I shall try the quick fix you 
suggest.

" Otherwise, you'll have to discard the parent element
   from the pom and dig up a consistent set of version
   elements for the individual dependences."
This is beyond my present skill level with  Maven, I'm afraid.  Anyway, it
rather begs the real question, 'How can the Central Maven Repository be
maintained in perfect working order?'

I agree that there must be something missing from my .m2 repository. In 
fact
the reason  I deliberately emptied it was as a test that the project 
really would
be 'without tears' for a new user. I did not do it to irritate anyone, I 
assure you;
'testing' is your friend, remember.

I should be able to build 2.2 trunk without any private email advice, I 
hope. If there
are any further problems, particularly if they might improve the 
excellent article on your
website, I shall be in touch.

I do expect to use blocks, but nearly all of my projects continue their 
development after they have been
deployed to Tomcat. This is neither second-best nor amateurish, it is 
the correct strategy for my needs.

We now have all three options:
a. No blocks
b. A mixture
c. Nothing but blocks.

In my opinion, your option (b), should be part of the mainstream, not 
merely an independent effort.
This is because it could then come with a set of unit-tests and 
functional tests against which the
developers could tweak their bleeding-edge and  stable releases before 
committing them to their
repository. Or, in the absence of such automated tests, the developers 
would at least feel a duty
not to break your sub-project, once it was  part of  mainstream Cocoon.
 
Bye for now,

Ken






 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Cocoon 2.2 without tears

[Hugh Sparks <hu...@csparks.com>]

> Ken Starks writes:
> [...]
> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
> but it isn't working for me.
> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project:
> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0

I'll try to get you going in this letter, but if this takes
any further correspondence, we should probably switch
to private email because I don't want to irritate users
who aren't interested in this topic.

I just tried the download myself and it worked for me.
There's evidently something missing in your local .m2
repository. I think the problem is with the parent element
in the pom. It looks like the cocoon-core-modules artifact
is not being maintained in the central maven repository
or I don't know how to use it properly.

Do you have Subversion installed? I keep a checkout of
the cocoon 2.2 trunk that I update and build every day.
I think that's why it works for me and not for you.

A quick fix is to checkout and build the cocoon 2.2 truck.
Then the reference to cocoon-core-modules 6-SNAPSHOT
will be correctly resolved.

Otherwise, you'll have to discard the parent element
from the pom and dig up a consistent set of version
elements for the individual dependences.

In light of your difficulty, I'll update my website
so others won't have this problem, but I'm not able
to do this immediately.

If you don't intend to use blocks at all, I like the cocoon classic
method recently published by Reinhard Pötz.
My write-up is for uses who want to combine open content
but keep the option of using blocks as well.

-Hugh Sparks


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org