You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/11/13 19:21:21 UTC
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by Martin Cooper <ma...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 15 Nov 2003, Brent Worden wrote:
> > -----Original Message-----
> > From: Martin Cooper [mailto:martinc@apache.org]
> > Sent: Thursday, November 13, 2003 11:22 PM
> > To: Jakarta Commons Developers List; tobrien@discursive.com
> > 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.
Cool. I've embellished that a bit, but there's still more I want to add.
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.
--
Martin Cooper
>
> Brent Worden
> http://www.brent.worden.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
JSVC
Posted by Yuan John Jiang <yj...@yahoo.com>.
Hi,
I downloaded the commons-daemon-1.0-Alpha for Linux/RH and got the
following problem. It looks like a problem finding the
org/apache/commons/daemon/support/DaemonLoader
class. But commons-daemon.jar is definitely in the -cp option.
I'm lost. I'd appreciate if some one can shed some light. Thanks.
John
----------------
# jsvc -debug -cp commons-daemon.jar:... MAIN-CLASS
jsvc.exec debug: redirecting stdout to /dev/null and stderr to
/dev/null
...
library /usr/java/j2sdk1.4.2_02/jre/lib/i386/client/libjvm.so loaded
jsvc.exec debug: JVM library entry point found (0x401EF864)
...
jsvc.exec debug: | Version: 10002
...
jsvc.exec debug: | "-Djava.class.path=commons-daemon.jar:...
(0x00000000)
...
jsvc.exec debug: Java VM created successfully
jsvc.exec error: Cannot find daemon loader
org/apache/commons/daemon/support/DaemonLoader
jsvc.exec error: Service exit with a return value of 1
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by Brent Worden <br...@worden.org>.
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Thursday, November 13, 2003 11:22 PM
> To: Jakarta Commons Developers List; tobrien@discursive.com
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by Martin Cooper <ma...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by Tim O'Brien <to...@discursive.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
-----------------------------------------------------
Tim O'Brien - tobrien@discursive.com - (847) 863-7045
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Dirk Verbeeck <di...@pandora.be>.
(inline)
Rodney Waldhoff wrote:
> Two clarifications:
>
> (1) jakarta-commons-sandbox/primitives and jakarta-commons/primitives are
> two different things. I think the plan is to remove or rename the
> sandboxed version at some point, but I don't think we need to put a lot of
> time pressure on that necessarily.
My mistake, it looked very much like the primitive collections.
> (2) jakarta-commons-sandbox/jux does in fact have real code
> (<http://jakarta.apache.org/commons/sandbox/jux/xref/org/apache/commons/jux/ObjectTestCase.html>).
> It extends junit.framework.TestCase, but that's the point, it's a base
> test case. It also has a web presence
> (<http://jakarta.apache.org/commons/sandbox/jux/>) and a snapshot
> distribution
> (<http://cvs.apache.org/builds/jakarta-commons/nightly/commons-jux/>).
Probably a jakarta record, the smallest distribution ever ;-)
> Otherwise I'm in favor of cleaning up the sandbox.
-- Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Rodney Waldhoff <rw...@apache.org>.
Two clarifications:
(1) jakarta-commons-sandbox/primitives and jakarta-commons/primitives are
two different things. I think the plan is to remove or rename the
sandboxed version at some point, but I don't think we need to put a lot of
time pressure on that necessarily.
(2) jakarta-commons-sandbox/jux does in fact have real code
(<http://jakarta.apache.org/commons/sandbox/jux/xref/org/apache/commons/jux/ObjectTestCase.html>).
It extends junit.framework.TestCase, but that's the point, it's a base
test case. It also has a web presence
(<http://jakarta.apache.org/commons/sandbox/jux/>) and a snapshot
distribution
(<http://cvs.apache.org/builds/jakarta-commons/nightly/commons-jux/>).
Otherwise I'm in favor of cleaning up the sandbox.
On Thu, 13 Nov 2003, 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:
> betwixt cli codec
> daemon dbutils digester
> discovery el fileupload
> jelly jexl lang
> latka launcher logging
> math modeler primitives
>
> These components/directories can also be removed IMHO:
> amend empty
> cjan empty
> graph empty
> latka-webapp empty
> morphos empty
> pattern empty
> cadastre empty old avalon comp
> cvs empty dir
> periodicity_1 empty dir
> jdbc2pool moved into dbcp
> util move into lang & collections
> bzip2 moved into IO
> altrmi moved to incubator
> jux no real code
> armi old altrmi project
> http old 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] Current CVS status
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Please test and verify that you can checkout and build the new cvs tree
I can now. I could not last night, so something is definitely fixed. Good
work. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Current CVS status
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Dirk has completed the commit process to bring the cvs uptodate with
where the original /home/cvs/jakarta-commons/math cvs tree was at. He
should be applauded for this great effort on his part to assist us in
maintaining all the historical information in the tree. :-)
Please test and verify that you can checkout and build the new cvs tree
properly and contact the list if you have any issues, please also verify
that any patches you provided are still accurately reflected in the
current head of the tree.
Thanks Dirk! :-)
-Mark
Mark R. Diggory wrote:
> Dirk Verbeck has reworked /home/cvs/jakarta-commons/math tree, which now
> contains the full history from the sandbox plus two refactorings I
> preformed after the move. He will be applying the rest of the changes
> made from 11/1/03 to present today.
>
> The current /home/cvs/jakarta-commons-sandbox/math cvs tree is recovered
> to just prior to the deletion. We will expect to remove this sandbox
> tree once the updating is complete.
>
> We should have things stablized by later today. Sorry for any
> incovenience during this process.
>
> -Mark
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] Current CVS status
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Dirk Verbeck has reworked /home/cvs/jakarta-commons/math tree, which now
contains the full history from the sandbox plus two refactorings I
preformed after the move. He will be applying the rest of the changes
made from 11/1/03 to present today.
The current /home/cvs/jakarta-commons-sandbox/math cvs tree is recovered
to just prior to the deletion. We will expect to remove this sandbox
tree once the updating is complete.
We should have things stablized by later today. Sorry for any
incovenience during this process.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] Merging two cvs trees
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Sorry I meant this to go to the math group
-Mark
Mark R. Diggory wrote:
> Dirk,
>
> Well, I've recovered the sandbox cvs tree up to where I deleted
> everything in the sandbox, this is now under jakarta-commons/math and
> looks ok to me. I have the following backups:
>
> jakarta-commons-sandbox-math-original.tar
> Original sandbox math tree with deletions prior to 11/1/03
>
> jakarta-commons-math-original.tar
> Original commons math tree with changes made from 11/1/03 to present.
>
> jakarta-commons-sandbox-math-new.tar
> Original sandbox math tree + recovered additions.
>
>
> The current CVS structure looks like:
> /jakarta-commons-sandbox/math --> changes made up to 11/1/03 + recovered
> additions.
>
> /jakarta-commons/math --> changes made from 11/1/03 to 11/13/03.
>
>
> My major problem now seems to be that the commit emails all have padding
> embedded in them that the mailer/log seems to insert, So I'm having a
> real difficulty processing them and re-applying them.
>
> I'm wondering if its just easier to merge the two cvs trees, but this is
> something I've never attempted before, I could really use any
> information on how to best attempt this.
>
> thanks,
> -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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Mergin two cvs trees
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Dirk,
Well, I've recovered the sandbox cvs tree up to where I deleted
everything in the sandbox, this is now under jakarta-commons/math and
looks ok to me. I have the following backups:
jakarta-commons-sandbox-math-original.tar
Original sandbox math tree with deletions prior to 11/1/03
jakarta-commons-math-original.tar
Original commons math tree with changes made from 11/1/03 to present.
jakarta-commons-sandbox-math-new.tar
Original sandbox math tree + recovered additions.
The current CVS structure looks like:
/jakarta-commons-sandbox/math --> changes made up to 11/1/03 + recovered
additions.
/jakarta-commons/math --> changes made from 11/1/03 to 11/13/03.
My major problem now seems to be that the commit emails all have padding
embedded in them that the mailer/log seems to insert, So I'm having a
real difficulty processing them and re-applying them.
I'm wondering if its just easier to merge the two cvs trees, but this is
something I've never attempted before, I could really use any
information on how to best attempt this.
thanks,
-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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Dirk Verbeeck <di...@pandora.be>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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:
>>> betwixt cli codec
>>> daemon dbutils digester
>>> discovery el fileupload
>>> jelly jexl lang
>>> latka launcher logging
>>> math modeler primitives
>>>
>>> These components/directories can also be removed IMHO:
>>> amend empty
>>> cjan empty
>>> graph empty
>>> latka-webapp empty
>>> morphos empty
>>> pattern empty
>>> cadastre empty old avalon comp
>>> cvs empty dir
>>> periodicity_1 empty dir
>>> jdbc2pool moved into dbcp
>>> util move into lang & collections
>>> bzip2 moved into IO
>>> altrmi moved to incubator
>>> jux no real code
>>> armi old altrmi project
>>> http old 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: commons-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Dirk Verbeeck <di...@pandora.be>.
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:
>> betwixt cli codec
>> daemon dbutils digester
>> discovery el fileupload
>> jelly jexl lang
>> latka launcher logging
>> math modeler primitives
>>
>> These components/directories can also be removed IMHO:
>> amend empty
>> cjan empty
>> graph empty
>> latka-webapp empty
>> morphos empty
>> pattern empty
>> cadastre empty old avalon comp
>> cvs empty dir
>> periodicity_1 empty dir
>> jdbc2pool moved into dbcp
>> util move into lang & collections
>> bzip2 moved into IO
>> altrmi moved to incubator
>> jux no real code
>> armi old altrmi project
>> http old 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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:
> betwixt cli codec
> daemon dbutils digester
> discovery el fileupload
> jelly jexl lang
> latka launcher logging
> math modeler primitives
>
> These components/directories can also be removed IMHO:
> amend empty
> cjan empty
> graph empty
> latka-webapp empty
> morphos empty
> pattern empty
> cadastre empty old avalon comp
> cvs empty dir
> periodicity_1 empty dir
> jdbc2pool moved into dbcp
> util move into lang & collections
> bzip2 moved into IO
> altrmi moved to incubator
> jux no real code
> armi old altrmi project
> http old 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Rodney Waldhoff <rw...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Martin Cooper <ma...@apache.org>.
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 jexl lang
> > latka launcher logging
> > math modeler 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by John Keyes <jb...@mac.com>.
<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 jexl lang
> latka launcher logging
> math modeler 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Dirk Verbeeck <di...@pandora.be>.
On the infrastructure list there was some discussion a while ago about putting
old unreleased unmaintained code in a special "graveyard" section.
something to consider?
-- Dirk
David Graham wrote:
> --- Dirk Verbeeck <di...@pandora.be> 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:
>>betwixt cli codec
>>daemon dbutils digester
>>discovery el fileupload
>>jelly jexl lang
>>latka launcher logging
>>math modeler primitives
>>
>>These components/directories can also be removed IMHO:
>>amend empty
>>cjan empty
>>graph empty
>>latka-webapp empty
>>morphos empty
>>pattern empty
>>cadastre empty old avalon comp
>>cvs empty dir
>>periodicity_1 empty dir
>>jdbc2pool moved into dbcp
>>util move into lang & collections
>>bzip2 moved into IO
>>altrmi moved to incubator
>>jux no real code
>>armi old altrmi project
>>http old httpclient
>>jpath old jxpath
>>joran only proposal 13 months old
>
>
> The directories still contain CVS info in the Attic and I think the ASF
> wants to keep that around even if the component moved somewhere else.
>
> David
>
>
>>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by David Graham <gr...@yahoo.com>.
--- Dirk Verbeeck <di...@pandora.be> 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:
> betwixt cli codec
> daemon dbutils digester
> discovery el fileupload
> jelly jexl lang
> latka launcher logging
> math modeler primitives
>
> These components/directories can also be removed IMHO:
> amend empty
> cjan empty
> graph empty
> latka-webapp empty
> morphos empty
> pattern empty
> cadastre empty old avalon comp
> cvs empty dir
> periodicity_1 empty dir
> jdbc2pool moved into dbcp
> util move into lang & collections
> bzip2 moved into IO
> altrmi moved to incubator
> jux no real code
> armi old altrmi project
> http old httpclient
> jpath old jxpath
> joran only proposal 13 months old
The directories still contain CVS info in the Attic and I think the ASF
wants to keep that around even if the component moved somewhere else.
David
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Dirk Verbeeck <di...@pandora.be>.
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 jexl lang
latka launcher logging
math modeler primitives
These components/directories can also be removed IMHO:
amend empty
cjan empty
graph empty
latka-webapp empty
morphos empty
pattern empty
cadastre empty old avalon comp
cvs empty dir
periodicity_1 empty dir
jdbc2pool moved into dbcp
util move into lang & collections
bzip2 moved into IO
altrmi moved to incubator
jux no real code
armi old altrmi project
http old 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by David Graham <gr...@yahoo.com>.
--- Martin Cooper <ma...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by Martin Cooper <ma...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: Web Presence for ALL Jakarta Commons components
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Web Presence for ALL Jakarta Commons components
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org