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
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.
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
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
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
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
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
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
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:
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
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
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
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:
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
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
+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
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
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
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
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
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
- 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
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
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
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
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
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:
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
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
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?
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
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
||
| get/put to cache with group/name/blob-version semantics, |
| security on transmission, integrity checking, |
| and reliability of service |
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
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
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
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)
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
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
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]
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
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
+depend project=xmlunit/
Cool, but what does it do what do we use it for? Just curious.
regards
Adam
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
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
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
-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
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
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
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 =
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
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
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
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]:
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
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 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
-
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
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
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
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
- Warning - Optional dependency commons-vfs failed with reason build
failed
I was stretching (hoping) when I set this optional, not mandatory.
regards
Adam
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,
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
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
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,
66 matches
Mail list logo
