You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/05/23 17:55:43 UTC
Custom Cocoon 2.2 projects: Alternatives to Maven 2
Joerg Heinicke wrote:
> On 22.05.2007 13:55, Reinhard Poetz wrote:
>
>> Compared with JSF and Struts Cocoon is very different. This means that
>> you have to learn to think in Cocoon (btw, the same is true for
>> frameworks like Tapestry or Wicket). Without good documentation it is
>> very difficult to learn this way of thinking and hence my reasoning
>> that we need better docs.
>
> The annoying in the original post [1] is that the main reason for his
> frustration seems to be Maven and not necessarily Cocoon itself.
yes, Maven 2 is IMHO an even more complex beast than Cocoon (and I mean 2.1
here!). Since I've been involved in two big projects (Cocoon 2.2 and one
commercial project) that migrated to Maven 2, I've learnt to appreciate the
power of Maven 2 but I remember how difficult it was to learn how Maven 2 works
and how to solve real-world problems.
How can we help our upcoming 2.2 users? IMO there are two approaches which
should be followed in parallel:
1) make the usage of Maven 2 as simple as possible
- the tutorials take this into account
- we provide different archetypes
2) offer an alternative to Maven 2
Option one is clear and is nearly finsihed. My question is regarding to option
2: What do you expect, when you download Cocoon 2.2 in order to get your new
Cocoon 2.2 project started?
Keep in mind that Cocoon 2.2 is split into a core and several blocks (template,
forms, etc.). All of them are separate release artifacts and in contrast to
Cocoon 2.1 they can and will be shipped as binaries again. (Note that I'm not
talking about samples, that's something different.)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> I don't want to say that we should focus on this non-Maven Cocoon 2.2
> archetyp - at least I won't and probably won't do much more than the
> prototyp already does - but providing alternatives to our ours is a good
> thing IMO.
As long as we state in docs that this way of building applications is
not that actively tracked and maintained as maven there is no harm in
showing users the alternative.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Hello,
>
> Reinhard Poetz wrote:
>>
>> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It
>> should be useful to people that want to avoid Maven 2 as build system
>> for their Cocoon based projects. The mail below, that I sent to the
>> users list, explains in more detail how this prototyp is supposed to
>> work.
>>
>> Feedback would be much appreciated.
>
> My first question is: why would people want to avoid maven as a build
> system if they get from us everything on the plate?: standard structure,
> archetypes. You do not have to know maven at all and be able to run
> cocoon app in under 10 minutes.
I agree with you but there are people with different opinions that I can
understand to some point.
> Once cocoon libs (especially plugins and archetypes) are uploaded on
> public maven repo where is no easier way to start.
right, but see above
> Custom build will always get outdated some time which will bring confusion.
Agreed, maintaining a non-Maven based build is more difficult but the difference
is that this build system was invented and developed by the developer himself
and updating libraries can be done in the same way as usual. He doesn't have to
learn something new. He also knows how to do all the other things like
releasing, adding e.g. source generation tools, etc.
Additionally there are tools like Ivy or the Maven Ant tasks which can make your
life a lot easier.
I don't want to say that we should focus on this non-Maven Cocoon 2.2 archetyp -
at least I won't and probably won't do much more than the prototyp already does
- but providing alternatives to our ours is a good thing IMO.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Hello,
Reinhard Poetz wrote:
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It
> should be useful to people that want to avoid Maven 2 as build system
> for their Cocoon based projects. The mail below, that I sent to the
> users list, explains in more detail how this prototyp is supposed to work.
>
> Feedback would be much appreciated.
My first question is: why would people want to avoid maven as a build
system if they get from us everything on the plate?: standard structure,
archetypes. You do not have to know maven at all and be able to run
cocoon app in under 10 minutes.
Once cocoon libs (especially plugins and archetypes) are uploaded on
public maven repo where is no easier way to start.
Custom build will always get outdated some time which will bring confusion.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It should be
useful to people that want to avoid Maven 2 as build system for their Cocoon
based projects. The mail below, that I sent to the users list, explains in more
detail how this prototyp is supposed to work.
Feedback would be much appreciated.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> If someone can document the steps (which we should do anyway) I can
>> try and come up with the ant script.
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You
> can download it from
> http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
>
> It contains a build.xml that has two targets:
>
> - webapp
> Build a web application
> - run
> Starts the webapp using Jetty
>
> Some words to the directory structure:
>
> [root]
> +-src
> | +-webapp The Cocoon web application
> | +-block1 A Cocoon demo block
> +-lib All required libraries and Cocoon blocks
> +-jetty Minimum files to run a Jetty 6.1.3 instance
> +-build.xml The Ant build script
>
> The Ant build is only a starting point but it shows how things are
> supposed to work together. It works well for me but it misses two
> important things in order to be useful for others:
>
> 1) make it simple to add just another _own_ block
> (adding a third-party block only means copying the libs into ./lib)
>
> 2) create a properties file that configures all servlet services to use the
> src/block1/src/main/resources/COB-INF files as block contexts
>
> Having this feature allows working on the sources with support for
> hot reload.
>
> I think the build script shouldn't do much more because if people prefer
> to use Ant, they have their own way of building/deploying their Java
> applications anyway. Using this build script as template for that
> purpose, should give them a enough ideas to integrate it into their own
> build and deployment architectures.
>
> WDYT? Feedback, not only from Carsten, is much appreciated!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. It should be
useful to people that want to avoid Maven 2 as build system for their Cocoon
based projects. The mail below that I sent to the users lists explains in more
detail how this prototyp is supposed to work.
Feedback would be much appreciated.
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> If someone can document the steps (which we should do anyway) I can
>> try and come up with the ant script.
>
> I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You
> can download it from
> http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
>
> It contains a build.xml that has two targets:
>
> - webapp
> Build a web application
> - run
> Starts the webapp using Jetty
>
> Some words to the directory structure:
>
> [root]
> +-src
> | +-webapp The Cocoon web application
> | +-block1 A Cocoon demo block
> +-lib All required libraries and Cocoon blocks
> +-jetty Minimum files to run a Jetty 6.1.3 instance
> +-build.xml The Ant build script
>
> The Ant build is only a starting point but it shows how things are
> supposed to work together. It works well for me but it misses two
> important things in order to be useful for others:
>
> 1) make it simple to add just another _own_ block
> (adding a third-party block only means copying the libs into ./lib)
>
> 2) create a properties file that configures all servlet services to use the
> src/block1/src/main/resources/COB-INF files as block contexts
>
> Having this feature allows working on the sources with support for
> hot reload.
>
> I think the build script shouldn't do much more because if people prefer
> to use Ant, they have their own way of building/deploying their Java
> applications anyway. Using this build script as template for that
> purpose, should give them a enough ideas to integrate it into their own
> build and deployment architectures.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> If someone can document the steps (which we should do anyway) I can try
> and come up with the ant script.
I've started with a prototyp of a non-Maven Cocoon 2.2 archetype. You can
download it from http://people.apache.org/~reinhard/cocoon-22-bootstrap.zip.
It contains a build.xml that has two targets:
- webapp
Build a web application
- run
Starts the webapp using Jetty
Some words to the directory structure:
[root]
+-src
| +-webapp The Cocoon web application
| +-block1 A Cocoon demo block
+-lib All required libraries and Cocoon blocks
+-jetty Minimum files to run a Jetty 6.1.3 instance
+-build.xml The Ant build script
The Ant build is only a starting point but it shows how things are supposed to
work together. It works well for me but it misses two important things in order
to be useful for others:
1) make it simple to add just another _own_ block
(adding a third-party block only means copying the libs into ./lib)
2) create a properties file that configures all servlet services to use the
src/block1/src/main/resources/COB-INF files as block contexts
Having this feature allows working on the sources with support for
hot reload.
I think the build script shouldn't do much more because if people prefer to use
Ant, they have their own way of building/deploying their Java applications
anyway. Using this build script as template for that purpose, should give them a
enough ideas to integrate it into their own build and deployment architectures.
WDYT? Feedback, not only from Carsten, is much appreciated!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz schrieb:
>> What about creating a zip containing the result of the cocoon
>> archetype run? People could use this as a starting point for own
>> projects without maven.
>
> I guess that you mean the result in ./target/webapp which is created by
> "mvn install", don't you?
>
Ah, yes, you're right. Yepp.
>> Adding blocks should then just be adding the jar which is available
>> for download.
>
> yep
>
>> The final step would be a document how to build your own block without
>> maven, perhaps someone could come up with an ant script doing this stuff.
>
> good idea, shouldn't be that difficult.
>
If someone can document the steps (which we should do anyway) I can try
and come up with the ant script.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> How can we help our upcoming 2.2 users? IMO there are two approaches
>> which should be followed in parallel:
>>
>> 1) make the usage of Maven 2 as simple as possible
>> - the tutorials take this into account
>> - we provide different archetypes
>>
>> 2) offer an alternative to Maven 2
>>
>> Option one is clear and is nearly finsihed. My question is regarding
>> to option 2: What do you expect, when you download Cocoon 2.2 in order
>> to get your new Cocoon 2.2 project started?
>>
>> Keep in mind that Cocoon 2.2 is split into a core and several blocks
>> (template, forms, etc.). All of them are separate release artifacts
>> and in contrast to Cocoon 2.1 they can and will be shipped as binaries
>> again. (Note that I'm not talking about samples, that's something
>> different.)
>>
> Just some unstructured thoughts:
>
> What about creating a zip containing the result of the cocoon archetype
> run? People could use this as a starting point for own projects without
> maven.
I guess that you mean the result in ./target/webapp which is created by "mvn
install", don't you?
> Adding blocks should then just be adding the jar which is
> available for download.
yep
> The final step would be a document how to build your own block without
> maven, perhaps someone could come up with an ant script doing this stuff.
good idea, shouldn't be that difficult.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> Joerg Heinicke wrote:
>> On 22.05.2007 13:55, Reinhard Poetz wrote:
>>
>>> Compared with JSF and Struts Cocoon is very different. This means
>>> that you have to learn to think in Cocoon (btw, the same is true for
>>> frameworks like Tapestry or Wicket). Without good documentation it is
>>> very difficult to learn this way of thinking and hence my reasoning
>>> that we need better docs.
>>
>> The annoying in the original post [1] is that the main reason for his
>> frustration seems to be Maven and not necessarily Cocoon itself.
>
> yes, Maven 2 is IMHO an even more complex beast than Cocoon (and I mean
> 2.1 here!). Since I've been involved in two big projects (Cocoon 2.2 and
> one commercial project) that migrated to Maven 2, I've learnt to
> appreciate the power of Maven 2 but I remember how difficult it was to
> learn how Maven 2 works and how to solve real-world problems.
>
> How can we help our upcoming 2.2 users? IMO there are two approaches
> which should be followed in parallel:
>
> 1) make the usage of Maven 2 as simple as possible
> - the tutorials take this into account
> - we provide different archetypes
>
> 2) offer an alternative to Maven 2
>
> Option one is clear and is nearly finsihed. My question is regarding to
> option 2: What do you expect, when you download Cocoon 2.2 in order to
> get your new Cocoon 2.2 project started?
>
> Keep in mind that Cocoon 2.2 is split into a core and several blocks
> (template, forms, etc.). All of them are separate release artifacts and
> in contrast to Cocoon 2.1 they can and will be shipped as binaries
> again. (Note that I'm not talking about samples, that's something
> different.)
>
Just some unstructured thoughts:
What about creating a zip containing the result of the cocoon archetype
run? People could use this as a starting point for own projects without
maven. Adding blocks should then just be adding the jar which is
available for download.
The final step would be a document how to build your own block without
maven, perhaps someone could come up with an ant script doing this stuff.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Reinhard Haller schrieb:
>>
>>> Is there a design decision to use maven as a base or not? If so then
>>> go ahead and use it. If you want to get a new design decision, wait
>>> until the next version is in the design phase.
>>>
>> The decision was to use maven for developing cocoon itself and to not
>> require maven for cocoon based projects.
>>
> Maybe, but I'd push Cocoon 2.2 out the door before worrying about this.
> It's been in the oven long enough.
>
Oh, yes - definitly; it is possible to use 2.2 without maven; you just
have to figure out how...when it's released we can update the docs and
give help.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> Reinhard Haller schrieb:
>
>> Is there a design decision to use maven as a base or not? If so then
>> go ahead and use it. If you want to get a new design decision, wait
>> until the next version is in the design phase.
>>
> The decision was to use maven for developing cocoon itself and to not
> require maven for cocoon based projects.
>
Maybe, but I'd push Cocoon 2.2 out the door before worrying about this.
It's been in the oven long enough.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Haller schrieb:
> Is there a design decision to use maven as a base or not? If so then
> go ahead and use it. If you want to get a new design decision, wait
> until the next version is in the design phase.
>
The decision was to use maven for developing cocoon itself and to not
require maven for cocoon based projects.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Poetz <re...@apache.org>.
Martin Heiden wrote:
> What do you think of a web application that does it for the users? It
> could be a simple list of blocks and core components with description and
> a nice cocoon app that reads the actual poms and zips all important jars
> before deliviring them to the user.
The problem with this idea is that is is difficult to integrate this with your
build system. If you need Ant with dependency management, I'd have a look into Ivy.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Martin Heiden <ma...@netcologne.de>.
On Thu, May 24, 2007 8:07 am, Reinhard Haller wrote:
>
> sounds like we need a kind of installer to hide the complexity of maven
> from the user. This way we reduce complexity without adding options with
> the need of further support.
>
I switched to use maven for all my projects after evaluating cocoon 2.2.
It was a steep learning curve, but it was definitly worth doing it.
Please correct me if I'm wrong, but with cocoon 2.2 the only thing one
needs, to write custom applications, are jars from core and used blocks.
What maven does, is managing the dependencies for the user. If one opts
for not using maven, he/she would have to manage this complex task on
his/her own. This is the point where help is needed.
What do you think of a web application that does it for the users? It
could be a simple list of blocks and core components with description and
a nice cocoon app that reads the actual poms and zips all important jars
before deliviring them to the user.
This could even be included as a sample app.
Martin.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Reinhard Haller <re...@interactive-net.de>.
Hi,
Carsten Ziegeler schrieb:
> Grzegorz Kossakowski wrote:
>> To sum up, if you really want to put effort into it could it be
>> assumed as only temporary solution that aims to make it easier to
>> migrate?
>>
> Hmm, no I don't think so :)
> Personally, I really love maven 2 and it works very well for a lot of
> our projects. It makes sense to use it for developing cocoon itself, but
> we should not force everyone who wants to do a cocoon project to use
> maven 2. This ain't gonna work.
sounds like we need a kind of installer to hide the complexity of maven
from the user. This way we reduce complexity without adding options with
the need of further support.
>
> You're right that we should not maintain all possible different ways,
> but we spend a lot of energy into 2.2 to make it independent from m2.
Is there a design decision to use maven as a base or not? If so then
go ahead and use it. If you want to get a new design decision, wait
until the next version is in the design phase.
Greetings
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
> Hmm, no I don't think so :)
> Personally, I really love maven 2 and it works very well for a lot of
> our projects. It makes sense to use it for developing cocoon itself, but
> we should not force everyone who wants to do a cocoon project to use
> maven 2. This ain't gonna work.
>
> You're right that we should not maintain all possible different ways,
> but we spend a lot of energy into 2.2 to make it independent from m2.
> For example that's the reason why we extract blocks at runtime through
> cocoon itself and not at build time. So if someone wants to use
> something different than m2, all he has to do is to create a block. A
> block is just a jar with a special format. We have to document this
> format anyway and that's all we have to do for other build systems.
> Nothing more but also nothing less.
> But as a proof that the docs are correct and our ideas work, we should
> just come up with one additional solution like an ant script. My idea is
> to put this script into the documentation and not into our svn. The
> script would act as a starting point.
Carsten, thanks for your clarification. Now I'm fine with the proposal and our current view on this issue.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>
>> 2) offer an alternative to Maven 2
>>
>> Option one is clear and is nearly finsihed. My question is regarding
>> to option 2: What do you expect, when you download Cocoon 2.2 in order
>> to get your new Cocoon 2.2 project started?
>>
>> Keep in mind that Cocoon 2.2 is split into a core and several blocks
>> (template, forms, etc.). All of them are separate release artifacts
>> and in contrast to Cocoon 2.1 they can and will be shipped as binaries
>> again. (Note that I'm not talking about samples, that's something
>> different.)
>
> To be honest I would not like to see option 2 implemented. I believe
> that diversity is important but we must also be aware of the costs that
> come along with more options.
> First, I really think that we should focus on the other things like
> documenting, testing, polishing and releasing stuff we already have.
> Of course, if someone wants to put his effort into developing Ant
> scripts I won't stop him, it's always better than not doing anything.
>
> The second argument is stronger in my opinion. Even though introducing
> more options is usually not so difficult, we must remember that it's our
> (as community) responsibility to maintain these more options for a long
> time.
> More options means that possible refactorings and serious changes are
> much more difficult to carry out and providing migration guides is also
> much more troublesome because you hardly can assume something about
> readers setup.
>
> I would not really like to see situation like I can't help someone on
> the list only because I don't want to dig through his very own
> Ant-driven setup.
>
> Now I really like situation with Cocoon 2.2 where I can say this: mate,
> use archetypes for your blocks and for assembling your webapp and if you
> encounter some problems/bugs just extract bits related to the problem
> and send us an ad-hoc created block showing the problem. Then, I can
> just write mvn cocoon:rcl and start helping this person being sure that
> we both talk about the same thing and problem.
> Sounds encouraging, doesn't it? :-)
>
> To sum up, if you really want to put effort into it could it be assumed
> as only temporary solution that aims to make it easier to migrate?
>
Hmm, no I don't think so :)
Personally, I really love maven 2 and it works very well for a lot of
our projects. It makes sense to use it for developing cocoon itself, but
we should not force everyone who wants to do a cocoon project to use
maven 2. This ain't gonna work.
You're right that we should not maintain all possible different ways,
but we spend a lot of energy into 2.2 to make it independent from m2.
For example that's the reason why we extract blocks at runtime through
cocoon itself and not at build time. So if someone wants to use
something different than m2, all he has to do is to create a block. A
block is just a jar with a special format. We have to document this
format anyway and that's all we have to do for other build systems.
Nothing more but also nothing less.
But as a proof that the docs are correct and our ideas work, we should
just come up with one additional solution like an ant script. My idea is
to put this script into the documentation and not into our svn. The
script would act as a starting point.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Custom Cocoon 2.2 projects: Alternatives to Maven 2
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> 2) offer an alternative to Maven 2
>
> Option one is clear and is nearly finsihed. My question is regarding to
> option 2: What do you expect, when you download Cocoon 2.2 in order to
> get your new Cocoon 2.2 project started?
>
> Keep in mind that Cocoon 2.2 is split into a core and several blocks
> (template, forms, etc.). All of them are separate release artifacts and
> in contrast to Cocoon 2.1 they can and will be shipped as binaries
> again. (Note that I'm not talking about samples, that's something
> different.)
To be honest I would not like to see option 2 implemented. I believe that diversity is important but we must also be aware of the costs that
come along with more options.
First, I really think that we should focus on the other things like documenting, testing, polishing and releasing stuff we already have.
Of course, if someone wants to put his effort into developing Ant scripts I won't stop him, it's always better than not doing anything.
The second argument is stronger in my opinion. Even though introducing more options is usually not so difficult, we must remember that it's
our (as community) responsibility to maintain these more options for a long time.
More options means that possible refactorings and serious changes are much more difficult to carry out and providing migration guides is
also much more troublesome because you hardly can assume something about readers setup.
I would not really like to see situation like I can't help someone on the list only because I don't want to dig through his very own
Ant-driven setup.
Now I really like situation with Cocoon 2.2 where I can say this: mate, use archetypes for your blocks and for assembling your webapp and if
you encounter some problems/bugs just extract bits related to the problem and send us an ad-hoc created block showing the problem. Then, I
can just write mvn cocoon:rcl and start helping this person being sure that we both talk about the same thing and problem.
Sounds encouraging, doesn't it? :-)
To sum up, if you really want to put effort into it could it be assumed as only temporary solution that aims to make it easier to migrate?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org