Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as
optional dependencies. This
Reinhard Poetz schrieb:
That's one of the differnces between block requirements and Maven2
dependencies. Maven2 dependencies are concrete implementations and
block requirement always point to a contract which have to be
implemented by a block.
What we _could_ do is having real artifacts
Jörg Schaible wrote:
But how would it be possible to say that the samples block depends on
any implementation which implements a certain API, like the roles
are used in Cocoon today? For example, my-block-samples-block needs
an XSL:FO processor but does not depend on a concrete
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as optional
dependencies. This might not be the possible in every case.
Think about
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as optional
dependencies. This might not be the possible in every case.
Think about choosing some commercial
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Ah, very insightful!
This would be a good start.
But with this interim solutions we have to be aware of the fact, that
the block has to define all potential XSL:FO implementations as
optional dependencies. This might not be the possible in
Jorg Heymans wrote:
Andreas Hochsteger wrote:
But how would it be possible to say that the samples block depends on
any implementation which implements a certain API, like the roles
are used in Cocoon today? For example, my-block-samples-block needs
an XSL:FO processor but does not
Jorg Heymans schrieb:
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
Andreas Hochsteger wrote:
But how would it be possible to say that the samples block depends on
any implementation which implements a certain API, like the roles
are used in Cocoon today? For example, my-block-samples-block needs
an XSL:FO processor but does not depend on a concrete
Andreas Hochsteger wrote:
Jorg Heymans schrieb:
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2).
/my-block
pom.xml
/api
pom.xml
/impl
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
After working on the deployer and learning more about the Maven2
internals, I want to share 2 thougths:
I've already raised the question whether it is possible to merge
block.xml and pom.xml. For now it's not as dependencies in pom.xml
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +-- MyJavaflowController.class
+-- app
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102875010469w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
The (usual)
Reinhard Poetz skrev:
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
| +--
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Reinhard Poetz wrote:
A second thought: As outlined in one of my previous mails, a Cocoon
block will become a valid jar file, for example with following content:
ROOT
+-- block.xml
+-- pom.xml
+-- sitemap.xmap
+-- org
| +--myProject
After working on the deployer and learning more about the Maven2 internals, I
want to share 2 thougths:
I've already raised the question whether it is possible to merge block.xml and
pom.xml. For now it's not as dependencies in pom.xml can't carry all the
necessary information for us.
Reinhard Poetz skrev:
After working on the deployer and learning more about the Maven2
internals, I want to share 2 thougths:
I've already raised the question whether it is possible to merge
block.xml and pom.xml. For now it's not as dependencies in pom.xml can't
carry all the necessary
Reinhard Poetz wrote:
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
Marc Portier wrote:
Reinhard Poetz wrote:
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
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
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
Daniel Fagerstrom wrote:
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
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
What do you think about moving block dependecy handling from block.xml
to pom.xml? It means reduced flexibilty as block dependencies becomes
direct instead of indirect as in the current schema. OTH it reduce
complexity and fullfills our current
Daniel Fagerstrom wrote:
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
Jorg Heymans wrote:
Daniel Fagerstrom wrote:
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
Daniel Fagerstrom wrote:
Jorg Heymans wrote:
Daniel Fagerstrom wrote:
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
I'm far over the stage of remote interest, I can't wait until we have
switched completely to M2. And Carsten might be interested in discussing
Maven as well ;)
Yupp, definitly :)
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
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
Daniel Fagerstrom wrote:
What do you think about moving block dependecy handling from block.xml
to pom.xml? It means reduced flexibilty as block dependencies becomes
direct instead of indirect as in the current schema. OTH it reduce
complexity and fullfills our current use cases. If we need
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
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
+---+
ROOT
+--
Great guys, let us go back to work again :)
Jorg Heymans wrote:
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
Jorg Heymans wrote:
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
Daniel Fagerstrom wrote:
Great guys, let us go back to work again :)
yep :-)
Jorg Heymans wrote:
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's
34 matches
Mail list logo
