The Apache Cocoon team is pleased to announce the release of subprojects
Cocoon Integration Test Framework 1.0.1 and Servlet Service
Implementation 1.3.2.
Apache Cocoon is an XML processing framework built around the concepts of
separation of concerns and component-based development.
Apache
, Francesco Chicchiriccò
ilgro...@apache.org wrote:
I've created a Cocoon Integration Test Framework 1.0.1 release, with the
following artifacts up for a vote:
Vote will be open for 72 hours.
Can't really test at the moment but +1
+1
On Thu, Dec 13, 2012 at 10:16 AM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
I've created a Cocoon Integration Test Framework 1.0.1 release, with the
following artifacts up for a vote:
SVN source tag (r1421155):
https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon
+1
El 13/12/2012 10:17, Francesco Chicchiriccò ilgro...@apache.org
escribió:
I've created a Cocoon Integration Test Framework 1.0.1 release, with the
following artifacts up for a vote:
SVN source tag (r1421155):
https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
it-fw/tags
On 13/12/2012 10:16, Francesco Chicchiriccò wrote:
I've created a Cocoon Integration Test Framework 1.0.1 release, with
the following artifacts up for a vote:
SVN source tag (r1421155):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/
List
I've created a Cocoon Integration Test Framework 1.0.1 release, with the
following artifacts up for a vote:
SVN source tag (r1421155):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/
List of changes:
https://svn.apache.org/repos/asf/cocoon/subprojects
On Thu, Dec 13, 2012 at 3:16 AM, Francesco Chicchiriccò ilgro...@apache.org
wrote:
I've created a Cocoon Integration Test Framework 1.0.1 release, with the
following artifacts up for a vote:
Vote will be open for 72 hours.
Can't really test at the moment but +1
In addition to COCOON-2327 it's possible to build Cocoon with JDK 1.7.
Update LocaleAction test case
-
Key: COCOON-2328
URL: https://issues.apache.org/jira/browse/COCOON-2328
Project: Cocoon
Issue
Javier Puerto created COCOON-2328:
-
Summary: Update LocaleAction test case
Key: COCOON-2328
URL: https://issues.apache.org/jira/browse/COCOON-2328
Project: Cocoon
Issue Type: Improvement
with the updated test case.
Update LocaleAction test case
-
Key: COCOON-2328
URL: https://issues.apache.org/jira/browse/COCOON-2328
Project: Cocoon
Issue Type: Improvement
Components: * Cocoon
[
https://issues.apache.org/jira/browse/COCOON-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned COCOON-2184:
--
Assignee: Francesco Chicchiriccò
mvn test fails
mvn test fails
Key: COCOON-2184
URL: https://issues.apache.org/jira/browse/COCOON-2184
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core, - Build System: Maven
Affects Versions: 2.2
On 08/06/2012 11:16, Francesco Chicchiriccò wrote:
I've created a Cocoon Integration Test Framework 1.0.0 release, with
the following artifacts up for a vote:
SVN source tag (r1347959):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.0/
List
2012/6/8 Francesco Chicchiriccò ilgro...@apache.org
I've created a Cocoon Integration Test Framework 1.0.0 release, with the
following artifacts up for a vote:
SVN source tag (r1347959):
https://svn.apache.org/repos/**asf/cocoon/subprojects/cocoon-**
it-fw/tags/cocoon-it-fw-1.0.0/https
[X] +1 approve
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jun 8, 2012 at 11:16 AM, Francesco Chicchiriccò
ilgro...@apache.org wrote:
I've created a Cocoon Integration Test Framework 1.0.0
I've created a Cocoon Integration Test Framework 1.0.0 release, with the
following artifacts up for a vote:
SVN source tag (r1347959):
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.0/
List of changes:
https://svn.apache.org/repos/asf/cocoon/subprojects
On Fri, Jun 8, 2012 at 5:16 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:
I've created a Cocoon Integration Test Framework 1.0.0 release, with the
following artifacts up for a vote:
Great, +1
Peter Hunsberger
was failing
Modified:
cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java
Modified:
cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java
URL:
http://svn.apache.org/viewvc/cocoon
: The
org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator is
incomplete
test cases included
Unfortunately this commit breaks the build:
---
Test set
is
incomplete
test cases included
Unfortunately this commit breaks the build:
---
Test set:
org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGeneratorTestCase
David Legg wrote:
I thought I'd give C3 a go but I appear to have a couple of artifacts
missing when I run Maven. They are: -
com.sun.jersey:jersey-core:jar:1.0.3
com.sun.jersey:jersey-server:jar:1.0.3
I've tried making sure I'm using the 'cocoon-staging' profile mentioned
in the
Reinhard Pötz wrote:
David Legg wrote:
I thought I'd give C3 a go but I appear to have a couple of artifacts
missing when I run Maven. They are: -
com.sun.jersey:jersey-core:jar:1.0.3
com.sun.jersey:jersey-server:jar:1.0.3
Thanks David! I don't know why this can happen because I
I thought I'd give C3 a go but I appear to have a couple of artifacts
missing when I run Maven. They are: -
com.sun.jersey:jersey-core:jar:1.0.3
com.sun.jersey:jersey-server:jar:1.0.3
I've tried making sure I'm using the 'cocoon-staging' profile mentioned
in the email but to no effect. It
(Note: Those instructions require the usage of Maven 2. If you want to
use/test Cocoon without Maven, pls let me know.)
If you already use Cocoon 3 the best way to test is setting the version
to 3.0.0-alpha-2, e.g.:
dependency
groupIdorg.apache.cocoon.sax/groupId
artifactIdcocoon-sax
Thorsten Scherler wrote:
On 13/10/2009, at 23:02, Reinhard Pötz wrote:
thors...@apache.org wrote:
Author: thorsten
Date: Tue Oct 13 11:33:26 2009
New Revision: 824705
URL: http://svn.apache.org/viewvc?rev=824705view=rev
Log:
COCOON3-43
Provide a Consumer that interacts with solr
On Thu, 2009-10-15 at 10:06 +0200, Reinhard Pötz wrote:
Thorsten Scherler wrote:
On 13/10/2009, at 23:02, Reinhard Pötz wrote:
thors...@apache.org wrote:
Author: thorsten
Date: Tue Oct 13 11:33:26 2009
New Revision: 824705
URL: http://svn.apache.org/viewvc?rev=824705view=rev
thors...@apache.org wrote:
Author: thorsten
Date: Tue Oct 13 11:33:26 2009
New Revision: 824705
URL: http://svn.apache.org/viewvc?rev=824705view=rev
Log:
COCOON3-43
Provide a Consumer that interacts with solr
Reporter and Patch-Provder: Bertil Chapuis
Thanks Bertil.
+public void
On 13/10/2009, at 23:02, Reinhard Pötz wrote:
thors...@apache.org wrote:
Author: thorsten
Date: Tue Oct 13 11:33:26 2009
New Revision: 824705
URL: http://svn.apache.org/viewvc?rev=824705view=rev
Log:
COCOON3-43
Provide a Consumer that interacts with solr
Reporter and Patch-Provder: Bertil
Hi All,
I noticed the cocoon-sax module implements tests referring to old
cocoon-pipeline module, this should be the right taxonomy:
org.apache.cocoon.pipeline.util.TransformationUtilsTest
should be
org.apache.cocoon.sax.util.TransformationUtilsTest
Thanks Reinhard!
I just moved an issue liked to a wrong component, and then uploaded a
new patch for the XSLT, I hope this will be useful!
Best regards,
Simone
On Thu, Apr 30, 2009 at 11:14 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi All,
I noticed the cocoon-sax
Simone Tripodi wrote:
Hi All,
I noticed the cocoon-sax module implements tests referring to old
cocoon-pipeline module, this should be the right taxonomy:
org.apache.cocoon.pipeline.util.TransformationUtilsTest
should be
org.apache.cocoon.sax.util.TransformationUtilsTest
Also cocoon-optional packages should be renamed, here you can find my
suggestions:
org.apache.cocoon.optional.pipeline.components.sax.betwixt ||
org.apache.cocoon.sax.components.betwixt
org.apache.cocoon.optional.pipeline.components.sax.fop ||
org.apache.cocoon.sax.components.fop
you to check the release artifacts whether they meet
the legal requirements (checksums, pgp signatures, license files,
notice files) of the ASF.
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
details. :)
Our code is not really broken. Usually we call startPrefixMapping() in
startDocument() methods of transformers or something like this. It's
only broken for the test cases since we just have a look at the
component to test without its framework. From a component POV adding
start
On 09.06.2008 22:40, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Mon Jun 9 19:40:16 2008
New Revision: 665954
URL: http://svn.apache.org/viewvc?rev=665954view=rev
Log:
as a follow-up of COCOON-2168 (http://marc.info/?t=12089986853r=1w=4):
Cocoon's pipeline buffer increases from an
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:
Please ignore
Regards,
Jeroen
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
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
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
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
@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
: 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alfred Nathaniel wrote:
| On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote:
| I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
| bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
| I'm certain we won't be
On Mon, 2008-05-05 at 00:08 -0700, Ralph Goers wrote:
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
I'm certain we won't be supporting 1.4 until 2010.
No hope to get rid of 1.4 anytime soon. Java
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least now
I'm certain we won't be supporting 1.4 until 2010.
Ralph Goers wrote:
Carsten Ziegeler said:
Although I guess everyone understood what I meant above,
On May 5, 2008, at 3:08 AM, Ralph Goers wrote:
I sure am glad we decided to go with Java 1.4 for 2.2. See the nice
bulletin at http://java.sun.com/j2se/1.4.2/download.html. At least
now I'm certain we won't be supporting 1.4 until 2010.
Ralph Goers wrote:
Carsten Ziegeler said:
On 17.04.2008 19:57, [EMAIL PROTECTED] wrote:
Author: anathaniel
Date: Thu Apr 17 16:57:56 2008
New Revision: 649333
URL: http://svn.apache.org/viewvc?rev=649333view=rev
Log:
Fix compile errors
Modified:
cocoon/branches/BRANCH_2_1_X/src/blocks/javaflow/test/org/apache/cocoon/components
=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
-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.
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
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:
settings
profiles
profile
Just a test to see if my messages arrive on the list.
Just a test to see if my messages arrive on the list.
Just a test to see if my messages arrive on the list.
[
https://issues.apache.org/jira/browse/COCOON-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kuckartz updated COCOON-2184:
-
Summary: mvn test fails (was: Missing artifact:
org.apache.cocoon:cocoon-pipeline
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:
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:
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
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,
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
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
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
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
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
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
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 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
I saw that some committers have been using lowercase filenames
e.g. notice.txt, so the release-builder needs to handle that.
-David
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
Sorry for the noise, I'm having problems sending messages to Apache
mailing lists.
Ugo
declarations either but my opinion is that
test-cases should always reflect in every detail behaviour of components they
test.
Current behaviour of tested components is to leave superfluous namespace
declarations and this must be reflected in tests.
My point was that it is no error if the component's
fixed patches but your
suggestion must be taken into account when patches are applied, of course.
I'm don't like these superfluous declarations either but my opinion is that
test-cases should always reflect in every detail behaviour of components they
test. Current behaviour of tested components
[
https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Heinicke updated COCOON-2155:
--
Summary: Failing test cases due to additional attributes from namespace
declarations in a DOM
the class. That's what you usually do using
SAXTransformerFactory as Cocoon's DOMBuilder does or
DocumentBuilderFactory. The names matches more or less by coincidence.
The fix for XALANJ-2091 is triggered by startPrefixMapping(). With
FlowJXPathSelectionList.generateSaxFragment() as in the test
declarations in CIncludeTransformerTestCase.
Failing test cases due to additional attributes from namespace declarations
in a DOM from parser, but not from serializer
[
https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski updated COCOON-2155:
-
Attachment: COCOON-2155-parent-pom.patch
I have taken a closer look at our test
/endPrefixMapping calls in a code generating XML in Forms.
Also removed work-arounds for a bug in Xalan that is fixed in 2.7.1 version.
Failing test cases due to additional attributes from namespace declarations
in a DOM from parser, but not from serializer
prefix declarations.
Failing test cases due to additional attributes from namespace declarations
in a DOM from parser, but not from serializer
-
Key: COCOON-2155
is not really broken. Usually we call startPrefixMapping() in
startDocument() methods of transformers or something like this. It's
only broken for the test cases since we just have a look at the
component to test without its framework. From a component POV adding
start/endPrefixMapping() is the correct
namespace declarations it is probably better
to remove them. This should be possible using RedundantNamespacesFilter.
Failing test cases due to additional attributes from namespace declarations
in a DOM from parser, but not from serializer
Joerg Heinicke pisze:
On 22.11.2007 22:49 Uhr, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Thu Nov 22 19:49:58 2007
New Revision: 597535
URL: http://svn.apache.org/viewvc?rev=597535view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's
Parser produces redundant element attributes (namespace declarations) in a DOM
while test-cases are executed
Key: COCOON-2155
URL: https
On 26.12.2007 20:09 Uhr, Grzegorz Kossakowski wrote:
URL: http://svn.apache.org/viewvc?rev=597535view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's broken, not our code, fix the issue
in the test case.
Modified:
cocoon/trunk/blocks
Joerg Heinicke pisze:
Just an explanation: A namespace declaration is not an attribute (even
if it looks so) and that's why it should not end as such. The DOM
produced by Cocoon is absolutely correct, the one by parsing expected
document in the test case is not since it has both the namespace
On 02.11.2007 18:24 Uhr, [EMAIL PROTECTED] wrote:
Author: gkossakowski
Date: Fri Nov 2 15:24:41 2007
New Revision: 591496
URL: http://svn.apache.org/viewvc?rev=591496view=rev
Log:
Fixed FlowJXPathSelectionList test-case by:
* fixed generation of SAX stream so if it is serialized
On 22.11.2007 22:49 Uhr, [EMAIL PROTECTED] wrote:
Author: joerg
Date: Thu Nov 22 19:49:58 2007
New Revision: 597535
URL: http://svn.apache.org/viewvc?rev=597535view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's broken, not our code, fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHKsv9LNdJvZjjVZARAiFnAJ45aD206nWtB1/Hd5mTWHV2fNLLpACffTXO
9OO1L/H8238hWoWSvxWU8RE=
=3FU/
-END PGP SIGNATURE-
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:
settings
profiles
profile
[EMAIL PROTECTED] pisze:
Author: lgawron
Date: Mon Oct 8 09:17:27 2007
New Revision: 582862
URL: http://svn.apache.org/viewvc?rev=582862view=rev
Log:
use springified version of cocoon store
Do you think we you need real implementation of store for testing?
What about using mock objects?
about using mock objects?
The store itself is not that heavy to mock it. Anyway the purpose of
mocking IMO is:
- provide parts of the environment you do not have (http request,
response, servlet context)
- test interaction between the tested component and it's dependencies
(like testing
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
Our problem is not minimum Java requirement for Cocoon 2.2. The problem
is release time lines. [..] Java requirements? Nah, that's peanuts...
Thanks, you hit the nail. When was the vote? 1 year ago?
Despite being still convinced that raising
Vadim Gritsenko wrote:
Our problem is not minimum Java requirement for Cocoon 2.2. The problem
is release time lines. Cocoon 2.2 was supposed to be Cocoon 2.1 +
ECM+. Now we don't have ECM+, it went through Spring migration, there
seems to be second wave of OSGi activity - and 2.2 ain't
be found. It seems to be a Maven
2/Java 1.4 related problem.
I'm not willing to invest anymore time into this and for that reason I
disable the test for the
release. Java 1.4 support is really a PITA because any of the
committers seems to use it and
then it's me who has to deal with that problems
configuration files can't be found. It seems to be a Maven
2/Java 1.4 related problem.
I'm not willing to invest anymore time into this and for that reason I
disable the test for the
release. Java 1.4 support is really a PITA because any of the
committers seems to use
is that the included
Spring configuration files can't be found. It seems to be a Maven
2/Java 1.4 related problem.
I'm not willing to invest anymore time into this and for that reason I
disable the test for the
release. Java 1.4 support is really a PITA because any
Carsten Ziegeler said:
Although I guess everyone understood what I meant above, just a
clarification: of course I meant that it only makes sense to stick with
1.4 if the people working on and using 2.2 *with jdk 1.4* is a critical
mass. There is no doubt that currently there are many people
I agree. I am optimistic adn believe people opinions changes with time.
I would like to start a new vote since we have now a new jave version
scenario in front of us. :)
wdyt?
Best Regards,
Antonio Gallardo.
Ralph Goers escribió:
Carsten Ziegeler said:
Although I guess everyone
Date: Tue, 25 Sep 2007 17:08:52 +0200
From: [EMAIL PROTECTED]
J2SE 1.4.2 began its end of life process Dec 11 2006 and is expected to
complete it for the summer of 2008 http://java.sun.com/j2se/1.4.2/.
Sun's isn't the only JVM, you know...
According to
1 - 100 of 502 matches
Mail list logo
