Re: Removing interim dated builds from /www/www.apache.org/dist/java-repository
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
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
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
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.
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?
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
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]
Can't commit any new bugs
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]
