Re: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003, Tim O'Brien wrote: On Thu, 2003-11-13 at 13:59, Noel J. Bergman wrote: You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) I too would favor Maven and could definately help with the transition. OK, that's three: Mark, Martin and Brett. Is there any reason to NOT do this? If not, I'd suggest that the three of you coordinate efforts, and do it. Count me on the list, I've done a fair amount of Mavenizing already, but most of it has been undercover :-) Ditto. Am prepared to put time into achieving a common lf for Commons. Couple of complaints about Maven: 1) I don't want to have to build every project [ie figure out weird Sun dependencies] just to push up a global site change. I can accept this though. 2) The standard 'project documentation' section gets placed at the bottom when it's the most important information for a specific project. We replicate most of this in other sections. This replication can be a bit odd though, ie) contributors page and the maven generated project team page. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
1) I don't want to have to build every project [ie figure out weird Sun dependencies] just to push up a global site change. I can accept this though. I know diddly about the multi-project capabilities of Maven at this point, but I'm kinda hoping it will take care of this kind of thing... No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) Cheers, Brett
Web Presence for ALL Jakarta Commons components = updates for cache, clazz, jjar
Previews here: http://cvs.apache.org/~dirkv/cache/ http://cvs.apache.org/~dirkv/clazz/ http://cvs.apache.org/~dirkv/jjar/ cache is a totally new site that follows the dbcp/pool style clazz jjar had some existing content and I did just some minimal fix to make them buildable. (restyle can be done later) If there are no objections I'll push them to the site tomorrow. -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:28 PM To: 'Jakarta Commons Developers List' Subject: RE: Web Presence for ALL Jakarta Commons components No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Great! Actually, we recently discussed one such javamail alternative on the Maven list, but if there is one at Apache, even better. Here is the list of replacements needed: http://maven.apache.org/sun-licensing-journey.html Cheers, Brett -Original Message- From: Brent Worden [mailto:[EMAIL PROTECTED] Sent: Tuesday, 18 November 2003 1:29 PM To: Jakarta Commons Developers List Subject: RE: Web Presence for ALL Jakarta Commons components -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:28 PM To: 'Jakarta Commons Developers List' Subject: RE: Web Presence for ALL Jakarta Commons components No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Only the interface. It does not operate, AFAIK. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
I'd like to add tables for the Current Status, but it appears that tables are not currently enabled for our wiki. I've requested that from the wiki admin folks, so hopefully I'll be able to add them soon. You have? I don't recall seeing ... OH! You must have posted to the Wiki Admin list instead of the infrastructure list. The current Wiki is expected to go hasta la bye-bye soon. The new Wiki technology can be seen at http://wiki.apache.org/. There are a few people who have volunteered to help migrate the data from the current wiki, so as soon as they have that worked out, hopefully we can migrate and cut over. When that happens, there will be a Wiki specifically for Jakarta. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Mon, 17 Nov 2003, Noel J. Bergman wrote: I'd like to add tables for the Current Status, but it appears that tables are not currently enabled for our wiki. I've requested that from the wiki admin folks, so hopefully I'll be able to add them soon. You have? I don't recall seeing ... OH! You must have posted to the Wiki Admin list instead of the infrastructure list. Yup. The WikiAdmin page lists you as one of them, too. ;-) The current Wiki is expected to go hasta la bye-bye soon. The new Wiki technology can be seen at http://wiki.apache.org/. There are a few people who have volunteered to help migrate the data from the current wiki, so as soon as they have that worked out, hopefully we can migrate and cut over. When that happens, there will be a Wiki specifically for Jakarta. Um, OK. I guess I missed that we're changing wikis (again?). Any idea what the timeframe is likely to be? I'd guess that it's not quite imminent, so we should find a workaround for the current wiki in the meantime? -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Yup. The WikiAdmin page lists you as one of them, too. ;-) I'm not subscribed to wikidiff, though. Um, OK. I guess I missed that we're changing wikis (again?). Again? The current Wiki is the original one that Andrew Oliver installed. The new one is MoinMoin, which has (amongst other benefits) the ability to have a Wiki per-PMC. That addresses oversight concerns that have been raised, plus it has a lot more functionality. Any idea what the timeframe is likely to be? It is up and running now. AFAIK, the only hangup is migrating existing pages. I'd guess that it's not quite imminent, so we should find a workaround for the current wiki in the meantime? Hmmm ... if you want, I could look into setting up the Jakarta Wiki, even without the data currently on nagoya. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 11:22 PM To: Jakarta Commons Developers List; [EMAIL PROTECTED] Subject: RE: Web Presence for ALL Jakarta Commons components When I find a few minutes, I'll try to put up a page on the wiki to help us organise this effort, with a list of tasks that need to happen to get us where we want to be. (Unless, of course, someone beats me to it! ;) I put a little page together trying to summarize what's been discussed already: http://nagoya.apache.org/wiki/apachewiki.cgi?CreatingStandardWebPresence Feel free to make and changes. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
snip/ Shouldn't we cleanup the sandbox a bit first? (tar rm) The following components are graduated out the sandbox: betwixt cli codec daemon dbutils digester discovery el fileupload jelly jexllang latka launcherlogging mathmodeler primitives CLI has returned to the 'sandbox'. This was to grant commit privileges to someone who didn't have Jakarta commons commit privileges. Now I'm unsure if this was the correct approach (I did broach the subject on the dev list) but it certainly allowed us to continue very easily. So I think a better means to determine whether a sandbox project should be removed or not should be determined by activity. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Fri, 14 Nov 2003, John Keyes wrote: snip/ Shouldn't we cleanup the sandbox a bit first? (tar rm) The following components are graduated out the sandbox: betwixt cli codec daemon dbutils digester discovery el fileupload jelly jexllang latka launcherlogging mathmodeler primitives CLI has returned to the 'sandbox'. This was to grant commit privileges to someone who didn't have Jakarta commons commit privileges. Now I'm unsure if this was the correct approach (I did broach the subject on the dev list) but it certainly allowed us to continue very easily. So I think a better means to determine whether a sandbox project should be removed or not should be determined by activity. If said person has demonstrated useful contributions to CLI in the sandbox, then it seems to me that it would be appropriate to propose that they now become a Commons Proper committer. Deciding upon the removal, or otherwise, of components from the sandbox base on activity alone is not quite right, I think. As Noel pointed out when he started this thread, there are components in the sandbox that might have generated a community around them, had they actually been made visible on the web site. Personally, I'd prefer to see any given component exist (actively) in either Proper or the sandbox, but not both. Once a component has been promoted, it should stay in Proper, and its presence in the sandbox should be removed. I understand the history in the particular case of CLI, but I'd just as soon avoid that particular scenario going forward. -- Martin Cooper -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Fri, 14 Nov 2003, Martin Cooper wrote: Personally, I'd prefer to see any given component exist (actively) in either Proper or the sandbox, but not both. Once a component has been promoted, it should stay in Proper, and its presence in the sandbox should be removed. I understand the history in the particular case of CLI, but I'd just as soon avoid that particular scenario going forward. +1 - Rod http://radio.weblogs.com/0122027/ Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Web Presence for ALL Jakarta Commons components
there is precedent, albeit comatose, in the sandbox 'filters' and 'servlet' components. Yet another set of components that are not on the Jakarta Commons web page (http://jakarta.apache.org/commons/). Did it never occur to anyone that projects might be comotose because no one knows about them? I, for one, have code that could have gone in there, but I didn't know it existed. Can we agree on how to handle these projects? Every project in the CVS ought to have a web presence. If there isn't anyting particularly useful (no one created web content), then we should at least list it with a URL to its CVS presence. I think we discussed this before, but no one effected a change. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
If everything were mavenized couldn't we use the multiproject plugin to render the entire commons sandbox on its own? Default settings would render at least a html shell for those projects that don't have a project.xml. Or simply maintain that all sandbox components should maintain a project.xml and someone insert a default one in each project that doesn't have one? -Mark Noel J. Bergman wrote: there is precedent, albeit comatose, in the sandbox 'filters' and 'servlet' components. Yet another set of components that are not on the Jakarta Commons web page (http://jakarta.apache.org/commons/). Did it never occur to anyone that projects might be comotose because no one knows about them? I, for one, have code that could have gone in there, but I didn't know it existed. Can we agree on how to handle these projects? Every project in the CVS ought to have a web presence. If there isn't anyting particularly useful (no one created web content), then we should at least list it with a URL to its CVS presence. I think we discussed this before, but no one effected a change. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003, Noel J. Bergman wrote: there is precedent, albeit comatose, in the sandbox 'filters' and 'servlet' components. Yet another set of components that are not on the Jakarta Commons web page (http://jakarta.apache.org/commons/). Did it never occur to anyone that projects might be comotose because no one knows about them? I, for one, have code that could have gone in there, but I didn't know it existed. Can we agree on how to handle these projects? Every project in the CVS ought to have a web presence. If there isn't anyting particularly useful (no one created web content), then we should at least list it with a URL to its CVS presence. I think we discussed this before, but no one effected a change. IMHO, the best way to handle this is to have ONE mechanism to build ONE web site for ONE Jakarta project - i.e. Jakarta Commons. Right now, each component is responsible for putting up its own web presence, and many folks who drop things into the sandbox do not bother doing that - or even providing any documentation at all to indicate what it is / does. If we could decide on one mechanism for generating web content (Maven would be my choice because it does so much for so little work), and have a mechanism that would create a unified Commons web site, that would be great. As you suggest, any component that doesn't have any web content could still have at least a link to CVS. (Or perhaps there's a way to generate a minimal Maven site even in these cases?) The autonomy given to Commons components is nice in some ways, but in other ways I think it hurts us, and the outside perception of us. I think it would behoove us to improve our behaviour as a single entity, rather than simply an accretion of handy bits and pieces. -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Mark, If everything were mavenized couldn't we use the multiproject plugin to ... That is a means. I don't care about the means. I only care that it exists. If someone wants to mavenize everything, fine. If people object because they want everything to require only Ant, fine. I just don't want to see one issue held hostage to the other. :-) You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003 14:22:16 -0500, Noel J. Bergman wrote: Mark, If everything were mavenized couldn't we use the multiproject plugin to ... That is a means. I don't care about the means. I only care that it exists. If someone wants to mavenize everything, fine. If people object because they want everything to require only Ant, fine. I just don't want to see one issue held hostage to the other. :-) You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) --- Noel I too would favor Maven and could definately help with the transition. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
--- Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2003, Noel J. Bergman wrote: there is precedent, albeit comatose, in the sandbox 'filters' and 'servlet' components. Yet another set of components that are not on the Jakarta Commons web page (http://jakarta.apache.org/commons/). Did it never occur to anyone that projects might be comotose because no one knows about them? I, for one, have code that could have gone in there, but I didn't know it existed. Can we agree on how to handle these projects? Every project in the CVS ought to have a web presence. If there isn't anyting particularly useful (no one created web content), then we should at least list it with a URL to its CVS presence. I think we discussed this before, but no one effected a change. IMHO, the best way to handle this is to have ONE mechanism to build ONE web site for ONE Jakarta project - i.e. Jakarta Commons. Right now, each component is responsible for putting up its own web presence, and many folks who drop things into the sandbox do not bother doing that - or even providing any documentation at all to indicate what it is / does. If we could decide on one mechanism for generating web content (Maven would be my choice because it does so much for so little work), and have a mechanism that would create a unified Commons web site, that would be great. I am also a big fan of Maven. As you suggest, any component that doesn't have any web content could still have at least a link to CVS. (Or perhaps there's a way to generate a minimal Maven site even in these cases?) What about when one component X's build is broken and I want to update component Y's website? Do I have to fix X's build or just wait for X to be fixed? What if component X has site updates that are in progress and I publish them prematurely with Y's update. I'm reluctant to push updates to the commons website because of the build and the risk for ruining the entire site. As it is now, I just ruin my own component. Of course, all components' builds should work and site updates be committed in one step but are we certain that will happen every time? Especially with people new to the commons? The autonomy given to Commons components is nice in some ways, but in other ways I think it hurts us, and the outside perception of us. I think it would behoove us to improve our behaviour as a single entity, rather than simply an accretion of handy bits and pieces. Certainly, the differing build systems and websites are a problem. I'm just not comfortable yet with the idea that I have to build all component's sites to update a small piece of a component I'm directly working on. David -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Certainly, the differing build systems and websites are a problem. I'm just not comfortable yet with the idea that I have to build all component's sites to update a small piece of a component I'm directly working on. As I understand it, the proposal is to use the multi-project plug-in. I believe that you should be able to build just your own, too. Not sure what happens if you want to build everything that can build if they don't have dependencies on ones that didn't build, but that ought to be something that the Maven mavens can address. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
It's only 12 days ago that the move was done. We could redo the move and then reapply all changes since the move. It is a little extra work but if the historical information is important it is probably worth the effort. -- Dirk Mark R. Diggory wrote: The only difficulty I have is that theres a great deal of historical information still in the sandbox cvs tree for math, even though the latest version has been deleted, you should review how many of these trees are historical and are actually now empty directory structures (all files deleted). These are easily removed from any cvs checkout using -Pd. I'm not impressed with the way I moved the math project out of the sandbox, its version tree sould have been moved physically up to commons. This is a little late now, but we should consider moving other sandbox projects from now on in a way that maintains the historical information. -Mark Dirk Verbeeck wrote: I'm also willing to help a hand mavenizing the commons (sandbox) components. What do you guys think about the maven setup of DBCP as example (menu layout/content)? Shouldn't we cleanup the sandbox a bit first? (tar rm) The following components are graduated out the sandbox: betwixtclicodec daemondbutilsdigester discoveryelfileupload jellyjexllang latkalauncherlogging mathmodelerprimitives These components/directories can also be removed IMHO: amendempty cjanempty graphempty latka-webappempty morphosempty patternempty cadastreempty old avalon comp cvsempty dir periodicity_1empty dir jdbc2poolmoved into dbcp utilmove into lang collections bzip2moved into IO altrmimoved to incubator juxno real code armiold altrmi project httpold httpclient jpathold jxpath joranonly proposal 13 months old The component template in the proposal directory should also be updated. One last remark, there is a xmlunit component and there is also a sourceforge project with the same name: http://sourceforge.net/projects/xmlunit/ -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
this would be wise, before things get too different. What would be the best approach to tackle this? -Mark Dirk Verbeeck wrote: It's only 12 days ago that the move was done. We could redo the move and then reapply all changes since the move. It is a little extra work but if the historical information is important it is probably worth the effort. -- Dirk Mark R. Diggory wrote: The only difficulty I have is that theres a great deal of historical information still in the sandbox cvs tree for math, even though the latest version has been deleted, you should review how many of these trees are historical and are actually now empty directory structures (all files deleted). These are easily removed from any cvs checkout using -Pd. I'm not impressed with the way I moved the math project out of the sandbox, its version tree sould have been moved physically up to commons. This is a little late now, but we should consider moving other sandbox projects from now on in a way that maintains the historical information. -Mark Dirk Verbeeck wrote: I'm also willing to help a hand mavenizing the commons (sandbox) components. What do you guys think about the maven setup of DBCP as example (menu layout/content)? Shouldn't we cleanup the sandbox a bit first? (tar rm) The following components are graduated out the sandbox: betwixtclicodec daemondbutilsdigester discoveryelfileupload jellyjexllang latkalauncherlogging mathmodelerprimitives These components/directories can also be removed IMHO: amendempty cjanempty graphempty latka-webappempty morphosempty patternempty cadastreempty old avalon comp cvsempty dir periodicity_1empty dir jdbc2poolmoved into dbcp utilmove into lang collections bzip2moved into IO altrmimoved to incubator juxno real code armiold altrmi project httpold httpclient jpathold jxpath joranonly proposal 13 months old The component template in the proposal directory should also be updated. One last remark, there is a xmlunit component and there is also a sourceforge project with the same name: http://sourceforge.net/projects/xmlunit/ -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
Any help on resolving build dependencies write index.xml file is appeciated. I just tried to build the xo component and it failed. So even the components with an existing maven.xml will need to be updated. PS: my point with xmlunit was about the naming conflict -- Dirk Inger, Matthew wrote: I know the sourceforge project is active. I'm willing to help out with whatever i can, though I'm new to the commons project, i have submitted stuff for ANT, and i own the ANT-CONTRIB project on sourceforge. -Original Message- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 5:28 PM To: Jakarta Commons Developers List Subject: Re: Web Presence for ALL Jakarta Commons components I'm also willing to help a hand mavenizing the commons (sandbox) components. What do you guys think about the maven setup of DBCP as example (menu layout/content)? Shouldn't we cleanup the sandbox a bit first? (tar rm) The following components are graduated out the sandbox: betwixt cli codec daemon dbutils digester discovery el fileupload jelly jexllang latka launcherlogging mathmodeler primitives These components/directories can also be removed IMHO: amend empty cjanempty graph empty latka-webappempty morphos empty pattern empty cadastreempty old avalon comp cvs empty dir periodicity_1 empty dir jdbc2pool moved into dbcp utilmove into lang collections bzip2 moved into IO altrmi moved to incubator jux no real code armiold altrmi project httpold httpclient jpath old jxpath joran only proposal 13 months old The component template in the proposal directory should also be updated. One last remark, there is a xmlunit component and there is also a sourceforge project with the same name: http://sourceforge.net/projects/xmlunit/ -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
First we should inform all math committers of course. I will take a closer look tomorrow evening but we should undelete the files in the sandbox, backup the proper version, do the move like you described and then either redo all changes (including commit log) or do a simple merge. If there are only a few of them then we can use the commit mails. The bulk changes, renaming and stuff can be done by merging the backuped fileset into the new fileset. -- Dirk Mark R. Diggory wrote: this would be wise, before things get too different. What would be the best approach to tackle this? -Mark Dirk Verbeeck wrote: It's only 12 days ago that the move was done. We could redo the move and then reapply all changes since the move. It is a little extra work but if the historical information is important it is probably worth the effort. -- Dirk Mark R. Diggory wrote: The only difficulty I have is that theres a great deal of historical information still in the sandbox cvs tree for math, even though the latest version has been deleted, you should review how many of these trees are historical and are actually now empty directory structures (all files deleted). These are easily removed from any cvs checkout using -Pd. I'm not impressed with the way I moved the math project out of the sandbox, its version tree sould have been moved physically up to commons. This is a little late now, but we should consider moving other sandbox projects from now on in a way that maintains the historical information. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Thu, 2003-11-13 at 13:59, Noel J. Bergman wrote: You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) I too would favor Maven and could definately help with the transition. OK, that's three: Mark, Martin and Brett. Is there any reason to NOT do this? If not, I'd suggest that the three of you coordinate efforts, and do it. Count me on the list, I've done a fair amount of Mavenizing already, but most of it has been undercover :-) Beanutils, Digester, Discovery, Jexl - these projects already have published Maven sites that are not being linked to. Tim --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Thu, 2003-11-13 at 14:08, Noel J. Bergman wrote: Certainly, the differing build systems and websites are a problem. I'm just not comfortable yet with the idea that I have to build all component's sites to update a small piece of a component I'm directly working on. As I understand it, the proposal is to use the multi-project plug-in. I believe that you should be able to build just your own, too. Not sure what happens if you want to build everything that can build if they don't have dependencies on ones that didn't build, but that ought to be something that the Maven mavens can address. Different projects are going to want to update sites at different frequencies. I think we should make an attempt to achieve consistency throughout the J-C sites before attempting to create a system generate and publish every single J-C project. Different projects change at different frequencies, and we should leave the process of publishing the site to each component. The good idea is to Mavenize - everything I do think it a good idea to generate the Jakarta Commons site using Maven - we would continue to use the same xdoc. Tim --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Tim O'Brien - [EMAIL PROTECTED] - (847) 863-7045 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
There are about 16 commits that I made after move, it shouldn't be difficult to redo these. I'll make an announcement to the group. -Mark Dirk Verbeeck wrote: First we should inform all math committers of course. I will take a closer look tomorrow evening but we should undelete the files in the sandbox, backup the proper version, do the move like you described and then either redo all changes (including commit log) or do a simple merge. If there are only a few of them then we can use the commit mails. The bulk changes, renaming and stuff can be done by merging the backuped fileset into the new fileset. -- Dirk Mark R. Diggory wrote: this would be wise, before things get too different. What would be the best approach to tackle this? -Mark Dirk Verbeeck wrote: It's only 12 days ago that the move was done. We could redo the move and then reapply all changes since the move. It is a little extra work but if the historical information is important it is probably worth the effort. -- Dirk Mark R. Diggory wrote: The only difficulty I have is that theres a great deal of historical information still in the sandbox cvs tree for math, even though the latest version has been deleted, you should review how many of these trees are historical and are actually now empty directory structures (all files deleted). These are easily removed from any cvs checkout using -Pd. I'm not impressed with the way I moved the math project out of the sandbox, its version tree sould have been moved physically up to commons. This is a little late now, but we should consider moving other sandbox projects from now on in a way that maintains the historical information. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003 23:26:31 -0500, Mark R. Diggory wrote: There are about 16 commits that I made after move, it shouldn't be difficult to redo these. I'll make an announcement to the group. -Mark You might try grabing the current code from commons proper and creating a patch againt the sandbox. I've never tried this; it's just a thought. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Different projects are going to want to update sites at different frequencies. I think we should make an attempt to achieve consistency throughout the J-C sites before attempting to create a system generate and publish every single J-C project. Different projects change at different frequencies, and we should leave the process of publishing the site to each component. +1. The good idea is to Mavenize - everything I do think it a good idea to generate the Jakarta Commons site using Maven - we would continue to use the same xdoc. +1. However, I think the issue of insuring all subprojects are listed on the main site's menu should be tackled promptly. Along with the uniformity issue, the problem of not finding all existing subprojects was a big concern. Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003, Tim O'Brien wrote: On Thu, 2003-11-13 at 14:08, Noel J. Bergman wrote: Certainly, the differing build systems and websites are a problem. I'm just not comfortable yet with the idea that I have to build all component's sites to update a small piece of a component I'm directly working on. As I understand it, the proposal is to use the multi-project plug-in. I believe that you should be able to build just your own, too. Not sure what happens if you want to build everything that can build if they don't have dependencies on ones that didn't build, but that ought to be something that the Maven mavens can address. Different projects are going to want to update sites at different frequencies. I think we should make an attempt to achieve consistency throughout the J-C sites before attempting to create a system generate and publish every single J-C project. Different projects change at different frequencies, and we should leave the process of publishing the site to each component. +1 for achieving consistency as a first step. If we want to use the Maven multi-project plug-in, having everything Mavenised first will (probably) make that easier. (I say probably because I've never played with the multi-project stuff myself.) Regarding publishing the sites, I'm not all that worried about that. There is already a system in place to automatically update the main Jakarta site periodically (i.e. every few hours), and I suspect it wouldn't be hard to piggy back on that. Of course, that will be easier when we have one Commons site to update, rather than one per component, but hey, baby steps first. ;-) When I find a few minutes, I'll try to put up a page on the wiki to help us organise this effort, with a list of tasks that need to happen to get us where we want to be. (Unless, of course, someone beats me to it! ;) -- Martin Cooper The good idea is to Mavenize - everything I do think it a good idea to generate the Jakarta Commons site using Maven - we would continue to use the same xdoc. Tim --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003 [EMAIL PROTECTED] wrote: Different projects are going to want to update sites at different frequencies. I think we should make an attempt to achieve consistency throughout the J-C sites before attempting to create a system generate and publish every single J-C project. Different projects change at different frequencies, and we should leave the process of publishing the site to each component. +1. The good idea is to Mavenize - everything I do think it a good idea to generate the Jakarta Commons site using Maven - we would continue to use the same xdoc. +1. However, I think the issue of insuring all subprojects are listed on the main site's menu should be tackled promptly. Along with the uniformity issue, the problem of not finding all existing subprojects was a big concern. +1. Once the list of real sandbox projects is whittled down (per another earlier thread), we can make sure everything is at least listed. -- Martin Cooper Brent Worden http://www.brent.worden.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
