cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: M10N
Date Tue, 17 Jan 2006 16:04:43 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 17 Jan 2006, Ralph Goers wrote:

> Date: Tue, 17 Jan 2006 06:55:04 -0800
> From: Ralph Goers <Ralph.Goers@dslextreme.com>
> Reply-To: dev@cocoon.apache.org, rgoers@apache.org
> To: dev@cocoon.apache.org
> Subject: Re: M10N
> 
> I could be wrong, but it sounds as if user's wil still be "building" cocoon.

The one that develop their own block will still need some "support" from 
our build system (and yes, they build their own blocks with the help of 
our build infrastructure which are achetypes, plugins and blocks ready 
to be downloaded by Maven dependencies).

> They won't (or won't have to).  Hopefully, after Cocoon is completely 
> building successfully the artifacts will be available in a repository.  At 
> that point our download should consist of a script of some sort that allows

I hope we don't need any scripts (beside Maven 2) for it. We are 
building a system that will support us building our own blocks as well 
as others using it to build their own applications. But still it's a 
build system. Many of the Unix knowledgable people are used to the

 	./configure
 	make
 	make install

sequence of command to build a application.

> the user to build their own block with maven and downloads all the 
> dependencies they specify.  At least, that is what I am expecting.

And I guess we'll also have a bin dist that has all it needs to get in 
touch with Cocoon not just a bunch of blocks for the already savvy 
Cocooners.

And what about us developers _of_ Cocoon?

I'd really would like to

1. create a project/block from an archetype using mvn
 	[We do have a start of it]

2. edit/create some file needed for it
3. run i.e. "mvn cocoon:run"
 	[That's what's still missing and I don't know whether a "mvn
          jetty6:run" would be enought]

4. debug and enhance the running block
 	[This should go as far as we can reach including class
          and resource reloading etc. without the need to restart from
          3. above]

5. publish it by "mvn deploy" for others
6. release it at the end of a cycle with "mvn release"


>
> Ralph
>
> Giacomo Pati wrote:
>
>>  We can define our own artifact types so that there is possibilities to
>>  supply archetypes for things like application blocks, component blocks,
>>  abstract blocks, whatever and build them in a consistent way (from the
>>  users perspective), but package them as we need/like.
>>
>>  I.e.
>> 
>> =>  mvn   # build the package depending on the artifact we
>> #  want to produce for a certain module (single modules
>> #  as well as multi module build)
>>
>>     mvn cocoon:run  # run it (independent whether this is the root or
>>                     # a single module)
>>
>>  WDYT?
>
>
>

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDzRWcLNdJvZjjVZARAvTGAKC3xsWLGM0J71axTq1PB6DZrLDfFQCfeUw7
zzSfJ4CjDWwtpgIhTH3ROMo=
=8Dyg
-----END PGP SIGNATURE-----

Mime
View raw message