tcurdt commented on PR #35:
URL: https://github.com/apache/cocoon/pull/35#issuecomment-1328134784
Odd. But if that makes it work...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific
jpuerto opened a new pull request, #35:
URL: https://github.com/apache/cocoon/pull/35
```
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'javax.jcr.Repository': Initialization of bean failed; nested
exception is java.lang.IllegalAccessError: tried
Hi all,
We started a Cocoon 3 project with some blocks and we need to use Saxon for
XSLT 2.0 features.
The problem is with the RCL, we used latest cocoon-maven-plugin (1.0.2) but
I've noticed that Xalan dependency is always used so my XSLT are not
working. I've change the version to 1.0.0
On 27/06/2013 13:34, Javier Puerto wrote:
Hi all,
We started a Cocoon 3 project with some blocks and we need to use
Saxon for XSLT 2.0 features.
The problem is with the RCL, we used latest cocoon-maven-plugin
(1.0.2) but I've noticed that Xalan dependency is always used so my
XSLT
that Xalan dependency is always used so my
XSLT are not working. I've change the version to 1.0.0 then it's
working OK.
Why is using Xalan if I didn't declare the dependency? Is there a way
to configure this behaviour?
Hi Javier, I guess this bug was introduced by COCOON-2322, included in
1.0.2 [1
dependency is always used so my XSLT are not
working. I've change the version to 1.0.0 then it's working OK.
Why is using Xalan if I didn't declare the dependency? Is there a way to
configure this behaviour?
Hi Javier, I guess this bug was introduced by COCOON-2322, included in
1.0.2 [1
Robby Pelssers created COCOON3-115:
--
Summary: Adding Saxon-HE 9.4 as dependency [cocoon-sax] broke unit
tests
Key: COCOON3-115
URL: https://issues.apache.org/jira/browse/COCOON3-115
Project: Cocoon
[
https://issues.apache.org/jira/browse/COCOON3-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robby Pelssers closed COCOON3-115.
--
Resolution: Fixed
Assignee: Robby Pelssers
Adding Saxon-HE 9.4 as dependency
/?view=revrev=1418726
Files :
*
/cocoon/cocoon3/trunk/cocoon-profiling/src/main/java/org/apache/cocoon/profiling/component/ProfilingGenerator.java
Adding Saxon-HE 9.4 as dependency [cocoon-sax] broke unit tests
[
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò reassigned COCOON3-76:
-
Assignee: Francesco Chicchiriccò
Remove jakarta-regexp dependency
question, using find() instead of
matches() should keep the same behavior as previous.
WDYT?
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-optional
Affects Versions: 3.0.0
ambiguity and also it's the
behaviour I should expect. The problem is the backwards compatibility.
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
can not be worried about backward compatibility
issues: I'll apply your patch then.
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project
dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-optional
Affects Versions: 3.0.0-beta-1
[
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò closed COCOON3-76.
-
Resolution: Fixed
Remove jakarta-regexp dependency
/DirectoryGenerator.java
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-optional
but there are differences in behaviour. See
http://stackoverflow.com/questions/6582569/differences-between-jakarta-regexp-and-java-6-java-util-regex
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https
Hi !
Just glancing through recent evolutions in cocoon 3.
When building a block, based upon the sample, I notice a dependency:
- avalon-framework-api
- avalon-framework implementation
Just curious: what does it come from?What needs it?
I am running an application with minimum dependencies
On 07/11/2011 09:04, Jos Snellings wrote:
Hi !
Just glancing through recent evolutions in cocoon 3.
When building a block, based upon the sample, I notice a dependency:
- avalon-framework-api
- avalon-framework implementation
Just curious: what does it come from?What needs it?
I am running
Remove jakarta-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-optional
Reporter
-regexp dependency
Key: COCOON3-76
URL: https://issues.apache.org/jira/browse/COCOON3-76
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-optional
Reporter: Francesco
==
--- cocoon/cocoon3/trunk/cocoon-optional/pom.xml (original)
+++ cocoon/cocoon3/trunk/cocoon-optional/pom.xml Sat Jul 2 00:48:39 2011
@@ -92,6 +92,11 @@
optionaltrue/optional
/dependency
dependency
+groupIdorg.apache.xmlgraphics/groupId
+artifactIdxmlgraphics-commons
==
--- cocoon/cocoon3/trunk/cocoon-optional/pom.xml (original)
+++ cocoon/cocoon3/trunk/cocoon-optional/pom.xml Sat Jul 2 00:48:39 2011
@@ -92,6 +92,11 @@
optionaltrue/optional
/dependency
dependency
===
--- cocoon-optional/pom.xml (revision 1142145)
+++ cocoon-optional/pom.xml (working copy)
@@ -92,12 +92,6 @@
optionaltrue/optional
/dependency
dependency
-groupIdorg.apache.xmlgraphics/groupId
-artifactIdxmlgraphics-commons/artifactId
-version1.4
On Sat, 2011-07-02 at 16:39 +0200, Reinhard Pötz wrote:
...
Please use the dependency management section of the parent POM to set
version numbers so that they are the same for one artifact throughout
our codebase. Thanks!
Committed revision 1142266.
Thanks for pointing out.
salu2
===
--- cocoon-optional/pom.xml (revision 1142145)
+++ cocoon-optional/pom.xml (working copy)
@@ -92,12 +92,6 @@
optionaltrue/optional
/dependency
dependency
- groupIdorg.apache.xmlgraphics/groupId
- artifactIdxmlgraphics
the same problem.
Session-attr set in dependency blocks destroyed after servlet call.
---
Key: COCOON-2194
URL: https://issues.apache.org/jira/browse/COCOON-2194
Project: Cocoon
on this issue in foreseeable future so I leave it
unassigned.
Upgrade Forms samples' dependency on jDBI to 2.0.x version
--
Key: COCOON-2087
URL: https://issues.apache.org/jira/browse/COCOON-2087
Does cocoon-xml still need a dependency on xml-apis? AFAIU with Java 5
the Jaxp API is part of the JDK and we don't need to add it ourselves,
do we?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people
Reinhard Pötz wrote:
Does cocoon-xml still need a dependency on xml-apis? AFAIU with Java 5
the Jaxp API is part of the JDK and we don't need to add it ourselves,
do we?
Yes, you're right - I removed it in trunk.
Carsten
--
Carsten Ziegeler
cziege...@apache.org
the JMSEventMessageListener into
the jms-sample block, because it is a concrete subclass of
the AbstractMessageListener, we would get a more satisfying situation.
Doesn't the JMSEventMessageListener have a dependency on eventcache, or
none at all (it's been a while so I might be off here...)
The way
with that?
Regards,
Lukas
Ard Schrijvers schrieb:
Hello Lukas,
Sry for my late respond
Hello,
I'm wondering, why the eventcache block has dependencies on
the JMS block and not the other way round?
I do not know what you would win by switching the dependency around. JMS
seems to me more uncoupled from
Hello Lukas,
Sry for my late respond
Hello,
I'm wondering, why the eventcache block has dependencies on
the JMS block and not the other way round?
I do not know what you would win by switching the dependency around. JMS
seems to me more uncoupled from eventcache then eventcache to jms
[
https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2226:
Assignee: Grzegorz Kossakowski
Build error due to wrong dependency
here.
Build error due to wrong dependency version from cocoon-servlet-service in
cocoon-spring-configurator
-
Key: COCOON-2226
URL: https://issues.apache.org
Build error due to wrong dependency version from cocoon-servlet-service in
cocoon-spring-configurator
-
Key: COCOON-2226
URL: https://issues.apache.org/jira
[
https://issues.apache.org/jira/browse/COCOON-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abel Muiño updated COCOON-2226:
---
Attachment: patch.txt
Changes version of dependency to 1.1.0-SNAPSHOT
Build error due to wrong
Hello,
I'm wondering, why the eventcache block has dependencies on
the JMS block and not the other way round?
For those who are familiar with these blocks,
in my opinion the JMSEventListener makes use of eventcache capabilities.
So I would say, JMS provides callback support via eventcache.
[
https://issues.apache.org/jira/browse/COCOON-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reassigned COCOON-2176:
Assignee: Grzegorz Kossakowski
Remove dependency on CocoonSourceResolver
Service Framework(10247).
Level 1 values: 1.1.0-dev(10351).
Remove dependency on CocoonSourceResolver from Servlet Service Framework
Key: COCOON-2176
URL: https://issues.apache.org/jira
that depends on refactored SSF that is free of
CocoonSourceResolver dependencies.
This test-case passes so the bug can be closed.
Many thanks to Reinhard for his work that made this happen!
Remove dependency on CocoonSourceResolver from Servlet Service Framework
[
https://issues.apache.org/jira/browse/COCOON-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh updated COCOON-2194:
-
Summary: Session-attr set in dependency blocks destroyed after servlet
call. (was: Session-attr set
Session-attr set in dependency blocks systematically destroyed after servlet
call.
--
Key: COCOON-2194
URL: https://issues.apache.org/jira/browse/COCOON-2194
Project
on the
client. CForms cannot stop you from using stuff that would not work.
eg. onchange handlers etc.
The dependency that the Forms block has on the Ajax block is currently
very important.
CForms uses the BrowserUpdate mechanism for updating forms on the fly.
BrowserUpdate consists
Joerg Heinicke wrote:
On 13.03.2008 16:20, Luca Morandini wrote:
Which is a departure from 2.1.9, which, IIRC, worked even with
Javascript disabled on the browser.
I don't think Forms used to work without Javascript.
I beg to differ: disable your javascript, go to
On 18.03.2008 03:46, Luca Morandini wrote:
I beg to differ: disable your javascript, go to
http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no
Javascript there (at least for the widget types we used).
With JavaScript *enabled* I'm stuck at the front page saying Tutela del
Joerg Heinicke wrote:
On 18.03.2008 03:46, Luca Morandini wrote:
I beg to differ: disable your javascript, go to
http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see no
Javascript there (at least for the widget types we used).
With JavaScript *enabled* I'm stuck at the front
On 18.03.2008 08:15, Luca Morandini wrote:
I beg to differ: disable your javascript, go to
http://www.tutelamare.it/ and click on AmbienteMeteo; you'll see
no Javascript there (at least for the widget types we used).
With JavaScript *enabled* I'm stuck at the front page saying Tutela
del
Joerg Heinicke wrote:
On 18.03.2008 08:15, Luca Morandini wrote:
Seriously: does it lament any Javascript error ?
I'm using latest Mozilla SeaMonkey. It does not show any error in the
Error Console. I have certain JavaScript functions disabled though:
- Move or resize existing windows
-
Remove dependency on CocoonSourceResolver from Servlet Service Framework
Key: COCOON-2176
URL: https://issues.apache.org/jira/browse/COCOON-2176
Project: Cocoon
Issue
class from
cocoon-core. CocoonSourceResolver class is used to resolve paths in
context-path using custom source implementation, see ServletFactoryBean class
for details.
The SSF is meant to be Cocoon-independent subproject so this dependency must
be removed as soon as possible.
was:
The Servlet
'org.apache.excalibur.source.SourceResolver' is defined
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:378)
[...]
Remove dependency on CocoonSourceResolver from Servlet Service Framework
On 13.03.2008 16:20, Luca Morandini wrote:
This means that Forms must depend on Ajax (Dojo to be more precise)
despite the fact you use Ajax or not.
This is not quite true I think. Forms used to have two different
stylesheets: forms-field-styling.xsl and
forms-advanced-field-styling.xsl.
I must admit I am a bit uneasy about this dependency, which adds
considerably to the JAR-tonnage of Cocoon even when the user is not
interested in Ajax forms.
Is this inevitable or there is a way to disentangle the two blocks ?
As far as I understand one has to change forms-field-styling.xsl
Luca Morandini pisze:
I must admit I am a bit uneasy about this dependency, which adds
considerably to the JAR-tonnage of Cocoon even when the user is not
interested in Ajax forms.
Is this inevitable or there is a way to disentangle the two blocks ?
As far as I understand one has
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
Dojo is used to only handle Ajax mode of Forms but to handle advanced field
styling of Forms widgets
as well that has nothing to do with Ajax.
Yes, I've looked into the code and discovered that ;)
This means that Forms must depend on Ajax
HTML forms conditional? It
would only require
tweaking existing templates.
This would not remove dependency on ajax block in Forms block but at least you
would get clean
web-pages.
Why I'm making such a plea ?
Well, the use of non-Javascript forms is a requirement for making
websites
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
I presume that a way to disentangle forms and ajax blocks would be to
make two different forms-field-styling.xsl (one with Javascript and/or
Ajax, the other without Javascript), loaded conditionally on ajax=true
by forms-samples-styling.xsl.
Luca Morandini pisze:
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
I presume that a way to disentangle forms and ajax blocks would be to
make two different forms-field-styling.xsl (one with Javascript and/or
Ajax, the other without Javascript), loaded conditionally on ajax=true
by
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
Come to think of it, there should be three modes, not teo: ajax,
javascript, no-javascript.
Hence, ajax='true' should be changed too, maybe to
client='static|dynamic|ajax'... hmm... the matter is getting hairy.
Ah, right. Not sure what's the
Luca Morandini pisze:
Well, you can use hidden DIVs, to be displayed when an on hover event
is triggered.
Off the top of my head:
...
style type=text/css
.errmsg div {
display:none;
}
.errmsg:hover div {
display:block;
position:absolute;
Grzegorz Kossakowski wrote:
Luca Morandini pisze:
Well, you can use hidden DIVs, to be displayed when an on hover event
is triggered.
...
Ah, right. Is this technique considered as accessible?
Yep: it doesn't use Javascript and it dosn't break the linearity of the
page.
Regards,
Kossakowski
Not a blocker for 2.2 final release.
I managed to make jDBI 2.0.2 work with Cocoon 2.2 locally for my own
application needs so this issue is still in scope of my interests. I will apply
all needed fixes to trunk as soon as I have some spare time.
Upgrade Forms samples' dependency
Ralph Goers wrote:
Reinhard Poetz wrote:
Ralph Goers wrote:
Is the cocoon build really trying to rely on transitive dependency
verions? Very bad idea. Versions of every dependency cocoon uses
directly or indirectly should be specified in the managedDependencies.
The problem
Cocoon 2.1 will stay around for a while so same here!
Jeroen
Antonio Gallardo wrote:
Bertrand Delacretaz escribió:
Agree with Ralph, there's no need to close anything, if people want
to fix bugs on older versions that's one of the beauties of open
source: no one forces you to upgrade, as long
On Nov 17, 2007 9:49 AM, Ralph Goers [EMAIL PROTECTED] wrote:
...If someone finds a bug and wants to fix it and do a release of 2.1.x
they should be free to do so
Grzegorz Kossakowski wrote:
...After 2.1.11 I would like to close 2.1.x branch completely
Agree with Ralph, there's no
Carsten Ziegeler wrote:
If I get enough positive feedback about the current state I'm happy to
prepare a release of 2.1.11 in December.
the lenya community would appreciate that a lot! i'm collecting some
cocoon-specific user feedback on our lists atm. there have been no
problem reports
Hi Cocoon devs
Am 15.11.2007 um 15:41 schrieb Carsten Ziegeler:
We have no real plans or another 2.1.x release, although we talked
briefly about it over the last year several times. I think it makes
sense to do a 2.1.11 release as a maintenance release, especially if
Lenya wants to use this
Bertrand Delacretaz escribió:
Agree with Ralph, there's no need to close anything, if people want
to fix bugs on older versions that's one of the beauties of open
source: no one forces you to upgrade, as long as you're ready to fix
what you're using if needed.
+1
Best Regards,
Antonio
Antonio Gallardo wrote:
Bertrand Delacretaz escribió:
Agree with Ralph, there's no need to close anything, if people want
to fix bugs on older versions that's one of the beauties of open
source: no one forces you to upgrade, as long as you're ready to fix
what you're using if needed.
+1
Bertrand Delacretaz pisze:
On Nov 17, 2007 9:49 AM, Ralph Goers [EMAIL PROTECTED] wrote:
...If someone finds a bug and wants to fix it and do a release of 2.1.x
they should be free to do so
Grzegorz Kossakowski wrote:
Agree with Ralph, there's no need to close anything, if people want
If you fix a bug in 2.1 it should obviously go to trunk. 2.1.11 has not
been released so if you know of a bug that applies to 2.1.x that is
fixed in trunk, IMO it should also be applied to 2.1.x. I would
recommend that this policy be followed until 2.2.0 is released. Past
that I would suggest
On Thu, 2007-11-15 at 09:41 -0500, Carsten Ziegeler wrote:
If I get enough positive feedback about the current state I'm happy to
prepare a release of 2.1.11 in December.
WDYT?
Carsten
+1
Cheers, Alfred.
On 19.11.2007 17:54 Uhr, Alfred Nathaniel wrote:
If I get enough positive feedback about the current state I'm happy to
prepare a release of 2.1.11 in December.
+1 I'd like to have a final 2.1 release as well.
Joerg
Fine by me. I finally have the fix for XMLFileModule that I will be
checking in and it would be nice to get that in a release.
Ralph
Carsten Ziegeler wrote:
We have no real plans or another 2.1.x release, although we talked
briefly about it over the last year several times. I think it
If someone finds a bug and wants to fix it and do a release of 2.1.x
they should be free to do so. Once 2.2 is released and has all the
parts working I doubt anyone will though.
Grzegorz Kossakowski wrote:
Thanks for offer Carsten, I will help with testing (based only on samples,
though).
On Nov 15, 2007 9:41 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote:
...I think it makes
sense to do a 2.1.11 release as a maintenance release, especially if
Lenya wants to use this version. However, the only problem I see right
now is the question of the qualitify. Which means, how many people
or SVN-Version 595020
dependency.
The most desirable way for us would be to ship lenya with a 2.1.11
dependency. Reading the cocoon dev list, I'm very much aware, that
you're working on a 2.2 release. Do you plan to release 2.1.11 as well
in the near future?
Thanks a lot
Grzegorz Kossakowski wrote:
Florian, I completely forgot about this. Since your report looks to be
perfect (screenshots, sample
files etc.) it should be really appreciated by fixing it.
I won't make any promises but since it also affects 2.2 and there is about a
month left to
planned(?)
declaring either a 2.1.10 or SVN-Version 595020
dependency.
The most desirable way for us would be to ship lenya with a 2.1.11
dependency. Reading the cocoon dev list, I'm very much aware, that
you're working on a 2.2 release. Do you plan to release 2.1.11 as well
in the near future?
Thanks
Bertrand Delacretaz wrote:
If Lenya is using it successfully, and if our automated tests pass (I
can run them on Linux and MacOSX when the time comes) I'd be ok with
making a release. There have been some small changes since 2.1.10, and
little is happening in the 2.1 branch, so it might be
Dev at weitling pisze:
Bertrand Delacretaz wrote:
If Lenya is using it successfully, and if our automated tests pass (I
can run them on Linux and MacOSX when the time comes) I'd be ok with
making a release. There have been some small changes since 2.1.10, and
little is happening in the 2.1
dependency.
The most desirable way for us would be to ship lenya with a 2.1.11
dependency. Reading the cocoon dev list, I'm very much aware, that
you're working on a 2.2 release. Do you plan to release 2.1.11 as well
in the near future?
Thanks a lot for an orientation about the topic
block/cocoon-core-sample/cocoon-core-main-sample is by default enabled
to be built. The problem is it depends on cocoon-xsp-impl which is only
build with -Dallblocks.
Can I make xsp-impl to be built every time?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at
Leszek Gawron pisze:
block/cocoon-core-sample/cocoon-core-main-sample is by default enabled
to be built. The problem is it depends on cocoon-xsp-impl which is only
build with -Dallblocks.
Leszek, this dependency is almost redundant because thanks to Unico's commit[1]
most of the stuff
has
Remove dependency on cocoon-pipeline-impl in cocoon-expression-language-impl
Key: COCOON-2125
URL: https://issues.apache.org/jira/browse/COCOON-2125
Project: Cocoon
[
https://issues.apache.org/jira/browse/COCOON-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski closed COCOON-2125.
Resolution: Fixed
Also removed dependency on cocoon-pipeline-impl module. From
Upgrade Forms samples' dependency on jDBI to 2.0.x version
--
Key: COCOON-2087
URL: https://issues.apache.org/jira/browse/COCOON-2087
Project: Cocoon
Issue Type: Task
Jorg Heymans napisał(a):
http://jira.codehaus.org/browse/MECLIPSE-262 seems to be somewhat
similar to our problem, I've added our findings there.
Thanks Jorg.
For now i've excluded commons-logging explicitly from commons-jxpath, it
is brought in by several other blocks anyway.
I'm puzzled
Grzegorz Kossakowski wrote:
For now i've excluded commons-logging explicitly from commons-jxpath, it
is brought in by several other blocks anyway.
I'm puzzled now a little. Do we have some exclusion guidelines? Previously, I
thought we had to exclude only
avalon-framework but you excluded
[
https://issues.apache.org/jira/browse/COCOON-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jorg Heymans closed COCOON-2029.
Resolution: Fixed
fixed, thanks for reporting.
Missing dependency in cocoon-databases-impl
Grzegorz Kossakowski wrote:
I also tried dependency plug-in already and had the same results as you.
It does not mention dependency we are talking about. I have no idea why.
However, I'm almost sure. Try mvn eclipse:eclipse and import project.
You'll see avalon-framework-4.1.3.jar in build
Jorg Heymans wrote:
It seems that the eclipse plugin is using some different (buggy)
dependency resolution mechanism. Don't have time now to investigate
further, will have another look later (perhaps its a confirmed bug in
the plugin?)
http://jira.codehaus.org/browse/MECLIPSE-262 seems
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
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
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
Missing dependency in cocoon-databases-impl?
Key: COCOON-2029
URL: https://issues.apache.org/jira/browse/COCOON-2029
Project: Cocoon
Issue Type: Bug
Components: Blocks: Databases
Ralph Goers wrote:
We should consider leveraging the new feature that I finally got
committed into Maven - real dependency management. With the change any
version you specify in a dependencyManagement section will override
versions specified in transitive dependencies as well as being
1 - 100 of 228 matches
Mail list logo
