You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by hepabolu <he...@gmail.com> on 2006/09/27 12:46:18 UTC
Maven info wanted
Guys,
I've watched the devlist with growing astonishment seeing how you got
into Maven2 and under its hood at an amazing pace.
My first steps into Maven v1 were not very successful and at the time
clear documentation of Maven2 was non-existent. I suppose this has
changed by now, but I'm still confused and heavily rely on your
documentation of what arguments to call and what poms to setup.
I guess I'm not alone in this and many current Branch users might be
holding off the transition to Trunk because of the magic maven
mumbo-jumbo that has to be done. Don't get me wrong, I'm not criticizing
the use of Maven, I merely find it very difficult to understand what's
going on and why things have to be done the way they are done.
What I'd like to see is some documentation on how to do things for
Cocoon, but enhanced with links to the relevant information about
Maven2. I'm sure you all have your favorite (web)sources, so please
share them.
At the least: send me a list of your favorite URLs (and please hold off
the link to the Maven homepage) and I'll compile a Daisy page with links.
Thanks.
Bye, Helma
Re: Maven info wanted
Posted by Leszek Gawron <lg...@mobilebox.pl>.
hepabolu wrote:
> Guys,
>
> I've watched the devlist with growing astonishment seeing how you got
> into Maven2 and under its hood at an amazing pace.
>
> My first steps into Maven v1 were not very successful and at the time
> clear documentation of Maven2 was non-existent. I suppose this has
> changed by now, but I'm still confused and heavily rely on your
> documentation of what arguments to call and what poms to setup.
>
> I guess I'm not alone in this and many current Branch users might be
> holding off the transition to Trunk because of the magic maven
> mumbo-jumbo that has to be done. Don't get me wrong, I'm not criticizing
> the use of Maven, I merely find it very difficult to understand what's
> going on and why things have to be done the way they are done.
>
> What I'd like to see is some documentation on how to do things for
> Cocoon, but enhanced with links to the relevant information about
> Maven2. I'm sure you all have your favorite (web)sources, so please
> share them.
>
> At the least: send me a list of your favorite URLs (and please hold off
> the link to the Maven homepage) and I'll compile a Daisy page with links.
>
> Thanks.
I have managed to create a single blog entry about starting a mavenized
cocoon application: http://ouzo.squash.eu.org/
It enlists all the commands you need to enter to create a valid cocoon
application skeleton.
--
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: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> On 30 Sep 2006, at 15:03, Jean-Baptiste Quenot wrote:
>
>> Did you turn on Maven's offline mode? In my experience the
>> offline mode is not reliable, you often have to switch back
>> online, and then you don't have the same build duration! It's
>> something I can't bear with Maven 2: why bother doing HTTP
>> requests as the jar is already fetched?!
>
> Does this really matter? How often during development of a typical
> webapplication do you invoke your build system?
At least once for each commit ;-)
At least that's how it should be. Since it's too slow, I'm now resolved to doing
it once a week :-P
Vadim
Re: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Jorg Heymans <jh...@domek.be>.
On 30 Sep 2006, at 15:03, Jean-Baptiste Quenot wrote:
>
> Did you turn on Maven's offline mode? In my experience the
> offline mode is not reliable, you often have to switch back
> online, and then you don't have the same build duration! It's
> something I can't bear with Maven 2: why bother doing HTTP
> requests as the jar is already fetched?!
<sigh>
Does this really matter? How often during development of a typical
webapplication do you invoke your build system? I don't know about
you but for me, using maven in a project does not mean i type "mvn
clean install" from the project root every 2 minutes. I'll invoke it
to regenerate the eclipse project files, i'll invoke it each time i
need to deliver a new EAR for testing and a few times in between to
regenerate hibernate descriptors through xdoclet. That's *it*,
everything else is pretty much IDE driven.
So frankly if you're suggesting me an alternative build system that
does less http requests, has better logging output or compiles my
code 50% faster then i can't honestly say i'm interested as it's not
at all what having a standardized build system is all about.
Regards,
Jorg
Re: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> Jean-Baptiste Quenot wrote:
>
> > Also, I wanted to share some amazing good news with you:
> > BUILD SUCCESSFUL
> > Total time: 4 minutes 15 seconds
>
> What is so amazing about this figures? Here is the output of
> "mvn compile", of course after calling mvn clean. I ran the
> build on my two years old laptop:
>
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 4 minutes 28 seconds
> [INFO] Finished at: Sat Sep 30 11:02:17 GMT+01:00 2006
> [INFO] Final Memory: 35M/63M
> [INFO] ------------------------------------------------------------------------
Did you turn on Maven's offline mode? In my experience the
offline mode is not reliable, you often have to switch back
online, and then you don't have the same build duration! It's
something I can't bear with Maven 2: why bother doing HTTP
requests as the jar is already fetched?!
> Can't you use the Maven descriptors for your purpose so that we
> have to declare things only once?
That's what I do, Ivy files are automatically generated from POMs
using XSLT, no manual editing of the generated files is necessary
afterwards. There are also a bunch of build.xml files that are
generated in every module.
Cheers,
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
> Jean-Baptiste Quenot wrote:
>> * Reinhard Poetz:
>>
>>> 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.
>>
>> An update to this:
>>
>> It is technically possible to have Ivy and Maven coexist, at least
>> as a temporary solution because they don't overlap with eachother.
>> So we may continue using Maven 2 for some specific things.
>
> hmmm, do you really want to maintain two build systems? I have to say
> that I'm against going down this path.
Can't you use the Maven descriptors for your purpose so that we have to declare
things only once?
--
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: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Reinhard Poetz <re...@apache.org>.
Jean-Baptiste Quenot wrote:
> * Reinhard Poetz:
>
>> 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.
>
> An update to this:
>
> It is technically possible to have Ivy and Maven coexist, at least
> as a temporary solution because they don't overlap with eachother.
> So we may continue using Maven 2 for some specific things.
hmmm, do you really want to maintain two build systems? I have to say that I'm
against going down this path.
> Also, I wanted to share some amazing good news with you:
>
> BUILD SUCCESSFUL
> Total time: 4 minutes 15 seconds
What is so amazing about this figures? Here is the output of "mvn compile", of
course after calling mvn clean. I ran the build on my two years old laptop:
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 minutes 28 seconds
[INFO] Finished at: Sat Sep 30 11:02:17 GMT+01:00 2006
[INFO] Final Memory: 35M/63M
[INFO] ------------------------------------------------------------------------
--
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: BUILD SUCCESSFUL (Was: Maven info wanted)
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> 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.
An update to this:
It is technically possible to have Ivy and Maven coexist, at least
as a temporary solution because they don't overlap with eachother.
So we may continue using Maven 2 for some specific things.
Also, I wanted to share some amazing good news with you:
BUILD SUCCESSFUL
Total time: 4 minutes 15 seconds
This is the result of building Cocoon trunk with all blocks ;-) I
let you guess how... If I have some spare time I'll have a
look at the deployer plugin. Can you point me to relevant
documentation? I only found a [1] retired document. What is the
entry point of the deployer if I want to run it let's say from the
command-line?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
[1] http://cocoon.zones.apache.org/daisy/documentation/795.html
Re: Maven info wanted
Posted by Reinhard Poetz <re...@apache.org>.
hepabolu wrote:
> Reinhard Poetz said the following on 28/9/06 14:55:
>
>> 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.
>
> As said: I really don't care as long as I'm able to figure out how
> things work. For now I'm stuck on a 'build failure' on the line
> "$mvn clean install eclipse:clean eclipse:eclipse" as described in
> http://cocoon.zones.apache.org/daisy/documentation/g1/756.html
>
> and I have no clue where to go and find more info.
I suggest that you start by sending the relevant parts of your console output to
this list.
--
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: Maven info wanted
Posted by hepabolu <he...@gmail.com>.
Reinhard Poetz said the following on 28/9/06 14:55:
> 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.
As said: I really don't care as long as I'm able to figure out how
things work. For now I'm stuck on a 'build failure' on the line
"$mvn clean install eclipse:clean eclipse:eclipse" as described in
http://cocoon.zones.apache.org/daisy/documentation/g1/756.html
and I have no clue where to go and find more info.
I'll settle for Maven but then we need to devote considerable hackathon
time to proper documentation. I don't mind doing corrections or writeups
or whatever else that's needed to make documentation a coherent piece,
but I need the initial info from you guys.
Bye, Helma
Re: Maven info wanted
Posted by Jorg Heymans <jh...@domek.be>.
On 28 Sep 2006, at 17:52, Sylvain Wallez wrote:
>
> There is a good thing in Maven: the repository, where people can
> pick up
s/repository/concept of a central repository/
remember that repo1 and cvs.a.o were killing our builds initially,
plus the fact that most of the pom metadata in the beginning was
automatically converted from maven1 and thus quite crappy to say the
least. (there is still a lot of cruft out there, ever tried to
include hibernate in your project ?)
>
> With its POM and repository, Maven managed to create an amazing
> dictatorship on the entire OSS Java community. That buggy tool
> (because
you call it dictatorship, i call it a 'standardisation effort' (and
that's what you would've called it too had it worked flawlessly).
> 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.
Yes it's buggy, yes it's lacking in documentation and no i don't
understand either why some of the more crucial bugs are taking so
long to fix (or why there are so many of them surfacing after you've
scratched away some of the glossy paint).
With 'endangered and damaged' i suppose you're referring to Cocoon,
i'm curious to hear which other projects you know of that have taken
the same route (and beating) ?
I <snipped> the rest of your comments because it's getting late.
You're touching on many valid points, so i better save my energy to
debate them during the hackathon :-P
Jorg
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/
Maven dictatorship and software parasitism (was Re: Maven info wanted)
Posted by Sylvain Wallez <sy...@apache.org>.
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 info wanted
Posted by Reinhard Poetz <re...@apache.org>.
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?
> 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?
> 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.
> Look at what happened here: I personnaly stopped looking at the 2.2
> branch after spending too much hours trying (and finally giving up)
> building Cocoon with Maven. The broken 2.2 build lasted for weeks and
> months. The switch to Maven is one of the reasons of me leaving the
> project, even if I wasn't against it a first (I wasn't particularly
> enthusiastic, but trusted the majority that wanted this move, and was
> also naively caught by the hype).
I was one of the last people around here that agreed to use Maven as build tool
but in the meantime I have to say that I like it although not everything is as
perfect as I would like to see it.
> Similarly, Jorg became a Maven expert,
> actively participating and contributing to Maven. Very good for Maven
> that earns his skills and time and kudos to him for all his efforts, but
> so bad for Cocoon that lost his valuable time for more useful things.
>
> Ant+Ivy just works, and you understand what happens in your build. It
> provides dependency management, and can also use the Maven repository
> (yes, XML makes things interoperable).
>
> 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.).
--
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 info wanted
Posted by Sylvain Wallez <sy...@apache.org>.
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.
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?
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.
Look at what happened here: I personnaly stopped looking at the 2.2
branch after spending too much hours trying (and finally giving up)
building Cocoon with Maven. The broken 2.2 build lasted for weeks and
months. The switch to Maven is one of the reasons of me leaving the
project, even if I wasn't against it a first (I wasn't particularly
enthusiastic, but trusted the majority that wanted this move, and was
also naively caught by the hype). Similarly, Jorg became a Maven expert,
actively participating and contributing to Maven. Very good for Maven
that earns his skills and time and kudos to him for all his efforts, but
so bad for Cocoon that lost his valuable time for more useful things.
Ant+Ivy just works, and you understand what happens in your build. It
provides dependency management, and can also use the Maven repository
(yes, XML makes things interoperable).
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.
My 0.02 euro.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Maven info wanted
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Jorg Heymans wrote:
> On 28 Sep 2006, at 21:16, Reinhard Poetz wrote:
>
> +1. This has been suggested a few times before IIRC, but we called it
> "deciding which blocks are core and which ones aren't " back then.
http://wiki.apache.org/cocoon/BlockStatusPoll
Vadim
Re: Maven info wanted
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jorg Heymans skrev:
> On 28 Sep 2006, at 21:16, Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>> The simplest solution to that is that we just create a new catalog
>>> named e.g. optionalblocks and move all of the blocks but the few that
>>> actually are actively developed or used from blocks to optional
>>> blocks. Then we don't have the optionalblock module as part of the
>>> main pom. This would cut down the build time quite a lot for the
>>> majority of developers. And by making the optionalblocks being built
>>> by continuum we still keep track on that we don't happen to break it.
>>
>> agreed
>
> +1. This has been suggested a few times before IIRC, but we called it
> "deciding which blocks are core and which ones aren't " back then.
>
> Any objections in doing this still before the hackathon? I think it
> would be beneficial to all wanting to give the maven build a spin during
> the hackathon. I suggest we start by moving all blocks that haven't been
> released yet, we can argue about the which other ones to include later.
No objections, quite the opposite :) Go ahead.
/Daniel
Re: Maven info wanted
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> On 28 Sep 2006, at 21:16, Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>> The simplest solution to that is that we just create a new catalog
>>> named e.g. optionalblocks and move all of the blocks but the few that
>>> actually are actively developed or used from blocks to optional
>>> blocks. Then we don't have the optionalblock module as part of the
>>> main pom. This would cut down the build time quite a lot for the
>>> majority of developers. And by making the optionalblocks being built
>>> by continuum we still keep track on that we don't happen to break it.
>>
>> agreed
>
> +1. This has been suggested a few times before IIRC, but we called it
> "deciding which blocks are core and which ones aren't " back then.
>
> Any objections in doing this still before the hackathon? I think it
> would be beneficial to all wanting to give the maven build a spin during
> the hackathon. I suggest we start by moving all blocks that haven't been
> released yet, we can argue about the which other ones to include later.
I don't think we have to move around directories. Just add another Maven project
descriptor at cocoon/trunk/blocks/all-blocks-pom.xml and remove all but a few
(e.g. cforms, ctemplate, ajax, ...) from the original pom.xml.
--
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 info wanted
Posted by Jorg Heymans <jh...@domek.be>.
On 28 Sep 2006, at 21:16, Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>> The simplest solution to that is that we just create a new catalog
>> named e.g. optionalblocks and move all of the blocks but the few
>> that actually are actively developed or used from blocks to
>> optional blocks. Then we don't have the optionalblock module as
>> part of the main pom. This would cut down the build time quite a
>> lot for the majority of developers. And by making the
>> optionalblocks being built by continuum we still keep track on
>> that we don't happen to break it.
>
> agreed
+1. This has been suggested a few times before IIRC, but we called it
"deciding which blocks are core and which ones aren't " back then.
Any objections in doing this still before the hackathon? I think it
would be beneficial to all wanting to give the maven build a spin
during the hackathon. I suggest we start by moving all blocks that
haven't been released yet, we can argue about the which other ones to
include later.
Jorg
Re: Maven info wanted
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Jean-Baptiste Quenot skrev:
>> * Reinhard Poetz:
>>
>>
>>> Also don't forget that releasing a Cocoon artifact has become
>>> very simple.
>>>
>>
>> Could you be a little more specific?
>>
>> Last time I tried following the instructions in README.txt, the
>> build was successful after 111 minutes. That is very simple, but
>> very long however :-(
>>
>> I don't mean to integrate a Cocoon release with the published
>> artifacts. I mean as a Cocoon developer.
>>
> The simplest solution to that is that we just create a new catalog named
> e.g. optionalblocks and move all of the blocks but the few that actually
> are actively developed or used from blocks to optional blocks. Then we
> don't have the optionalblock module as part of the main pom. This would
> cut down the build time quite a lot for the majority of developers. And
> by making the optionalblocks being built by continuum we still keep
> track on that we don't happen to break it.
agreed
--
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 info wanted
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jean-Baptiste Quenot skrev:
> * Reinhard Poetz:
>
>
>> Also don't forget that releasing a Cocoon artifact has become
>> very simple.
>>
>
> Could you be a little more specific?
>
> Last time I tried following the instructions in README.txt, the
> build was successful after 111 minutes. That is very simple, but
> very long however :-(
>
> I don't mean to integrate a Cocoon release with the published
> artifacts. I mean as a Cocoon developer.
>
The simplest solution to that is that we just create a new catalog named
e.g. optionalblocks and move all of the blocks but the few that actually
are actively developed or used from blocks to optional blocks. Then we
don't have the optionalblock module as part of the main pom. This would
cut down the build time quite a lot for the majority of developers. And
by making the optionalblocks being built by continuum we still keep
track on that we don't happen to break it.
/Daniel
Re: Maven info wanted
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Reinhard Poetz:
> Also don't forget that releasing a Cocoon artifact has become
> very simple.
Could you be a little more specific?
Last time I tried following the instructions in README.txt, the
build was successful after 111 minutes. That is very simple, but
very long however :-(
I don't mean to integrate a Cocoon release with the published
artifacts. I mean as a Cocoon developer.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Maven info wanted
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> Jean-Baptiste Quenot skrev:
>>> And FWIW I added an interesting topic for the Hackaton:
>>>
>>> See http://wiki.apache.org/cocoon/GT2006Hackaton
>>>
>> -->
>> [Jean-Baptiste Quenot] Try to replace Maven 2 with Ant and Ivy
>>
>> You are of course free to experiment with whatever you feel like. But
>> IMO it would be to attack the problem from the wrong direction. The main
>> problem with Cocoon from a build POV, is that it is so huge and has so
>> many dependencies. This is the problem that we should attack.
>>
>> As we have discussed many times we should split up the core, so that it
>> only contains the absolute minimum and move everything else to optional
>> blocks. This would considerably reduce the number of dependencies for
>> users, and as long as the number of dependencies is reasonable Maven is
>> OK. We could also move the majority of the blocks to a "legacy" area and
>> remove them from the main build. For most Cocoon developers there is no
>> use at all to build all the +100 modules, it would be enough with the
>> core and a few other blocks. For the rest it is enough that specially
>> interested people and the Continuum integration build builds them, so
>> that we will see if we happen to break anything there.
>>
>> So IMO it would be better to invest our efforts in the *root* cause of
>> our build problems, i.e. decreasing the complexity of the dependencies
>> rather than trying to hack around them by spending even more effort in
>> using new build systems and forcing everyone to learn still another
>> build technology.
>>
> Big +1 - we should really stop discussing things over and over again.
> Let's use m2 and solve the real problems.
Yes, I agree completly.
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.
Just my € 0.02 ...
--
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 info wanted
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Jean-Baptiste Quenot skrev:
>> And FWIW I added an interesting topic for the Hackaton:
>>
>> See http://wiki.apache.org/cocoon/GT2006Hackaton
>>
> -->
> [Jean-Baptiste Quenot] Try to replace Maven 2 with Ant and Ivy
>
> You are of course free to experiment with whatever you feel like. But
> IMO it would be to attack the problem from the wrong direction. The main
> problem with Cocoon from a build POV, is that it is so huge and has so
> many dependencies. This is the problem that we should attack.
>
> As we have discussed many times we should split up the core, so that it
> only contains the absolute minimum and move everything else to optional
> blocks. This would considerably reduce the number of dependencies for
> users, and as long as the number of dependencies is reasonable Maven is
> OK. We could also move the majority of the blocks to a "legacy" area and
> remove them from the main build. For most Cocoon developers there is no
> use at all to build all the +100 modules, it would be enough with the
> core and a few other blocks. For the rest it is enough that specially
> interested people and the Continuum integration build builds them, so
> that we will see if we happen to break anything there.
>
> So IMO it would be better to invest our efforts in the *root* cause of
> our build problems, i.e. decreasing the complexity of the dependencies
> rather than trying to hack around them by spending even more effort in
> using new build systems and forcing everyone to learn still another
> build technology.
>
Big +1 - we should really stop discussing things over and over again.
Let's use m2 and solve the real problems.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Maven info wanted
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Daniel Fagerstrom:
> [Jean-Baptiste Quenot] Try to replace Maven 2 with Ant and Ivy
>
> You are of course free to experiment with whatever you feel
> like. But IMO it would be to attack the problem from the wrong
> direction. The main problem with Cocoon from a build POV, is
> that it is so huge and has so many dependencies. This is the
> problem that we should attack.
Let me rephrase then:
[Jean-Baptiste Quenot] Proof of concept: Building Cocoon with Ant
and Ivy instead of Maven 2
Is that better? Clearly the Hackathon is an opportunity to
demonstrate to the Cocoon developers that we can have a simple
non-intrusive dependency manager, namely Ivy, replacing Maven 2,
because as you mention very clearly we have a very huge beast with
many dependencies. This is the core of the problem.
I'm working on Wicket besides Cocoon and it doesn't exhibit those
dependency problems because it justs depends on commons-logging,
junit, and servlet API. That's a whole different story, there
wouldn't be much to gain from switching to Ant+Ivy there.
Deciding whether it is worth the effort or not to do that with
Cocoon, we'll see next week. We'll only be able to make a wise
decision once enough people have watched how the Ivy build looks
like. And you may be surprised how easy it is to switch to Ivy
for resolving the dependencies!
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Maven info wanted
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jean-Baptiste Quenot skrev:
> And FWIW I added an interesting topic for the Hackaton:
>
> See http://wiki.apache.org/cocoon/GT2006Hackaton
>
-->
[Jean-Baptiste Quenot] Try to replace Maven 2 with Ant and Ivy
You are of course free to experiment with whatever you feel like. But
IMO it would be to attack the problem from the wrong direction. The main
problem with Cocoon from a build POV, is that it is so huge and has so
many dependencies. This is the problem that we should attack.
As we have discussed many times we should split up the core, so that it
only contains the absolute minimum and move everything else to optional
blocks. This would considerably reduce the number of dependencies for
users, and as long as the number of dependencies is reasonable Maven is
OK. We could also move the majority of the blocks to a "legacy" area and
remove them from the main build. For most Cocoon developers there is no
use at all to build all the +100 modules, it would be enough with the
core and a few other blocks. For the rest it is enough that specially
interested people and the Continuum integration build builds them, so
that we will see if we happen to break anything there.
So IMO it would be better to invest our efforts in the *root* cause of
our build problems, i.e. decreasing the complexity of the dependencies
rather than trying to hack around them by spending even more effort in
using new build systems and forcing everyone to learn still another
build technology.
/Daniel
Re: Maven info wanted
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
And FWIW I added an interesting topic for the Hackaton:
See http://wiki.apache.org/cocoon/GT2006Hackaton
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Maven info wanted
Posted by Sylvain Wallez <sy...@apache.org>.
hepabolu wrote:
<snip/>
> At the least: send me a list of your favorite URLs (and please hold
> off the link to the Maven homepage) and I'll compile a Daisy page with
> links.
Hmm... not Cocoon-specific, but I'd like to suggest
http://bluxte.net/blog/2006-09/17-52-51.html and all its sequels
(related blog posts and comments)
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Maven info wanted
Posted by Jorg Heymans <jh...@domek.be>.
> Hi,
>
> hepabolu wrote:
>
>> What I'd like to see is some documentation on how to do things for
>> Cocoon, but enhanced with links to the relevant information about
>> Maven2. I'm sure you all have your favorite (web)sources, so please
>> share them.
>
> Sounds like a good thing to work on at the hackathon too, perhaps.
>
+1, Helma if you want i'll give you a hand getting past the initial
hurdles and writing things up in Daisy.
(that is, if JBQ hasn't made the maven build obsolete by that time)
Jorg
Re: Maven info wanted
Posted by hepabolu <he...@gmail.com>.
One reply to all the others:
Leszek Gawron said the following on 27/9/06 16:25:
> I have managed to create a single blog entry about starting a mavenized
> cocoon application: http://ouzo.squash.eu.org/
>
> It enlists all the commands you need to enter to create a valid cocoon
> application skeleton.
Yes I noticed and I'd love to hold you to your promise of more
installments. With your permission I'd like to integrate it the Daisy
pages that already exist.
Andrew Savory said the following on 27/9/06 13:10:
> Sounds like a good thing to work on at the hackathon too, perhaps.
+1
Jorg Heymans said the following on 27/9/06 16:19:
> +1, Helma if you want i'll give you a hand getting past the initial
> hurdles and writing things up in Daisy.
Good idea.
> (that is, if JBQ hasn't made the maven build obsolete by that time)
I'm very curious to see Ant + Ivy building Cocoon.
I don't mind which one it's going to be eventually, but I think that
every build method needs links into the documentation of the project.
Even links to Ant documentation as a courtesy to newcomers would be good.
Sylvain Wallez said the following on 27/9/06 15:09:
> Hmm... not Cocoon-specific, but I'd like to suggest
> http://bluxte.net/blog/2006-09/17-52-51.html and all its sequels
> (related blog posts and comments)
I've read the initial post and all its comments. I didn't follow through
to the other posts, because I recognized my previous experience in your
post: I couldn't get Maven to comfortably build my project and it felt
very arbitrarily and artificial to split my project according to Maven's
wishes.
I suppose that before I start putting a big effort into writing about
builds with Maven, we could use the Hackathon to decide on Maven vs
something else.
One more remark, something that was in the comments of your posts: Maven
provides an easy way to build a consistent project website. I both agree
and disagree. It's true that Maven gives you a consistent project site
with the usual "what, who, where and how to install" stuff. I strongly
suggest that Cocoon has a consistent way of providing this information
in an easy to find place.
However, proper documentation about the USE of the project, be it Maven,
be it Cocoon or any other project, needs quite different tools. Using
Maven for the Cocoon documentation takes us back from Daisy to
handcrafted xdocs.
Re: Maven info wanted
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
hepabolu wrote:
> What I'd like to see is some documentation on how to do things for
> Cocoon, but enhanced with links to the relevant information about
> Maven2. I'm sure you all have your favorite (web)sources, so please
> share them.
Sounds like a good thing to work on at the hackathon too, perhaps.
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/