On 20.04.2007 15:29, Alexander Klimetschek wrote:
Just an additional note: the original patch and related discussion can
be found here: http://issues.apache.org/bugzilla/show_bug.cgi?id=19206
That's now at https://issues.apache.org/jira/browse/COCOON-650.
Joerg
needed. I don't know about the XMLizer, so no idea about the
difference between the other toSAX() methods and parse().
Joerg
it using plain, written English ;-)
Looking forward to it! :)
Joerg
has to be that all blocks are
working and continuum runs all blocks. That's orthogonal to independent
release cycles and community interest. As long it the blocks are in
Cocoon's codebase we have to care for them.
Regards
Joerg
been to the UK, but already in Italy and Rome.
Anyway, I can't join this year for nearly sure. I'll be in the US
(Philadelphia btw.) starting soon (just waiting for the visa) and till
the end of the year.
Joerg
On 07.04.2007 15:10, Grzegorz Kossakowski wrote:
What about validation? Do you think we should stop share it also?
Why not? What should be different about this block?
Joerg
On 05.04.2007 18:09, Joern Nettingsmeier wrote:
in case it turns out to be a hard problem or you are short on time,
could you tell me at which revision the issue was introduced, so that i
can roll back?
Information can be found at http://marc.info/?t=11753452452r=1w=4.
Regards
Jörg
/wml_1.1.xml/doctype-system
encodingASCII/encoding
omit-xml-declarationyes/omit-xml-declaration
/map:serializer
Regards
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/webapp/sitemap.xmap?revision=477161view=markup
Hi Igor,
On 31.03.2007 03:43, Igor Naumov wrote:
Oh, good, somebody is not only working on it but also checking the mail
list :-)
actually I'm not working on or with it. Just checked the Cocoon
lifecycle aspects.
Now since I found somebody to complain to :-), here are a couple of
other
Hi,
just to repeat the subject: The [PATCH] prefix for Jira issues is no
longer necessary. Jira has its own switch Patch available, which is
also used by the script sending the patches mail to this list. Mostly
for that script [PATCH] was introduced long ago.
Regards
Joerg
On 28.03.2007 17:55, Reinhard Poetz wrote:
As a caching source is of general interest for many of our users (see
several requests on the users list) I want to propose to move it to
cocoon-core.
+1
Joerg
refreshing this project and building it since
it may be inconsistent.
Regards
Joerg
On 20.03.2007 17:48, Peter Hunsberger wrote:
However, note that some CSS tweaking may be required; if you increase
your browser text size (ctrl + in Firefox) you get some strange things
going on. People with poor eyesight may not be able to use it very
well as it currently sits.
Actually I
On 20.03.2007 13:30, Ross McDonald wrote:
The new site looks excellent.. can't wait till its live, thanks!
+1 I completely agree. Thanks, Thien.
Jörg
problems by forcing the browser into the quirks mode as it can't understand
XHTML anyway. Delivering standard conform HTML is much more appropriate for
those browsers.
Joerg
[1] http://marc.info/?l=xml-cocoon-devm=117407836212241w=4
[2] http://marc.info/?l=xml-cocoon-devm=117408459418886w=4
[3] http
On 19.03.2007 14:41, Jason Johnston wrote:
Yes, I only fixed the html serializer and that fix is not appropriate
for the xhtml. In html, the contents of the script tag is defined as a
cdata section, therefore there should be no encoding inside the script.
And that's what I fixed.
With xhtml the
On 17.03.2007 16:43, Jason Johnston wrote:
If by the lazy guys you also mean Cocoon itself. For instance, the
CForms forms-field-styling.xsl creates all its output in the null
namespace, which is fine for regular HTML delivery but if for some
reaason you do want to deliver as XHTML you have
(moving to dev list)
On 16.03.2007 14:58, Jason Johnston wrote:
Another option might be to wrap the contents of script elements
within a CDATA section so the JS could remain unencoded but it would
still result in well-formed XML. I'm not sure how some browsers
would handle the CDATA
, but abdicable - it's for the lazy guys. Also the meta tag
for content type it adds should be abdicable. AFAIR it's also only for
IE as it stumbles on the XML declaration.
But at the end it should not do more than this.
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks
On 16.03.2007 11:54, Ross Gardler wrote:
Also perhaps some other information could be tied in.. such as who
are the experts on which blocks or areas within Cocoon
Independent from the counter argument already given the Cocoon changes
site [1] already gives this information in a more verbose
On 15.03.2007 07:10, Grzegorz Kossakowski wrote:
I would like to ask you about my possible participation in GSoC and
having Cocoon as a project of choice, of course.
Just wondering if you are allowed to as you are already committer?
As far as I understand this:
On 14.03.2007 08:39, Reinhard Poetz wrote:
I want to share two thoughts:
- the probably best source of information to find out whether a project
and its
committers are (in)active is looking at the mailing lists and the
changes docs.
+1
What's the additional value of having a list
On 14.03.2007 09:27, Ross McDonald wrote:
I suppose a list of active committers will prevent people who are no
longer active from receiving emails they don't want to receive from
those looking for help.. so it may stop dead end investigations?
In that way an up-to-date list of committers
On 14.03.2007 23:56, Grzegorz Kossakowski wrote:
I would like to ask you about my possible participation in GSoC and having
Cocoon as a project of choice, of course. Do
you think it's good idea in general?
Just wondering if you are allowed to as you are already committer? IIRC
the original
On 10.03.2007 17:53, Grzegorz Kossakowski wrote:
I would like to ask if you have no objections to creating issues on JIRA
for each task I'm going to work.
Once upon the time ... we tried to use Bugzilla for project management
and release planning (but it was not really successful). So I
On 05.03.2007 09:19, Andrew Savory wrote:
I'd like to propose Jeroen Reijn as a Cocoon committer.
+1, welcome.
Jörg
On 05.03.2007 20:38, Reinhard Poetz wrote:
I want to propose Felix as a committer.
+1 and welcome.
Jörg
Andrew Savory andrew at luminas.co.uk writes:
I'd like to propose Jeroen Reijn as a Cocoon committer.
Jeroen has been active on the lists since September 2006
Wondering about this short time I had a look into the archives. And so, just for
the records: Jeroen has been active quite regularly
On 02.03.2007 15:32, Reinhard Poetz wrote:
I fear that the most difficult task will be encouraging you to stop
sharing forms and ajax blocks between trunk and 2.1.x branch. On the
other hand, I can live with that stuff in patches/whiteboard if you wish.
I propose that we stop sharing blocks
On 22.02.2007 17:36, Daniel Fagerstrom wrote:
I'd like to propose Grzegorz Kossakowski (aka Grek) as a new Cocoon
committer.
+1
Jörg
On 21.01.2007 18:07, Mark Lundquist wrote:
Should the wiki be set up to email update notifiers to the user list
(like it does today to the doc list)? That might help the user
community to become more aware of the wiki (assuming that'd be a good
thing? :-) WDYT?
Please not. At other places
For reference what already has been suggested:
http://marc.theaimsgroup.com/?t=11692292551r=1w=4.
Jörg
On 21.01.2007 22:40, Gary Larsen wrote:
I'm now trying the dev-list for this. Thanks for any ideas.
I'm upgrading Cocoon from 2.1.7 to 2.1.10 and having a problem with a custom
On 19.01.2007 12:01, Jeroen Reijn wrote:
wow great designs Thien! I really like 2-4.
#3 has a nice touch with the 'blocks', but somehow #4 was the first one
that appealed to me. It's kind of playfull and dreamy. I really like it.
It's a bit too dreamy IMO. :-) I prefer #2 and #3.
Great
On 19.01.2007 18:24, Grzegorz Kossakowski wrote:
Anyway, it would be good
if someone with necessary skills could investigate further and find out
why compiling serializers block demands so much memory.
This has always been the case, also for 2.1. It's a problem of the code
itself. For
On 16.01.2007 18:07, Bertrand Delacretaz wrote:
http://www.cocoontecs.com - Cocoon Technologies Software AG.
Doesn't look like these guys are using (the one and only) Cocoon, but
it's hard to tell from the marketingspeak.
Only requirement for career as java programmer is swing [1], so
On 11.01.2007 02:28, Mark Lundquist wrote:
I ran mvn eclipse:eclipse; now which projects do I need to import, and
what's the easiest way to do it? :-)
At least the Eclipse setup works as expected if following the
description in README.txt in Cocoon trunk's root dir.
Jörg
On 07.01.2007 01:15, [EMAIL PROTECTED] wrote:
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/15/buildId/1581
Changes
joerg COCOON-1471: Forms block: Add method to create binding
from DOM tree
On 05.01.2007 00:21, Jörg Heinicke (JIRA) wrote:
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
2.1.11-dev (current SVN)
I wonder how we manage those versions. It seems to be quite strange:
Issues fixed in 2.1.9:
On 04.01.2007 22:13, Jörg Heinicke (JIRA) wrote:
Jörg Heinicke updated COCOON-1977:
--
Affects Version/s: 2.2-dev (Current SVN)
I'm wondering what this caching does buy us at all? Can somebody
tell in which cases the reader is really faster? From what I
On 03.01.2007 17:47, Ard Schrijvers wrote:
Locally we added this svn 'pre-commit' hook to prohibit a commit that
did not contain a reference to a jira issue. In jira, via an issue,
you can then find the commits that below to it. Although it is
sometimes a little annoying, it forces everybody
On 02.01.2007 23:05, Daniel Fagerstrom wrote:
One complication in our work in making the Cocoon components work in a
standard Spring container without special Avalon support is that a large
amount of our components are Poolable (or more specifically Recyclable).
And Spring doesn't have any
On 29.12.2006 10:41, Carsten Ziegeler wrote:
Hmm, perhaps we could use the spring authoring functionality (like we do
for setting up Cocoon) and provide some element (don't quote me on the
syntax right now, this is just a rough idea):
bean name=my.pac.kage.NiceGenerator
..!-- Configuration
On 28.12.2006 09:36, Carsten Ziegeler wrote:
What's wrong with property injection?
The current sitemap features do not require the component implementation
to have support for a mime-type (or a label), so they don't need to have
a property for that.
We could use properties for that, with the
On 27.12.2006 13:48, Reinhard Poetz wrote:
Does anybody else see this error message when he tries to use the latest
snapshot from trunk?
java.lang.NullPointerException
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:50)
Line 50
On 27.12.2006 14:03, Carsten Ziegeler wrote:
Line 50 of the PoolableProxyHandler is
RequestContextHolder.getRequestAttributes().removeAttribute(this.attributeName,
RequestAttributes.SCOPE_REQUEST);
I removed our own implementation in favour of Spring's
RequestContextHolder. The attributes
On 27.12.2006 19:05, Reinhard Poetz wrote:
I removed our own implementation in favour of Spring's
RequestContextHolder. The attributes are used to keep track of poolable
components and to release them when the request is finished.
Therefore you should add the Spring's request context listener
Hello Lars,
just from having a look at the code:
1. It's http://www.w3.org/TR/REC-xml (see Validator interface and its
declared constants).
2. This exception is thrown in AbstractValidator.getValidationHandler()
in line 327 in the current code. It is thrown when no SchemaParser can
be found.
Isn't their a thread on the users list about creating generic components
using input and output modules for such tasks? Wouldn't be your
to-be-donated component one of the first to be deprecated? So what about
contributing an InputModuleSelector and a ContextAttributeInputModule ;)
Regards
Bertrand Delacretaz bdelacretaz at apache.org writes:
Sorry to rain on this party again, but Junit tests in your release
candidates fail on non-Windows systems, due to debugging statements
which try to create files like d:/enum.xml.
Oh, sorry for this. Needed this for comparing the files.
On 18.12.2006 09:39, Carsten Ziegeler wrote:
Please cast your votes on the 2.1.10 release.
+1
Jörg
On 18.12.2006 10:42, Bertrand Delacretaz wrote:
all the automated tests from org.apache.cocoon.forms.datatype fail
(DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase).
IIRC the same tests passed last week, anyone know what could have changed?
This is
On 18.12.2006 20:34, Joerg Heinicke wrote:
all the automated tests from org.apache.cocoon.forms.datatype fail
(DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase).
IIRC the same tests passed last week, anyone know what could have
changed?
As forms block
On 18.12.2006 16:22, Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
+1
Jörg
On 17.12.2006 17:29, Jeremy Quinn wrote:
It may be too early to deprecate CFormsTransformer (for this release)
but would it be possible to replace the old JXT with the new one, so it
can be tested more heavily?
I'll give it a try and click around a bit.
Lucene Block
I fixed
On 17.12.2006 17:29, Jeremy Quinn wrote:
Unfortunately that's a side effect of linking trunk sources into the
branch. The Captcha only works with the new JXTemplateGenerator from
the template block but not with the one from branch core. While on
trunk the one from template block is for sure
On 17.12.2006 23:46, Andrew Stevens wrote:
Although this means the developers presumably won't be worrying about
preserving 1.3 compatibility in future, if anyone else submits patches
for it would these still get applied to the branch?
That's how I would really like to see it is handled.
On 14.12.2006 08:37, Joerg Heinicke wrote:
Woody block does neither compile due to missing outerj stuff.
Where the hell did the Woody block get its org.outerj.i18n.* stuff from?
I can't find it. Only found the commits where Sylvain dropped its usage
(157067 on branch and 157080 on trunk
Hello Gary,
thanks very much for your efforts. Such extensive testing is very
welcome of course.
On 15.12.2006 17:48, Stewart, Gary wrote:
Hello World Tests
=
org.xml.sax.SAXParseException: Invalid byte 3 of 3-byte UTF-8 sequence.
Was a problem in build system, when UTF-8
Hello,
this relatively new feature of adding comments to Jira issues by
replying to its mails has one caveat: autoreplies like this absent
message get added to Jira as well like you can see here:
http://issues.apache.org/jira/browse/COCOON-1969
On 11.12.2006 14:55, Carsten Ziegeler wrote:
Hi community,
the Cocoon project is working very hard to release 2.1.10 by Monday,
December 18th.
I fear JCR block does not compile as all the API (package javax.jcr.*)
stuff has been removed (probably with the update to jackrabbit 1.0.1).
Jörg
On 14.12.2006 08:10, Carsten Ziegeler wrote:
I fear JCR block does not compile as all the API (package javax.jcr.*)
stuff has been removed (probably with the update to jackrabbit 1.0.1).
No, the jcr api has not been removed, we never had it in our repository
(due to licencing problems). The
On 08.12.2006 22:38, Alfred Nathaniel wrote:
I propose to delete the obsolete
BRANCH_2_1_X/src/java/org/apache/cocoon/matching/helpers/WildcardHelper.java
and the related test case.
+1
Jörg
On 07.12.2006 11:51, Ard Schrijvers wrote:
1) The lightweight StripNameSpaceTransformer ... Add
this to trunk/branch or not?
+1
2) The XHTML serializer: Make it by default strip the list of
namespaces we know people don't want to sent to the browser.
-1 No, please don't. If you have a
It is. Riester-Rente is a specific German pensions product. The page is
about comparing those products from different vendors. Riester is the
former minister of employment and social in Germany.
On 05.12.2006 03:58, Antonio Gallardo wrote:
I wonder if this is wiki spam.
wdyt?
Best Regards,
Mark Lundquist ml at wrinkledog.com writes:
And I guess the old convention of starting with '[PATCH]' is
superfluous now, right?
It is indeed no longer necessary to prefix the title as you can see in the
recent COCOON-open-with-patch mails:
On 18.11.2006 17:09, Dan Hertz wrote:
I'm hoping someone can help me troubleshoot why I can't insert an xml
nodeset into my database using the SQL Transformer. All I end up with is
the text() values concatenated together -- no elements or attribute
nodes.
How does your pipeline look like? Is
On 18.11.2006 21:12, Mark Lundquist wrote:
On Nov 18, 2006, at 5:46 AM, Carsten Ziegeler wrote:
So if you have two sitemaps in your block, one for /myblock and one for
/myblock/misc, then you add two component definitions to the spring
context and you don't have to mount the misc sub sitemap
On 16.11.2006 13:11, Carsten Ziegeler wrote:
Please cast your votes for using latest rhino in 2.1.x.
+1
Jörg
On 03.11.2006 23:17, Carsten Ziegeler wrote:
With the help from Leszek we now have a Cocoon version in trunk which
does not need any deployment plugin. This means you can just drop the
jar files into WEB-INF/lib and are done! So it doesn't matter if you're
using Maven, Ant or some other strange
On 31.10.2006 08:59, Carsten Ziegeler wrote:
The proposal is to use the following directory structure inside a block jar:
COB-INF - resources
META-INF/cocoon/xconf/**
META-INF/cocoon/spring/**
META-INF/cocoon/properties/**
+1
Jörg
Carsten Ziegeler cziegeler at apache.org writes:
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of files during deployment
Alexander Klimetschek alexander.klimetschek at mindquarry.com writes:
But roles are a different concept than bean-ids
Why do you think so?
I am not a Spring expert, but roles have this inheritance concept, and
bean-ids are merely just IDs, aren't they?
I might be wrong, but there is
On 30.10.2006 18:52, Torsten Curdt wrote:
I've already applied it on my machine and can do the commit ...but I
think Maurizio also did another update to it to re-enable the
component reloading as well. Maurizio?
...also think it would be really worth having that in ASAP
could you apply
On 28.10.2006 12:16, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?view=revrev=468669
Log:
Improve error reporting by using a CascadingIOException instead of an ordinary
IOException. Due to Alexander Klimetschek.
Modified:
On 28.10.2006 12:37, Nathaniel Alfred wrote:
-1 to put 2.1.x into *pure* bug fixing mode
Selling to management another
migration project before 2008 would be very hard, especially since
the current 2.2 has new feature really interesting to us.
Something is wrong with that sentence I guess.
On 27.10.2006 20:57, Carsten Ziegeler wrote:
The release of 2.1.10 should be the last planned release for 2.1.x - we
should drop the block sharing between trunk and the branch of the blocks
right after the release and continue development of things only in trunk
from that point on.
+1
So my
On 25.10.2006 22:07, [EMAIL PROTECTED] wrote:
+ xsl:template match=* mode=copy-parent-id
+xsl:copy
+ !-- do not override id if already specified, else use parent id --
+ xsl:if test=not(@id)
+xsl:attribute name=idxsl:value-of
select=../@id//xsl:attribute
+ /xsl:if
+
On 22.10.2006 11:36, Daniel Fagerstrom wrote:
Both these changes affects interfaces, but I would be surprised if
anyone have implemented Processor or ProcessingPipeline outside our code
base, so it shouldn't matter that much.
Even if ... when to do it if not now?
Jörg
Jean-Baptiste Quenot jbq at apache.org writes:
Antonio,
Do you plan to work on adding random headers support to this
transformer? If you don't there is no point at reopening this bug
IMHO.
I could file JIRA issues for very interesting wishes like:
Implement Stax-based
Jörg Heinicke (JIRA jira at apache.org writes:
JEXL Does not support full cocoon object model on its own
-
Key: COCOON-1816
URL: http://issues.apache.org/jira/browse/COCOON-1816
Ard Schrijvers a.schrijvers at hippo.nl writes:
Can I create some sort of dependency between the to, or do I need to make a
cocoon JIRA issue that says update excalibur jars, and somehow relate
http://issues.apache.org/jira/browse/COCOON-1909 to it (in
principal, then when the update jira
On 09.10.2006 06:01, Antonio Gallardo wrote:
Should we call for a new votation about the
minimal java version for cocoon 2.2?
No, please don't.
Jörg
If you are interested, I could add the Ivy build system into
tools/build...
As it's still experimental IIUC, I'd prefer to have it somewhere under
http://svn.apache.org/repos/asf/cocoon/whiteboard/
So much I dislike Maven, shouldn't we be honest and say there is no real
chance of
On 09.10.2006 23:03, Antonio Gallardo wrote:
I am thinking in 2.2 too. The above reference to 2.1 is just a sample of
what we are repeating for 2.2. Because we claim 2.1 is java 1.3 when it
fact few of us care about this compatibility and some blocks does not
compile at all. This somehow
On 06.10.2006 11:35, Daniel Fagerstrom wrote:
For the JavaFlow the Abstract.Contunable.processPipelineTo uses
PipelineUtil.processToStream, it might be a good idea to copy the code
to JavaFlow to get rid of the dependency on Floscript.
The PipelineUtil in its current form depends on Rhino.
On 08.10.2006 14:02, Jorg Heymans wrote:
http://www.apache.org/dev/svn-eol-style.txt
However this won't work for files you already added. For those you just do
something like svn propset svn:eol-style native yourfile.java and commit.
It's all described in detail here
On 07.10.2006 14:43, Laurent Perez wrote:
I'm using JSPs an Cocoon 2.2, but I still don't understand if I did
the right integration : basically, my usecase requires custom JSP
tags to be able to retrieve XML from sitemap patterns. Under 2.1, I
wrote an integration method starting up a
On 06.10.2006 00:32, [EMAIL PROTECTED] wrote:
action dev=AG type=update
Deprecate method
org.apache.cocoon.components.flow.FlowHelper.unwrap(Object). This method
will be removed in 2.2 release. Use
org.apache.cocoon.components.flow.util.PipelineUtil.unwrap(Object) instead.
/action
Why
On 06.10.2006 00:57, Antonio Gallardo wrote:
Why actually? What has unwrap to do with pipeline processing? If it is
because it is only used there then it makes only sense to move it
there if you also make it private. Otherwise it is a public method and
it should be seen in a more API-POV,
On 02.10.2006 15:05, [EMAIL PROTECTED] wrote:
One of the patches was a change of template priorities in the
forms-field-styling.xslt If this isn't applied, I get
Abiguous Template errors from Saxon.
xsl:template match=fi:styling/@* mode=styling
Has to be changed to:
xsl:template
On 03.10.2006 15:01, Jean-Baptiste Quenot wrote:
I think time has come for Lars Trieloff to become a Cocoon
committer
+1
Jörg
On 29.09.2006 09:19, Carsten Ziegeler wrote:
Now what about the other directories we currently have:
config/spring, config/xconf and config/properties?
Should we leave them where they are or move them one directory up?
I'd prefer the flat variant, i.e. without config subdir.
Jörg
On 24.09.2006 19:20, [EMAIL PROTECTED] wrote:
Author: simoneg
Date: Sun Sep 24 10:20:27 2006
New Revision: 449440
URL: http://svn.apache.org/viewvc?view=revrev=449440
Log:
XReporter recompiled for 1.4 and without the Column function which is outside
cocoon scope.
The 2.1 branch should be
On 20.09.2006 10:39, Nathaniel Alfred wrote:
Since map:match is the
most frequently executed pipeline instruction, speed is an issue. That
can be mastered by a) caching the compiled regexps and b) handling the
simple pattern with a single * or ** as special cases without using
regexps.
Just
On 17.09.2006 14:38, Leszek Gawron wrote:
Is this something we can influence at all? Is this a problem of the
Maven Eclipse plugin? Or is everything left to the project wizard of
Eclipse?
Are you refering to maven eclipse plugin which you invoke by mvn
eclipse:eclipse or to m2eclipse (which
Hi Florian,
On 13.09.2006 23:27, Dev at weitling wrote:
The Cocoon directory structure isn't very concise: many directories with
the same or at least similar names at different locations, some
directories with non-intuitive names (e.g. lib/endorsed: why endorsed?).
I can't agree. Cocoon
On 13.09.2006 23:55, Dev at weitling wrote:
And: On the left side there's the point Updating to version 2.1.5. May
it be outdated or was that a difficult change?
Yes, migrating to 2.1.5 had some implications as you can read on the
first two topics. But the rest of the document is more a
Hi,
I finally really wanted to try Cocoon 2.2 and evaluate it. But unfortunately I
failed early - my Maven nightmares becoming true ;)
[INFO] Building Apache Cocoon
[INFO]task-segment: [install]
[INFO]
Downloading:
Jorg Heymans jh at domek.be writes:
Temporary network hickup, proxy problems ? Below url resolves fine
for me from a browser.
Indeed a proxy problem - but only for this file, for other plugins it works. Our
proxy tries to parse it and stumbles. Don't know how to solve it yet. Have to
ask our
Hi,
I tried the Maven build at home and it worked. Only eclipse:eclipse
generates some project definitions, which don't work:
cocoon-template-impl had a wrong source dir, so that package declaration
did not match the package set in Eclipse. Same is true for
cocoon-22-archetype-block.
301 - 400 of 1679 matches
Mail list logo
