[...]
Then, can somebody add to cocoon-webapp/pom.xml:
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-core-additional-sample/artifactId
version1.0.0-SNAPSHOT/version
/dependency
thx,
—ml—
Mark Lundquist wrote:
I don't get it, why is keeping cocoon-dist-samples working so much
harder than making samples work in cocoon-webapp?
The dist module requires the latest version of the maven release plugin
(I think it is the release plugin, but I might be wrong). So as long as
this
Carsten Ziegeler wrote:
Mark Lundquist wrote:
I don't get it, why is keeping cocoon-dist-samples working so much
harder than making samples work in cocoon-webapp?
The dist module requires the latest version of the maven release plugin
(I think it is the release plugin, but I might be wrong).
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Mark Lundquist wrote:
I don't get it, why is keeping cocoon-dist-samples working so much
harder than making samples work in cocoon-webapp?
The dist module requires the latest version of the maven release plugin
(I think it is the release
I don't say that it is much harder to keep cocoon-dist-samples working
than making cocoon-webapp working. I just say that I lack the motivation.
The reason for that is that cocoon-webapp is a good example for seeing
what a development environment for Cocoon 2.2 looks like with Maven poms
and
On Jan 2, 2007, at 10:55 AM, Daniel Fagerstrom wrote:
What IMO would be cool, would be to blockify the samples. If we do
that the sample app would only be a POM that would download all the
needed blocks and create a webapp from them with the deployer. That
would illustrate what Cocoon 2.2 is
