Re: [VOTE] green light for flattening repo structure in trunk
hepabolu wrote: Jorg Heymans wrote: [X] flatten the structure and pave the way for a 2.2 release Same here. same here :) -- Leszek Gawron [EMAIL PROTECTED] 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
[VOTE] green light for flattening repo structure in trunk
In line of the ongoing M10N process I would like to call a vote for starting the work to flatten the trunk repo structure. Main points to note : It makes it much easier to manage, maintain and oversee the maven build process. The experiment was very positive, you can still check out the flat layout in the whiteboard and play around with it [2]. The benefits towards componentisation are well known and accepted by everyone. In short, i don't see any reason to keep the old structure. and ... it's a change that affects *everybody*, and the less you know about maven the more you'll perceive yourself being affected. I thought that waiting a bit longer would give ppl more the chance to get up to speed with m2 in general. and If someone gives me the green light (again) and people are not afraid of a bit of a bumpy ride in trunk for a while then I can start flattening trunk *today* (as in __now__). Core, tests, mocks and a few of the more used blocks are obvious candidates. We can decide about the blocks that are externalized from branch later. Ofcourse I'll document the moving a block to the flat structure process as well as i go along. Please cast your votes : [ ] flatten the structure and pave the way for a 2.2 release [ ] no because Thanks Jorg
Re: [VOTE] green light for flattening repo structure in trunk
Le 5 janv. 06, à 14:52, Jorg Heymans a écrit : ...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Please cast your votes : [X] flatten the structure and pave the way for a 2.2 release [ ] no because And thanks for the hard work! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [VOTE] green light for flattening repo structure in trunk
...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [VOTE] green light for flattening repo structure in trunk
[+1 ] flatten the structure and pave the way for a 2.2 release [ ] no because Go for it. Matthew
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: In line of the ongoing M10N process I would like to call a vote for starting the work to flatten the trunk repo structure. Please cast your votes : [+1] flatten the structure and pave the way for a 2.2 release Ralph
Re: [VOTE] green light for flattening repo structure in trunk
Please cast your votes : [ +1 ] flatten the structure and pave the way for a 2.2 release [ ] no because /Daniel
RE: [VOTE] green light for flattening repo structure in trunk
...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because Max
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Vadim
Re: [VOTE] green light for flattening repo structure in trunk
[X] flatten the structure and pave the way for a 2.2 release [ ] no because
Re: [VOTE] green light for flattening repo structure in trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [X] flatten the structure and pave the way for a 2.2 release [ ] no because - -- 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) iD8DBQFDvTSpLNdJvZjjVZARAn9FAJ46FDN/o4Ejjrh3sUw55+FLHNBpRwCeMcsd X0rr5rAFELMKU7JlSaeW/0s= =x6m1 -END PGP SIGNATURE-
Re: [VOTE] green light for flattening repo structure in trunk
On 1/5/06, Jorg Heymans [EMAIL PROTECTED] wrote: [+1 ] flatten the structure and pave the way for a 2.2 release [ ] no because And thanks for taking care of that! -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [VOTE] green light for flattening repo structure in trunk
Vadim Gritsenko skrev: ... Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Agree, M2 repositories provide hierarchial group id's: org.apache.cocoon e.g. So there is no need for globally unique artifact id's anymore. /Daniel
Re: [VOTE] green light for flattening repo structure in trunk
Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Jorg
Re: [VOTE] green light for flattening repo structure in trunk
My account is not yet created, but please accept my vote: [X] flatten the structure and pave the way for a 2.2 release [ ] no because -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote:
Please cast your votes :
[X] flatten the structure and pave the way for a 2.2 release
[ ] no because
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [VOTE] green light for flattening repo structure in trunk
Please cast your votes : [+1 ] flatten the structure and pave the way for a 2.2 release Best Regards, Antonio Gallardo.
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. Best Regards, Antonio Gallardo.
Re: [VOTE] green light for flattening repo structure in trunk
Antonio Gallardo wrote: Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. I was talking about directory name only. cocoon-core.jar is fine. Vadim
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: [X] flatten the structure and pave the way for a 2.2 release Same here. Bye, Helma
Re: [VOTE] green light for flattening repo structure in trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Antonio Gallardo wrote: Date: Thu, 05 Jan 2006 11:24:40 -0600 From: Antonio Gallardo [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [VOTE] green light for flattening repo structure in trunk Jorg Heymans wrote: Vadim Gritsenko wrote: Jorg Heymans wrote: [ +1 ] flatten the structure and pave the way for a 2.2 release Minor point: does it have to be 'cocoon-core', 'cocoon-webapp', 'cocoon-blockname'; could it be 'core', 'webapp', 'block-blockname'? Not sure it will be easy to navigate among all those 'cocoon-foo's :) Matching the directory name with the artifactId is recommended practice. I can't exactly remember the benefits, but i know it saves extra configuration in reactor builds eg when using continuum. Should not be due name collision. ie: a core.jar released in another project? Yes, I will prefer to keep a prefixed name as cocoon-core.jar. No matter where we find this file, his names states it is the cocoon core. There is a project/build/finalName element in the pom.xml to define the artifact name. - -- 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) iD8DBQFDvZZALNdJvZjjVZARApo1AKCvMTgUt84IB81HisOwHqS7AC/6NgCcCYeo qv1TSElVNyj5W9EbMBZVtpc= =khdX -END PGP SIGNATURE-
Re: [VOTE] green light for flattening repo structure in trunk
Jorg Heymans wrote: Please cast your votes : [ +1 ] flatten the structure and pave the way for a 2.2 release [ ] no because -David
Re: [VOTE] green light for flattening repo structure in trunk
[+1] flatten the structure and pave the way for a 2.2 release cheers -- Torsten PGP.sig Description: This is a digitally signed message part
