Re: Test and verify Cocoon 3 alpha-1 release artifacts
Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> [EMAIL PROTECTED] pisze:
It took me a while but now I finished the creation of all
release artifacts for a Cocoon 3 alpha-1 release. Since this is
the initial creation of Maven artifacts and distribution files,
I don't call for a vote at this point of time but rather want
to wait for some feedback.
>>> Hi Reinhard. Thanks for preparing all of these. I've finally
>>> found some time to bustle around your work.
>>>
I would like to ask you to check the release artifacts whether
they meet the legal requirements (checksums, pgp signatures,
license files, notice files) of the ASF.
>>> What about tags in svn?
>> That's a missing feature of the Maven release plugin when you do a
>> multi-module release. The plugin only tags the root module, in our
>> case
>> http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-root/cocoon-root-3.0.0-alpha-1/
>>
>
> Is this only my feeling that release plug-in does nothing useful? I
> mean here that it does some unintelligent editing of your POMs that:
>
> 1. Does not resolve SNAPSHOT versions to correct released versions
> (but to some random ones) 2. May result in corrupted POM (e.g. it can
> remove deployment info).
>
> Is it only me who had a bad experience with this plug-in?
Except for the SVN tagging issue I managed to route around all the
problems mentioned by you. See the 'preparations section' of
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt
Otherwise I would have to call 'mvn release:prepare release:perform' in
the correct order for each module and manipulate the pom files accordingly.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: Test and verify Cocoon 3 alpha-1 release artifacts
Reinhard Pötz pisze: > Grzegorz Kossakowski wrote: >> [EMAIL PROTECTED] pisze: >>> It took me a while but now I finished the creation of all release >>> artifacts for a Cocoon 3 alpha-1 release. Since this is the initial >>> creation of Maven artifacts and distribution files, I don't call for a >>> vote at this point of time but rather want to wait for some feedback. >> Hi Reinhard. Thanks for preparing all of these. I've finally found some time >> to bustle around your work. >> >>> I would like to ask you to check the release artifacts whether they meet >>> the legal requirements (checksums, pgp signatures, license files, >>> notice files) of the ASF. >> What about tags in svn? > > That's a missing feature of the Maven release plugin when you do a > multi-module release. The plugin only tags the root module, in our case > http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-root/cocoon-root-3.0.0-alpha-1/ Is this only my feeling that release plug-in does nothing useful? I mean here that it does some unintelligent editing of your POMs that: 1. Does not resolve SNAPSHOT versions to correct released versions (but to some random ones) 2. May result in corrupted POM (e.g. it can remove deployment info). Is it only me who had a bad experience with this plug-in? > I will copy the directories manually before I call for a vote. Thanks. I'm sorry that you have to do it manually... -- Grzegorz Kossakowski
Re: Test and verify Cocoon 3 alpha-1 release artifacts
Grzegorz Kossakowski wrote:
> [EMAIL PROTECTED] pisze:
>> It took me a while but now I finished the creation of all release
>> artifacts for a Cocoon 3 alpha-1 release. Since this is the initial
>> creation of Maven artifacts and distribution files, I don't call for a
>> vote at this point of time but rather want to wait for some feedback.
>
> Hi Reinhard. Thanks for preparing all of these. I've finally found some time
> to bustle around your work.
>
>> I would like to ask you to check the release artifacts whether they meet
>> the legal requirements (checksums, pgp signatures, license files,
>> notice files) of the ASF.
>
> What about tags in svn?
That's a missing feature of the Maven release plugin when you do a
multi-module release. The plugin only tags the root module, in our case
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-root/cocoon-root-3.0.0-alpha-1/
I will copy the directories manually before I call for a vote.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: Test and verify Cocoon 3 alpha-1 release artifacts
sorry for my late response. I was ill and then I had some hardware
problems that prevented me from reading my Apache mails.
Simone Tripodi wrote:
> Hi Reinhard,
> first of all, please excuse me I'm late to reply to your mail... I've
> been busy in some meeting with the customer and I was focused more on
> providing patches :P
> Notes follow inline
>
> 2008/10/22 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> It took me a while but now I finished the creation of all release
>> artifacts for a Cocoon 3 alpha-1 release. Since this is the initial
>> creation of Maven artifacts and distribution files, I don't call for a
>> vote at this point of time but rather want to wait for some feedback.
>>
>> I would like to ask you to check the release artifacts whether they meet
>> the legal requirements (checksums, pgp signatures, license files,
>> notice files) of the ASF.
>
> I noticed the 'doap' files are missing: they can be created by hand or
> using the maven doap plugin:
>
> http://maven.apache.org/plugins/maven-doap-plugin/
>
> I suggest you the second choice, maintaining 2 identical metadata sets
> in 2 different formats could be a little confusing, in that way you're
> sure the 'doap' is always 'synched' with the pom.
thanks for the hint. I haven't thought of DOAP files yet. I will try to
integrate it into the site generation process.
>> Maven artifacts
>> ...
>> Maven artifacts are available at http://people.apache.org/builds/cocoon/
>> If you want to use Cocoon 3, add this location as an additional
>> repository to your settings:
>>
>>
>> http://maven.apache.org/POM/4.0.0";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>>
>>
>> cocoon-staging
>>
>>
>> cocoon.staging
>> Cocoon staging repository
>> http://people.apache.org/builds/cocoon
>>
>>
>>
>>
>> cocoon.staging
>> Cocoon staging repository
>> http://people.apache.org/builds/cocoon
>>
>>
>>
>>
>>
>> and use it: e.g.
>> mvn install -P cocoon-staging
>
> I removed all cocoon libraries from my local maven repository to start
> from scratch, then I modified the settings.xml as you explained and
> finally I created a new project, importing the pipeline and everything
> worked fine. It seems the checksums have been retrieved correctly.
>
> Best regards, I hope to hear you soon!
Thanks for your feedback! I will start a vote this week.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: Test and verify Cocoon 3 alpha-1 release artifacts
[EMAIL PROTECTED] pisze: > It took me a while but now I finished the creation of all release > artifacts for a Cocoon 3 alpha-1 release. Since this is the initial > creation of Maven artifacts and distribution files, I don't call for a > vote at this point of time but rather want to wait for some feedback. Hi Reinhard. Thanks for preparing all of these. I've finally found some time to bustle around your work. > I would like to ask you to check the release artifacts whether they meet > the legal requirements (checksums, pgp signatures, license files, > notice files) of the ASF. What about tags in svn? > If you already use Cocoon 3 libraries in your project, please test them > using the proposed release artifacts. > If you haven't used Cocoon 3 yet, it would be great if you tried out the > Maven archetypes. I've taken second approach. > Maven artifacts > ... > Maven artifacts are available at http://people.apache.org/builds/cocoon/ > If you want to use Cocoon 3, add this location as an additional > repository to your settings: > > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/settings-1.0.0.xsd";> > > > cocoon-staging > > > cocoon.staging > Cocoon staging repository > http://people.apache.org/builds/cocoon > > > > > cocoon.staging > Cocoon staging repository > http://people.apache.org/builds/cocoon > > > > > > and use it: e.g. > mvn install -P cocoon-staging > > Maven archetypes > > There are also 4 archetypes available that help you to start a new > Cocoon 3 based web application project > > . archetype-block -> create a new block that uses Cocoon 3 as >web application framework > > . archetype-parent -> create a parent POM for a Cocoon 3 project > > . archetype-webapp -> create a web application project > > > or to run the samples > > . archetype-sample -> create a block that contains all available >Cocoon 3 samples > > Here are the commands: > > mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7 > -DarchetypeGroupId=org.apache.cocoon.archetype-block > -DarchetypeArtifactId=cocoon-archetype-block > -DarchetypeVersion=3.0.0-alpha-1 -DgroupId=com.mycompany > -DartifactId=mysite > -DremoteRepositories=http://people.apache.org/builds/cocoon/ > > mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7 > -DarchetypeGroupId=org.apache.cocoon.archetype-parent > -DarchetypeArtifactId=cocoon-archetype-parent > -DarchetypeVersion=3.0.0-alpha-1 -DgroupId=com.mycompany > -DartifactId=myparent > -DremoteRepositories=http://people.apache.org/builds/cocoon/ > > mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7 > -DarchetypeGroupId=org.apache.cocoon.archetype-webapp > -DarchetypeArtifactId=cocoon-archetype-webapp > -DarchetypeVersion=3.0.0-alpha-1 -DgroupId=com.mycompany > -DartifactId=mywebapp > -DremoteRepositories=http://people.apache.org/builds/cocoon/ > > mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7 > -DarchetypeGroupId=org.apache.cocoon.archetype-sample > -DarchetypeArtifactId=cocoon-archetype-sample > -DarchetypeVersion=3.0.0-alpha-1 -DgroupId=com.mycompany > -DartifactId=mysample > -DremoteRepositories=http://people.apache.org/builds/cocoon/ > These commands miss goal for archetype plug-in. You probably have missed that due to fact that first line is completely unreadable. Instead of mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7 it should be: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create Then all of them work. I've tested cocoon-archetype-sample more carefully and despite that some samples do not wok the overall picture is ok. As I was already playing with Cocoon3 I decided to have a closer look at source code of it. There are many nice things about it (probably the most important one is that this code is much cleaner than what we have in c2.2). Nevertheless, what I found surprising is that you decided to rewrite EL and OM handling from scratch once again. Was there any specific reason for doing that apart from "let's throw out the whole c.2.2's core"? I don't recall any discussion about that particular decision. You know my opinion about this. The second problem I can see with this release is that I fail to see where this project is heading to and what are its goals and aims. I would feel rather strange voting for a release of something that I don't fully identify with. To sum up my situation: +1 from technical point (provided you fix tags) +0 from my own personal point of view I would really like to know how to convert 0 into 1. Anyway, thanks f
Re: Test and verify Cocoon 3 alpha-1 release artifacts
Hi Reinhard, first of all, please excuse me I'm late to reply to your mail... I've been busy in some meeting with the customer and I was focused more on providing patches :P Notes follow inline 2008/10/22 [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > It took me a while but now I finished the creation of all release > artifacts for a Cocoon 3 alpha-1 release. Since this is the initial > creation of Maven artifacts and distribution files, I don't call for a > vote at this point of time but rather want to wait for some feedback. > > I would like to ask you to check the release artifacts whether they meet > the legal requirements (checksums, pgp signatures, license files, > notice files) of the ASF. I noticed the 'doap' files are missing: they can be created by hand or using the maven doap plugin: http://maven.apache.org/plugins/maven-doap-plugin/ I suggest you the second choice, maintaining 2 identical metadata sets in 2 different formats could be a little confusing, in that way you're sure the 'doap' is always 'synched' with the pom. > Maven artifacts > ... > Maven artifacts are available at http://people.apache.org/builds/cocoon/ > If you want to use Cocoon 3, add this location as an additional > repository to your settings: > > > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/settings-1.0.0.xsd";> > > > cocoon-staging > > > cocoon.staging > Cocoon staging repository > http://people.apache.org/builds/cocoon > > > > > cocoon.staging > Cocoon staging repository > http://people.apache.org/builds/cocoon > > > > > > and use it: e.g. > mvn install -P cocoon-staging I removed all cocoon libraries from my local maven repository to start from scratch, then I modified the settings.xml as you explained and finally I created a new project, importing the pipeline and everything worked fine. It seems the checksums have been retrieved correctly. Best regards, I hope to hear you soon! Simone
RE: test
> Usually, if unsubscribe to a list doesn't work it's because > one's trying to unsubscribe from a different address than the > one used to subscribe. > > For more info, send a message to [EMAIL PROTECTED] - > that includes a command to unsubscribe a different address > than the sender's. Indeed: try '[EMAIL PROTECTED]' Where XX = the email you want to unsubscribe, with the '@' replaced by '=' You still need to reply the confirmation ard > > -Bertrand >
Re: test
On Wed, May 21, 2008 at 4:29 PM, Marcus Clemens <[EMAIL PROTECTED]> wrote: > ...Its impossible I have tried everything all you can do is block each and > every sender... Usually, if unsubscribe to a list doesn't work it's because one's trying to unsubscribe from a different address than the one used to subscribe. For more info, send a message to [EMAIL PROTECTED] - that includes a command to unsubscribe a different address than the sender's. -Bertrand
RE: test
Its impossible I have tried everything all you can do is block each and every sender Marcus Clemens Director & Senior Consultant Mercator IT Ltd Tel: 01892 752730 Fax: 01892 750972 Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Address: The Studio, Eridge Park, Eridge Green, Tunbridge Wells, Kent TN3 9JS Registered in England no: 05755983 Registered office: 117 Dartford Road, Dartford, Kent DA1 3EN This email may contain privileged/confidential information and is for the intended addressee only. If you have received this message in error then you must not use, retain, disseminate or otherwise deal with it. Please notify the sender by return email and destroy. The views of the author may not necessarily constitute the views of Mercator IT Solutions Ltd. Nothing in this email shall bind Mercator IT Solutions Ltd in any contract or obligation. From: Prabhpreet Singh [mailto:[EMAIL PROTECTED] Sent: 21 May 2008 15:24 To: dev@cocoon.apache.org Subject: Re: test Jeroen, I want to get rid of cocoon related mails. Do you know how can I do that? Regards, Prabhpreet 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: Please ignore Regards, Jeroen
RE: test
Hi Prabhpreet, You can unsubscribe from the mailinglist if you want. See [1] for more information. http://cocoon.apache.org/2.1/1175.html Regards, Jeroen From: Prabhpreet Singh [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 4:24 PM To: dev@cocoon.apache.org Subject: Re: test Jeroen, I want to get rid of cocoon related mails. Do you know how can I do that? Regards, Prabhpreet 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: Please ignore Regards, Jeroen
Re: test
Jeroen, I tried that but it didn't worked. Regards, Prabhpreet On Wed, May 21, 2008 at 10:26 AM, James Cowie <[EMAIL PROTECTED]> wrote: > remove your self from the emal list. i think it unsubscrie in the title to > dev. > > 2008/5/21 Prabhpreet Singh <[EMAIL PROTECTED]>: > > Jeroen, >> >> I want to get rid of cocoon related mails. >> >> Do you know how can I do that? >> >> Regards, >> Prabhpreet >> >> 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: >> >>> Please ignore >>> >>> Regards, >>> >>> Jeroen >>> >> >> >
Re: test
We'll hunt you in your dreams ;) [EMAIL PROTECTED] does not work for you? On May 21, 2008, at 16:24, Prabhpreet Singh wrote: Jeroen, I want to get rid of cocoon related mails. Do you know how can I do that? Regards, Prabhpreet 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: Please ignore Regards, Jeroen
Re: test
remove your self from the emal list. i think it unsubscrie in the title to dev. 2008/5/21 Prabhpreet Singh <[EMAIL PROTECTED]>: > Jeroen, > > I want to get rid of cocoon related mails. > > Do you know how can I do that? > > Regards, > Prabhpreet > > 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: > >> Please ignore >> >> Regards, >> >> Jeroen >> > >
Re: test
Jeroen, I want to get rid of cocoon related mails. Do you know how can I do that? Regards, Prabhpreet 2008/5/21 Jeroen Reijn <[EMAIL PROTECTED]>: > Please ignore > > Regards, > > Jeroen >
Re: [test] Instructions to test Cocoon 2.2-final
Andrew Savory wrote: Hi On 02/04/2008, Reinhard Poetz <[EMAIL PROTECTED]> wrote: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myBlock -DremoteRepositories=http://people.apache.org/builds/cocoon/ works for me Please test the "getting-started" application (http://people.apache.org/~reinhard/cocoon-staging/cocoon-getting-started/) whether it runs at your environment. works for me Andrew. Same here. Both work great! Good to see some sort of getting started app! This will help out users a lot! Regards, Jeroen
Re: [test] Instructions to test Cocoon 2.2-final
Reinhard Poetz pisze: The proposed release artifacts of all the modules that we vote on (see the seperate voting thread) are available at http://people.apache.org/builds/cocoon/ The easiest way to test the artifacts is by adding a "cocoon-staging" profile to your ~/.m2/settings.xml: - o - In order to test the archetypes - cocoon-22-archetype-block-1.0.0 - cocoon-22-archetype-webapp-1.0.0 - cocoon-22-archetype-block-plain-1.0.0 append -DremoteRepositories=http://people.apache.org/builds/cocoon/ to your "mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create" commands, e.g. mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myBlock -DremoteRepositories=http://people.apache.org/builds/cocoon/ The commands to use the archetypes and explanations of what they are for can be found at http://cocoon.apache.org/2.2/maven-plugins/ (Note: Make sure that you set the correct archetypeVersion parameter!). Tested archetypes and Cocoon artifacts quite extensively (with my own small apps). Everything works like a charm at openSUSE with Java 1.6. - o - Please test the "getting-started" application (http://people.apache.org/~reinhard/cocoon-staging/cocoon-getting-started/) whether it runs at your environment. - o - In general, please check if the release artifacts meet all legal requirements of the ASF. (checksums, signatures, license & notice files) Will do this tomorrow. Thanks for your work Reinhard! -- Grzegorz Kossakowski
Re: [test] Instructions to test Cocoon 2.2-final
Hi On 02/04/2008, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > mvn > org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create >-DarchetypeGroupId=org.apache.cocoon >-DarchetypeArtifactId=cocoon-22-archetype-block >-DarchetypeVersion=1.0.0 >-DgroupId=com.mycompany >-DartifactId=myBlock > > -DremoteRepositories=http://people.apache.org/builds/cocoon/ works for me > Please test the "getting-started" application > (http://people.apache.org/~reinhard/cocoon-staging/cocoon-getting-started/) > whether it runs at your environment. works for me Andrew.
Re: Test release artifacts - Legal requirements check [take2]
Reinhard Poetz wrote: > Vadim Gritsenko wrote: > > > >Do we really have to include each license into single LICENSE.txt file? > >I think I missed this development... > > There were so many discussions on several Apache lists that I can't point > you to the thread :-/ > > Anyway, I was following the proposed structure as being suggested at > http://wiki.apache.org/legal/3party/notice It has always been required, and it gets re-iterated in many license discussions. At both Cocoon and Forrest we have had trouble doing it, having so many supporting libraries. So we put the licenses beside each jar as text files with the same filename. At Forrest i have done a further compromise (until we move to Ivy which hope can help automate this license management). We put the license beside the jar as a text file, and mention the pathname in LICENSE.txt file. See more in a legal-discuss@ link, mentioned by me earlier in this thread. -David
Re: Test release artifacts - Legal requirements check [take2]
Vadim Gritsenko wrote:
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote:
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
Jar file name to source/documentation directory name mapping is
inconsistent:
cocoon-servlet-service-components-1.0.0-RC1.jar --> cocoon-components/
cocoon-servlet-service-impl-1.0.0-RC1 --> impl/
thanks, I will fix this.
and
http://people.apache.org/~reinhard/cocoon-staging/getting-started/
This contains spring version 2.0.6, while cocoon-webapp in trunk is
linked against 2.5.1. Does not seem correct.
I was using the RC1 Maven archetypes to create the cocoon-webapp. For the
release I will use the new archetypes that will be used on the latest stuff.
Do we really have to include each license into single LICENSE.txt file?
I think I missed this development...
There were so many discussions on several Apache lists that I can't point you to
the thread :-/
Anyway, I was following the proposed structure as being suggested at
http://wiki.apache.org/legal/3party/notice
BTW you have duplicate AL2 there -
for ehcache. Seems redundant - especially since all other AL2 jars are
not explicitly mentioned.
IIRC it was slightly different, but I will check this.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check [take2]
On Mar 18, 2008, at 2:29 PM, Reinhard Poetz wrote: I've created another series of non-Maven release artifacts. See http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/ Jar file name to source/documentation directory name mapping is inconsistent: cocoon-servlet-service-components-1.0.0-RC1.jar --> cocoon- components/ cocoon-servlet-service-impl-1.0.0-RC1 --> impl/ and http://people.apache.org/~reinhard/cocoon-staging/getting-started/ This contains spring version 2.0.6, while cocoon-webapp in trunk is linked against 2.5.1. Does not seem correct. Do we really have to include each license into single LICENSE.txt file? I think I missed this development... BTW you have duplicate AL2 there - for ehcache. Seems redundant - especially since all other AL2 jars are not explicitly mentioned. Vadim
Re: Test release artifacts - Legal requirements check [take2]
I've created another series of non-Maven release artifacts. See
http://people.apache.org/~reinhard/cocoon-staging/cocoon-servlet-service/
and
http://people.apache.org/~reinhard/cocoon-staging/getting-started/
What has changed:
o The archive name is the base directory of the ZIP.
o fix EOL, depending whether it is a ZIP or a tar.gz archive
o the getting-started package is new and contains third-party libraries
This time I want also draw your attention to the LICENSE.txt file of the
getting-started package. There you will find a list of all subcomponents that
have licenses that are different to the Apache License 2.0. This is the same
style as proposed in http://wiki.apache.org/legal/3party/notice.
Additionally, could others please check
o NOTICE.txt
o MD5 checksums
o PGP signatures
Thanks in advance!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote: > Reinhard Poetz wrote: > >David Crossley wrote: > >>I saw that some committers have been using lowercase filenames > >>e.g. "notice.txt", so the "release-builder" needs to handle that. > > > >Is there some requirement that the file names of notice.txt and > >license.txt have to be either lower or upper case? Or is it up to us? The uppercase might just be tradition, but also what people expect to see. > See http://www.apache.org/dev/apply-license.html#license-file-name > > so we should name them "NOTICE" and "LICENSE". > > We should use the same name throughout all modules. Ah thanks. Also from that page: "Can the LICENSE and NOTICE files be called LICENSE.txt and NOTICE.txt? This is permitted. However the preference is that the files be called LICENSE and NOTICE. " The .txt filename extension helps with svn clients. I am going to add explicit handling to the ASF committers configuration so we can use "NOTICE" and "LICENSE". http://www.apache.org/dev/version-control.html#https-svn-config Would all committers please update their configuration. -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: > David Crossley wrote: > > > >I see that the META-INF/NOTICE.txt etc. files in each > >of "cocoon-components" and "impl" directory, would correspond > >with those from the sources. However where does top-level > >NOTICE.txt file come from? Should it be generated as a > >combination of the other two? The files in the sub-directories > >could potentially be different. > > The problem is that the release artifacts are sometimes collections of > several more focused artifacts, at least in the Maven 2 world they get > distributed in smaller units. > > I guess that the correct solution is that each of those "collection release > artifacts" has to contain a hand-crafted NOTICE.txt file. > > The license > should because of the ASF policy always be the same. I gather from listening to legal-discuss@ list that the licenses of supporting products need to be appended to the main LICENSE file. This has been added to the draft legal pages. http://wiki.apache.org/legal/3party/notice This is another wrinkle that we have not yet fully addressed at Forrest. A comment from Roy made me realise why that is needed. The LICENSE and NOTICE files are intended to be shown to the user in an "About..." style pop-up box. http://markmail.org/message/evydcvctn6c6of27 -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to put NOTICE and LICENSE into the main directory of each "sub-tree", that in our case relates to each of our modules that are released separately. Yes. We should do this "clean-up work" in one go as soon as there is a Maven 2 plugin available, that picks up those files and puts them into META-INF. No need to wait for a plugin, we can just add this to our parent pom: .. src/main/resources . META-INF LICENSE* NOTICE* Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test release artifacts - Legal requirements check
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. "notice.txt", so the "release-builder" needs to handle that.
Is there some requirement that the file names of notice.txt and
license.txt have to be either lower or upper case? Or is it up to us?
See http://www.apache.org/dev/apply-license.html#license-file-name
so we should name them "NOTICE" and "LICENSE".
We should use the same name throughout all modules.
If I understood some discussion on [EMAIL PROTECTED] correctly, we would also have to
put NOTICE and LICENSE into the main directory of each "sub-tree", that in our
case relates to each of our modules that are released separately.
We should do this "clean-up work" in one go as soon as there is a Maven 2 plugin
available, that picks up those files and puts them into META-INF.
WDOT?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: David Crossley wrote: I saw that some committers have been using lowercase filenames e.g. "notice.txt", so the "release-builder" needs to handle that. Is there some requirement that the file names of notice.txt and license.txt have to be either lower or upper case? Or is it up to us? See http://www.apache.org/dev/apply-license.html#license-file-name so we should name them "NOTICE" and "LICENSE". We should use the same name throughout all modules. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
I saw that some committers have been using lowercase filenames
e.g. "notice.txt", so the "release-builder" needs to handle that.
Is there some requirement that the file names of notice.txt and license.txt have
to be either lower or upper case? Or is it up to us?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
David Crossley wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
This time I will
create the Maven 2 release artifacts and "normal" zip/tar release
artifacts for non-Maven users.
I created release artifacts for the Servlet-Service framework using the old
RC1 release form October last year and published them to
http://people.apache.org/~reinhard/cocoon-staging/ssf/.
Could others please have a look and check if those release artifacts meet
all legal requirements?
I see that the META-INF/NOTICE.txt etc. files in each
of "cocoon-components" and "impl" directory, would correspond
with those from the sources. However where does top-level
NOTICE.txt file come from? Should it be generated as a
combination of the other two? The files in the sub-directories
could potentially be different.
The problem is that the release artifacts are sometimes collections of several
more focused artifacts, at least in the Maven 2 world they get distributed in
smaller units.
I guess that the correct solution is that each of those "collection release
artifacts" has to contain a hand-crafted NOTICE.txt file. The license should
because of the ASF policy always be the same.
I expected a top-level "cocoon-servlet-service" directory
to be created. Should it?
good suggestions. I will fix this in the script.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Test release artifacts - Legal requirements check
I saw that some committers have been using lowercase filenames e.g. "notice.txt", so the "release-builder" needs to handle that. -David
Re: Test release artifacts - Legal requirements check
Reinhard Poetz wrote: > Reinhard Poetz wrote: > >This time I will > >create the Maven 2 release artifacts and "normal" zip/tar release > >artifacts for non-Maven users. > > I created release artifacts for the Servlet-Service framework using the old > RC1 release form October last year and published them to > http://people.apache.org/~reinhard/cocoon-staging/ssf/. > > Could others please have a look and check if those release artifacts meet > all legal requirements? I see that the META-INF/NOTICE.txt etc. files in each of "cocoon-components" and "impl" directory, would correspond with those from the sources. However where does top-level NOTICE.txt file come from? Should it be generated as a combination of the other two? The files in the sub-directories could potentially be different. I expected a top-level "cocoon-servlet-service" directory to be created. Should it? -David
Re: Test Cases are broken in trunk
Carsten Ziegeler pisze: Grzegorz Kossakowski wrote: Hmm, now they're gone - strange (one of those maven things I guess). I don't think so. My gut feeling is that caching source test case failed for you but this was caused by your network condition's or slashdot's server conditions. I really dislike this approach when, while testing, we are fetching data from external site. This causes tests failing due to conditions that we are not in control of. Usually second run solves compilation error, though. Thanks for fixing the others - now I can compile all blocks as well. No problem, thanks for pointing this out. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: Test Cases are broken in trunk
Grzegorz Kossakowski wrote: > I fixed tests in chaperon, midi and webdav blocks (commits > r566049:566067) by working around Maven's MNG-1378 issue[1]. After > applying these changes trunk with -P allblocks compiled just fine. > > What broken tests in core block do you refer to? > Hmm, now they're gone - strange (one of those maven things I guess). Thanks for fixing the others - now I can compile all blocks as well. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Test Cases are broken in trunk
Carsten Ziegeler pisze: Hi, since the latest refactorings, most of our test cases do not compile anymore. I managed to fix the portals block (which is just one test case), but I fail to see how to fix the others, e.g. in the core block. I fixed tests in chaperon, midi and webdav blocks (commits r566049:566067) by working around Maven's MNG-1378 issue[1]. After applying these changes trunk with -P allblocks compiled just fine. What broken tests in core block do you refer to? Also, I'm not sure if it helps but voting for MNG-1378 is probably a good idea. This is main cause of having a lot of crap in our poms. [1] http://jira.codehaus.org/browse/MNG-1378 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Grzegorz Kossakowski-3 wrote: > > src/main/resources/META-INF/cocoon/spring/servlet-service.xml broken: >class="org.apache.cocoon.sitemap.SitemapServlet"> > context-path="blockcontext:/myBlock1/"/> > > > > > > Notice that servlet:connections is _not_ inside servlet:context tag (it's > not open at all). It should be: >class="org.apache.cocoon.sitemap.SitemapServlet"> > context-path="blockcontext:/myBlock1/"> > > > > > > Yes and that was the cause! Its running now - 10k Thanx for that Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11275862 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Grzegorz Kossakowski-3 wrote: > > It's odd. Can you send us zipped myBlock1 and myBlock2 directories? It > would allow me to help you effectively. > hi Grzegorz. Sure. This Nabble Forum do not let me add attachments. I send you a direct mail via Nabble. Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11274504 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
xweber pisze: Hi Grzegorz, Hi Alex, RCL [create]: /home/xweber/tmp/cocoon/test/myBlock1/./target/classes/demo/MyBean.class 2007-06-23 23:11:02.460:/:INFO: Initializing Spring root WebApplicationContext 2007-06-23 23:11:03.961::WARN: Failed startup of context [EMAIL PROTECTED] ... Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unable to read spring configurations from classpath*:META-INF/cocoon/spring; nested exception is org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionDecorator for element [connections] ... Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Cannot locate BeanDefinitionDecorator for element [connections] on the jetty:run step. So browser says: HTTP ERROR: 503 SERVICE_UNAVAILABLE RequestURI=/myBlock1/ Powered by jetty:// I even tried it with a clean second dir + attempt to build the steps. It's odd. Can you send us zipped myBlock1 and myBlock2 directories? It would allow me to help you effectively. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi Grzegorz,
> Component (Spring beans) configurations files can be found at
> src/main/resources/META-INF/cocoon/spring. Before we change id of spring
> bean
> to make it unique we have to rename java class as well. Here are
> instructions (everything should be done in myBlock2 from the tutorial):
> 1. Rename Java class demo.myBean to demo.myBean2. The class can be found
> at src/main/java
> 2. Open
> src/main/resources/META-INF/cocoon/spring/demo-application-context.xml for
> edition and change following part:
>
>
>
> 3. We need to update flowscript code to make it picking up new component.
> Open src/main/resources/COB-INF/flow/spring-bean.js and change
> this line:
> var demoBean = cocoon.getComponent("demo");
> so it looks:
> var demoBean = cocoon.getComponent("demo2");
>
> Run jetty:run from myBlock1 and everything (I hope) should be working.
>
RCL [create]:
/home/xweber/tmp/cocoon/test/myBlock1/./target/classes/demo/MyBean.class
2007-06-23 23:11:02.460:/:INFO: Initializing Spring root
WebApplicationContext
2007-06-23 23:11:03.961::WARN: Failed startup of context
[EMAIL PROTECTED]
...
Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
Unable to read spring configurations from classpath*:META-INF/cocoon/spring;
nested exception is
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Cannot locate BeanDefinitionDecorator for element
[connections]
...
Caused by:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Cannot locate BeanDefinitionDecorator for element
[connections]
on the jetty:run step. So browser says:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
RequestURI=/myBlock1/
Powered by jetty://
I even tried it with a clean second dir + attempt to build the steps.
Alex
--
View this message in context:
http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11270315
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
xweber pisze:
Hi Grzegorz,
Grzegorz Kossakowski wrote:
I think you found little trap in our current setup. When two blocks
containing demo classes are connected they define exactly the same
Spring component (same package and same component id) twice. In my setup
this does not lead to exception, just first Java class and last
declaration of component is used. Try to change a class name/package and
Spring Id of the component (don't forget to change in flowscript
too) and everything should be working fine.
Please report if it's the case.
Sure, i would like to test it but unfortunately i have no clue what
files/lines to change. The doc part for this
(http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g4/1268.html) is near
empty. So I cannot figure what part means "component id". I beg your pardon
for this - i am just starting with cocoon.
Yes, docs needs polishing, I hope we will get more attention on this as soon as
RC1 is released and we are sure that most of the code is stable.
Component (Spring beans) configurations files can be found at src/main/resources/META-INF/cocoon/spring. Before we change id of spring bean
to make it unique we have to rename java class as well. Here are instructions (everything should be done in myBlock2 from the tutorial):
1. Rename Java class demo.myBean to demo.myBean2. The class can be found at
src/main/java
2. Open src/main/resources/META-INF/cocoon/spring/demo-application-context.xml
for edition and change following part:
3. We need to update flowscript code to make it picking up new component. Open src/main/resources/COB-INF/flow/spring-bean.js and change
this line:
var demoBean = cocoon.getComponent("demo");
so it looks:
var demoBean = cocoon.getComponent("demo2");
Run jetty:run from myBlock1 and everything (I hope) should be working.
Grzegorz Kossakowski wrote:
I don't think it's show-stopper for release, we just should put an
information about work-around in docs and fix it in RC2 that would follow
RC1 quickly (I hope you all remember independent release cycles).
Yesterday I have run the examples from a svn build. There have been some
error messages and "dead" pages while clicking through all the links.
Don't hesitate report them. Some of them may be broken because we move samples
to new architecture (servlet-service-fw, docs comming soon).
Haven't tried if a example webapp build is possible with the "to rc1"
released files (i am just a beginner with cocoon - so i would need a little
howto).
e.g. in cocoon-validation-sample's sitemap.xmap is a
type="servletService" "> - count the "
Maybe it's a wanted syntax error for validation to check something.
No, it's typo, it would be commented that it's broken intentionally. I fixed
that, thanks.
If you want i can run through all examples in rc1 and give a more complete
list of problems.
AFAIK you can run in rcl only blocks that are already converted to use servlet-service-fw. If you want to check if it's the case just find
out if file at src/main/resources/META-INF/cocoon/spring/*blockServlet.xml exists. Some blocks are not converted yet, see:
http://thread.gmane.org/gmane.text.xml.cocoon.devel/73643/focus=73661
Any help will be appreciated, of course.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi Grzegorz, Grzegorz Kossakowski wrote: > > I think you found little trap in our current setup. When two blocks > containing demo classes are connected they define exactly the same > Spring component (same package and same component id) twice. In my setup > this does not lead to exception, just first Java class and last > declaration of component is used. Try to change a class name/package and > Spring Id of the component (don't forget to change in flowscript > too) and everything should be working fine. > Please report if it's the case. > Sure, i would like to test it but unfortunately i have no clue what files/lines to change. The doc part for this (http://cocoon.zones.apache.org/daisy/cdocs/g1/g1/g4/1268.html) is near empty. So I cannot figure what part means "component id". I beg your pardon for this - i am just starting with cocoon. Grzegorz Kossakowski wrote: > > I don't think it's show-stopper for release, we just should put an > information about work-around in docs and fix it in RC2 that would follow > RC1 quickly (I hope you all remember independent release cycles). > Yesterday I have run the examples from a svn build. There have been some error messages and "dead" pages while clicking through all the links. Haven't tried if a example webapp build is possible with the "to rc1" released files (i am just a beginner with cocoon - so i would need a little howto). e.g. in cocoon-validation-sample's sitemap.xmap is a - count the " Maybe it's a wanted syntax error for validation to check something. If you want i can run through all examples in rc1 and give a more complete list of problems. Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11268794 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
xweber pisze: Hi, I tried to follow the tutorials with latest rc1 files. (http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1291.html) On the connecting example (Connect two blocks) I receive an error like java.lang.RuntimeException: Cannot invoke listener [EMAIL PROTECTED] .. Unable to read spring configurations from classpath .. on mvn jetty:run startup Maybe it is related to the rc1 build. I think you found little trap in our current setup. When two blocks containing demo classes are connected they define exactly the same Spring component (same package and same component id) twice. In my setup this does not lead to exception, just first Java class and last declaration of component is used. Try to change a class name/package and Spring Id of the component (don't forget to change in flowscript too) and everything should be working fine. Please report if it's the case. I don't think it's show-stopper for release, we just should put an information about work-around in docs and fix it in RC2 that would follow RC1 quickly (I hope you all remember independent release cycles). As regards the fix, do you have a good idea how to make demo beans unique? Do you think that appending block's name (artifact Id) is a good idea? Is artifact Id strict enough to not brake name of class? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Hi, I tried to follow the tutorials with latest rc1 files. (http://cocoon.zones.apache.org/daisy/cdocs/g2/g2/g1/1291.html) On the connecting example (Connect two blocks) I receive an error like java.lang.RuntimeException: Cannot invoke listener [EMAIL PROTECTED] .. Unable to read spring configurations from classpath .. on mvn jetty:run startup Maybe it is related to the rc1 build. Alex -- View this message in context: http://www.nabble.com/-test--Cocoon-2.2-RC1---others-%28take-2%29-tf3965214.html#a11267783 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [test] Cocoon 2.2-RC1 & others (take 2)
Reinhard Poetz pisze: The proposed release artifacts are available at http://people.apache.org/builds/cocoon/. Except for the archetypes the easiest way to test the artifacts is by adding a "cocoon-staging" profile to your ~/.m2/settings.xml: Then change the version number of the artifacts that you use in your POMs to the number of the proposed artifact and append "-P cocoon-staging" to all your Maven commands, e.g. mvn install -P cocoon-staging - o - I also want to draw your attention to http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1370.html which contains references to 4 tutorials that help you to get started with Cocoon 2.2 and also help to test the release artifacts. Again, make sure that you use the cocoon-staging profile for all your commands as explained above. Otherwise the referenced artifacts can't be found. Thanks Reinhard for brining this release. I tested it briefly and everything seems to work well. Tested functionality: 1. block archetype 2. cocoon:rcl goal, reloading works very well. I could even create new Spring beans and use them in modified flowscript code. Great work, really :-) 3. webapp archetype 4. Forms and Templates (using some basic application) I would like to test database block as well but I don't find any documentation about it. Does any one know how to configure database block to have HSQL db running, how to create tables and add sample data (so basically, how to run SQL statements from file) and how to integrate it with JDBI? Any tips will be appreciated. I also wonder what is status of documentation? What work is left to be done before we can publish new documentation? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.
Why is there no release of cocoon spring configurator?
because there has already been a final release 1.0.0 of it and there
haven't been any changes that would justify a 1.0.1.
Hmm, there have been some changes and actually the 1.0.0 release is not
100% correct as it contains 1.0.1 references :) So, it would be great to
have a 1.0.1 release as well.
Ok. I will do so.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [test] Cocoon 2.2-RC1 & others
Grzegorz Kossakowski pisze: Reinhard Poetz pisze: POM file of commons-jci-core is not downloaded because apache-m2-snapshot is not used while searching for this pom file. However, when Maven tries to download jar file it uses apache-m2-snpashot repository declared cocoon-rcl-webapp-wrapper. Sight, I spent about two hours to discover things described above to only find out that we again hit this issue: https://issues.apache.org/jira/browse/COCOON-1975 I forgot to say: if you fix first problem and add this: apache-m2-snapshot Apache Maven 2 Repository http://people.apache.org/repo/m2-snapshot-repository true false to your block's pom mvn jetty:run works fine. Now it should be clear for you that we hit again COCOON-1975... -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: [test] Cocoon 2.2-RC1 & others
Reinhard Poetz pisze:
The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.
Except for the archetypes the easiest way to test the artifacts is by
adding a
"cocoon-staging" profile to your ~/.m2/settings.xml:
cocoon-staging
cocoon.staging
Cocoon staging repository
http://people.apache.org/builds/cocoon
cocoon.staging
Cocoon staging repository
http://people.apache.org/builds/cocoon
Then change the version number of the artifacts that you use in your POMs
to the number of the proposed artifact and append "-P cocoon-staging" to
all
your Maven commands, e.g.
mvn install -P cocoon-staging
I really think that creating separate settings file with non-default local repository path is much better option. You don't mess your
original installation, you have clean local repo but do not loose ability to work with other projects, etc. I gave a model file:
http://article.gmane.org/gmane.text.xml.cocoon.devel/73498
Again, make sure that you use the
cocoon-staging profile for all your commands as explained above.
Otherwise the
referenced artifacts can't be found.
There is a problem with dependencies of org.apache.cocoon:cocoon-rcl-webapp-wrapper:1.0.0-M1 that was reported by Joakim Verona. There are
two problems:
1.
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon/4/cocoon-4.pom
contains:
org.apache.commons
commons-jci-fam
1.0-SNAPSHOT
and it makes Maven going mad. It downloads both (SNAPSHOT and RC) versions but does not use any of them at runtime. I guess we must remove
it, right?
2. I fixed first problem locally and ran mvn jetty:run -X -s
testing-cocoon-settings.xml -X and got:
[INFO] [cocoon:rcl {execution: rcl}]
[INFO] Creating a reloading Cocoon web application.
[INFO] Deploying string-template to WEB-INF/log4j.xml
[DEBUG] unspecified:unspecified:jar:0.0 (selected for null)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-rcl-webapp-wrapper/1.0.0-M1/cocoon-rcl-webapp-wrapper-1.0.0-M1.pom
[...]
4K downloaded
[DEBUG] Artifact resolved
[DEBUG] Retrieving parent-POM: org.apache.cocoon:cocoon-tools-modules::4 for project: null:cocoon-rcl-webapp-wrapper:jar:1.0.0-M1 from the
repository.
[DEBUG] Retrieving parent-POM: org.apache.cocoon:cocoon::4 for project:
null:cocoon-tools-modules:pom:4 from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::4 for project:
org.apache.cocoon:cocoon:pom:4 from the repository.
[DEBUG] Adding managed depedendencies for unknown:cocoon-rcl-webapp-wrapper
[...]
[DEBUG] org.apache.cocoon:cocoon-rcl-webapp-wrapper:jar:1.0.0-M1:compile
(selected for compile)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.pom
[DEBUG] Unable to get resource 'org.apache.commons:commons-jci-core:pom:1.0-RC1' from repository cocoon.staging
(http://people.apache.org/builds/cocoon)
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.pom
[DEBUG] Unable to get resource
'org.apache.commons:commons-jci-core:pom:1.0-RC1' from repository central
(http://repo1.maven.org/maven2)
[DEBUG] Artifact not found - using stub model: Unable to download the artifact
from any repository
org.apache.commons:commons-jci-core:pom:1.0-RC1
from the specified remote repositories:
cocoon.staging (http://people.apache.org/builds/cocoon),
central (http://repo1.maven.org/maven2)
[DEBUG] Using defaults for missing POM
org.apache.commons:commons-jci-core:pom:1.0-RC1:compile
[DEBUG] org.apache.commons:commons-jci-core:jar:1.0-RC1:compile (selected
for compile)
[DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected for
compile)
[DEBUG] log4j:log4j:jar:1.2.12:compile (selected for compile)
[DEBUG] javax.servlet:servlet-api:jar:2.3:compile (selected for compile)
[DEBUG] log4j:log4j:jar:1.2.12:compile (removed - nearer found: 1.2.14)
[DEBUG] log4j:log4j:jar:1.2.14:compile (selected for compile)
[DEBUG] Trying repository cocoon.staging
Downloading:
http://people.apache.org/builds/cocoon/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.jar
[DEBUG] Unable to get resource 'org.apache.commons:commons-jci-core:jar:1.0-RC1' from repository cocoon.staging
(http://people.apache.org/builds/cocoon)
[DEBUG] Trying repository apache-m2-snapshot
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-core/1.0-RC1/commons-jci-core-1.0-RC1.jar
[...]
26K downloaded
[DEBUG] Artifact resolved
POM file of commons-jci-core is not downloaded because apache-m2-snapshot is not used while searching for
Re: [test] Cocoon 2.2-RC1 & others
Reinhard Poetz wrote: Leszek Gawron wrote: Reinhard Poetz wrote: The proposed release artifacts are available at http://people.apache.org/builds/cocoon/. Why is there no release of cocoon spring configurator? because there has already been a final release 1.0.0 of it and there haven't been any changes that would justify a 1.0.1. Hmm, there have been some changes and actually the 1.0.0 release is not 100% correct as it contains 1.0.1 references :) So, it would be great to have a 1.0.1 release as well. Carsten
Re: [test] Cocoon 2.2-RC1 & others
Leszek Gawron wrote:
Reinhard Poetz wrote:
The proposed release artifacts are available at
http://people.apache.org/builds/cocoon/.
Why is there no release of cocoon spring configurator?
because there has already been a final release 1.0.0 of it and there haven't
been any changes that would justify a 1.0.1.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [test] Cocoon 2.2-RC1 & others
Reinhard Poetz wrote: The proposed release artifacts are available at http://people.apache.org/builds/cocoon/. Why is there no release of cocoon spring configurator? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: [test] please ignore, only pinging this list
previous ping message took 6 hours to come through, testing again... -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Test
Le 8 sept. 04, à 12:17, Sylvain Wallez a écrit : ...Is everyone busy? Dunno about the others but me...yes, unfortunately (but it's on a Cocoon project ;-) -Bertrand
Re: Test
Siesta time :) Sylvain Wallez wrote: Just a test, wondering why the list is so silent lately. Is everyone busy? Sylvain
Re: Test
Yes, unbelievably so! On Wed, 08 Sep 2004 12:17:57 +0200, Sylvain Wallez <[EMAIL PROTECTED]> wrote: > Just a test, wondering why the list is so silent lately. Is everyone busy? > > Sylvain
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Leo Simons wrote: Michael Wechner wrote: Leo Simons wrote: In this case, Noel has raised some perfectly valid concerns about files living on http://www.apache.org/dist/ without a PMC putting them there (which is a *big thing*, for legal and other reasons). If I were lenya, I wouldn't complain about constraints, but just address those concerns. well, IIRC then concerns have been addressed promptly. No, they have not been addressed promptly. There exists content on http://www.apache.org/dist/cocoon/lenya/ which is not supposed to be there. I renamed them to dev after Steven approached me (btw, I didn't put them there in the first place) I'll quote Noel: "Thinking on it, we should probably delete those files, which were never approved by either the Incubator or Cocoon PMCs. Baring commentary to the contrary, I will do so within the next day or so (leaving time for legitimate contrary views)." do you like us to delete them for good? C'mon guys, a mistake or two have been made, which is fine! That's why we have an incubation process in the first place :-D. Live and learn. Go fix things. that's my intention duly noted, and lenya-dev added back to CC list. thanks Michi Guys, you may have missed some useful bits of info. Please go read recent [EMAIL PROTECTED] archives to make sure you haven't. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test -- please ignore
David Crossley wrote: > Sylvain Wallez wrote: > > > > Ok, so the problem isn't on my side of the pipe. I just hope the > > roundtrip time will come again to a smaller value, as fast interaction > > is key for groups like ours. > > Yes, i too have been very confused by mail lately. > I just sent a message to [EMAIL PROTECTED] to make > sure they are aware of the issue. Infrastructure are asking for more information like an example mail header and timing example. --David
Re: Test -- please ignore
Sylvain Wallez wrote: > > Ok, so the problem isn't on my side of the pipe. I just hope the > roundtrip time will come again to a smaller value, as fast interaction > is key for groups like ours. Yes, i too have been very confused by mail lately. I just sent a message to [EMAIL PROTECTED] to make sure they are aware of the issue. --David
Re: Test -- please ignore
Steven Noels wrote:
On 08 Jun 2004, at 17:16, Sylvain Wallez wrote:
Comparing roundtrip time between gname and my smtp server (got some
annoying delay)
Mail *is* slower these days, perceptively after the migration from
daedalus to hermes (or we have been spoiled in having mailing list
roundtrip times similar to instant messaging over the past years ;-)
Ok, so the problem isn't on my side of the pipe. I just hope the
roundtrip time will come again to a smaller value, as fast interaction
is key for groups like ours.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Test -- please ignore
On 08 Jun 2004, at 17:16, Sylvain Wallez wrote: Comparing roundtrip time between gname and my smtp server (got some annoying delay) Mail *is* slower these days, perceptively after the migration from daedalus to hermes (or we have been spoiled in having mailing list roundtrip times similar to instant messaging over the past years ;-) -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: test case (class DefaultSitemapComponentSelector not found )
Stephan Michels wrote: I replaced the selector by the ExtendedComponentSelector, and it seems to work. But nevertheless the Resolver testcase break the tests. I've changed a declaration in ResolverImplTestCase.java and now the tests are OK. I've just committed the fix. Ugo
Re: test case (class DefaultSitemapComponentSelector not found )
On Sun, 21 Sep 2003, Ugo Cei wrote: > Looks like the org.apache.cocoon.sitemap.DefaultSitemapComponentSelector > was recently removed, thus breaking all the tests. I've tried to > implement a quick fix and substituted > o.a.c.components.treeprocessor.sitemap.ComponentsSelector for it in the > .xtest files, but I get the following error: > > Testcase: testFileGenerator took 0 sec > Caused an ERROR > Could not load class for component named 'file' at null:62:88 > org.apache.avalon.framework.configuration.ConfigurationException: Could > not load class for component named 'file' at null:62:88 > at > org.apache.cocoon.components.ExtendedComponentSelector.configure(ExtendedComponentSelector.java:283) > > So, is o.a.c.components.treeprocessor.sitemap.ComponentsSelector the > right class to use and how do we fix the .xtest files? Or would it be > better to restore the DefaultSitemapComponentSelector and mark it as > deprecated? I replaced the selector by the ExtendedComponentSelector, and it seems to work. But nevertheless the Resolver testcase break the tests. Stephan Michels.
Re: test case (class DefaultSitemapComponentSelector not found )
[Please do not send HTML mail to this list, thanks.] Nicolas Maisonneuve wrote: hy i would test a transformer and i used the code of the cocoon AbtractTransformerTestCase class and the "TraxTransformerTestCase.xtest" but i have a error : the class "org.apache.cocoon.sitemap.DefaultSitemapComponentSelector" is not found Looks like the org.apache.cocoon.sitemap.DefaultSitemapComponentSelector was recently removed, thus breaking all the tests. I've tried to implement a quick fix and substituted o.a.c.components.treeprocessor.sitemap.ComponentsSelector for it in the .xtest files, but I get the following error: Testcase: testFileGenerator took 0 sec Caused an ERROR Could not load class for component named 'file' at null:62:88 org.apache.avalon.framework.configuration.ConfigurationException: Could not load class for component named 'file' at null:62:88 at org.apache.cocoon.components.ExtendedComponentSelector.configure(ExtendedComponentSelector.java:283) So, is o.a.c.components.treeprocessor.sitemap.ComponentsSelector the right class to use and how do we fix the .xtest files? Or would it be better to restore the DefaultSitemapComponentSelector and mark it as deprecated? Ugo
Re: Test
Tony Collen wrote: Berin Loritsch wrote: My messages seem to be getting swallowed in Cyberspace. You can disregard this message. i had this problem too, i sent a message to users@ and never saw it again! It was a bunch of virii overloading the mail servers. ~ 27,000 mails with 100k attachments==bad news. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: Test
Berin Loritsch wrote: My messages seem to be getting swallowed in Cyberspace. You can disregard this message. i had this problem too, i sent a message to users@ and never saw it again! tony
