Reinhard Poetz wrote:
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency handling, thus only relevant for the deployer?
In that case if we have something like
<dependency>
<artifactId>myBlock</artifactId>
<groupId>org.apache.cocoon.blocks</groupId>
<version>1.2alpha</version>
</dependency>
then the deployer could check for all declared dependencies with
groupId "org.apache.cocoon.blocks" and treat them as "block"
dependencies. There are other ways to distinguish between
dependencies in maven, but this would be the easiest initially i think.
dependencies we can add it later. There would be a need to give the
dependencies POM unique ids that can be used in the block protocol and
not sure on how to best solve this, i'll give it some thought.
Today, Jorg and I had a long chat about this. In short, we failed to
find a solution that works with Maven 2 as it is today. The problem is
that Cocoon block requirements have a different purpose than Maven 2
dependencies. Cocoon block requirements desribe what a block needs to
run while Maven 2 dependencies describe what a project needs to compile.
Can't you use <scope>runtime</scope>?
Additionally we want to describe our dependencies as contracts and not
as direct dependencies to a JAR.
Yes and no ;) My idea was to start simple with only jar dependencies
which solves our current needs and is simple. Then we could add indirect
dependencies later when we need it.
In our opinion there are two possible options:
A) We talk with the Maven guys whether there is some way to add our
Cocoon
specific information to a dependency description.
B) We use block.xml.
I'm in favour of B) as
- we don't bend Maven to something which it wasn't created for
- we shouldn't force everybody to use Maven just as we are so
exited about it
- it doesn't tie Cocoon unnecessarily to Maven
Simplicity vs flexibillity ;)
Anyway, the important thing is to get something that works ASAP, and the
block code is designed for B) and you seem to think that it is easier
with M2, so go ahead with B). We can impove usabillity with various
"conventions" at a later stage.
Of course we can provide a Maven goal that checks if block.xml and
pom.xml describe the same dependencies.
Maybe some of you guys find some time to talk about this with the
Maven folks at the ApacheCon. Maybe they see a simple solution for our
problem.
There have been a long discussion on Felix-dev about how to use M2
(which is jar based) with OSGi (which is contract based, although at the
package level) in the best way. Both people from Maven and Eclipse have
been involved. We can use what they come up with later, and I will try
to discuss the problem with them at ApacheCon.
/Daniel
