You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@depot.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2004/06/22 20:02:23 UTC
Refactoring (for merge) and APIs
1) Resource -> Artifact:
It will not be trivial, but we could rename Resource to be Artifact to ease
a merge with Avalon Repository (and since Artifact has started to become a
recognized term).
BTW: I've started to create a page for terms (as Nick suggested):
http://wiki.apache.org/incubator/DepotTerminology
BTW: I figured a similar page for design objectives/tenets would help
communicate:
http://wiki.apache.org/incubator/DepotDesign
Can anybody think of any others?
BTW: We need to get Javadocs for the projects up onto the sites, I think
this'll help us see things from 30 thousand feet, and hence seen
similarities/differences.
2) APIs
I'd like help on how we craft a good API, how we keep it clear and simple.
One problem (as I've noted) is we have all aspects of our code muddled into
one source folder, so we have to rely upon package names to help us separate
& that isn't enough. Maybe without this we need Javadoc help, or something
(Wiki/whatever).
I'd been told that a good API has the main classes in the root package, i.e.
in org.apache.depot.update. That I can believe. Trouble is, the 'Updater'
project is focused towards Updating, so we put ResourceUpdater there. Maybe
we need to add Artifact/Repository, and move ResourceUpdater to a separate
client package (or separate project). Thoughts?
Also, we have things like FileAssistent/FileUpdater (and ClasspathUpdater)
these are higher level 'helpers' for working with ResourceUpdater. Ought
they be in a separate package, so they don't clutter the main access point?
Are they even needed -- or ought our resource API be simple enough they
aren't? Could these be samples?
All input on how to cleanup/make an API appreciated...
regards
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
Re: Refactoring (for merge) and APIs
Posted by "Markus M. May" <mm...@gmx.net>.
Hello,
>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?
>
to access SVN and especially the repository of depot in SVN try the
following URL:
https://svn.apache.org/repos/asf/incubator/depot/. There you'll find "tags"
and "trunks". trunks contains the main layers of depot right now, the tags
are just (like the name indicates) old versions of the same stuff. Like
already stated there is more then just Updater to Depot. There is also
Version and a Common layer, which is used in all other layers :-)
SVN is pretty cool, except that there are no real Clients for IDEs available
right now, but hopefully this will change soon. As a client I would
recommend rapidSVN, which is a cross-platform tool and pretty nice. But
since you are using IDEA, you could be lucky and use svnUp?
I am not really sure, if you could just use svn with the same password as
you are using with cvs, so you just have to try.
R,
Markus
Re: Refactoring (for merge) and APIs
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Adam R. B. Jack wrote:
>
>>>> 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?
>
>
> +1
>
+1
Re: Refactoring (for merge) and APIs
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Adam R. B. Jack wrote:
>>>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?
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Refactoring (for merge) and APIs
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> >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
Re: Refactoring (for merge) and APIs
Posted by Michael Davey <Mi...@coderage.org>.
Adam R. B. Jack wrote:
>1) Resource -> Artifact:
>
>It will not be trivial, but we could rename Resource to be Artifact to ease
>a merge with Avalon Repository (and since Artifact has started to become a
>recognized term).
>
>
+1. Shouldn't be to difficult using IDEA. 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?
>BTW: I've started to create a page for terms (as Nick suggested):
> http://wiki.apache.org/incubator/DepotTerminology
>
>
I'd like to suggest three others:
Java Artifact (AFSRepository specification defines more than just jars
in the repository)
Depot Artifact - artifact that can be manipulated by Depot
Update(r) - see below
>I'd been told that a good API has the main classes in the root package, i.e.
>in org.apache.depot.update. That I can believe. Trouble is, the 'Updater'
>project is focused towards Updating, so we put ResourceUpdater there. Maybe
>we need to add Artifact/Repository, and move ResourceUpdater to a separate
>client package (or separate project). Thoughts?
>
>
I thought that update was a seperate project. Ah, do you mean that
Updater and Artifact are in the same package? If so, then I agree that
there should be a seperate core or artifact package.
--
Michael