Re: [RT] Starting 2.2
On Thursday, Sep 18, 2003, at 05:12 Europe/Rome, Geoff Howard wrote: Stefano Mazzocchi wrote: All right, what the hell, you are right, let's move out of the impasse. I thought we'd come to some agreement that no option was without problems but that splitting to a separate cocoon-2.2 module was probably the least bad option. Yes, this seems to be the consensus. let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. Did Niclas' comment about the unreleased status kill this? Yes, it did. We will consider moving to Subversion only when they release a public final version that will not move under our feet. It's a defensive attitude, admittedly, but we don't want any more problems. -- Stefano.
Re: [RT] Starting 2.2
Stefano Mazzocchi wrote: All right, what the hell, you are right, let's move out of the impasse. I thought we'd come to some agreement that no option was without problems but that splitting to a separate cocoon-2.2 module was probably the least bad option. let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. Did Niclas' comment about the unreleased status kill this? Geoff
Re: [RT] Starting 2.2
On Friday, Aug 29, 2003, at 20:27 Europe/Rome, Jay Freeman ((saurik)) wrote: Stefano: I totally agree on the evolution thing. To start, the process of moving to Subversion would be a repository import, not starting from scratch. As for tools: http://subclipse.tigris.org/ (Subversion plugin for Eclipse, although only on Win32 currently, haven't tried it as I hate Eclipse; it seems like it could be gotten to work on Unix easily, just would require compiling the JNI stubs on your platform yourself and dropping them in as the subclipse people are currently relying on some precompiled binaries) http://ankhsvn.tigris.org/ (Subversion plugin for VS.NET, a little slow at times, but usable) They already have it integrated into ViewCVS (which is what I thought Apache used, might be wrong; there was a lot of impetus to do it as the guy who originally forked ViewCVS from CVSWeb is one of the lead Subversion developers). I've been working with the Chora (another web interface) people and we have it working in that as well. What I think would be more productive, both for Cocoon and for Subversion, is to have more than a flat out no, stick with something that works but instead to put forward a list of requirements from a revision control system for it to be considered an evolutionary move. Then people who work on version control know where to apply effort and people working on Cocoon have a roadmap for their evolution (rather than just getting stuck with existing systems and never moving). It's somewhat like deciding to switch to a different underlying framework for component/block management; one wouldn't want to just say hey, this is newer and has one better feature, let's do it, but if that one feature is crucial enough you'd want to have a list of requirements of a new system (one that obviously includes everything important from the old system) so that you'd know when you _would_ be able to move to it and when it would be worth it. All right, what the hell, you are right, let's move out of the impasse. let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. [as win2k-macosx/mozilla-Mail.app switcher I can attest that sometimes changing your habits is dramatic and painful, but can help you a lot down the road and you never look back. This sounds another one of those situations] -- Stefano.
Re: [RT] Starting 2.2
On Saturday 13 September 2003 18:40, Stefano Mazzocchi wrote: let's do a quick poll: who would be absolutely against using Subversion for the Cocoon 2.2 tree (granted that we can safely import the existing CVS tree into it)? state your reasons and try to be as less inertial and defensive on your status quo as possible. Subversion is not final. They say themselves that it is reliable, but not stable, i.e. there will be additional data migration issues prior to ver 1.0. Niclas
Re: [RT] Starting 2.2
Yeah, the Win32 client used to have all kinds of / vs. \ issues and they tended to break the build a lot. However, nowadays, the windows client (at least the command line one, which is what I first thought you meant) works quite well. RapidSVN (a Win32 GUI) is probably buggy as all hell still. However! TortoiseSVN (a Win32 shell extension) works extremely well. When I'm not using the command line client that's what I now use (and what I set up the few other developers at Gnostic Labs with when I finally switched us over to Subversion a week or two ago). As for the CVS to Subversion repository importer, it seems to at least partially support branches. BUT, it doesn't seem to support the Cocoon2 repository somehow. *Got it out of rsync earlier and let it sit for an hour or something converting.* I'm working on looking at the input, generated dump file, and partial output to try to figure out what's going wrong (it has something to do with a branch where some files got added to the branch later and then got deleted and it doesn't know they weren't int the branch to begin with for whatever reason). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Berin Loritsch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 28, 2003 3:30 PM Subject: Re: [RT] Starting 2.2 J.Pietschmann wrote: Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [RT] Starting 2.2
On Thursday, Aug 28, 2003, at 20:00 Europe/Rome, Jay Freeman ((saurik)) wrote: So my eye finally caught on the Starting 2.2 thread today, it seemed interesting, and I went to read through this... and I must say the main reaction I ended up having to it is HUH?!?. :) Is the reason you need a new repository because CVS doesn't support move/copy/rename (especially so on directories?). I guess I've just been using Subversion so long that some of the solutions people have been proposing sound rather terrifying... making a new repository and copying all of the RCS files into it in order to preserve history? But then you'd still be maintaining the files in both versions seperately with no computer way to know this file is a copy of that one to try to help you do that. Then there was the suggestion to have the new repository copy stuff from the 2.1 repository during build or something... With Subversion you could just copy the current trunk off to a cocoon-2.1 branch (as you'd likely be doing many less fixes on that over the future than enhancements to 2.2, so that would be considered the branch) and then start reorganizing the directories in the trunk by just moving them around and committing the move operations (so far with no space duplication on the server as all of these copy/move operations are just references to the same file data in the repository), files that need to be renamed could easily be done so, and this entire process would be keeping track of the history through all of the move operations... (although merging the 2.1 branch changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure the Subversion people are working on this; 0.28.0, released a few days ago, has some features that is bringing it a lot closer). Has any thought been put into the next time we have to create another new repository should be the day we look into better version control? Yes, you are right, CVS sucks, but the way it's integrated with the apache infrastructure and with tools that people use is not. there is a huge inertia there. greatly underestimated by the subversion people, expecially for people used to IDEs like eclipse that hide CVS stuff under the hood and do things automatically. I'm sick of this thread. It's stopping evolution. Carsten, forget beauty of versioning and let's start working on cocoon-2.1 HEAD, this will: 1) reduce effort and duplication 2) keep people sane since every commit will have to keep the tree in shape (it's entirely possible to implement real blocks with what we have, without moving things around, even turning the current static blocks into real ones). So, my vote is: cut the crap, let's work on the thing right here and right now, we'll think about what to do later. Evolution is always prefered to revolution. [believe me, I've made this mistake so many times that I learned my way thru] -- Stefano.
RE: [RT] Starting 2.2
Stefano Mazzocchi wrote: Carsten, forget beauty of versioning and let's start working on cocoon-2.1 HEAD, this will: 1) reduce effort and duplication 2) keep people sane since every commit will have to keep the tree in shape (it's entirely possible to implement real blocks with what we have, without moving things around, even turning the current static blocks into real ones). This is a very optimistic assumption, which I personally doubt. But, ok, I can live with doing everything in cocoon-2.1 HEAD, no problem. I'm absolutely frustrated as well: over the last months people always said, Let's get 2.1 out, we want to start 2.2. Now that we can do it, I'm the only one keeping to it. Great! Now I can already imagine what will happen. Someday someone checks in something that is not suitable for a 2.1.x version and then a new flame war against this person will begin. Ok, agreed. Let's stop the crap and work with the 2.1 repo then. joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Carsten
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Don't tease me... Want I should do it? -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
RE: [RT] Starting 2.2
Berin Loritsch wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? /joke Don't tease me... Want I should do it? Hey, great! I'm definitly +5 for this! So if you want to do it, you could start a vote and see what will happen next... Carsten
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: joke Ah, btw. I will replace ECM with fortress over the weekend. Any problems with that? Yep. Aren't we supposed to use Merlin instead? I'm checking in the code as we speak... /joke Vadim
RE: [RT] Starting 2.2
Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home? Carsten Ziegeler wrote: Pier Fumagalli wrote: On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections? Carsten
Re: [RT] Starting 2.2
Bertrand Delacretaz wrote: Le Jeudi, 28 aoû 2003, à 09:18 Europe/Zurich, Carsten Ziegeler a écrit : ...Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or are there still objections?... I'm +1 on starting 2.2 given what's going on (or planned) with blocks, forms, etc. -Bertrand I think, as has been said before, we need to discuss _what_ it is that would require a new repository. So far, we've had a number of RTs, but to my knowledge, no one is working on implementing any of these yet, and no one is working on code that cannot be placed into the 2.1 repository without breaking interfaces (at least ones that aren't still alpha). I think we should consider the 2.2 repository _only_ when we've got a concrete proposal for code that _cannot_ be included in the 2.1 repository. Switching repositories last time was a pain. Switching to a 2.2 repository will also be a pain, and that pain has to be worth it, and at present I do not see any proposals being made (that is, people proposing to implement proposals) that actually require this 2.2 repository. Therefore, at present I think we should stick with 2.1, until concrete proposals emerge that make it worth the effort. Regards, Upayavira
RE: [RT] Starting 2.2
Carsten Ziegeler dijo: Hello. Is there anybody in there? Just nod if you can hear me. Is there anyone home? Great :) Antonio Gallardo
Re: [RT] Starting 2.2
So my eye finally caught on the Starting 2.2 thread today, it seemed interesting, and I went to read through this... and I must say the main reaction I ended up having to it is HUH?!?. :) Is the reason you need a new repository because CVS doesn't support move/copy/rename (especially so on directories?). I guess I've just been using Subversion so long that some of the solutions people have been proposing sound rather terrifying... making a new repository and copying all of the RCS files into it in order to preserve history? But then you'd still be maintaining the files in both versions seperately with no computer way to know this file is a copy of that one to try to help you do that. Then there was the suggestion to have the new repository copy stuff from the 2.1 repository during build or something... With Subversion you could just copy the current trunk off to a cocoon-2.1 branch (as you'd likely be doing many less fixes on that over the future than enhancements to 2.2, so that would be considered the branch) and then start reorganizing the directories in the trunk by just moving them around and committing the move operations (so far with no space duplication on the server as all of these copy/move operations are just references to the same file data in the repository), files that need to be renamed could easily be done so, and this entire process would be keeping track of the history through all of the move operations... (although merging the 2.1 branch changes into 2.2 still wouldn't be entirely automated, but I'm pretty sure the Subversion people are working on this; 0.28.0, released a few days ago, has some features that is bringing it a lot closer). Has any thought been put into the next time we have to create another new repository should be the day we look into better version control? Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Carsten Ziegeler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 2:18 AM Subject: RE: [RT] Starting 2.2 Pier Fumagalli wrote: On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or a there still objections? Carsten
Re: [RT] Starting 2.2
Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does Cocoon 5.0 look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does MX mean? The MX moniker is not an acronym and doesn't have a literal translation. They add the MX, and then they realize they have to release a new version so they tack a 2004 on the end. In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Regards, Tony
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Tony Collen wrote: Nicola Ken Barozzi wrote: Maybe start 2.5, just to be in line with Linux? ;-P Screw that, let's just skip a couple major versions, everyone's doing it now, how does Cocoon 5.0 look? :) Better yet, let's just change the name alltogether: Cocoon XP Cocoon MX Cocoon MX 2004 I just love Macromedia, at least they admit MX doesn't mean anything: What does MX mean? The MX moniker is not an acronym and doesn't have a literal translation. What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. Geoff
Re: [RT] Starting 2.2
Jay Freeman (saurik) wrote: Has any thought been put into the next time we have to create another new repository should be the day we look into better version control? Amen! Personally I'd +1 the subversion switch in any moment. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. How about: Cocoon Interrobang It would be pronounced, Cocoon?! In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Regards, Tony
Re: [RT] Starting 2.2
Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). J.Pietschmann
Re: [RT] Starting 2.2
J.Pietschmann wrote: Timothy Larson wrote: I also wondered about Subversion when the repositories started multiplying :) Is this a possibility? Is there a good CVS-Subversion repository converter? What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin
Re: [RT] Starting 2.2
Berin Loritsch wrote: What's good? The Subversion project has a converter, last time I checked they said it still can't convert branches, and that this was *the* killer for declaring SVN to be production ready. Trunk only CVS repositories seem to work for a long time already (disclaimer: gathered from various messages, I didn't try personally). Hmm. Do we still have a test server available? The last time I played with SVN, the Windows client was a bit buggy. However that was roughly a year ago. I'm sure it has gotten better since then. Look at: http://cvs.apache.org/repos/asf/ On infrastructure@ there was an email describing how to add yourself to the right passwd file (with htpasswd). I don't know how sensible that information is, so I'd rather not write it here. Just contact me if you feel lik playing around. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Starting 2.2 (was going to be The Project Formerly KnownAs Cocoon)
Tony Collen wrote: Geoff Howard wrote: What about renaming the next release to an unpronounceable set of symbols, like Prince, or that Led Zepplin album? I'd suggest !#. How about: Cocoon Interrobang It would be pronounced, Cocoon?! Actually, my proposal could be pronounced bang and pound which might not be positive... In all seriousness, I'm all for 2.2, but what sorts of loose ends are there that could be tied up for 2.1.x? Howabout a push to clear out some bugs from bugzilla? Me too, but a push for bug fix (and I'd like to see a docs blitz) wouldn't need to hold up creating the repository and working out the best way of working two trees at once would it? Hrm, actually a docs push would be more like it, since I was prodded by a few people to do up some nice InputModule docs, so I am guilty as charged :) I just didn't want to see new stuff get started and have older issues unresolved. I don't see why we'd need to postpone a new repository, really, I'd just hate to see things forgotten about. Agreed. Side note: Is a build of 2.1.x or 2.2 going to be using the new forrest-style skins for the docs anytime soon? It's kind of nasty seeing the old site design when I build docs from the current CVS. I asked about this before and got the impression that some people are getting the forrest look. Near as I can tell, it falls back to the old xml.apache metal look if forrest is not downloaded at ../xml-forrest or as specified in build.properties? So far I've been too lazy to confirm. I'd much rather be able to import the stylesheets, etc. which would be needed but I've been too lazy for that as well. By the way, I thought we were planning on breaking from ECM in 2.2 because it would make blocks easier among other great benefits. Is this still a thought? That would certainly make a new repo an attractive thing. I'm not a hugely knowledgeable on Avalon, so I'm not sure about the issues surrounding it. Just when I thought I'd start to learn Avalon stuff, the carpet gets pulled out from under me! :) Hopefully it's not as bad as that. Avalon's not going away, just the implementation that's changing... Geoff
RE: [RT] Starting 2.2
Pier Fumagalli wrote: On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Great! Combined with the recent RTs, does still someone feel that starting 2.2 is the right thing? Or a there still objections? Carsten
RE: [RT] Starting 2.2
Sylvain Wallez wrote: I don't clearly understand what you want to achieve... It's plain simple :) Now, the usual way would be to create a new repository (cocoon-2.2) and copy everything from 2.1 in there. Then we have two branches which require syncing which can be a real pita. My approach is to sync as less as possible by only copying those parts that we will change in the near future. And this should be the core sources, but not the documentation or any block. As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy. Does this make sense? Carsten
Re: [RT] Starting 2.2
On 13/8/03 16:37, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). YES! :-) As I have few [RT]s on my own! :-) :-) :-) Pier
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: ... Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. I'm wondering. What are you personally planning which requires 2.2 repo and can not be done in the current repo? /me feels that you are trying to solve some problem without stating what the problem is Vadim
RE: [RT] Starting 2.2
Sylvain Wallez wrote: Carsten Ziegeler wrote: Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). You ask for the solution to a problem that's not defined... Why do you need the 2.2 repo to be created before writing your RTs ? Ok, it has nothing to do with my RT's, I had the impression that blocks required a major version changes and that we want to start with it asap. If I'm wrong here, let's stop this RT. Carsten
RE: [RT] Starting 2.2
Title: RE: [RT] Starting 2.2 /me feels that you are trying to solve some problem without stating what the problem is Vadim Planning a IRC block with a mIRC log generator and all ? Great ! ;) fabien.
Re: [RT] Starting 2.2
Joerg Heinicke wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106077110314347w=2 Stefano: the road to real blocks: how to build it minimizing the impact on the existing code and with complete back compatibility (yes, it's possible!) Here's my own Mini-RT: If you've used a BSD, you've quite possibly run into what's known as _ports_. Ports is really cool, and for anyone who doesn't know what it is, here's a little description. Ports is a big directory skeleton which usually sits in /usr/ports. It is organized in a hierarchy, so you end up with a directory structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc. Under each category is another directory for each program which belongs to it, so /usr/ports/games/fortune, etc. Now the cool thing is that each program directory contains a makefile, unified diffs, and a list of repositories where the software resides. (FTP, WWW, etc) When you run make, it automatically downloads the software from the repository, and patches the software specifically for BSD. Even cooler, is that it automatically takes care of dependencies recursively. Once all the dependencies are done, the software is built. There are several other commands, such as make install or make clean which does the usual expected chores. The only downfall is that you have to keep the directory skeleton up to date. FreeBSD does this over CVS. Very handy. Now, imagine this applied to Cocoon and blocks. If we distributed a core Cocoon, we could dramatically cut down the typical amount of code that gets distributed. If we wanted the PDF block installed, all we would do is go to $cocoon_src/blocks/pdf/ and type build install. It would download the PDFSerializer, and realize that the FOP jars are required, and download them. We could also come up with some block packages that are geared towards some basic tasks, i.e. blocks which are grouped together to accomplish some goal.. sort of how the more popular Linux distros have a workstation, server, basic, everything install. That's my RT, I hope I didn't spoil anything anybody was saving :) Tony
Re: [RT] Starting 2.2
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't clearly understand what you want to achieve...
It's plain simple :) Now, the usual way would be to create a new repository
(cocoon-2.2) and copy everything from 2.1 in there.
Then we have two branches which require syncing which can be a real pita. My
approach is to sync as less as possible by only copying those parts that we will change in the
near future. And this should be the core sources, but not the documentation or any block.
Ah, so we'll have a 2.2 repo containing only those parts whose structure
will change, and keep the 2.1 repo as a fallback for those parts whose
structure is the same (but who may have been upgraded since 2.1.0) ?
But how do we decide that some modifications should occur in 2.2 and not
in 2.1 ?
As I expect that we will end in a different structure when we have real blocks (e.g. perhaps a blocks repository etc.) this would be imho an easier migration strategy.
That's right. With real blocks, we'll have several distinct CVS
repositories. But will we have distinct kernel and core component
blocks ? Should the kernel be really naked (in which case it may even
contain only the block manager and the main interfaces but nothing
else), or should it provide the common services used by every
application (e.g. WildcardMatcher, FileGenerator, HTMLSerializer, etc) ?
Does this make sense?
Yep. But the granularity has to be found. Maybe we should wait for
Stefano's RT so that everybody has a common understanding of the
consequences of blocks on the Cocoon organisation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [RT] Starting 2.2
Ok, let's do simple steps perhaps: Do you think that we should start a new repository? This is equivalent to saying we start a new major version (2.2). (if the answer is yes, we can talk about the layout). Carsten
Re: [RT] Starting 2.2
Tony Collen wrote:
Joerg Heinicke wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106077110314347w=2
Stefano:
the road to real blocks: how to build it minimizing the impact on
the existing code and with complete back compatibility (yes, it's
possible!)
Here's my own Mini-RT:
snip/
Now, imagine this applied to Cocoon and blocks. If we distributed a
core Cocoon, we could dramatically cut down the typical amount of
code that gets distributed. If we wanted the PDF block installed, all
we would do is go to $cocoon_src/blocks/pdf/ and type build install.
It would download the PDFSerializer, and realize that the FOP jars are
required, and download them. We could also come up with some block
packages that are geared towards some basic tasks, i.e. blocks which
are grouped together to accomplish some goal.. sort of how the more
popular Linux distros have a workstation, server, basic,
everything install.
That's my RT, I hope I didn't spoil anything anybody was saving :)
You did ;-)
The idea behind blocks uses similar concepts but goes even further by
relying on a discovery system that can ask a server for the location of
dependencies. This means you won't even need a local list of the
available blocks.
But let's not steal Stefano's pleasure of explaining us the results of
his worldwide discussions !
Stefano, seems like a lot of people are ready and waiting ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote:
Ok, let's do simple steps perhaps:
Do you think that we should start a new repository? This is
equivalent to saying we start a new major version (2.2).
(if the answer is yes, we can talk about the layout).
You ask for the solution to a problem that's not defined... Why do you
need the 2.2 repo to be created before writing your RTs ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Starting 2.2
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: ... Hmm, yes, but we could start the 2.2 repo with the current core source, so we have a starting point. I expect that blocks will require longer discussions and I personally don't want to wait with 2.2 for this. I'm wondering. What are you personally planning which requires 2.2 repo and can not be done in the current repo? /me feels that you are trying to solve some problem without stating what the problem is Secret plans something like world domination ... :) (just kidding) I have several smaller RTs that require major changes in the core, so I think they are targetted for a 2.2 release rather than 2.1.1. And the blocks require a major version change, so I thought about merging them. I will write the RTs as soon as we have the repository. Let's do the other way around -- send in RT first and let's hear about those major changes :) Vadim
