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 fo
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 mi
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 ev
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 XSL:FO
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 choo
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 concret
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 doe
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-dev&m=113102875010469&w=2).
/my-block
pom.xml
/api
pom.xml
/impl
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 impl
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-dev&m=113102875010469&w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
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
|
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
| +-- MyJavaflowControlle
Reinhard Poetz wrote:
We also discussed the structure of projects as proposed by Jorg some
time ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113102875010469&w=2).
/my-block
pom.xml
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
The (usual)
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
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
can't
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 in
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. Maven
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 des
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 blo
>>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, S&N AG
http://www.s-und-n.de
http://www.osoco.org/webl
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
>>> Ecl
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:
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,
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 u
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 s
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 ha
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
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
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
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:
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 PO
Jorg Heymans wrote:
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
+-
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|
+-
Reinhard Poetz wrote:
- o -
+---+
| Build and deployment from a Cocoon user's POV|
+---+
ROOT
+-- blo
IIUC Daniel did some great work so that we get feature complete for Cocoon 2.2.
The last missing pice is a proper build and deployment system for the things
called block.
Last days I had some time to look into Maven2 and I have to say that
I'm impressed. They finally overcome the limitations
35 matches
Mail list logo