Re: Removing interim dated builds from /www/www.apache.org/dist/java-repository

2005-01-07 Thread Mark R. Diggory
Thanks Brett,
I'm just concerned as well, that there may be distributions out on 
Apache the reference the ASF Repository jars directly instead of using 
Ibiblio or dyncloser.cgi. If those projects have been shortsighted in 
releasing distros's that have dependencies on interim releases in 
java-repository, then my proposed changes will effect them.

I think I will be moving forward with this proposal. As well as deleting 
these files, I will build a log of all the changes so that recovery from 
the archives can occur if any problems arise. It seems more important 
that we get the repository properly organized and structured than 
maintain old external project dependencies on unsanctioned interim 
releases in java-repository.

-Mark
Brett Porter wrote:
Hi Mark,
I think this is just a miscommunication, as what you have said below
is what all the projects do

1.) In Maven project.properties, Referencing the remote repository
maven.repo.remote=http://www.apache.org/dist/java-repository/
2.) In Maven project.properties, Referencing a central repository
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
3.) In Ant files generated from Maven, Hardcoded references to
java-repository.
I believe we should take the following stance on these cases:
1.) 1 !!!
2.) +1
3.) 1 !!!

I agree.

As well, most projects that have java-repository as a remote repo, also
have have ibibilio in from of it:

If I ever reference java-repository, its not in an automated fashion,
and always behind dyncloser.cgi (eg, the release announcements).
- Brett
-
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: Removing interim dated builds from /www/www.apache.org/dist/java-repository

2005-01-07 Thread Mark R. Diggory

Dain Sundstrom wrote:
On Jan 7, 2005, at 6:56 AM, Mark R. Diggory wrote:

Heres a really good example of a reference we promote usage of:
jakarta-commons/chain/project.properties,v: 
maven.repo.central.directory=/www/www.apache.org/dist/java-repository

maven.repo.central.directory is property which states where to  publish
to, not where to download from.

This is exactly my point.  If someone pulled down that source, it  
potentially won't build.  Once you start messing with repos, it can  
eliminate the possibility of recreating *historical* builds.

No, your missing it, the point of maven.repo.central.directory is that 
it specifically configures where things get published to, not where to 
download them from. Release Managers using Maven need to maintain this 
sort of stuff outside of the cvs and only use it when publishing 
releases or interim builds

http://maven.apache.org/reference/user-guide.html#Behavioural_Properties
http://maven.apache.org/reference/plugins/artifact/properties.html
Are examples of configuring the client.
It might be good to go through the Apache projects that are in   
java-repository and see if any are packaged to download 
dependencies   from there, I doubt it that here would be any 
occurances however.  As a  majority of the files were originally 
published to/against  ibiblio in  the first place.
Unfortunately, not all projects that use the apache repos are not   
hosted at apache.

We've never publicized the the java-repository to be used externally.  It
's content was originally migrated from Apache by Jason Van Zyl and
Myself with the goal of getting publishing of Apache content back to
Apache (with Ibibilio as a mirror). Anyone using it would be using it  at
their own risk. I believe that any consultation with the ASF Repository
project here at Apache would have made this issue clear to them.
Further, my point is that currently there shouldn't be projects
dependent on java-repository as its location for resolving jar
dependencies, there is an entire discussion on the [EMAIL PROTECTED]
list concerning this subject, the repository used is a configuration of
the client right now (in Maven) not a characteristic of the project.xml
of a maven project. You can suggest a repository to use in properties
handed to Maven, but the default is always www.ibiblio.org/maven. Our
initial creation of java-repository was never not to have a  Standalone
Maven repository at Apache, but to provide a simple means for Apache
developers to publish release jars and distributions to Ibibilio until
such a time when distributed repositories become a greater practice.
Its a real bad idea to force build dependencies against it at this time
until we get it stabilized. Its entire contents are present at Ibiblio,
there currently is no reason a project should be using it directly vs
ibibilio.

I agree with what you are writing, but people do it.  IMHO if you are  
going to create a public repo, they you have a responsibility to keep  
the artifacts around forever.

But this is exactly our argument, java-repository was never meant to be 
used as a public interim release repository (based on where it is 
located in the dist directory and the policies of dist...


On top of this I recommend that Apache avoid maintaining interim builds
in such a way that external projects can build dependencies against
them. External projects should only be using fully 'sanctioned'  releases
published in dist for this purpose. Until tooling is completed in Ant
and Maven to support distributing download requests from the ASF
Repository across the mirrors we really cannot recommend that external
projects build dependencies against the contents of the ASF Repository
directly, please use Ibiblio/maven for this until such capabilities  come
into existence.

That is simply not possible.  Geronimo has three external sister  
projects OpenEJB, ActiveMQ and TranQL.  These projects import Geronimo  
and Geronimo aggregates their jars into the final distribution.  If  
this were policy, then either the Geronimo project would stop, or more  
likely the Geronimo project would publish fully sanctioned' releases  
every checkin.
This is an interesting example that represents a challenge. This is 
probably best served using http://cvs.apache.org/repository or a 
repository for Geronimo to manage sharing of the development snapshots.

Why are they so separate? Why not have these projects as part of Apache?

After writing some scripts to search the Apache cvs tree and  
inspecting the results. It really breaks down to three cases where  
projects reference java-repository:

1.) In Maven project.properties, Referencing the remote repository
maven.repo.remote=http://www.apache.org/dist/java-repository/
2.) In Maven project.properties, Referencing a central repository
maven.repo.central.directory=/www/www.apache.org/dist/java-repository
3.) In Ant files generated from Maven, Hardcoded references to  
java-repository.

I believe we should take

Re: Removing interim dated builds from /www/www.apache.org/dist/java-repository

2005-01-05 Thread Mark R. Diggory
Dain Sundstrom wrote:
On Jan 5, 2005, at 10:26 AM, Mark R. Diggory wrote:
Thanks for your response Dain,
Dain Sundstrom wrote:
On Jan 4, 2005, at 8:34 PM, Mark R. Diggory wrote:
Please excuse the cross post. I'm planning to run some commands on 
the java-repository to remove interim builds and SNAPSHOTS. 
Specifically, I'll be running:
If you remove SNAPSHOTS, it not only can it break head branches of 
projects,

Can you explain this further, I'm not sure what your suggesting here. 
Are you referring to content outside of 
/www/www.apache.org/dist/java-repository? Its important to point out 
that I'm only suggesting modification of content in the repository, 
not modification of any other content inside dist/...

it can break milestone source releases that people are still
using.
-dain

Well, the http://www.ibiblio.org/maven repository will still maintain 
all the SNAPSHOTS/interim builds I am planning on removing. That 
rsync does not delete files. So users of Maven working solely with 
the www.ibiblio.org/maven repository will not experience any of these 
changes.

If it is really the case that Maven users are going to 
dist/java-repository instead www.ibiblio.org/maven we should alert 
them, dist/java-repository is in practice just for publishing Apache 
jars to ibiblio (though we have visions of its usage for other goals 
in the near future).

For Apache developers using Maven, what I recommend is to continue 
using www.ibiblio.org to resolve dependencies for milestone and 
release builds. Then, to actually do any interim, snapshot or dated 
builds into

http://cvs.apache.org/repository
which is not mirrored.

I can say that I was not aware of the policy, so I would assume other 
are not.  If there are any projects that were using that location as a 
maven repo, their builds will break.  Also if someone shipped a source 
distribution that needs one of these files, it will break, which means 
there would be no way to reproduce a historical build from a source 
distribution.

-dain
Yes, I'm not sure that we can refer to it accepably as a policy, as 
much as a best practice.

Well, if we take the latest release of Commons Math for instance. From 
both a Maven and Ant standpoint the distributions dependecies are 
resolved to/against ibibilio:

   get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true 
ignoreerrors=true 
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
/get
get dest=${libdir}/commons-discovery-0.2.jar 
usetimestamp=true ignoreerrors=true 
src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-0.2.jar;
/get

In Maven, the repository used to get downloads from is not a project 
attiribute, it is a user decision/configuaration of the client. So 
really, a project that ends up with any dependency downloads directly 
from dist/java-repository is not the best solution, ibiblio is the more 
persistent and canonical point to be downloading from at this point.

It might be good to go through the Apache projects that are in 
java-repository and see if any are packaged to download dependencies 
from there, I doubt it that here would be any occurances however. As a 
majority of the files were originally published to/against ibiblio in 
the first place.

cheers,
MArk

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Removing interim dated builds from /www/www.apache.org/dist/java-repository

2005-01-04 Thread Mark R. Diggory
Please excuse the cross post. I'm planning to run some commands on the 
java-repository to remove interim builds and SNAPSHOTS. Specifically, 
I'll be running:

#!/bin/sh
 LOCATION=/www/www.apache.org/dist/java-repository

find ${LOCATION} -name '*200[0-4]*' | while read j;
do
   rm -f $j;
done
find ${LOCATION} -name '*SNAPSHOT*' | while read j;
do
   rm -f $j;
done
find ${LOCATION} -name '*snapshot-version*' | while read j;
do
   rm -f $j;
done

I want to announce this so that folks have an opportunity to object or 
make other recommendations.

For anyone wondering, all these files are currently available in 
/www/archive.apache.org/dist/java-repository as well. So if anything 
needs recovery it can be recovered from there.

-Mark
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Jakarta download pages Was: download pages in j.a.o.

2004-12-29 Thread Mark R. Diggory
I'm late to this discussion, so pardon if I'm rehashing something said 
earlier.

It would be very advantageous to consider how the ASF Repository factors 
into the the download picture. I've been hoping to see some integration 
between the contents of dist and those of dist/java-repository. The 
ability of the repository download requests to be sent to the mirrors 
using closer.cgi or something similar would be very powerful.

This url structure would be something that helped.
http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
Pointing Maven at the asf repository as:
http://www.apache.org/download.cgi/repository
http://www.apache.org/download.cgi/repository/commons-lang/jars/commons-lang-1.4.jar
would begin to use the mirrors more appropriately (if the maven client 
handles redirects appropriately.

better yet, how about a separate virtual host just for downloads that is 
an implementation of the ASF Repository.

http://download.apache.org/jakarta/commons/lang/jars/commons-lang-1.4.jar
http://download.apache.org/struts/distributions/struts-x.x.zip
http://download.apache.org/xml/xerces/jars/xerces-x.x.jar
http://download.apache.org/xml/xerces/distributions/xerces-x.x.zip
the download.cgi could handle all requests to the virtual host and 
properly redirect the user to a mirror.

-mark
Henri Yandell wrote:

On Tue, 28 Dec 2004, Phil Steitz wrote:
Henri Yandell wrote:

On Tue, 28 Dec 2004, Martin Cooper wrote:
I think, if we had a standard template for download pages, each
subproject could have its own download page, something like we have
for Struts:
http://struts.apache.org/download.cgi

Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects 
didn't have to really care about it; ie) they'd just link to:

http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
You can link directly now, using the anchors in the main Jakarta 
download pages, e.g.
http://jakarta.apache.org/site/binindex.cgi#commons-math

Yep. There are two poor things about this:
1) As with the new header, it means most people jump the text on 
keys/md5 etc.

2) It seems pointless from a user point of view. The bit they're 
interested in is very small compared to the size of the whole page 
they're being dumped in.

The struts download page is a lot nicer from a user point of view, 
though one criticism is that the pgp/key stuff is at the bottom of the 
page there and unlikely to be seen by a downloader too. It's also 
serving more than one file.

I'd like to see each project with links to something like:
http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip
which would show a page that automatically does the pgp/md5 blurb, links 
to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles 
the mirror stuff. We'd use the download.cgi for both binary and source.

Hen
-
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: Deciding on Java futures?

2004-10-29 Thread Mark R. Diggory
Noel,
How can we find out whats already planned by Sun. For instance, I'm sure 
us Commons Math folks would all like to see the Nist/Java Grande 
rectangular matrices issue finalized and implemented.

http://jcp.org/en/jsr/detail?id=083
But its difficult to see if this is stalled or dead at this point. Seems 
the issue is not that Sun needs more ideas, seems they need better 
execution on the those that already do exist in the JCP. Theres a severe 
bottleneck here where if there isn't a lead at Sun to channel the JCP 
into the standard, then it just sits there, festering and dying. My fear 
is that the same would happen to any of Jakarta's efforts to do the 
same. Ultimately, I wonder why Sun is going around their own designed 
community process to interact with Apache concerning these sorts of 
questions? Who's spearheading this from Sun's side? Is this evidence 
that JCP is a failing process?

-Mark
--
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]


md5 checksum formats on BSD

2004-08-11 Thread Mark R. Diggory
A subject came up on the Tomcat developers list which we thought should
be shared with the whole community.
Specifically, it was found that BSD's default md5 format is not parsable
by some external programs that clients are using to verify the integrity
of our downloads.
While we thought this not mission critical, we did think it wise that
we should begin making the following recommendation when creating md5
signatures for files.
We discovered there is a -r option which makes BSD md5 generate md5
signature format that is the same as that of GNU's md5sum, a more
prevalent tool for generating checksums of files.
We also found that on BSD, cksum is comparable to to GNU's md5sum
--check functionality and that it works on both the BSD and GNU file
format.
Our recommendation is that Apache should be signing with the more
prevalent GNU formated output so that other file integrity software
available on platforms other than BSD can verify the file integrity more
easily. This is simply accomplished by adding the -r option
For Example:
%md5 -r foo.bar  foo.bar.md5
We should remember that md5 signatures are for the public to verify the
integrity of our software package distributions. Making sure that 
everyone can verify our file integrity is probably more important than 
maintaining a platform specific format because it is the default for the 
OS these were generated on.

-Mark Diggory
Mark R. Diggory wrote:
For example here are the outputs of the various signing tools we use at 
this time:

BSD md5:
  md5 commons-collections-3.1.jar
MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36
while the GNU md5 script generates the following:
[EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36  commons-collections-3.1.jar
And maven just generates and uses:
d1dcb0fbee884bb855bb327b8190af36
Yes, the nice thing about BSD md5 is that the -r can be used to make it 
look like the GNU md5sum output, it would probably be good if we started 
to use this as it will be more prevalent and possibly is the closest one 
can get to a standard:

  md5 -r commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar
Mark R. Diggory wrote:
This is the md5 output generated by BSD md5 and not necessarily a 
standard, GNU md5sum generates a different format that is not 
standard as well. For maven, just the checksum portion of the 
content is stored in the file.

It would be nice if there was a standard in this area, but I have yet 
to see one in the internet community. We have the same problem with 
generating md5 checksums for the maven repository at the moment.

-Mark
Shapira, Yoav wrote:
Hi,
The format I use for MD5 sums is the standard one.  Every other project
I know uses this format, so I think if anything this user needs to
adjust his preferences ;)  However, if there's a standard or spec
somewhere that mandates we use md5 -r (reverse output format), then
sure, someone point me to it and I'll follow that spec when signing
releases.
Yoav Shapira
Millennium Research Informatics

-Original Message-
From: jean-frederic clere [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 5:26 AM
To: Tomcat Developers List
Subject: Re: Fwd: md5 sums for jakarta downloads
Pier Fumagalli wrote:
Begin forwarded message:

From: Andy Mudrak [EMAIL PROTECTED]
Date: 10 August 2004 00:57:44 BST
To: [EMAIL PROTECTED]
Subject: md5 sums for jakarta downloads
Hi,

I noticed that your MD5 sums on your website are not all formatted
correctly.  I specifically downloaded the Tomcat 5.0.27 MD5 file,

and
found this out.  Not that it's a big deal or anything like that, but
it'd be good to have the MD5 properly formatted, that is the MD5 sum
and then the file name...

I am not sure that is a good idea:
+++
-bash-2.05b$ openssl md5  toto
MD5(toto)= efd6b079984c77cd80254ff266e9ab43
+++
And looking in the Jakarta Binary downloads I have found that a lot

of
other
MD5 file are using the Tomcat format.


Thanks,

Andy Mudrak
[EMAIL PROTECTED]



-
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://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: md5 checksum formats on BSD

2004-08-11 Thread Mark R. Diggory
Both Maven and Ant only insert only the checksum into the file. I 
believe they resolve the location of the actual source file from the 
name of the checksum file, which forces all checksum files to reside in 
the same directory as thier source files.

This represents a problem if you want verify the generated checksum on 
*nix or BSD using md5sum or cksum as these tools require the file path 
(relative to the md5) to actually be present in the md5 file and I do 
not believe there is any way around this.

-Mark
Martin Cooper wrote:
Do you happen to know which flavour Ant creates? For Struts releases,
the Ant build file generates the MD5 files using the checksum task.
That seems like a pretty obvious way to generate them for any project
that uses Ant, but the task doesn't appear to have any switch for
determining flavour (and the docs don't appear to say anything about
different flavours of MD5).
--
Martin Cooper
On Wed, 11 Aug 2004 13:06:00 -0400, Mark R. Diggory
[EMAIL PROTECTED] wrote:
 

A subject came up on the Tomcat developers list which we thought should
be shared with the whole community.
Specifically, it was found that BSD's default md5 format is not parsable
by some external programs that clients are using to verify the integrity
of our downloads.
While we thought this not mission critical, we did think it wise that
we should begin making the following recommendation when creating md5
signatures for files.
We discovered there is a -r option which makes BSD md5 generate md5
signature format that is the same as that of GNU's md5sum, a more
prevalent tool for generating checksums of files.
We also found that on BSD, cksum is comparable to to GNU's md5sum
--check functionality and that it works on both the BSD and GNU file
format.
Our recommendation is that Apache should be signing with the more
prevalent GNU formated output so that other file integrity software
available on platforms other than BSD can verify the file integrity more
easily. This is simply accomplished by adding the -r option
For Example:
%md5 -r foo.bar  foo.bar.md5
We should remember that md5 signatures are for the public to verify the
integrity of our software package distributions. Making sure that
everyone can verify our file integrity is probably more important than
maintaining a platform specific format because it is the default for the
OS these were generated on.
-Mark Diggory
Mark R. Diggory wrote:
   

For example here are the outputs of the various signing tools we use at
this time:
BSD md5:
 md5 commons-collections-3.1.jar
MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36
while the GNU md5 script generates the following:
[EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36  commons-collections-3.1.jar
And maven just generates and uses:
d1dcb0fbee884bb855bb327b8190af36
Yes, the nice thing about BSD md5 is that the -r can be used to make it
look like the GNU md5sum output, it would probably be good if we started
to use this as it will be more prevalent and possibly is the closest one
can get to a standard:
 md5 -r commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar
Mark R. Diggory wrote:
 

This is the md5 output generated by BSD md5 and not necessarily a
standard, GNU md5sum generates a different format that is not
standard as well. For maven, just the checksum portion of the
content is stored in the file.
It would be nice if there was a standard in this area, but I have yet
to see one in the internet community. We have the same problem with
generating md5 checksums for the maven repository at the moment.
-Mark
Shapira, Yoav wrote:
   

Hi,
The format I use for MD5 sums is the standard one.  Every other project
I know uses this format, so I think if anything this user needs to
adjust his preferences ;)  However, if there's a standard or spec
somewhere that mandates we use md5 -r (reverse output format), then
sure, someone point me to it and I'll follow that spec when signing
releases.
Yoav Shapira
Millennium Research Informatics

 

-Original Message-
From: jean-frederic clere [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 5:26 AM
To: Tomcat Developers List
Subject: Re: Fwd: md5 sums for jakarta downloads
Pier Fumagalli wrote:
   

Begin forwarded message:
 

From: Andy Mudrak [EMAIL PROTECTED]
Date: 10 August 2004 00:57:44 BST
To: [EMAIL PROTECTED]
Subject: md5 sums for jakarta downloads
Hi,

I noticed that your MD5 sums on your website are not all formatted
correctly.  I specifically downloaded the Tomcat 5.0.27 MD5 file,
   

and
 

found this out.  Not that it's a big deal or anything like that, but
it'd be good to have the MD5 properly formatted, that is the MD5 sum
and then the file name...
   

I am not sure that is a good idea:
+++
-bash-2.05b$ openssl md5  toto
MD5(toto)= efd6b079984c77cd80254ff266e9ab43
+++
And looking in the Jakarta

Re: md5 checksum formats on BSD

2004-08-11 Thread Mark R. Diggory
Excuse the cross post, I wanted to get this out to the Ant and Maven 
lists as well.

In the larger community the BSD default format is refered to as SVF 
(Simple File Verification) and the GNU md5sum format as MD5SUM, I 
suspect it would be good to see these as output features/options that 
could be set within Ant and Maven to allow developers to choose the md5 
output format one would like to use. Yes, I do believe this would be an 
excellent feature enhancement to these tools.

-Mark
Mark R. Diggory wrote:
Both Maven and Ant only insert only the checksum into the file. I 
believe they resolve the location of the actual source file from the 
name of the checksum file, which forces all checksum files to reside 
in the same directory as thier source files.

This represents a problem if you want verify the generated checksum on 
*nix or BSD using md5sum or cksum as these tools require the file path 
(relative to the md5) to actually be present in the md5 file and I do 
not believe there is any way around this.

-Mark
Martin Cooper wrote:
Do you happen to know which flavour Ant creates? For Struts releases,
the Ant build file generates the MD5 files using the checksum task.
That seems like a pretty obvious way to generate them for any project
that uses Ant, but the task doesn't appear to have any switch for
determining flavour (and the docs don't appear to say anything about
different flavours of MD5).
--
Martin Cooper
On Wed, 11 Aug 2004 13:06:00 -0400, Mark R. Diggory
[EMAIL PROTECTED] wrote:
 

A subject came up on the Tomcat developers list which we thought should
be shared with the whole community.
Specifically, it was found that BSD's default md5 format is not 
parsable
by some external programs that clients are using to verify the 
integrity
of our downloads.

While we thought this not mission critical, we did think it wise that
we should begin making the following recommendation when creating md5
signatures for files.
We discovered there is a -r option which makes BSD md5 generate md5
signature format that is the same as that of GNU's md5sum, a more
prevalent tool for generating checksums of files.
We also found that on BSD, cksum is comparable to to GNU's md5sum
--check functionality and that it works on both the BSD and GNU file
format.
Our recommendation is that Apache should be signing with the more
prevalent GNU formated output so that other file integrity software
available on platforms other than BSD can verify the file integrity 
more
easily. This is simply accomplished by adding the -r option

For Example:
%md5 -r foo.bar  foo.bar.md5
We should remember that md5 signatures are for the public to verify the
integrity of our software package distributions. Making sure that
everyone can verify our file integrity is probably more important 
than
maintaining a platform specific format because it is the default for 
the
OS these were generated on.

-Mark Diggory
Mark R. Diggory wrote:
  

For example here are the outputs of the various signing tools we 
use at
this time:

BSD md5:
 md5 commons-collections-3.1.jar
MD5 (commons-collections-3.1.jar) = d1dcb0fbee884bb855bb327b8190af36
while the GNU md5 script generates the following:
[EMAIL PROTECTED] jars]$ md5sum commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36  commons-collections-3.1.jar
And maven just generates and uses:
d1dcb0fbee884bb855bb327b8190af36
Yes, the nice thing about BSD md5 is that the -r can be used to 
make it
look like the GNU md5sum output, it would probably be good if we 
started
to use this as it will be more prevalent and possibly is the 
closest one
can get to a standard:

 md5 -r commons-collections-3.1.jar
d1dcb0fbee884bb855bb327b8190af36 commons-collections-3.1.jar
Mark R. Diggory wrote:


This is the md5 output generated by BSD md5 and not necessarily a
standard, GNU md5sum generates a different format that is not
standard as well. For maven, just the checksum portion of the
content is stored in the file.
It would be nice if there was a standard in this area, but I have yet
to see one in the internet community. We have the same problem with
generating md5 checksums for the maven repository at the moment.
-Mark
Shapira, Yoav wrote:
  

Hi,
The format I use for MD5 sums is the standard one.  Every other 
project
I know uses this format, so I think if anything this user needs to
adjust his preferences ;)  However, if there's a standard or spec
somewhere that mandates we use md5 -r (reverse output format), then
sure, someone point me to it and I'll follow that spec when signing
releases.

Yoav Shapira
Millennium Research Informatics



-Original Message-
From: jean-frederic clere 
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 5:26 AM
To: Tomcat Developers List
Subject: Re: Fwd: md5 sums for jakarta downloads

Pier Fumagalli wrote:
  

Begin forwarded message:


From: Andy Mudrak [EMAIL PROTECTED]
Date: 10 August 2004 00:57:44 BST
To: [EMAIL PROTECTED]
Subject

Maven Repository Status

2004-04-23 Thread Mark R. Diggory
I just wanted to drop everyone a note to let you know that I made the 
rsync of the java-repository between Apache and Ibiblio much more stable 
this week. It now occurs every 4 hours (EST 12am, 4am, 8am ...). If you 
ever encounter issues with your jars not getting synced into ibiblio, 
please contact me.

-Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Wiki Migration

2004-02-27 Thread Mark R. Diggory
So would I for jakarta stuff, but this stuff goes above and beyond Jakarta.

Geir Magnusson Jr. wrote:

On Feb 26, 2004, at 10:31 PM, Mark R. Diggory wrote:

What about non-project related wiki content like the following, where 
would that go in the new wiki?

http://nagoya.apache.org/wiki/apachewiki.cgi?GettingInvloved
http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest
http://nagoya.apache.org/wiki/apachewiki.cgi?IrcChannels


I'd like for us to have a general Jakarta wiki for the whole community

geir

-Mark

Henri Yandell wrote:

Sounds good to me, I think Commons can work fine as a single Wiki.
Continues to allow for interesting inter-component relations. Taglibs 
also
fits well as a single Wiki.
+1 (PMC)
I'm unsure if either have a wiki, but am prepared to learn the 
necessaries
to migrate if need be.
Hen
On Fri, 27 Feb 2004, Scott Eade wrote:

According to
http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki
and
http://wiki.apache.org/general/UseModMigration
we eventually need to migrate the existing Usemod wiki content over to
the new MoinMoin wiki.
For jakarta I would imagine that we will want a subwiki per subproject.

I would like to migrate the turbine project pages across as a subwiki
called turbine under a Jakarta heading (with change diffs going to the
turbine-dev mailing list).
I am only volunteering to migrate the turbine project pages, but if
others want to put their hands up for other subprojects then perhaps a
single request to infrastructure could be used to request multiple 
subwikis.

As I understand it there needs to be a consensus in the jakarta PMC 
that
this is the way forward before a request can be made to infrastructure
to create any subwikis.  Do any PMC members object to this approach?

Thanks,

Scott

--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au


-
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://www.hmdc.harvard.edu
-
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: Wiki Migration

2004-02-26 Thread Mark R. Diggory
What about non-project related wiki content like the following, where 
would that go in the new wiki?

http://nagoya.apache.org/wiki/apachewiki.cgi?GettingInvloved
http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest
http://nagoya.apache.org/wiki/apachewiki.cgi?IrcChannels
-Mark

Henri Yandell wrote:

Sounds good to me, I think Commons can work fine as a single Wiki.
Continues to allow for interesting inter-component relations. Taglibs also
fits well as a single Wiki.
+1 (PMC)

I'm unsure if either have a wiki, but am prepared to learn the necessaries
to migrate if need be.
Hen

On Fri, 27 Feb 2004, Scott Eade wrote:


According to
http://nagoya.apache.org/wiki/apachewiki.cgi?MigrateFromThisWiki
and
http://wiki.apache.org/general/UseModMigration
we eventually need to migrate the existing Usemod wiki content over to
the new MoinMoin wiki.
For jakarta I would imagine that we will want a subwiki per subproject.

I would like to migrate the turbine project pages across as a subwiki
called turbine under a Jakarta heading (with change diffs going to the
turbine-dev mailing list).
I am only volunteering to migrate the turbine project pages, but if
others want to put their hands up for other subprojects then perhaps a
single request to infrastructure could be used to request multiple subwikis.
As I understand it there needs to be a consensus in the jakarta PMC that
this is the way forward before a request can be made to infrastructure
to create any subwikis.  Do any PMC members object to this approach?
Thanks,

Scott

--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au


-
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://www.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: jelly releases

2004-02-11 Thread Mark R. Diggory
Now that there is a Maven Repository on the mirrors, it doesn't need to 
be specifically pointed there, thats just one mirror of it now.

http://www.apache.org/dist/java-repository/commons-jelly/
http://apache.130th.net/java-repository/commons-jelly/
...
http://www.apache.org/dyn/closer.cgi
The ibibilio repository is probably fine, it is updated from the apache 
dist directory every four hours. And is also the location the jar is 
pulled from when using Maven to resolve the dependency

-Mark

Torsten Curdt wrote:
Is there a particular reason why the jelly release is
hosted on ibiblio.org? (No nagging - just curious)
--
Torsten


-
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]


[release managers] Rsync with Apache's Maven repository

2004-01-29 Thread Mark R. Diggory
Release Managers,

rsync is now active between apache and www.ibiblio.org/maven every 4 hours.

minotaur.apache.org:/www/www.apache.org/dist/java-repository

contents are now rsynced directly to

www.ibibilio/maven.

by ibibilio.

This means anything you place into java-repository will be available 
through maven within 4 hours. To start deploying distributions to 
java-repository on minotaur set your Maven build.properties or 
project.properties to the following:

SNIP
#This is the host that Maven will attempt
#to deploy the distribution to during a dist:deploy.
maven.repo.central=minotaur.apache.org  
#This is the directory that Maven will
#copy the distribution to during a dist:deploy. 
maven.repo.central.directory=/www/www.apache.org/dist/java-repository

#ssh configuration settings just require your apache id to log on with
maven.username=apache-user-name
/SNIP
Cheers,
Mark
--
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]


PGP Key signing

2004-01-20 Thread Mark R. Diggory


I'm finishing up writing a PGP plugin for maven to generate 
public/private keypairs, sign artifacts, verify artifacts and do 
encryption/decryption. This should eventually make publishing to the 
maven repository very smooth and easy to accomplish.

I would like to gather together the following into some PGP/MD5 FAQ 
documentation for the Apache site:

1.) Proper procedures for generating and publishing PGP keys for use at 
 Apache.

Answer simple questions like;
where to place your public keys.
where not to place your private keys.
2.) How to go about key signing to build up the web of trust at Apache. 
When I was browsing Henk's page I noticed the web of trust stuff:

http://www.apache.org/~henkp/trust/apache.html
http://apache.org/~erikabele/wot/wot.html
http://www.apache.org/~henkp/md5/doc.html
http://www.apache.org/~henkp/sig/
3.) As much other interesting errata as possible concerning PGP 
signatures and MD5 checksums.

If you have any more interesting links, important documentation, etc, or 
come across anything. I'd like to start building them up into a 
canonical source on this stuff.

thanks,
Mark
--
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: [maven] developer repostory revisited

2004-01-11 Thread Mark R. Diggory
+1 I think this is very important to both automation and consistency in 
deliverables.

-Mark

Tim O'Brien wrote:
I second Matthew's suggestion that we create a repository that works 
with Maven as it is.
Create the directory /www/www.apache.org/repository/, this repository 
will contain soft links to jars and other deliverables we wish to 
distriute to ibilio and other repositories.  After a certain period of 
time, we can ask that whomever maintains the ibiblio repository use this 
source as the ASF's authoritative collection of distributables for Maven.

This doesn't prevent others from thinking about other ways to create a 
repository - like Ruper, or the ever active repository mailing list, but 
it solves a practical problem which is preventing progress for many. 
immediately.

Tim

__matthewHawthorne wrote:

In this thread:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=563250 

The idea of a Maven repository located on an ASF machine was discussed.
It seems like something that is doable, and also has been requested by
the ASF.
I would like to make this happen, but I am not sure what the official
steps to take are.  If a request has to be made to infrastructure, I
read that someone from a PMC has to do it.
Here are the steps that I can see:

1) Choose a machine, and create the directory.

2) Choose the URL to map the repo to
(something like maven.apache.org/repository ?)
3) Possibly modify Maven to search this repository as well as ibiblio by
default
4)  Modify nightly build script(s) to deploy to this directory as well
as others, so that all nightlies and SNAPSHOTs could be instantly 
available.

The last time I mentioned this, a few people pointed me to the
[EMAIL PROTECTED] project, which seems to be defining a
next-generation repository structure for Maven and other uses.  This
looks great, but I'm interested in something that will work with Maven
right now.
I think this is long overdue, since Apache projects that have been
released for months are still not available on ibiblio.  We need an
easier way.
Anyone else interested?  How can we make this happen?  Thanks for any 
help!



-
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: Why you *want* to be on the PMC

2003-12-18 Thread Mark R. Diggory


Henri Yandell wrote:

Obviously, something is afoot ... otherwise, why are healthy projects
moving out of Jakarta, up to the top level (Ant, Maven and now logging)?
Is that the destiny of Jakarta, to be a second-level incubator for
projects on the way to TLP status?  If so ... embrace that.


As far as I know, there is much ASF community resistance to Jakarta
continuing to be an Incubator. We're no longer anywhere near server-side
Java at ASF. Basically we are now:  What's left of the old server-side
Java project at ASF, but a bit confused about it all.
Hen

Your right, the real question is  What is Jakarta?

Is it a java component incubator or is it a umbrella for server side 
java?

The idea of server side java is a weak one in my book. There is no 
such thing as server side java and client side java, its all the 
same JVM! There are a few components that act as servers (tomcat, james, 
etc). There are components that are developed with the intention of 
running on those services (Struts, JSTL, Velocity ...) And there are 
java components that are totally agnostic to this artificial boundary of 
client/server side java (most of jakarta commons). There are 
components that were designed to be intentional gui clients (JMeter 
etc). But what they all have in common is java.

Jakarta is a java component incubator!

I suspect the components that have left Jakarta have done so because 
they've felt limited by its past mandate as server side java or 
things that run on tomcat...

Either way, language based delineations in top level apache project 
boundaries are logical given that its often the case that a subproject 
is usually developed with one language in mind (java, perl, c, php, 
xml). Yes there are overlaps and exceptions to this case (Xerces and 
Xalan for instance), but they are usually consolidated under an 
appropriate umbrella of commonality (in this case XML). I'm not 
convinced that a language agnostic top level incubator is a bad or 
good thing, I just think it may not be a very popular thing because of 
these umbrellas of commonality that arise based on language and 
implementation. In context to the parent projects umbrella is where the 
most appropriate creativity and invention arise, leading to the most 
successful subprojects.

-Mark

--
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: Choosing against Jakarta

2003-12-15 Thread Mark R. Diggory
Whatever the fate of the name Jakarta and/or Commons you can reliably 
assume the content housed at what is now called Apache Jakarta will 
persist. If it is the case that a reorganization or regrouping of 
PMC's does occur in response to growing pains, this is not going to 
result in any risk to the existence of the individual subprojects 
themselves. I don't think its unreasonable to propose a donation to a 
new/existing subproject. If down the road changes occur to the 
organization of groups, I'm sure there will be much sensitivity to 
maintaining the neccessities that the individual sub-projects require.

-Mark

Stephen Colebourne wrote:

As some of you may know, I look after my own date and time code in Java at
www.joda.org. I had been hoping to bring this code to Apache, as I believe
it to be a very good fit with developments within Jakarta/Jakarta-commons.
Today I decided not to pursue this option for the time being, until the
situation with Jakarta's future is resolved. Instead I applied for a new
sourceforge project to house it more cleanly.
Why post this here? Because I believe that others may also be questioning
the value of Jakarta. I confess that I have no idea what, or if, Jakarta
will look like in 6 months time. Certainly it made no sense to me to attempt
to get a new project adopted by Jakarta at the moment.
Stephen

-
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]


Site and CVS appear to be down

2003-11-18 Thread Mark R. Diggory
Seems the www and the cvs.apache.org hosts are currently 
unreachable/down. Are others encountering this?

-Mark

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: BSD style code and licensing issues

2003-11-11 Thread Mark R. Diggory
That last thread seemed such a waste of bandwidth. Unfortunately it 
swallowed a discussion we were trying to start concerning Licensing 
issues associated with the consideration of using BSD style licensed 
code in Apache Projects.

To formulate a more solid point people can respond to:

Can BSD licensed code be added to Apache licensed code bases? Can both 
licenses be maintained? If so can someone direct me to an example of this?

-Mark

robert burrell donkin wrote:

On 9 Nov 2003, at 22:01, Mark R. Diggory wrote:

Mostly, I'm trying to ascertain the best strategies for donations that 
will be arising in the near future from projects that are now 
relicensed using a BSD style license (portions of Colt and RngPack). I 
am working through details with these individuals and organizations to 
legally and ethically provide vehicles for the code from these 
projects to evolve and be included into the math project. This is 
currently through both individual interaction with the authors to get 
them to donate and through re-licensing endeavors.

So to try to form a clearer question. If code is licensed using the 
follow style licenses:

http://www.honeylocust.com/RngPack/rngpack/LICENSE
http://dsd.lbl.gov/~hoschek/colt/license.html
With agreement from the authors ,what is the best approach for 
integrating code under this license into an Apache project?


a very good question. now would be a good time for those folks with 
experience of this issue to take up the batten...

I'm slightly stumped, I see no references to a Licensing listserv 
anywhere in the Apache www site?


i suspect that it's a committer-only list. anyone know for sure?

- robert

-
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: BSD style code and licensing issues

2003-11-09 Thread Mark R. Diggory
Mostly, I'm trying to ascertain the best strategies for donations that 
will be arising in the near future from projects that are now relicensed 
using a BSD style license (portions of Colt and RngPack). I am working 
through details with these individuals and organizations to legally and 
ethically provide vehicles for the code from these projects to evolve 
and be included into the math project. This is currently through both 
individual interaction with the authors to get them to donate and 
through re-licensing endeavors.

So to try to form a clearer question. If code is licensed using the 
follow style licenses:

http://www.honeylocust.com/RngPack/rngpack/LICENSE
http://dsd.lbl.gov/~hoschek/colt/license.html
With agreement from the authors ,what is the best approach for 
integrating code under this license into an Apache project?

I'm slightly stumped, I see no references to a Licensing listserv 
anywhere in the Apache www site?

-Mark

robert burrell donkin wrote:
hi mark

IMHO there are two different issues here.

1. what's the right thing to do legally...

i don't recall any problems with including BSD licensed source 
(providing that the license is followed which probably means adding the 
appropriate credits) but the right place to ask this question is 
licensing at apache.org. you'll need to subscribe first (probably using 
your apache address).

2. what's the right thing to do ethically...

ethics are important for other reasons. being generous with credit often 
helps to stop flamewars before they start. i'd say that the right thing 
to do ethically is to put a note crediting the original author(s) below 
the the apache license.

it's usually possible to satisfy both 1 and 2 with an appropriate choice 
of words.

- robert

On 7 Nov 2003, at 20:38, Mark R. Diggory wrote:

Is there any sort of policy on the inclusion of BSD style licensed 
code into an Apache Project outside of relicensing.

As well, any standard set of policies/procedures on if that code is 
donated to a project? I understand that there are procedures for 
donation. But have some questions concerning this:

http://www.apache.org/licenses/software-grant.txt

Does supplying this document properly completed constitute a 
relicensing of donated code to Apache?

thanks,
--
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]


-
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]


Can't commit any new bugs

2002-11-16 Thread Mark R. Diggory
I've tried numerous times, but when I try to commit a new bug I never 
get a response from the server, it times out, the bug is not commited.

I'm trying to add one to the

http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons

product=Commons
version=nightly builds
component=HttpClient
os=all
platform=all
severity=enhancment
initial state=NEW

summary=...
description=...

Thank you,
-Mark Diggory
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]