Fw: Depot
Sent from wrong account... - Original Message - From: Adam Jack [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Sunday, October 31, 2004 6:26 AM Subject: Depot Folks Sorry I've been offline a while, I've had other priorities to take care of. I will be sad to let Depot go, but I suspect it is time. I am starting to believe that without a lot more community drive (or just outright individual stubbornness to continue) that something like a version/repository idea is too much to pull off. Further, I suspect that Javasoft ought be handling it, not other groups. Also, I do suspect we tried to do too much (and yes, I probably was over enthusiastic and helped over engineer some parts) so couldn't keep up with it. That, and (for me) the transition into incubation caused too much environment awkwardness, and I lost momentum. Whatever the case, long and the short is that we didn't seem to build on a simple use case, we didn't use it first and code it second. Basically it stagnated underneath us. I don't think I'll ever quite understand why, but despite technical merits (IMHO) something just didn't spark others. Maybe marketing, maybe star alignment, definitely community. That all said, I really really struggle with this. So much effort, so much good stuff, so close. Gak! I hate letting go. regards, Adam
Re: Distribution
the dist is easy, just do a ant dist hmm not sure it get dependent jars. I will check this weekend. But you want a install to DEPOT_HOME I will also do that this weekend. Yup, it is the 'extras' I am looking for. If we can put some effort into this aspect, I think we can start using it more. Usage usage usage... regards Adam
Re: Call generated classes VersionStamp
On Fri, 6 Aug 2004, Nick Chalko wrote: I think we should call generated version classes VersionStamp. This should reduce confusion with our Version interface. FWIIW: The naming of 'Version' was used because the discovery code was designed with the end-user (not us) in mind. Folks out there have classes they call Version thay we wanted to pick up. That said, we could teach it more aliases. BTW: What (really) is the difference between VersionMarker and VersionStamp? We need to get out terminology correct, I agree, I just don't have the answers... regards, Adam
ApacheVersionTest
I set a Logger.testInit() in the start of the test, and captured this below. What is interesting is it attempts the DataTime format a few times, but then only the JakartaCommons format, I don't even see the 'Apache' version that out process this. I wonder if my recent work n Datetime caused this knock on bug. I'll check it out. DEBUG : Test logging enabled. DEBUG : Import ApacheVersion: [1.2.1] DEBUG : Import DateTime? : [1.2.1] DEBUG : Datetimestamped: Exception: org.apache.depot.version.specification.formatting.VersionFormatException : Not a Datetime format [1.2.1] in [1.2.1] for [1], format: DatetimestampedVersionFormat org.apache.depot.version.specification.formatting.VersionFormatException: Not a Datetime format [1.2.1] in [1.2.1] for [1], format: DatetimestampedVersionFormat at org.apache.depot.version.specification.formatting.format.DatetimestampedVersionFormat.parseVersion(DatetimestampedVersionFormat.java:61) at org.apache.depot.version.impl.VersionImporter.importApacheVersion(VersionImporter.java:164) at org.apache.depot.version.impl.VersionImporter.importApacheVersion(VersionImporter.java:131) at org.apache.depot.version.impl.ApacheVersion.init(ApacheVersion.java:206) at org.apache.depot.version.impl.ApacheVersionTest.assertApacheVersion(ApacheVersionTest.java:40) at org.apache.depot.version.impl.ApacheVersionTest.testApacheVersionString(ApacheVersionTest.java:26) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) DEBUG : Spec: DatetimestampedVersionSpecification:DatetimestampedVersionFormat Exception: org.apache.depot.version.specification.formatting.VersionFormatException : Not a Datetime format [1.2.1] in [1.2.1] for [1], format: DatetimestampedVersionFormat org.apache.depot.version.specification.formatting.VersionFormatException: Not a Datetime format [1.2.1] in [1.2.1] for [1], format: DatetimestampedVersionFormat at org.apache.depot.version.specification.formatting.format.DatetimestampedVersionFormat.parseVersion(DatetimestampedVersionFormat.java:61) at org.apache.depot.version.impl.VersionImporter.importApacheVersion(VersionImporter.java:191) at org.apache.depot.version.impl.VersionImporter.importApacheVersion(VersionImporter.java:131) at org.apache.depot.version.impl.ApacheVersion.init(ApacheVersion.java:206) at org.apache.depot.version.impl.ApacheVersionTest.assertApacheVersion(ApacheVersionTest.java:40) at org.apache.depot.version.impl.ApacheVersionTest.testApacheVersionString(ApacheVersionTest.java:26) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) DEBUG : Import ApacheVersion: [1.2.1-dev] DEBUG : Import DateTime? : [1.2.1-dev] DEBUG : Datetimestamped: Exception: org.apache.depot.version.specification.formatting.VersionFormatException : Not a Datetime format [1.2.1-dev] in [1.2.1-dev] for [1], format: DatetimestampedVersionFormat org.apache.depot.version.specification.formatting.VersionFormatException: Not a Datetime format [1.2.1-dev] in [1.2.1-dev] for [1], format: DatetimestampedVersionFormat at
Deleting stuff
Folks From now on can we discuss something before deleting it? I know we had some baggage, but I don't think we have much/any left (in Updater, and Version I'd like to keep as my problem please). Right now I am trying to get some key unit tests working and I am finding that the main Artifact*.getTest static helper methods appear missing. I spent a lot of really boring time adding those, and the prospect of doing it again is seriously disheartening. (SVN is, IMHO, a pain in the rear to recover from, and I don't plan on trying to guess old version numbers to copy over and manually merge from). Please, although I doubt anything more is remaining to be snipped, please let's discuss twice, cut once. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: Deleting stuff
Ok, I see that viewcvs can help me find old code. I can go borrow it again. Markus, the if the getText stuff is ugly I'm game to change it to a better set of Mock objects (I just couldn't think of a better way at the time). I'll add them back (for now) but then happily work w/ folks to clean them out of important classes and get them into better places. regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Dev [EMAIL PROTECTED] Sent: Thursday, July 29, 2004 7:40 AM Subject: Deleting stuff Folks From now on can we discuss something before deleting it? I know we had some baggage, but I don't think we have much/any left (in Updater, and Version I'd like to keep as my problem please). Right now I am trying to get some key unit tests working and I am finding that the main Artifact*.getTest static helper methods appear missing. I spent a lot of really boring time adding those, and the prospect of doing it again is seriously disheartening. (SVN is, IMHO, a pain in the rear to recover from, and I don't plan on trying to guess old version numbers to copy over and manually merge from). Please, although I doubt anything more is remaining to be snipped, please let's discuss twice, cut once. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: Deleting stuff
You mean the statement that the work was really boring? ;-) ;-) Ok, I've recovered it now. And yes, I'd love to see a better way to create mock objects. Right now the MockRepository (and some unit tests) need to create these objects, so -- so long as we can find a nice way to do that [preferably under src/test, and perhaps not shipped w/ releases], I'm definitely +1 to see the statics removed the core classes. BTW: Sorry if I was crabby, I'm frustrated that I'm not getting this back into shape quicker/sooner. I know we are close, I know we have a good foundation, I think it is just hidden behind some confusion. I like your Javadoc comments, and I'll try to add to those. I'm hoping we are 'clean' within no more than a week, and we -- total group -- understand the codebase we have, and how it works. That is the main short term goal, IMHO. Also, I think it is key that we get green and stay green -- not having working unit tests means we don't know when we delete/break something important. For me (in Eclipse) I couldn't run the Ant unit tests, but I think I now can. I'll work to get the tests working, and then we can rest easier that we can hack w/o breaking (undetected). regards, Adam - Original Message - From: Markus M. May [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Thursday, July 29, 2004 7:55 AM Subject: Re: Deleting stuff Hmm, this was the testing stuff I was working on currently. Sorry for the delay :-( I do prefer the creation of the testing objects in the test class. And I definitly agree on your statement in the first mail :-) Greetz Markus Ok, I see that viewcvs can help me find old code. I can go borrow it again. Markus, the if the getText stuff is ugly I'm game to change it to a better set of Mock objects (I just couldn't think of a better way at the time). I'll add them back (for now) but then happily work w/ folks to clean them out of important classes and get them into better places. regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Dev [EMAIL PROTECTED] Sent: Thursday, July 29, 2004 7:40 AM Subject: Deleting stuff Folks From now on can we discuss something before deleting it? I know we had some baggage, but I don't think we have much/any left (in Updater, and Version I'd like to keep as my problem please). Right now I am trying to get some key unit tests working and I am finding that the main Artifact*.getTest static helper methods appear missing. I spent a lot of really boring time adding those, and the prospect of doing it again is seriously disheartening. (SVN is, IMHO, a pain in the rear to recover from, and I don't plan on trying to guess old version numbers to copy over and manually merge from). Please, although I doubt anything more is remaining to be snipped, please let's discuss twice, cut once. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Add to .svnignore?
Do we need to add these to an svn ignore? F:\data\OSS\depot-versionsvn status ? src\antlet\usage.xml ? src\antlet\antletdoc.xml Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: [GUMP@brutus]: depot/depot-version failed
It really bugs me that my Eclipse does not show this problem. [javac] /usr/local/gump/public/workspace/depot/version/src/java/org/apache/depot/ver sion/VersionManager.java:44: incompatible types [javac] found : org.apache.depot.version.impl.data.VersionData [javac] required: org.apache.depot.version.Version [javac] return VersionFormatFactory.createDefaultVersionFormat().parseVersion(versionString ); [javac] ^ [javac] 1 error I just don't get it! I finally go to that line of code, and lo and behold Eclipse suddenly wakes up (although doesn't put it in the problems pane). Heck, I'd even attempted to force a full rebuild. Oh well, I think I've coded around this now. regards, Adam
Re: UpdaterConfig
Basically what I did, is, that I totally recovered/resurrected the version before the deletion of UpdaterConfig. Huh? Oh no! I did a tonne of work yesterday. How much of that is gone? I recovered these files, and hope that I did not undo any changes you did :-) I think you did. Did you recover a whole version, or recover files from a version? Can we restore my work (even if it means loosing the UpdaterConfig.configure calls) and then simply restoring UpdaterConfig (which is what I thought you first did). Basically I can wire it back in, if the file (hopefully the latest) is there. But, I can't stand the thought of loosing all the debugging/fixing work I put in yesterday, I can't easily remember what it all was. Please let me know if you can work on this today (or ever) and if not I'll either figure out how to do it myself, or plan my day to work on something different. regards Adam
Re: UpdaterConfig
Markus wrote: from what I have seen basically nothing. You did some stuff in other classes. How strange, I swear I touched overlapping classes (such as DownloadTool). Oh well, maybe I'm just nuts. Also, I swear things (some) were working, I did update, they stopped. Oh well, no biggee -- I'll dig back in and try to figure things out. Sorry for the noise. regards Adam
Re: [GUMP@brutus]: depot/depot-version failed
Adam, Cleaning up my VersionData, mismatch ? Good to see movement in Depot. Yes, I was trying. You recall what this part is doing? It is yours? Is VersionHelper yours? regards Adam
Re: UpdaterConfig
You are right, you touched the DownloaderTool. But I believe that I did not checkin any version of DownloaderTool, where functional changes are done. Take a look at the class. It should work. But ... This (from one of your SVN commit message) is what made me nervous: Modified: incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Downloade rTool.java incubator/depot/trunk/update/src/java/org/apache/depot/update/tool/Tool.java Log: Added UpdaterConfig once again regards Adam
Re: [GUMP@brutus]: depot/depot-version failed
Do we need to do this get in a Gump run? http://brutus.apache.org/gump/public/depot/depot-version/gump_work/build_depot_depot-version.html get-servletapi: [get] Getting: http://www.ibiblio.org/maven/servletapi/jars/servletapi-2.3.jar [get] local file date : Mon Jul 08 17:36:13 PDT 2002 [get] Error getting http://www.ibiblio.org/maven/servletapi/jars/servletapi-2.3.jar to /home/gump/.apache.depot/local-repository/servletapi/jars/servletapi-2.3.jar BUILD FAILED /usr/local/gump/public/workspace/depot/version/build-ant-get.xml:19: java.net.ConnectException: Connection timed out at org.apache.tools.ant.taskdefs.Get.execute(Get.java:232) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at sun.reflect.GeneratedMethodAccessor1.invokeregardsAdam- Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 12:25 PM Subject: Re: [EMAIL PROTECTED]: depot/depot-version failed Adam, Cleaning up my VersionData, mismatch ? Good to see movement in Depot. Yes, I was trying. You recall what this part is doing? It is yours? Is VersionHelper yours? regards Adam
Wrappers Context
We have an updater 'context' (which holds things like the protocol provider, and 'base directory', and such. Later it might have some user credentials.) http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/ArtifactUpdaterContext.java This context is important when doing work, in the main 'cos repo work can't be done w/o it. A Repository is (to use a non-Java term) a 'abstract' thing (i.e.a repository out of context). Combined with the (user) context it can do work. I create a RepositoryWrapper to combine the two (and do a few 'above of the interface checks' such as checking if a repository has a capability before calling it to do something.) This RepositoryWrapper seemed to be a nice useful helper, it combined some things. http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/RepositoryWrapper.java With RepositorySets we have N Repositories. I created RepositorySetWrapper (a better name might be RepositoryWrapperSet) that constructs wrappers for a while set of repositories. http://svn.apache.org/repos/asf/incubator/depot/trunk/update/src/java/org/apache/depot/update/impl/RepositorySetWrapper.java When we provide a query we can specify a RepositorySet. For us to use it we need to convert it to a RepositorySetWrapper. This gets tedious, unless we cache some of these things. I don't want the user to know about these wrappers, they have to be hidden. Something tells me something is wrong, something is out of control. Any thoughts (i.e. 'I've seen that mistake before and ...' come to mind?) Thanks in advance for any help. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: UpdaterConfig
+1 for removal of everything unused and not needed right now. after we have cleared the API we could add this once again. there is still svn which takes care about backups :-) Yup, we have enough to do to get all we want in context w/o extras, I agree. +1. That said, I suspect this is used more than we realize. We'll see. Sorry, I worded this poorly. I meant, I agree we ought trim but I don't think we can trim this, it is used. Running the unit tests (and them not working) tells me we can't. 1) Who did this? 2) Did they run unit tests before and/or afterwards? 3) Anybody know how to recover stuff from SVN? Daft as it sounds, I don't know how to (I don't know if a concept of ATTIC exists.) regards, Adam
Re: svn commit: rev 23090 - incubator/depot/trunk/update/src/java/org/apache/depot/update/config
incubator/depot/trunk/update/src/java/org/apache/depot/update/config/Updater Config.java - copied unchanged from rev 22913, incubator/depot/trunk/update/src/java/org/apache/depot/update/config/Updater Config.java Log: Resurrected UpdaterConfig.java from old Revision Thanks, how and how old? regards Adam
Re: UpdaterConfig
Sorry, a little to hasty. rebuild the stuff. right now i still have the artifacttest where some work has to be done. Not sure I follow these sentences. to recover (resurrect) a deleted file, you have to find out the old revision number and copy it (svn copy) to the working copy. then just add it once again. pretty straight forward, i think :-) I think I follow, although I don't know how to query history. BTW: I gve up on Subclipse yet again, can't whittle well with it... Q: Did you merge w/ any changes I've jsut made, or does SVN allow you to copy over w/o a merge? sorry once again. Nope, don't be. If our unit tests were all working before you did that, maybe regards Adam
Re: Status Report
Thanks for doing this Nick, I appreciate you taking it on, 'cos it needs to
be done. I'm not sure what good cwiki format does me, ought it just be on a
wiki (so we can help by adding to it?) What am I missing? What do you want
from us?
regards
Adam
- Original Message -
From: Nick Chalko [EMAIL PROTECTED]
To: Depot Development [EMAIL PROTECTED]
Sent: Sunday, July 18, 2004 5:27 PM
Subject: Status Report
Is a my first take on a status report for the board in (cwiki format)
!!2004-07-18
{{{
1). Is the STATUS file up to date?
No
2). Any legal, cross-project or personal issues that still need to be
addressed?
No, all files licensed, all commiters have singed CLA
3). What has been done for incubation since the last report?
* Site update.
* PAckages renamed to depot
4). Plans and expectations for the next period?
* Delete unused under developed code.
* Complete Download manger for use by gump and others.
* Support directory artifacts for use by antworks and others.
5). Any recommendations for how incubation could run more smoothly for
you?
n/a
}}}
Re: Status Report
Any thing else I should mention otherwise I will send to to general@incubator.apache.org I'm not sure (my bad) if this the requirement on a status report are 'about the project' or just 'about the project within the incubation process', but I think the latter. Even if not, I suspect that'd do for this go around, and if we have any 'community building' content we could add that at next. Again, thanks. regards Adam
Re: ArtifactInstance.clone
Do not see any problems there??? Gak, I think my Eclipse 3.0 is playing silly buggars on me. I don't see a compile error reported an more. Sorry for the noise. regards Adam
Re: ASF Repository, closer.cgi and Depot
- Original Message - From: Mark R. Diggory [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 8:48 AM Subject: ASF Repository, closer.cgi and Depot Sorry for the cross post but this seems relevant to both these groups. I was thinking about the subject of mirroring and redirection for the ASF Repository. Currently, there was some discussion on the Depot list concerning this. I feel we could address this subject again for both groups interest. www.apache.org/dyn/closer cgi provides a simple resolution strategy to attempt to determine the closest mirror available to the client browser. It then generates an html page via a template that lists the selected mirror as well as other available mirrors. With Depot, we have a customized download client that could be extended to manage downloading from a list of mirrors as well. Here are my thoughts on this subject: A.) This script is really not that big (90% of it is just parsing the mirrors file), and the database (a flat text file called mirrors.list) as well is not very big. While closer.cgi is a neat service for browsers. Its not exactly helpful for automated clients. Yet, mirrors.list is an excellent example of metadata that is exposed in a effective manner such that automated clients can access it. http://www.apache.org/mirrors/mirrors.list I'm somewhat convinced that a it would be simple to create a client implementation which accomplished the same functionality as closer.cgi programatically so that it could be used in terms of resolving a location to download from when mirrors are available. This would be beneficial to the Apache Bandwidth issue in that if a client such as Depot/DownloadManager managed the same capability as closer.cgi then: Hmm, it seems to me that infra@ or mirrors@ (is that a list) probably have views on this. (But then, we probably don't want 4 lists on here. :-) I suspect their views would include what you suggest, that distribution might save some nomimal (c.f. artifact sizes) bandwidth savings give some CPU saving, but it'd be at significant loss of 'control' (of well behaved clients). Central control over this seems the most appealing. Since I doubt the CPU cycles are worth saving (or the script would've been optimised), could we not just change the script to check for some header from the client, and return XML or some structured text, for non-human browsers. [BTW: viewcvs seems to do this nicely, returning the file if non-human and the presentation is human (as browser identifies). regards, Adam
Re: Download Manager
Markus: Would you be willing to take the DownloadManager development on? I think the 'sharing' we'd get discussing it, and how to implement it, would be education for this team as a whole. I think we'd work out more details with doing it this way. ? regards Adam
Re: UpdaterConfig
like I said already, I am browsing through the API and adding JavaDoc to some classes. Right now I have a problem concerning the UpdaterConfig. This class is called all over the API and should provide basic configuration for the application. But right now, I am pretty unsure, how this configuration is provided to the calling classes. That was (is?) a nice experiment by Anou. Basically we wanted some form of 'ant types' (configuration in XML) but outside of Ant. The configuration file is read, and named configured objects are stored in a registry (by namespaced name). I think it works, but has some usage issues, so right now I'm kinda hoping to leave it on the side, until we find time to work on it. I do like the idea. Also please note, that there seems to be an endless loop in the method listArtifacts(...) in the class AbstractHierarchicalRepositories. Or is there any need for this? I suspect it was another bug introduced in the global renaming, when Artifact(Resource)Specifer - Artifact, and Artifact(Resource) - ArtifactInstance. There are a few cases where a cal lto something w/ type ArtifactSpecifer lost the Specifer, and hence changing the intended called method. I'll look into it, thanks. regards Adam
Re: [PROPOSAL] The Future of Avalon Repository
I have initiated some initial discussions to see what kind of support there would be to Help Depot to Help Us, i.e. transfer of Avalon Repository into the Depot codebase, and refactoring it into a more generic package than currently is the case. What was the outcome of this proposal? Are we all (Depot and Avalon) going to work together on this? regards Adam
Re: ArtifactType
Hello, since my project at work is pretty much live now, i hope that i can spend more time now on depot. right now i have a question concerning the artifactType. There are some :TODO: tags in this. What was the main intend for this class? Should we change this? Depot has a concept of namespaces (QName stolen from the WS folks) which basically allows a name within a URI, identified by a prefix. This is used in a bunch of places when a name alone isn't unique. For example say we wants the 'depot jars' or the 'depot source' we'd want to have jars:depot or source:depot both with the name 'depot'. The main intention of this class is to define a few types (as namespaces), for jar or docs or source or ... (hence the todos). Right now we are trying to get off the ground with jars. I'd leave the TODOs but I'd not worry about it too much. regards Adam
Re: ArtifactType
Usage usage usage. We need to start using this stuff (so we get incented to wire in the MD5 stuff, and so forth). regards Adam - Original Message - From: Markus M. May [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Friday, July 09, 2004 10:16 AM Subject: Re: ArtifactType Hmm, well. what do you think should be our next steps? I am not a big writer, so i am not really a big fan of writing documentation :-) also the security stuff is nice, but i guess that there are other issues scratching right now, right? Hello, since my project at work is pretty much live now, i hope that i can spend more time now on depot. right now i have a question concerning the artifactType. There are some :TODO: tags in this. What was the main intend for this class? Should we change this? Depot has a concept of namespaces (QName stolen from the WS folks) which basically allows a name within a URI, identified by a prefix. This is used in a bunch of places when a name alone isn't unique. For example say we wants the 'depot jars' or the 'depot source' we'd want to have jars:depot or source:depot both with the name 'depot'. The main intention of this class is to define a few types (as namespaces), for jar or docs or source or ... (hence the todos). Right now we are trying to get off the ground with jars. I'd leave the TODOs but I'd not worry about it too much. regards Adam
Re: ArtifactType
I can focus again from Monday onwards. Busy 'til then. Please dig around and let's get all these questions out/answered behind us. regards Adam - Original Message - From: Markus M. May [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 08, 2004 1:17 PM Subject: ArtifactType Hello, since my project at work is pretty much live now, i hope that i can spend more time now on depot. right now i have a question concerning the artifactType. There are some :TODO: tags in this. What was the main intend for this class? Should we change this? Markus
Re: [GUMP@brutus]: depot/depot-update failed
Folks, We need to get the date information that Gump is providing setting the date information that this build is using. Right now Gump is setting/passing: property name=DATE_STAMP value=@@DATE@@/ Can the build use that, or do we need to pick a predefined variable name? regards, Adam - Original Message - From: Adam Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 04, 2004 11:09 AM Subject: [EMAIL PROTECTED]: depot/depot-update failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project depot-update has an issue affecting its community integration. This issue affects 5 projects. Project State : 'Failed', Reason 'Missing Build Outputs' The following are affected: - antworks-importer-with-depot : Autodownload and import ant build.xml's. - depot-update-ant-sample-httpclient : Depot -- repository tools and more... - depot-update-ant-sample-jdk : Depot -- repository tools and more... - depot-update-ant-sample-vfs : Depot -- repository tools and more... - depot-update-test : Depot -- repository tools and more... Full details are available at: http://brutus.apache.org:8080/gump/depot/depot-update/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Sole jar [depot-update-gump-20040703.jar] identifier set to project name -INFO- Dependency on ant exists, no need to add for property ant.home. -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/depot/update/dist/depot-update-gump-2004070 3.jar -ERROR- See Directory Listing Work for Missing Outputs The following work was performed: http://brutus.apache.org:8080/gump/depot/depot-update/gump_work/build_depot_depot-update.html Work Name: build_depot_depot-update (Type: Build) State: Success Elapsed: 0 hours, 0 minutes, 8 seconds Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merg e.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/workspace/ ant/dist -DDATE_STAMP=20040703 -f build.xml gump [Working Directory: /usr/local/gump/public/workspace/depot/update] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/depo t/update/build/depot-home/classes:/usr/local/gump/public/workspace/ant/dist/ lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf. jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/g ump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/worksp ace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib /ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.j ar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/pub lic/workspace/depot/version/dist/depot-version-gump-20040703.jar:/usr/local/ gump/public/workspace/depot/common/dist/depot-common-gump-20040703.jar:/usr/ local/gump/public/workspace/antworks-importer/dist/antworks-importer-0.2-gum p-20040703.jar:/usr/local/gump/public/workspace/jakarta-servletapi/dist/lib/ servlet.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/ jakarta-regexp-20040703.jar:/usr/local/gump/public/workspace/ant/bootstrap/l ib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.j ar:/usr/local/gump/public/workspace/jakarta-commons/httpclient/dist/commons- httpclient.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/c ommons-codec-20040703.jar:/usr/local/gump/public/workspace/jakarta-commons/l ogging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-com mons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/c ommons-vfs/target/commons-vfs-20040703.jar-- --- [get] Not modified - so not downloaded get-commons-codec: [get] Getting: http://www.ibiblio.org/maven/commons-codec/jars/commons-codec-1.2.jar [get] local file date : Thu Jan 29 16:46:17 PST 2004 [get] Not modified - so not downloaded get-regexp: [get] Getting: http://www.ibiblio.org/maven/regexp/jars/regexp-1.3.jar [get] local file date : Mon Dec 22 05:00:12 PST 2003 [get] Not modified - so not downloaded get-all: -init-path: version.init: version-stamp: [version-stamp] Execute Synchronize... [version-stamp] Ignoring property [org.apache.depot.version.build.datetime] - [Sun Jul 04 02:47:10 PDT 2004] [version-stamp] Created class org.apache.depot.update.version.Version into /usr/local/gump/public/workspace/depot/update/src/java/org/apache/depot/upda te/version/Version.java -check-code-presence: -java.init: compile-src: [echo] Compiling project core with Java 1.4, debug on, optimize off, deprecation on [mkdir]
Re: Refactoring (for merge) and APIs
It will not be trivial, +1. Shouldn't be to difficult using IDEA. Eclipse can do the work also. It isn't so much the mechanics, more the mental shift (since they aren't quite the same things today). It'll mean a few other class name changes is my guess. Anyways, anybody else pro this change? I'd be happy to do the work if the source is in CVS. I'll give it a go if the source is in SVN but can't promise anything - I've not used SVN (other than to play with) before. BTW, *where* is the source? I appreciate the offer, but I think a committer ought do this. The patch would be humongous. :) regards Adam
Reviewing Avalon Depot Code bases
All, I did a quick review (and I say quick, so please correct me where I am wrong). This is what I found: The Avalon codebase is simple -- and that is a major plus, no clutter, no fuss. The approach is nicely broken into separate source directories (which helps illustrate the separations) such as API, SPI (Repository Plug-In), Impl, Util. The fundamental classes are Artifact and Repository (which map directly to Resource and Repository in Depot, and are coded *almost* identically.) Basically, I see *immense* similarities -- starting with basic design approach implementation choices. [One plus include similar coding style ... one less niggly 'discontinuity' for us to hold noses to, through with a merge.] I do see some Avalon code in there. I do see some 'Classloader' code (at lower levels, e.g. in Repository) and that we can discuss/negotiate over. I see some reference to security, but I'm not sure if that is Avalon security or JDK or whatever. I'd like to learn. In short, I see the same intentions/approaches, just minor (perhaps) implementation differences (e.g. API choices, Factory implementations, configuration, etc.) I think we can explore the pros and cons of each choice and select the better on a case by case basis. I remain of the opinion that we can import Avalon Repository into a classloader project, refactor it run it over some Depot core classes. Those Depot classes would either be (originally) Avalon Repository classes, or would have the 'required features' merged into them. That core could be called 'Update' (as it is today) or we could split off a core (simply the layer that Stephen mentioned yesterday). As I see it Depot Update has most of what Avalon Repository has -- albeit cluttered/unclear (and not all completed nor needed.) I think we need to pick apart this code so that we have a lean/mean core -- not a cluster. I think the task of teaching the Avalon folks about the Depot codebase will really helps us clarify what we want/what we need and what we can trim. [When reviewing things yesterday I got clear (after many months) on all our pieces, and it helped me.] Here is what I see Depot Updater has in addition: - Protocol code over java.net.URL or HtppClient or VFS. [Which is loaded depends upon the environment. Might be a portability (over CLs) issue, might be cool.] - Ant Tasks/Types (and some Tools) [These are used by AntWorks.] - More commandline tools (for Gump etc) - Logging (listener abstraction, so we can plug in to Ant or CL or Avalon or ...) - Utility classes (File interface (creates Resources) to/from Updater..) - Monitoring (listener pattern, stats collectors, stdout loggers, etc.) Some higher level capabilities (based upon understanding the data): - Repository Queries (with Selectors/Comparators) - Version Parsing (and hence ordering, selection of 'best') [We can discuss if these out be in a separate project.] Some dodgy (incomplete) clutter: - XML Configuration system (albeit incomplete). - XML deserialization/serialization (albeit incomplete). [There was a rationale here, I can discuss in a separate mail.] Basically, I feel that the Depot code has a lot more -- but I think that has hindered it, rather than helped. Develops are lost in the internals before it is complete, and we need to remove the clutter. BTW: I see the biggest problem ahead as either picking a build system, and/or picking a hierarchy that all three can live with (Maven -- still needed, Magic -- wanted here?, AntWorks -- has source folder issues). I hope we can find a simple solution. regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: Reviewing Avalon Depot Code bases
Thanks, and no stress (I need to find some time for family/EMT school/work/Gump, so I'll appreciate discussions not being too busy.) Also, maybe I can find some time to put Depot's house in order prior to a merge. Thanks for the impetus... regards Adam - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Tuesday, June 22, 2004 12:56 PM Subject: Re: Reviewing Avalon Depot Code bases On Tuesday 22 June 2004 23:14, Adam R. B. Jack wrote: I did a quick review (and I say quick, so please correct me where I am wrong). This is what I found: Just want to give you the nod, that I am happy to see your effort, and at large concur with your assessment. I will comment more in details when I have arrived to the USA, as I am leaving in a few hours, and need to get some sleep (among other things). So don't be alarmed that I will 'offline' for two days or three... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: Depot layers
|| | get/put to cache with group/name/blob-version semantics, | | security on transmission, integrity checking, | | and reliability of service | || ... and the starting point is the bottom layer. I can agree with starting at the bottom. I think this (above) is about it. I would like to offer both opaque(blob) version and structured/parsed, but I do (now) realize that folks need the ability to have the former (as a starting point). I've read the Avalon Repository code at: http://svn.apache.org/repos/asf/avalon/trunk/runtime/repository and I'm very pleased to see the significant similarities. I like the clarity/simplicity that Avalon Repository has, but I also like some of the features that Depot provides (e.g. ability to use java.net.URL or HttpClient or VFS as environment allows). I do like that we have Filters/Selectors in common (Depot has Comparators also, 'cos we think order is possible). I could go on, but not here. Again, I see more in common than I see in divergence. I'd be tempted to suggest we import the Repository code into Depot (as a separate ClassLoader project) and slowly (or quickly) migrate as much into the Updater project, or use Updater concepts. I think there are interesting choices to be made, and we could work that merge (over a suitable time) with some Wiki documentation and/or scheduled group chats. [For example, the Artifact and (Depot) Resource classes are next to identical, we need to document what we want, and merge them.] *If* we can all open our minds (and suppress our egos) sufficiently to allow this form of merge (without tonnes of blah/blah back and forth on minutiae) then I think we'd have one heck of a lively/healthy development team (community), worthy [IMHO] of Apache TLP. regards, Adam
(Avalon Depot) Re: Moving forward or letting go
Niclas wrote: Let us start the discussion around Avalon Repository, and see if something can be learnt from it (over at Avalon we are pretty pleased with it). [...] I hope you can digest this info a bit. The important Avalon crowd, Aaron, Stephen, Alex and myself, have expressed a wish to move Repository functionality into Depot, and get Depot out of Incubator and get proper releases out. Personally, I think Depot importance is big enough to validate a TLP. I've not been responding 'cos I've been trying to absorb evaluate. I am finding this thread compelling. I like a lot of what I read here. We called Depot -- not Ruper/Greebo (original source code) -- 'cos we wanted to be open to accept outside influences (primarily Avalon's, also Wagon's, whatever), and reading this I'm glad we did. We need input/help/drive like this. My thoughts are these... Ruper was based upon the concept that we query a repository for latest/best fit and download that. Not download version X from http://Y (one can do that with a simple ant get (HTTP GET)) but pick the latest 'fit', and download that. Basically, that is my passion w/ a download tool -- don't let the developer stagnate on older jars if there is a compatible beter one. For details see: http://incubator.apache.org/depot/update/ That said, I think we've got too much code for a simple problem I think that is hindering us. [My first passion being version, http://incubator.apache.org/depot/version/, it brings a bunch of baggage that may or may not help Depot Update.] I think we need to maintain the goal we have, but also supprot the simple straight-forward 'download this'. There is enough (simple by needed) work there with MD5 checks, and maybe click-through acceptance of licenses. I'd be interesting in collaborating to keep parts of Depot, and integrate with Avalon's code. I think that bringing fresh eyes into the code (and onto the problem) would force us (Depot) to focus and clean-up the docs/designs (on Wiki). I think a joint goal -- with joint use cases -- could really work this out to something practical. Yes, I'd be very interested in that. BTW: So Magic can use Ant tasks, is that it? I've read about it (in mails) but I hadn't registered that. Interesting. regards, Adam
Re: [GUMP@brutus]: depot/depot-version-test success
FWIIW: The issue was that with configureProject( ..., MSG_DEBUG) we just were too verbose (for BuildFileTest that stored output in a StringBuffer). I set the level to MSG_INFO. regards Adam - Original Message - From: Adam Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 03, 2004 11:04 PM Subject: [EMAIL PROTECTED]: depot/depot-version-test success To whom it may satisfy... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project depot-version-test *no longer* has an issue. Project State : 'Success' Full details are available at: http://brutus.apache.org:8080/gump/depot/depot-version-test/index.html That said, some snippets follow: The following annotations were provided: -INFO- Enable debug output, due to a sequence of 25 previous errors. -INFO- Project Reports in: /usr/local/gump/public/workspace/depot/version/build/depot-version/junit/res ults The following work was performed: http://brutus.apache.org:8080/gump/depot/depot-version-test/gump_work/build_depot_depot-version-test.html Work Name: build_depot_depot-version-test (Type: Build) State: Success Elapsed: 0 hours, 0 minutes, 45 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/works pace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/ xml-xerces2/java/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/wo rk/merge.xml -Dbuild.sysclasspath=only -Dant.home=/usr/local/gump/public/wor kspace/ant/dist -f build.xml test [Working Directory: /usr/local/gump/public/workspace/depot/version] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/depo t/version/build/depot-version/junit/classes:/usr/local/gump/public/workspace /depot/version/dist/depot-version-gump-20040603.jar:/usr/local/gump/public/w orkspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant /dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swin g.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/ gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/work space/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dis t/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/ usr/local/gump/public/workspace/depot/common/dist/depot-common-gump-20040603 .jar:/usr/local/gump/public/workspace/antworks-importer/dist/antworks-import er-0.1-gump-20040603.jar:/usr/local/gump/public/workspace/jakarta-servletapi /dist/lib/servlet.jar:/usr/local/gump/public/workspace/ant/build/l ib/ant-testutil.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar--- -- [junit] Implicitly adding /usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public /workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/an t/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.j ar to CLASSPATH [junit] Running org.apache.depot.version.util.dom.DOMTests [junit] Executing '/usr/local/j2sdk1.4.2_04/jre/bin/java' with arguments: [junit] '-classpath' [junit] '/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/dep ot/version/build/depot-version/junit/classes:/usr/local/gump/public/workspac e/depot/version/dist/depot-version-gump-20040603.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/an t/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swi ng.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local /gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/wor kspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/di st/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar: /usr/local/gump/public/workspace/depot/common/dist/depot-common-gump-2004060 3.jar:/usr/local/gump/public/workspace/antworks-importer/dist/antworks-impor ter-0.1-gump-20040603.jar:/usr/local/gump/public/workspace/jakarta-servletap i/dist/lib/servlet.jar:/usr/local/gump/public/workspace/ant/build/ lib/ant-testutil.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar' [junit] 'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner' [junit] 'org.apache.depot.version.util.dom.DOMTests' [junit] 'filtertrace=true' [junit] 'haltOnError=false' [junit] 'haltOnFailure=true' [junit] 'formatter=org.apache.tools.ant.taskdefs.optional.junit.SummaryJUnitResultFo rmatter' [junit] 'showoutput=false' [junit] 'formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormat ter,/usr/local/gump/public/workspace/depot/version/build/depot-version/junit /results/TEST-org.apache.depot.version.util.dom.DOMTests.xml'
Fw: Overall status of incubating projects
We need to do something about this... regards Adam - Original Message - From: Berin Lautenbach [EMAIL PROTECTED] To: general@incubator.apache.org Sent: Monday, May 31, 2004 5:15 AM Subject: Overall status of incubating projects Peoples, The following lists provides my understanding (based on the projects page on incubator.apache.org) of when the last status update was. Projects with a ** have gone more than 3 months without any kind of update. No Report means that the project *appears* (according to the status file) never to have issued a report to the Incubator PMC. I'm not sure it's accurate, but I'm just reporting based on the STATUS page. This started off from a comment from Noel, but I'd also be kinda interested in whether any of these projects can be graduated and/or shut down? *AltRMI 30 Oct 2003 (No report) *Axion 19 Dec 2003 (No report) *Directory 20 Jan 2004 *FtpServer 30 Oct 2003 (No report) GeronimoN/A - Graduated (probably needs to be documented) JuiCE 20 April 2004 *Lenya 20 Jan 2004 *Log4net15 Jan 2004 Pluto N/A - Graduated *Depot 20 Dec 2003 SpamAssassin22 April 2004 WSRP4J April 2004 (From CVS logs, date in file is 2004-10-) XMLBeans20 April 2004 I thought Log4cxx was also under incubation? Are there any others? Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to build?
You are mixing with an odd crowd, so expect odd. ;-) Since Gump is our friend, we tend to let it do building via antworks we let it set the classpath. When developing we (at least I) simply have three projects in Eclipse (becareful w/ subclipse, the Eclipse SVN plug-in, I've had woes with it) and Eclipse figures it out. I've struggled with the ant inside Eclipse (I suspect it is older) but command line depot runs. Further, I've manually set the CLASSPATH to the build directories for the three projects, then run the builds (it works). [Nick has a personal Gump set-up that ought help him do this, but that isn't as easy for newbies as I'd like, so I don't advise it.] For testing, I do similarly, I have a depotenv.bat (see below). I tend to like to use projects from CVS HEAD, but in doing so I've stumbled onto VFS problems. You might just add jars. I hope that helps. Thanks for digging in. Keep the feedback coming. regards, Adam # # DEPOTENV # set CLASSPATH=. #set SVN_EDITOR=vi set JUNIT_HOME=F:\apps\sforge\junit3.8.1 set WORK=F:\data\OSS set DEPOT_COMMON=%WORK%\depot-common set CLASSPATH=%CLASSPATH%;%DEPOT_COMMON%\build\ide\eclipse\ set DEPOT_VERSION=%WORK%\depot-version set CLASSPATH=%CLASSPATH%;%DEPOT_VERSION%\build\ide\eclipse\ set DEPOT_UPDATE=%WORK%\depot-update set CLASSPATH=%CLASSPATH%;%DEPOT_UPDATE%\build\ide\eclipse\ set DEPOT_VERSION=%WORK%\depot-version set CLASSPATH=%CLASSPATH%;%DEPOT_VERSION%\build\ide\eclipse\ set CODEC=%WORK%\commons-codec set CLASSPATH=%CLASSPATH%;%CODEC%\build\ide\eclipse\ # VFS has some woes... #set VFS=%WORK%\commons-vfs #set CLASSPATH=%CLASSPATH%;%VFS%\build\ide\eclipse\ set REGEXP=%WORK%\jakarta-regexp set CLASSPATH=%CLASSPATH%;%REGEXP%\build\ide\eclipse\ set HTTP=%WORK%\commons-httpclient set CLASSPATH=%CLASSPATH%;%HTTP%\build\ide\eclipse\ set LOGGING=%WORK%\commons-logging set CLASSPATH=%CLASSPATH%;%LOGGING%\build\ide\eclipse\ set REGEXP=%WORK%\jakarta-regexp set CLASSPATH=%CLASSPATH%;%REGEXP%\build\ide\eclipse\ cd %DEPOT_UPDATE%
Re: depot status?
Neeme Thanks for all the research you've done, and the feedback you've given. I think you've correctly identified the status, at least the public side of it. We have a lot of basic work to do on the site(s). As far as the less public side, the code/activity, we are making progress again. We hit a bit of a speed bump entering incubation, with changing in how we work, using SVN, and so forth. All environmental things that really ought not have slowed us down, but contributed to getting us out of sync. I think we are back on track now. Much has been implemented, the basics work, and we are looking into adding MD5 checks, and so forth. A few folks (us/others) are using depot in some experimental works. I'll work with other here to get the site(s) updated and make it clearly for folk like you. Thanks (again) for your pointers on what we need to fix. BTW: The antworks folks are using Ant 1.6 with depot, it might be worth you considering: http://antworks.sourceforge.net That project is about re-usable pieces of ant build descriptor. regards, Adam - Original Message - From: Neeme Praks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 13, 2004 5:55 AM Subject: depot status? Hi all! I need a tool like RuperJJAR and while doing some serious researching about the fate of these projects, I found out about this project (depot) that is supposed to be the successor of those efforts? I tried to find the homepage of Depot but there doesn't seem to exist any? And the incubation status report (http://incubator.apache.org/projects/depot.html) seems to be seriously out of date as well. The newest information seems to be available in the Wiki (http://wiki.apache.org/general/Depot) but even that seems to be at least couple of months old. Also, is there any mailing list archive available? www.mail-archive.com doesn't seem to have any depot related list, gmane neither... Hmm... now I managed to find the mailing list eyebrowse archive (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] apache.org) by an intelligent guess that all ASF mailing lists should go to eyebrowse... would be nice to have a link somewhere, though ;-) And, from the archives, I even found out the homepage URL (http://incubator.apache.org/depot/index.html)! :-) Not that there is much more info other than what was already on ruper homepage. :-( And I guess it would give a huge boost to the visibility of Depot if the link would at least be included in the incubation status report (http://incubator.apache.org/projects/depot.html). Currently even Google doesn't know that the homepage exists. :-( Also, the website seems to be seriously lacking in structure... very difficult to navigate and to understand where is your current location in relation to the whole site structure. As soon as I manage to get the sources, I'll see if I can help you out with this. So the main question for me is: what is the status with Depot? What has been implemented? What is still to be done? As far as I understand the code is in SVN. Are there any instructions for getting it from there? Maybe the time has come for me finally to start using SVN. :-) After I have found out your status, I would be more than happy to help you out with some features that I need (if not implemented already). Basically, what I'm looking for is a replacement for maven. I'm not happy how maven handles versioning and upgrading versions. And I have an external push from my employer to replace maven with Ant. And with version 1.6 of Ant here, I guess I'm ready to give it a try. :-) But I'll put the details of my ideas in a separate email. Rgds, Neeme
Re: Wiring up MD5
You know about java.security.DigestOutputStream and the similar java.crypt.MD5OutputStream from the cryptix package, right? It should be fairly straightforward to achieve what you want using either of these. Nope, I didn't (I am clueless in this area), thanks. Markus, any comments? regards Adam
Re: [GUMP@lsd]: depot/depot-version-test failed
Seems wacky. Anybody got a clue where to start? regards Adam [junit] Testcase: testExistence took 5.243 sec [junit] Testcase: testAbsence took 3.47 sec [junit] Testcase: testHigher took 214.496 sec [junit] Caused an ERROR [junit] java.lang.OutOfMemoryError [junit] java.lang.OutOfMemoryError [junit] at org.apache.depot.version.ant.available.VersionAvailableTaskTest.testHigher(V ersionAvailableTaskTest.java:55) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) [junit] Caused by: java.lang.OutOfMemoryError [junit] --- Nested Exception --- [junit] java.lang.OutOfMemoryError
http://incubator.apache.org/depot/index.html
Would somebody mind updating this? [My version of forrest isn't new enough, and to get a new one I'll need to download forrest from SVN over modem, which I don't have time for this morning. The main reason I want it is because the closed left menu (projects) looks empty, and we look like we have an empty project. http://incubator.apache.org/depot/index.html I've added a table of our three sub-projects so folks can get some insights, and perhaps get interested. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Wiring up MD5
Ok, here is what I am thinking, and I'm asking for feedback. We have an MD5 checksum file associated with an artefact we are wishing to download. We download/read the checksum, and then download the artefact, creating a checksum ourselves, comparing it to that original. Personally, I believe that we ought go to extreme measures to not leave any artefact on disk if it failed a check [even if we are CTRL-C'ed], since it is potentially tampered with. Even if we know it is bad, once taken out of the context of our code (and it'd be available on disk) others might become victim to it. As such I'd like to develop something like a stream that does the MD5 check as it is being written to, wrapped around some sort of tempfile(). If a stream isn't overkill, then the MD5 check could complete in the close() and if failed, perhaps destroy the file. We could attempt to re-write it with blanks, then try to delete it. Anybody got any thoughts on this? Anybody got any experience with similar things? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Fw: cvs commit: gump/project depot.xml
+depend project=xmlunit/ Cool, but what does it do what do we use it for? Just curious. regards Adam
Re: [GUMP@lsd]: depot/depot-update-test failed
I'd cut-n-paste the antlet code from version (it had a property for the repo, and also a new location) but still this fail. I then noticed an explicit test target at the bottom. I wonder if we could have a standard antlet (again) that included the others. BUILD FAILED Target `test' does not exist in this project. Ought be gone now. regards Adam
A few thoughts
1) CLASSPATH Repository Nick and I implemented a ClasspathRepository in Ruper days of old, the thinking being -- to allow updates to be sensitive to a [say] Gump context, and use Gumped jars (in Gump builds) in preference to downloading. I was considering this for Depot, but it dawned on me this was flawed. There is really no 100% accurate way to analyse/parse all artefacts just from filename, etc. (no group position, no extra metadata, etc). With artefacts in a classpath this is all one gets, so although it would work for many, it'd no work for all. Since Gump is (if I get my way) to create local repositories of jars it creates, maybe we ought just pass those locations to Depot, and use them as normal. I prefer this approach. 2) .../.depot directory I like how CVS and SVN work by storing metadata (repository location., etc) into a dotted local directory. I wonder if we ought have the same (*as and when/if* we need it). We could store thing in there like, where it came from, MD5 checks, etc. I like the ability that CVS|SVN has to 'svn update' a local repository, to (cheaply) just go get updates to what is there without (in our case) hunting around randomly. That might be a nice future optimisation. 3) Put repositories into our SVN for http testing. I wonder if we ought create (under depot) some repositories, and check them in to SVN. We can do unit/integration/whatever testing against them via HTTP (even w/o HTTPS). regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
depot-version-antlib.xml
Since Ant backed off namespaces (for a while) the version tasks loose the 'version:' version:stamp version:environment version:environment-check version:available version:constraint version:constraint-check I think we need to add version- to the front of them, or they clash (available) or could clash (stamp/env). Ant better ideas? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: depot-version-antlib.xml
Perhaps we should make both available. Hmm, what if we have both in one file? antlib taskdef name=stamp classname=org.apache.depot.version.ant.stamp.VersionMarkerGeneratorTask/ taskdef name=version-stamp classname=org.apache.depot.version.ant.stamp.VersionMarkerGeneratorTask/ I don't know what happen in the case of a clash (I see version-available already exists this way, not as available) but I assume the first takes over. If/when namespaces get restored we'll need uses to change to version: so having version- isn't so bad, is it? Having users change their resource file seems intrusive. Thoughts? regards Adam - Original Message - From: Nick Chalko [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Friday, April 30, 2004 9:23 AM Subject: Re: depot-version-antlib.xml Perhaps we should make both available. a depot-version-antlib.xml and a depot-version-antlib-terse.xml Where the first has version-name and the other has just name with the intention of the terse being used with namespaces. I would recommend checking in the terse and using XSLT to generate the verbose. R, Nick Adam R. B. Jack wrote: Since Ant backed off namespaces (for a while) the version tasks loose the 'version:' version:stamp version:environment version:environment-check version:available version:constraint version:constraint-check I think we need to add version- to the front of them, or they clash (available) or could clash (stamp/env). Ant better ideas? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: depot-version-antlib.xml
Lest use version-for now. When names spaces are available we can create in the terse version. The point is when used with name spaces use wont want to write version:version-stamp. and since they will be adding the name space declaration they can add the -terse suffix to the file name if they want to use the shorter task names. That is the right call. In reverting to this I find way too much documentation/samples that say version- anyways. :-) regards, Adam
Re: URI Syntax
project is the project name. It is unique within an organisation. If your artifact is a sub-project of a larger project, or is unique in some way, include that information in the name. For example, if your artifact is part of the bar project, which is a sub-project of foo, then your project would be named foo-bar. E.g: Nick is right, we ought do it on the repository list to get a wider audience. For my own thoughts, I can appreciate guidance like this. I believe that given how projects mature/migrate (e.g. from sub to peer to TLP) we'll be in flux with 'groups'. I don't really mind how groups are defined since I think they are the starting point (the input data) for most of what depot will do, they aren't calculated. BTW: I'd like to see commons-logging removed from the wiki, it isn't a big project and is perhaps a bad example. regards, Adam
Loading test resources
I think we need to get src/resources/test into the classpath (in Eclipse and
Ant) for these to work. Or, can we add ./src/resources/test to them?
Thougts?
package org.apache.depot.update.util.security;
...
public void testGetDigest() throws Exception {
ClassLoader clazzLoader = this.getClass().getClassLoader();
URL urlHashFile =
clazzLoader.getResource(org/apache/depot/update/util/security/test.txt);
URL urlMetaFile =
clazzLoader.getResource(org/apache/depot/update/util/security/test.txt.md5
);
regards
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
Re: Loading test resources
Why are we using a class loader here. MD5 don't usually ship inside a jar. This is part of a unit test. Are you saying we ought just use relative path? regards, Adam
Re: Enterprise Users may not trust availablity of Internet for repeatable builds.
I found its [Maven] insistence on connecting to an Internet repository offensive; in a production environment it has a snowflakes chance in hell of automated downloading of anything from the Internet. So don't do builds in productions. ;-) ;-) FWIIW: Gump seems to manage to automatically download stuff pretty often. :) Enterprise users trust there own CVS so perhaps a CVS backed local cache would handle the concerns I think SVN is a good fit with Depot, heck -- I'd like to follow their lead on lots of things (from security to command line to ...). I wonder if we could integrate as an SVN client (better than pyeclipse does, I hope) from Java. Any other ideas ? So a local repository that isn't version controlled isn't good enough? Why don't we just download to a local one? regards, Adam
Multiple IDE projects or one?
Nick and I found we'd approach the Depot SVN repository in two different ways. I'd had one eclipse project for it, and Nick had four(one for common, one for version, one for update, one for site). Clearly we both have different paths to things like ant test scripts, which causes issues. Anybody have opinions on one way or the other? If no objections I'll move to Nick's way of doing things, and restore the files/paths appropriately. regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: [GUMP@lsd]: depot/depot-common-test failed
The Gump descriptor was pointing to the wrong place for classes, so no test classes were found. Probably true for all three. regards Adam - Original Message - From: Adam Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 5:57 AM Subject: [EMAIL PROTECTED]: depot/depot-common-test failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project depot-common-test has an issue affecting its community integration, and has been outstanding for 4 runs. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/depot/depot-common-test/index.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Enable verbose output, due to 3 previous error(s). - Info - Failed with reason build failed - Info - Enable debug output, due to build failure. - Info - Project Reports in: /data3/gump/depot/common/target/tests - - - - - -- -- G U M P Gump performed this work: http://lsd.student.utwente.nl/gump/depot/depot-common-test/gump_work/build_depot_depot-common-test.html Work Name: build_depot_depot-common-test (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 7 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data3/gump/xml-xerces2/java /build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xml-apis.jar:/data3 /gump/xml-commons/java/external/build/xml-apis.jar:/data3/gump/xml-xalan/jav a/build/xalan-unbundled.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/data3/gump/gump-install/wor k/merge.xml -Dbuild.sysclasspath=only -Dant.home=/data3/gump/ant/dist -f build.xml test [Working Directory: /data3/gump/depot/common] - [javac] /data3/gump/depot/common/src/test/org/apache/depot/common/util/classpath/Pat hWalkerTests.java [copy] omitted as is up to date. [copy] org omitted as org is up to date. [copy] org/apache omitted as org/apache is up to date. [copy] org/apache/depot omitted as org/apache/depot is up to date. [copy] org/apache/depot/common omitted as org/apache/depot/common is up to date. [copy] org/apache/depot/common/junit omitted as org/apache/depot/common/junit is up to date. [copy] org/apache/depot/common/util omitted as org/apache/depot/common/util is up to date. [copy] org/apache/depot/common/util/classpath omitted as org/apache/depot/common/util/classpath is up to date. test: [junit] Implicitly adding /data3/gump/dist/junit/junit.jar:/data3/gump/ant/dist/lib/ant-launcher.jar:/ data3/gump/ant/dist/lib/ant.jar:/data3/gump/ant/dist/lib/ant-junit.jar to CLASSPATH [junit] Running org.apache.depot.common.util.RegistryTests dropping /data3/gump/depot/common/data3/gump/depot/common/target/unit/classes from path as it doesn't exist dropping /data3/gump/depot/common/data3/gump/depot/common/target/unit/classes from path as it doesn't exist dropping /data3/gump/depot/common/data3/gump/depot/common/target/unit/classes from path as it doesn't exist dropping /data3/gump/depot/common/data3/gump/depot/common/target/unit/classes from path as it doesn't exist [junit] Executing '/usr/java/j2sdk1.4.2_03/jre/bin/java' with arguments: [junit] '-classpath' [junit] '/usr/java/j2sdk1.4.2_03/lib/tools.jar:/data3/gump/depot/common/dist/depot-c ommon-20040413.jar:/data3/gump/ant/dist/lib/ant-stylebook.jar:/data3/gump/an t/dist/lib/ant-jmf.jar:/data3/gump/ant/dist/lib/ant-swing.jar:/data3/gump/an t/dist/lib/ant-junit.jar:/data3/gump/ant/dist/lib/ant-launcher.jar:/data3/gu mp/ant/dist/lib/ant-xalan2.jar:/data3/gump/ant/dist/lib/ant-trax.jar:/data3/ gump/ant/dist/lib/ant.jar:/data3/gump/ant/dist/lib/ant-nodeps.jar:/data3/gum p/ant/build/lib/ant-testutil.jar:/data3/gump/ant/build/lib/ant-stylebook.jar :/data3/gump/ant/build/lib/ant-jmf.jar:/data3/gump/ant/build/lib/ant-swing.j ar:/data3/gump/ant/build/lib/ant-apache-resolver.jar:/data3/gump/ant/build/l ib/ant-trax.jar:/data3/gump/ant/build/lib/ant-jdepend.jar:/data3/gump/ant/bu ild/lib/ant-apache-bsf.jar:/data3/gump/ant/build/lib/ant-xalan2.jar:/data3/g ump/ant/build/lib/ant-nodeps.jar:/data3/gump/ant/build/lib/ant-apache-oro.ja r:/data3/gump/ant/build/lib/ant-commons-logging.jar:/data3/gump/an t/build/lib/ant-apache-bcel.jar:/data3/gump/ant/build/lib/ant-apache-regexp. jar:/data3/gump/ant/build/lib/ant-launcher.jar:/data3/gump/ant/build/lib/ant -commons-net.jar:/data3/gump/ant/build/lib/ant-apache-log4j.jar:/data3/gump/ ant/build/lib/ant-antlr.jar:/data3/gump/ant/build/lib/ant-junit.jar:/data3/g ump/ant/build/lib/ant-jsch.jar:/data3/gump/ant/build/lib/ant-javamail.jar:/d
Re: [GUMP@lsd]: depot/depot-version-antlet failed
Sorry about this. The junit.antlet from antworks was a little over aggressive and forced the download the junit jar. [..] Can someone please delete /data3/gump/ant/dist/lib/junit-3.8.1.jar Won't Gump simply do it tonight when it synchronizes the ant working directory with ant CVS? Am I missing something? regards Adam
Consistency
Now we have three projects here we are showing consistency problems. at many levels, from different build scripts, to different naming conventions to different directory hierarchies. That is a shame. I'll keep trying to update whatever I find, but would appreciate help from other. The main reason I am bringing up is I can't find the ant types and antlib descriptor files for update. I fear they were removed. See that version has : Adding version\src\java\depot-version Adding version\src\java\depot-version-antlib.xml Deleting version\src\java\version Deleting version\src\java\version-antlib.xml which I just renamed. These used to sit in the src\java\ant directory. Update ought have similar ones, but I can't find them. Anybody got some, or know where they might be? regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: More source tree combining.
I wonder if we can achieve the discipline I was hoping for (w/o the hassle) by still building it in two parts in Gump, to ensure no ant dependencies get into non-ant work. Oh well, no biggee. Yours was the right call. I appreciate you making progress on this... regards Adam - Original Message - From: Nick Chalko [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 12:20 AM Subject: More source tree combining. Ok I combined the version source tree, no more ant/core I also fixed the jar so it get the antlib.xml. I am using the build_antlet.xml They are working really well for me. I added an version antlet and I will try to publish it soon. Take a look at the sample usage at, https://svn.apache.org/repos/asf/incubator/depot/trunk/version/src/test/antlet/build.xml R, Nick
Re: More source tree combining.
I tried doing 'svn update' and I get a conflict 'cos of some file I may have changed down in ant/test (probably sandbox.chalko) that I'd not checked in. I can't seem to find a --force option to ignore this. Any thoughts? Getting used to SVN is slow going... regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 7:24 AM Subject: Re: More source tree combining. I wonder if we can achieve the discipline I was hoping for (w/o the hassle) by still building it in two parts in Gump, to ensure no ant dependencies get into non-ant work. Oh well, no biggee. Yours was the right call. I appreciate you making progress on this... regards Adam - Original Message - From: Nick Chalko [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 12:20 AM Subject: More source tree combining. Ok I combined the version source tree, no more ant/core I also fixed the jar so it get the antlib.xml. I am using the build_antlet.xml They are working really well for me. I added an version antlet and I will try to publish it soon. Take a look at the sample usage at, https://svn.apache.org/repos/asf/incubator/depot/trunk/version/src/test/antlet/build.xml R, Nick
Re: Back in Town
Great, we have 4 of us on this (in one way or another) now. Hmm, I will look into that circular dependency w/ JarManifestHelper. That said, version.util is probably a perfect place for it. Thanks. I think I will try manually using SVN for a while, to ensure I get the gist of it. regards, Adam - Original Message - From: Markus M. May [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 3:18 PM Subject: Back in Town Hello Adam, did a couple of small changes. Coming back to this project now, have had a quite hard time with my laptop and the project at work. Anyway, I am using eclipse 3.0 as well, and you are right with the svn plugin. it is impossible to work with, therefor I recommend using rapidSvn, a nice tk tool. works well even on X. R, Marcus I can't seem to figure out undelete in SVN, so if anybody has a copy of this, either check it in or send to me, thanks. regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Dev [EMAIL PROTECTED] Sent: Friday, April 02, 2004 6:26 AM Subject: JarManifestHelper It seems that common.util was an incomplete copy of version.util, and this class is now missing. Anybody know how to restore files from SVN? [No Attic in the HTTP viewer.] Further, anybody able to create/checking this file it's package (into common)? regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: JarManifestHelper
I can't seem to figure out undelete in SVN, so if anybody has a copy of this, either check it in or send to me, thanks. regards Adam - Original Message - From: Adam R. B. Jack [EMAIL PROTECTED] To: Depot Dev [EMAIL PROTECTED] Sent: Friday, April 02, 2004 6:26 AM Subject: JarManifestHelper It seems that common.util was an incomplete copy of version.util, and this class is now missing. Anybody know how to restore files from SVN? [No Attic in the HTTP viewer.] Further, anybody able to create/checking this file it's package (into common)? regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
Re: [GUMP@lsd]: depot/depot-ruper failed
I've renamed Ruper - Update. Let's see if that is enough to fix this. regards, Adam - Original Message - From: Adam Jack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 20, 2004 5:52 AM Subject: [EMAIL PROTECTED]: depot/depot-ruper failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://gump.apache.org/nagged.html, and/or contact [EMAIL PROTECTED] Project depot-ruper has an issue affecting its community integration. This issue affects 1 projects. The current state is 'Failed', for reason 'Build Failed' Full details are available at: http://lsd.student.utwente.nl/gump/depot/depot-ruper.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data3/gump/depot/ruper/target/dist/jars/apache-depot-ruper-20040320.jar] identifier set to project name - Info - Dependency on ant exists, no need to add for property ant.home. - Error - Failed with reason build failed - - - - - -- -- G U M P Gump performed this work: Work Name: build_depot_depot-ruper (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 1 seconds Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true org.apache.tools.ant.Main -Dgump.merge=/data3/gump/gump-install/work/merge.x ml -Dbuild.sysclasspath=only -Dant.home=/data3/gump/ant/dist -DDATE_STAMP=20 040320 -f build.xml gump [Working Directory: /data3/gump/depot/ruper] - Buildfile: build.xml does not exist! Build failed - To subscribe to this information via syndicated feeds: RSS: http://lsd.student.utwente.nl/gump/depot/depot-ruper.rss | Atom: http://lsd.student.utwente.nl/gump/depot/depot-ruper.atom -- Gump http://gump.apache.org/ [lsd]
Re: [GUMP@lsd]: depot/depot-ruper failed
- Warning - Optional dependency commons-vfs failed with reason build failed I was stretching (hoping) when I set this optional, not mandatory. regards Adam
Re: [GUMP@lsd]: depot/depot-ruper failed
This looks like a problem where the jar referenced in the Gump metadata is different than created by the ant script. In this case, I'll fix Gump. regards Adam - Original Message - From: Markus M. May [EMAIL PROTECTED] To: Depot Development [EMAIL PROTECTED] Sent: Friday, February 20, 2004 1:43 AM Subject: Re: [EMAIL PROTECTED]: depot/depot-ruper failed Hello Adam, I have never worked with GUMP. Should I correct the problem in the ANT Buildfile or do you correct the output path in GUMP? R, Markus To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://jakarta.apache.org/gump/nagged.html, and/or contact [EMAIL PROTECTED] Project depot-ruper has an issue affecting it's community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state is 'Failed', for reason 'Missing Build Outputs' Full details are available at: http://lsd.student.utwente.nl/gump/depot/depot-ruper.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data3/gump/depot/ruper/dist/apache-depot-ruper-20040220.jar] identifier set to project name - Info - Dependency on ant exists, no need to add for property ant.home. - Error - Failed with reason missing build outputs - Error - Missing Output: /data3/gump/depot/ruper/dist/apache-depot-ruper-20040220.jar - Error - No such directory (where output is expected) : /data3/gump/depot/ruper/dist - - - - - -- -- G U M P Gump performed this work: Work Name: build_depot_depot-ruper (Type: Build) State: Success Elapsed: 0 hours, 0 minutes, 19 seconds Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data3/gump/gump/work/merge.xml -Dbuild.sysclasspath=only -Dant.home=/data3/gump/ant/dist -DDATE_STAMP=20040220 -f build.xml gump [Working Directory: /data3/gump/depot/ruper] - init: [mkdir] Created dir: /data3/gump/depot/ruper/target/classes/core [mkdir] Created dir: /data3/gump/depot/ruper/target/classes/ant [mkdir] Created dir: /data3/gump/depot/ruper/target/dist/jars [mkdir] Created dir: /data3/gump/depot/ruper/target/classes/test/core init_repository: [get] Getting: http://www.ibiblio.org/maven/junit/jars/junit-3.8.jar [get] [get] last modified = Thu Aug 29 18:13:57 CEST 2002 [get] Getting: http://www.ibiblio.org/maven/commons-httpclient/jars/commons-httpclient-2.0-rc3.jar [get] [get] last modified = Fri Jan 30 01:46:38 CET 2004 [get] Getting: http://www.ibiblio.org/maven/regexp/jars/regexp-1.3.jar [get] ... [get] last modified = Mon Dec 22 14:00:12 CET 2003 [get] Getting: http://www.ibiblio.org/maven/commons-vfs/jars/commons-vfs-SNAPSHOT.jar [get] [get] .. [get] last modified = Fri Jan 30 01:48:18 CET 2004 [get] Getting: http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar [get] . [get] last modified = Fri Jan 30 01:47:48 CET 2004 [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.3-1.jar [get] [get] [get] [get] [get] [get] last modified = Fri Jan 30 01:45:04 CET 2004 compile: [javac] Compiling 163 source files to /data3/gump/depot/ruper/target/classes/core make_jar: [jar] Building jar: /data3/gump/depot/ruper/target/dist/jars/apache-depot-ruper-0.1.jar make_jar_tests: [jar] Building jar: /data3/gump/depot/ruper/target/dist/jars/apache-depot-ruper-tests-0.1.jar build_core: make_jar_dist: [copy] Copying 1 file to /data3/gump/depot/ruper/target/dist/jars [copy] Copying /data3/gump/depot/ruper/target/dist/jars/apache-depot-ruper-0.1.jar to /data3/gump/depot/ruper/target/dist/jars/apache-depot-ruper-20040220.jar gump: BUILD SUCCESSFUL Total time: 18 seconds - To subscribe to this information via syndicated feeds: RSS: http://lsd.student.utwente.nl/gump/depot/depot-ruper.rss | Atom: http://lsd.student.utwente.nl/gump/depot/depot-ruper.atom -- Gump http://jakarta.apache.org/gump [lsd]
Re: MD5 Hash
Basically the MD5 Hash does not need keys. [...] Also apache.org delivers a file named .asc Ok, thanks, I get it now (I think.) This explains some of the negative comments I've heard about MD5 then (it not being too strong). I read on some, on one Apache list, that folks will be ok with this being strong enough though. What will be tricky for us, should we chose to attempt it, will be supporting mirrors yet using the original MD5 from Apache... Since ASC has keys, that ties in to the 'web of trust' that Apache is working on, I think. Once on trusts a certain set of keys, those keys can be used to verify others that are acquired, and those can be used to verify the ASC. This is much harder to automate, but something we could aspire to... regards, Adam
MD5 and Mirrors ( was Re: MD5 Hash )
Nick wrote: The MD5 should always come from the authoritative source (apache.org) using https. I'm not sure if all environments (JVMs) have HTTPS available. In a somewhat perfect world we'd try HTTPS and if it failed try HTTP, unless some 'minimum security' was requested. I think we'll have to experiment and experince this area over time/iterations. How are we going to know what the authoritative source for a resource is. For java we could enforce a reverse domain name. Four things: 1) Repository URI/URL is what it is (whatever it is) and the URL for the MD5 ought be the URL for the resources plus .md5 on the end. 2) As current Ruper thinking (coding) goes ... Mirrors ought mirror the hierarchy, so wherever a resource is in the repo, the .md5 ought be next to it, and the original .md5 ought be in exactly the same relative position (just relative to an apache root). 3) Mirroring is kinda hacked into Ruper right now, it silently moves the root of a repository (originally set relative to the mirror locator CGI script) to one such mirror. As such Ruper doesn't really know about mirrors. 4) We probably need to rethink current thinking... ;-) regards, Adam
WWW Sites
All, We need to get a WWW site up, to give us a face, and help us get momentum/community. Currently we have two things in depot -- ruper and version -- and we could have more (w/ Avalon folks, when we invite them, a TODO in itself.) As such we could have one depot site that references the others, or we could combine them into one site. My +1 for an umbrella site. [I'd like to keep version separate from version, for good separation if nothing more, and I'd like to use it separately.] regards Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
