[jira] Commented: (COCOON-2044) servlet: protocol URIs have to be globally unique for use as cache-keys

[ https://issues.apache.org/jira/browse/COCOON-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492629 ] Grzegorz Kossakowski commented on COCOON-2044: -- Alexander, are you going to provide a patch for this

[jira] Closed: (COCOON-1975) cocoon-core-M2 could not be runned because of missing dependencies on avalon-framework-api-4.3 and excalibur-instrument-api-2.1

[ https://issues.apache.org/jira/browse/COCOON-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-1975. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Assignee:

[jira] Created: (COCOON-2057) I18n transformer doesn't substitute params within attribute values

I18n transformer doesn't substitute params within attribute values -- Key: COCOON-2057 URL: https://issues.apache.org/jira/browse/COCOON-2057 Project: Cocoon Issue Type: Bug

[jira] Updated: (COCOON-2057) ParamSaxBuffer doesn't substitute params within attribute values

[ https://issues.apache.org/jira/browse/COCOON-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Hartmann updated COCOON-2057: - Summary: ParamSaxBuffer doesn't substitute params within attribute values (was: I18n

Exclusions does not work with dependency managment?

Hello, I'm struggling now with transitive dependencies and exclusions in Cocoon. The problem is that (for example) cocoon-sitemap-impl has dependency on commons-jxpath which depends on commons-logging. The last one, depends on avalon-framework:avalon-framework which should be excluded. In our

mvn archetype-block broken?

Hi, The block archetype seems to have problems with missing versions on dependencies now: Project ID: com.mycompany:myBlock1 POM Location: getting-started-app/myBlock1/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.cocoon:cocoon-core

Re: mvn archetype-block broken?

Andrew Savory napisał(a): Hi, The block archetype seems to have problems with missing versions on dependencies now: Project ID: com.mycompany:myBlock1 POM Location: getting-started-app/myBlock1/pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for

Why we have our own SAXParser interface?

Hi, I wonder why we have org.apache.cocoon.core.xml.SAXParser interface that is equally the same as org.apache.excalibur.xml.sax.SAXParser? Carsten, why did you introduce our own interface? -- Grzegorz Kossakowski

Re: Why we have our own SAXParser interface?

Grzegorz Kossakowski: Hi, I wonder why we have org.apache.cocoon.core.xml.SAXParser interface that is equally the same as org.apache.excalibur.xml.sax.SAXParser? Carsten, why did you introduce our own interface? The main reason was to have a simple bean based implementation that is not

Re: Exclusions does not work with dependency managment?

Grzegorz Kossakowski wrote: I'm struggling now with transitive dependencies and exclusions in Cocoon. The problem is that (for example) cocoon-sitemap-impl has dependency on commons-jxpath which depends on commons-logging. The last one, depends on avalon-framework:avalon-framework which should

Re: Exclusions does not work with dependency managment?

Jorg Heymans napisał(a): Neither dependency:resolve nor dependency:analyze list avalon-framework:avalon-framework as an included dependency (I executed the plugin from the block directory). Are you sure it comes from that block ? I also tried dependency plug-in already and had the same

Re: Why we have our own SAXParser interface?

Carsten Ziegeler napisał(a): The main reason was to have a simple bean based implementation that is not tied to Avalon/Excalibur. The sax parser is one of our core components so having this inside Cocoon makes sense and reduces dependencies while at the same time allows refactoring the stuff