You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2006/09/29 11:53:19 UTC
Maven dictatorship and software parasitism (was Re: Maven info wanted)
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>> Reinhard Poetz wrote:
>>
>> <snip/>
>>
>>> We have invested a lot of time into making trunk build with M2. And
>>> don't forget that it's much more than just compiling the thing.
>>>
>>> We have two archetypes, one deployment plugin, the documentation which
>>> is exported using Maven, a working integration build, reports and
>>> certainly much more. Also don't forget that releasing a Cocoon
>>> artifact has become very simple. And one last point: If you build
>>> Cocoon using some different build system I think that we cannot
>>> forbear providing Maven 2 metadata files (pom.xml) because many
>>> developers will ask for them.
>>
>> I'd like to react on that last point: a POM is just XML. And if there's
>> a place where we know that XML is an interchange format, this is for
>> sure here in Cocoon-land. And we know there are plenty of solutions to
>> generate XML files in whatever format we want from whatever data source
>> we have.
>>
>> There is a good thing in Maven: the repository, where people can pick up
>> dependencies (well, when it works) rather than copying them in their own
>> source control repository. This is not good for a large in-house project
>> where you want to control and version everything, but a good way for OSS
>> projects to lighten their development process.
>
> I can't follow your argumentation here. What are you missing?
Sorry if this wasn't clear. I'm not missing anything, but in a large
consumer project you need to carefully know and control what's used to
build your software. Having artifacts downloaded from a remote public
server doesn't allow for repeatable and controlled builds. Even more
when the build/dependency management system itself self-updates from the
remote repository. So although a remote repository is really convenient
when you are developping (provided that the repository is available and
that automatic updates of the build system don't get your team stuck for
more that one day as happened to me), it's definitely not something good
when a repeatable and mastered build is needed.
>> Now the problem with Maven is that, because people are interested in
>> that good thing, they feel obliged to use the tool where that repository
>> and the associated file format was born. Why should that be a
>> requirement? Why couldn't the POM be used/created by other tools as
>> well?
>
> Who or what prevents you from doing so?
Absolutely nothing! And that's the whole point: people are using
Maven-the-Tool because of Maven-the-Repository. Granted, the repository
would not have existed without the tool (and the effort of all
repository maintainers). But although Maven-the-Repo alleviated some
pains and brought some new features, Maven-the-Tool brought new pains.
And since the repository is "just" data, there is room for other tools
to use and feed it.
I don't remember if alternatives existed when Cocoon's move to Maven
started and don't want to rewrite history nor Cocoon's build system if
people are happy with it, but the point is that there are alternatives now.
>> With its POM and repository, Maven managed to create an amazing
>> dictatorship on the entire OSS Java community. That buggy tool (because
>> yes, it is buggy) with no clear documentation is becoming a vital part
>> of many projects. So vital actually, that it has endangered and damaged
>> some of them.
>
> If you're refering to Cocoon as a victim damaged by Maven, I'm not
> sure that this conclusion is fair. As Daniel pointed out, I think that
> we did a lot to damage ourselves by having too many dependencies
> across our code base.
I disagree: this is not the main cause of damage. Although the current
effort is more than welcome, the golden days of Cocoon where when we had
myriads of dependencies and an XSL-generated Ant build file. There are
many concurring factors, both internal and external, that can explain
the project slowdown. A discussion for the Hackathon?
<snip/>
>> Converting an Ant build to an Ant+Ivy build merely means writing an
>> ivy.xml (or pom.xml) expressing the dependencies and changing the
>> <classpath> instructions so that they're build from the dependencies
>> artifacts that Ivy will download, rather than from e.g. "lib/*.jar". And
>> writing Ant tasks that mimic an artifact, deploy and release things are
>> not rocket science.
>
> no, it's not but all those tedious things have to be done and I want
> to warn you not to underestimate the work. I won't stop any of you to
> fix what *you* consider as broken but don't expect that I will get
> excited about rewritting many things (poms, archetypes, deployer,
> documentation) or mimicing feautres that Maven provides out of the box
> or via its plugins (many reports, releasing artifacts, etc.).
I'm not saying that Cocoon's build *should* be rewritten. Just that
Maven, because it's a kitchen-sink that is meant to provide everything
and even more actually turned into a dictatorship. Had it been flawless,
we could have lived with it. Now it isn't, and the dictatorship actually
sucked energy from the project.
Makes me think we can write a new chapter in the Software Darwinism
story: Software Parasitism, where in order to survive, a project needs
to "plug" into existing organisms and suck its vital substance out of
them. Some of the host organisms survive and can even take benefit of
the parasite (i.e. symbiosis), some suffer badly but survive, some die,
and some find ways to get rid of the parasite.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Sorry if this wasn't clear. I'm not missing anything, but in a large
> consumer project you need to carefully know and control what's used to
> build your software. Having artifacts downloaded from a remote public
> server doesn't allow for repeatable and controlled builds. Even more
> when the build/dependency management system itself self-updates from the
> remote repository. So although a remote repository is really convenient
> when you are developping (provided that the repository is available and
> that automatic updates of the build system don't get your team stuck for
> more that one day as happened to me), it's definitely not something good
> when a repeatable and mastered build is needed.
Using the public Maven repositories (Ibiblio) or one of it's mirrors is a
feature that most people use but IIUC not carved in stone. If you configure a
repository with the id 'central' and point to a server that is under your
control, you don't rely on the, given shaky, public mechanisms.
Another option is using a repository proxy. Since we introduced it, we don't
face any problems anymore because the person changing something fills the
repository automatically at the time when he is testing it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Maven dictatorship and software parasitism (was Re: Maven info wanted)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 29 Sep, 2006, at 11:53 , Sylvain Wallez wrote:
> Makes me think we can write a new chapter in the Software Darwinism
> story: Software Parasitism, where in order to survive, a project needs
> to "plug" into existing organisms and suck its vital substance out of
> them. Some of the host organisms survive and can even take benefit of
> the parasite (i.e. symbiosis), some suffer badly but survive, some
> die,
> and some find ways to get rid of the parasite.
ROTFLMAO ... maven == sucker ??? :-P
Pier
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Well, I will continue being the bad guy today...
>
> This is actually one of the areas where there are some similarities
> between Cocoon and Maven. Its developers know it by heart and know how
> to use it, what to use and what not to use. And they not always
> understand that people not actively developing the project aren't
> comfortable with its magic.
>
> Note that I'm not pointing fingers to anybody here, being myself a
> developer for Cocoon, but realizing this matter of fact by trying to be
> a Maven user!
>
And we actually experienced the aposite - the people doing the Cocoon
based projects had no knowledge of maven and where the average Cocoon
user! And they were quiet happy as some of them knew the pain of
building a cocoon based application using 2.1.x.
And it is interesting to see that people like e.g. RoR because of the
convention over configuration pattern while they seem to hate such
things in Java-land and call it "too much magic". :)
Seriously, I see your points - we all struggled with using Maven and had
severe problems in the past months; but if you use it today, there is no
real magic just convention and it works.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> We (and I know others as well) are using Cocoon 2.2 with Maven in
> development for several projects without any major problems. All the
> complicated build stuff is hidden, people just create a project with our
> web archetype and develop their stuff. Works perfectly. (And yes, we are
> using a company repository)
>
Well, I will continue being the bad guy today...
This is actually one of the areas where there are some similarities
between Cocoon and Maven. Its developers know it by heart and know how
to use it, what to use and what not to use. And they not always
understand that people not actively developing the project aren't
comfortable with its magic.
Note that I'm not pointing fingers to anybody here, being myself a
developer for Cocoon, but realizing this matter of fact by trying to be
a Maven user!
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
Bertrand Delacretaz wrote:
> On 9/29/06, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> ...(And yes, we are
>> using a company repository)...
>
> I'm still a Maven novice, but it sounds like this is a key point.
> Maybe setting up our own repository for Cocoon would help a lot.
We[1] volunteered the capacity for this, but this only puts a temporary
plaster on the real problem - which from my point of view seemed to be
that maven does not handle repository interaction gracefully (e.g. no
caching of available files, no error handling on timeouts, broken
partial downloads that then cause builds to fail).
[1] http://www.sourcesense.com/
Thanks,
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Bertrand Delacretaz wrote:
> On 9/29/06, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> ...(And yes, we are
>> using a company repository)...
>
> I'm still a Maven novice, but it sounds like this is a key point.
> Maybe setting up our own repository for Cocoon would help a lot.
>
We do this. It is absolutely critical as our Configuration Management
team needs to identify and control all the third party jars. With maven
1 they always use maven -o. If the build fails then we haven't told them
about a dependency that is required.
Re: Re: Maven dictatorship and software parasitism (was Re: Maven info wanted)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 9/29/06, Carsten Ziegeler <cz...@apache.org> wrote:
> ...(And yes, we are
> using a company repository)...
I'm still a Maven novice, but it sounds like this is a key point.
Maybe setting up our own repository for Cocoon would help a lot.
-Bertrand
Re: Roadmap for 2.2
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> yes, it's only documentation! Remember, we have already released M1
>>>> but haven't announced it yet because without docs it doesn't make
>>>> much sense.
>>>
>>> As long as Cocoon samples webapp is not complete
>>
>> What's missing?
>
> The complete and working webapp :) Have you seen it? Only couple of
> blocks are "in". The rest is never tried / tested.
>
>
>>> , nothing can be labeled as "released". You can say that M1 was only
>>> first step in the proof of concept for maven migration. Next step is
>>> to have complete and functional samples webapp, and yet next is to
>>> have Cocoon 2.2 downloadable deliverables,
>>
>> What do those deliverables contain?
>
> Source distribution, containing complete source code. *Ideally* it would
> contain all required libraries as well, but probably that's not possible
> with Maven.
It probably is.. have a look at assembly plugin.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Jorg Heymans wrote:
>>
>> On 02 Oct 2006, at 16:25, Vadim Gritsenko wrote:
>>
>>> As far as I can see, latest assembly plugin (2.2-SNAPSHOT) can not
>>> create assemblies from multi module projects. I tried:
>>>
>>> $ svn co
>>> svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/
>>> $ cd src/it/multimodule/two-level-multimodule
>>> $ mvn `cat goals.txt`
>>>
>>> Fails with:
>>>
>>> [ERROR] BUILD ERROR
>>> [INFO] Included module: test:child-level1-project2:pom:1.0-SNAPSHOT
>>> does not have an artifact with a file. Please ensure the package
>>> phase is run before the assembly is generated.
>>
>>
>> I flagged this with the maven peeps, it is being investigated. At
>> least maven's behaviour here is consistent with the rest of its features.
>
> Vadim and I already find out: You have to invoke the package phase
> before you run the assembly plugin and you have to make sure that it is
> run within the same build:
>
> mvn package assembly
Yes, that is what I used above. Contents of goals.txt is:
package assembly:directory
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
>
> On 02 Oct 2006, at 16:25, Vadim Gritsenko wrote:
>
>> As far as I can see, latest assembly plugin (2.2-SNAPSHOT) can not
>> create assemblies from multi module projects. I tried:
>>
>> $ svn co
>> svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/
>> $ cd src/it/multimodule/two-level-multimodule
>> $ mvn `cat goals.txt`
>>
>> Fails with:
>>
>> [ERROR] BUILD ERROR
>> [INFO] Included module: test:child-level1-project2:pom:1.0-SNAPSHOT
>> does not have an artifact with a file. Please ensure the package phase
>> is run before the assembly is generated.
>>
>
>
> I flagged this with the maven peeps, it is being investigated. At least
> maven's behaviour here is consistent with the rest of its features.
Vadim and I already find out: You have to invoke the package phase before you
run the assembly plugin and you have to make sure that it is run within the same
build:
mvn package assembly
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Roadmap for 2.2
Posted by Jorg Heymans <jh...@domek.be>.
On 02 Oct 2006, at 16:25, Vadim Gritsenko wrote:
> As far as I can see, latest assembly plugin (2.2-SNAPSHOT) can not
> create assemblies from multi module projects. I tried:
>
> $ svn co svn.apache.org/repos/asf/maven/plugins/trunk/maven-
> assembly-plugin/
> $ cd src/it/multimodule/two-level-multimodule
> $ mvn `cat goals.txt`
>
> Fails with:
>
> [ERROR] BUILD ERROR
> [INFO] Included module: test:child-level1-project2:pom:1.0-SNAPSHOT
> does not have an artifact with a file. Please ensure the package
> phase is run before the assembly is generated.
>
I flagged this with the maven peeps, it is being investigated. At
least maven's behaviour here is consistent with the rest of its
features.
Jorg
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> Vadim Gritsenko wrote:
>>>> Reinhard Poetz wrote:
>>>>> If you need the single file that contains everything, I recommend
>>>>> to you that you look at the assembly plugin.
<snip/>
As far as I can see, latest assembly plugin (2.2-SNAPSHOT) can not create
assemblies from multi module projects. I tried:
$ svn co svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/
$ cd src/it/multimodule/two-level-multimodule
$ mvn `cat goals.txt`
Fails with:
[ERROR] BUILD ERROR
[INFO] Included module: test:child-level1-project2:pom:1.0-SNAPSHOT does not
have an artifact with a file. Please ensure the package phase is run before the
assembly is generated.
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> If you need the single file that contains everything, I recommend to
>>>> you that you look at the assembly plugin.
>>>
>>> I don't need no assembly plugin, I can manage to do a trunk build.
>>> What about users? Forcing maven down everybody's throat is not a
>>> sound business plan. Who wants to use it, can use it. Who does not,
>>> should have a download.
>>
>> Any volunteers? What I want to avoid is that we stop to release
>> artifacts "the Maven way" just because we want to wait that somebody
>> takes care of the alternative all-in-one distribution. Hence no
>> objections from my side of course.
>
> May be I'll have some time on Hackaton. But since I barely can find my
> way around maven myself I can't guarantee I'll be able to finish this...
Just let me know then, how I can help you!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> If you need the single file that contains everything, I recommend to
>>> you that you look at the assembly plugin.
>>
>> I don't need no assembly plugin, I can manage to do a trunk build.
>> What about users? Forcing maven down everybody's throat is not a sound
>> business plan. Who wants to use it, can use it. Who does not, should
>> have a download.
>
> Any volunteers? What I want to avoid is that we stop to release
> artifacts "the Maven way" just because we want to wait that somebody
> takes care of the alternative all-in-one distribution. Hence no
> objections from my side of course.
May be I'll have some time on Hackaton. But since I barely can find my way
around maven myself I can't guarantee I'll be able to finish this...
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> If you need the single file that contains everything, I recommend to
>>> you that you look at the assembly plugin.
>>
>> I don't need no assembly plugin, I can manage to do a trunk build.
>> What about users? Forcing maven down everybody's throat is not a sound
>> business plan. Who wants to use it, can use it. Who does not, should
>> have a download.
>
> Any volunteers? What I want to avoid is that we stop to release
> artifacts "the Maven way" just because we want to wait that somebody
> takes care of the alternative all-in-one distribution. Hence no
> objections from my side of course.
What I wanted to say:
Hence no objections from my side of course if it's not blocking any releases to
public Maven repos.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> If you need the single file that contains everything, I recommend to
>> you that you look at the assembly plugin.
>
> I don't need no assembly plugin, I can manage to do a trunk build. What
> about users? Forcing maven down everybody's throat is not a sound
> business plan. Who wants to use it, can use it. Who does not, should
> have a download.
Any volunteers? What I want to avoid is that we stop to release artifacts "the
Maven way" just because we want to wait that somebody takes care of the
alternative all-in-one distribution. Hence no objections from my side of course.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> If you need the single file that contains everything, I recommend to you
> that you look at the assembly plugin.
I don't need no assembly plugin, I can manage to do a trunk build. What about
users? Forcing maven down everybody's throat is not a sound business plan. Who
wants to use it, can use it. Who does not, should have a download.
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> Vadim Gritsenko wrote:
>>> Reinhard Poetz wrote:
>>>> yes, it's only documentation! Remember, we have already released M1
>>>> but haven't announced it yet because without docs it doesn't make
>>>> much sense.
>>>
>>> As long as Cocoon samples webapp is not complete
>>
>> What's missing?
>
> The complete and working webapp :) Have you seen it? Only couple of
> blocks are "in". The rest is never tried / tested.
We shouldn't make it a requirement, that all samples of all blocks run. If you
want to release cforms, working cforms samples should be enough.
>>> , nothing can be labeled as "released". You can say that M1 was only
>>> first step in the proof of concept for maven migration. Next step is
>>> to have complete and functional samples webapp, and yet next is to
>>> have Cocoon 2.2 downloadable deliverables,
>>
>> What do those deliverables contain?
>
> Source distribution, containing complete source code. *Ideally* it would
> contain all required libraries as well, but probably that's not possible
> with Maven.
>
> Binary distribution, containing built Cocoon source code, with all
> blocks, samples webapp, jetty bundle, and 'cocoon.sh' script. Complete
> JavaDoc also can be part of it (or it could be part of documentation
> download).
>
> Documentation, containing contents of Cocoon 2.2 documentation web site
> (and probably JavaDoc too).
We should move away from seeing Cocoon as one huge application. That's the main
reason why we only make small steps.
If you need the single file that contains everything, I recommend to you that
you look at the assembly plugin.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> Vadim Gritsenko wrote:
>> Reinhard Poetz wrote:
>>> yes, it's only documentation! Remember, we have already released M1
>>> but haven't announced it yet because without docs it doesn't make
>>> much sense.
>>
>> As long as Cocoon samples webapp is not complete
>
> What's missing?
The complete and working webapp :) Have you seen it? Only couple of blocks are
"in". The rest is never tried / tested.
>> , nothing can be labeled as "released". You can say that M1 was only
>> first step in the proof of concept for maven migration. Next step is
>> to have complete and functional samples webapp, and yet next is to
>> have Cocoon 2.2 downloadable deliverables,
>
> What do those deliverables contain?
Source distribution, containing complete source code. *Ideally* it would contain
all required libraries as well, but probably that's not possible with Maven.
Binary distribution, containing built Cocoon source code, with all blocks,
samples webapp, jetty bundle, and 'cocoon.sh' script. Complete JavaDoc also can
be part of it (or it could be part of documentation download).
Documentation, containing contents of Cocoon 2.2 documentation web site (and
probably JavaDoc too).
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>> yes, it's only documentation! Remember, we have already released M1
>> but haven't announced it yet because without docs it doesn't make much
>> sense.
>
> As long as Cocoon samples webapp is not complete
What's missing?
> , nothing can be labeled
> as "released". You can say that M1 was only first step in the proof of
> concept for maven migration. Next step is to have complete and
> functional samples webapp, and yet next is to have Cocoon 2.2
> downloadable deliverables,
What do those deliverables contain?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Roadmap for 2.2
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Reinhard Poetz wrote:
> yes, it's only documentation! Remember, we have already released M1 but
> haven't announced it yet because without docs it doesn't make much sense.
As long as Cocoon samples webapp is not complete, nothing can be labeled as
"released". You can say that M1 was only first step in the proof of concept for
maven migration. Next step is to have complete and functional samples webapp,
and yet next is to have Cocoon 2.2 downloadable deliverables, and with the last
step being updated website.
One step is done. There are three more steps to go for the first 2.2 release.
Vadim
Re: Roadmap for 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> hepabolu wrote:
>> I agree, but does anyone know what is needed for this? I went as far
>> back as May 2005 but every topic on roadmaps and release plans for 2.2
>> get mixed up with discussions on related topics/ideas/opinions etc.
>>
>> I've seen the phrases "documentation is lacking" and "documentation is
>> lagging behind" several times, and would love to do something about it,
>> but I have no clue where to start and what to do.
>>
> I fear this is a common problem right now, and only a few of us (if
> any!) know what is left to do. From my pov there is a minor thing
> unfinished with processor/container handling which I want to discuss at
> the hackathon and then finish. Apart from that we should wait for the
> final release of Spring 2.0 which has some incompatible changes to RC we
> currently use. But Spring 2.0 will be released in 3 days, so that should
> be a problem.
>
> So the real remaining parts are documentation and samples, I guess.
yes, it's only documentation! Remember, we have already released M1 but haven't
announced it yet because without docs it doesn't make much sense.
hepabolu wrote:
> Maybe a few of us (Reinhard a.o.) should sit down at the hackathon and decide
> on the new documentation setup and present that to the rest for voting. At
the > very least we could write up a list of docs to provide.
At the Hackathon I will demonstrate the new Maven Daisy plugin and will show how
the new "Cocoon documentation" site within Daisy is supposed to work.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Roadmap for 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
hepabolu wrote:
> I agree, but does anyone know what is needed for this? I went as far
> back as May 2005 but every topic on roadmaps and release plans for 2.2
> get mixed up with discussions on related topics/ideas/opinions etc.
>
> I've seen the phrases "documentation is lacking" and "documentation is
> lagging behind" several times, and would love to do something about it,
> but I have no clue where to start and what to do.
>
I fear this is a common problem right now, and only a few of us (if
any!) know what is left to do. From my pov there is a minor thing
unfinished with processor/container handling which I want to discuss at
the hackathon and then finish. Apart from that we should wait for the
final release of Spring 2.0 which has some incompatible changes to RC we
currently use. But Spring 2.0 will be released in 3 days, so that should
be a problem.
So the real remaining parts are documentation and samples, I guess.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Roadmap for 2.2 (was: Re: Maven dictatorship and software parasitism)
Posted by hepabolu <he...@gmail.com>.
Carsten Ziegeler said the following on 29/9/06 12:12:
> but I'm not very enthusiastic about it as imho time and energy could be
> used in different places. Let's get this 2.2 release out *now*.
I agree, but does anyone know what is needed for this? I went as far
back as May 2005 but every topic on roadmaps and release plans for 2.2
get mixed up with discussions on related topics/ideas/opinions etc.
I've seen the phrases "documentation is lacking" and "documentation is
lagging behind" several times, and would love to do something about it,
but I have no clue where to start and what to do.
Maybe a few of us (Reinhard a.o.) should sit down at the hackathon and
decide on the new documentation setup and present that to the rest for
voting. At the very least we could write up a list of docs to provide.
And guys, once again: if you feel like documenting, please go ahead and
DO it in Daisy. If you want me to go over it to fix English and check it
from the "fresh eyes" POV, just mail me (pref. off-list, since I'll
catch that quicker).
Bye, Helma
Re: Maven dictatorship and software parasitism (was Re: Maven info
wanted)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sigh, it seems that we are able to spend endless energy in discussing
stuff but aren't able to spend any energy in really doing something.
It will always happen that some people like technology/tool A while
others prefer B (and for any reason might hate A). Its always been this
way and this will never change.
Anyways, Maven is more than just the repository - we aren't using
everything (yet), but for example the archetypes are a nice way of
starting a project. The site generation with all the reports is imho
another big advantage.
Yes, Maven has bugs and some of them are really demotivating - the
qualitiy of the repository is not perfect and mistakes have been made
there (e.g. updating stuff in the repository without changing a version
number). But, all this is known stuff today - if you follow our
guidelines (check proxy settings, configure a mirror, use offline builds
etc.) then Maven works like most other tools: usually it works but in
some cases it fails.
We (and I know others as well) are using Cocoon 2.2 with Maven in
development for several projects without any major problems. All the
complicated build stuff is hidden, people just create a project with our
web archetype and develop their stuff. Works perfectly. (And yes, we are
using a company repository)
So, I'm happy to discuss this stuff at the hackathon if people want -
but I'm not very enthusiastic about it as imho time and energy could be
used in different places. Let's get this 2.2 release out *now*.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/