Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [tigerstripe-dev] API refactoring (Bug 215255)


Some more things....

Some of the query types make no sense ... We never implemented the code!
Should be "filter those out"?

Oh, and I forgot the IArtifactManagerSession!  I have put that in
org.eclipse.tigerstripe for now

And what is the format for adding comments ? Do I need to tag everything
I touch with an "admission of guilt " :-)
Eg should I add a line to the Contributor, or only If I've made
"significant" changes?


 * Copyright (c) 2007 Cisco Systems, Inc.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * Contributors:
 *    E. Dillon (Cisco Systems, Inc.) - reformat for Code Open-Sourcing

-----Original Message-----
From: tigerstripe-dev-bounces@xxxxxxxxxxx
[mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard
Craddock (rcraddoc)
Sent: 23 January 2008 13:53
To: Eric Dillon (erdillon)
Cc: tigerstripe-dev@xxxxxxxxxxx
Subject: [tigerstripe-dev] API refactoring (Bug 215255)

Some things about the refactoring of the api stuff:
1. There is a comment in IAbstractArtifact  to the effect that artifacts
in modules return something different (null) from artifacts in "proper
projects" , however the refactoring means that there are not two
different things to return. I don't understand what was meant to happen
* Returns the details contained in the project that this artifact
* to.
* NOTE: this is always populated, as opposed to
* {@link #IextTigerstripeProject()} which returns null for artifacts
* contained in Modules.
* @return

public IProjectDescriptor getIProjectDescriptor();

2. When I did the testing it all seems to work, but I am not clear now
what gets into the external api zip file (and how). Do we still need
that/need to update some references somewhere?

3. There are some items in the code that are already deprecated (mostly
around multiplicity enumerations etc) I think we should consider
deleting them at this point.

4. Re: further refactoring to put most stuff behind an "internal"
package. I have made some possible changes here and in the attached
javadoc you should be able to see what I am proposing should be
"visible" as a first pass. Generally I have tried to include only those
things that  are used in plugins, or in some simple imports.

I have not reviewed the actual classes themselves... I think there are
methods that return objects that are not in the exposed classes, which
doesn't make a lot of sense?

(I have also left stuff in a bizarrely named package -
org.eclipse.tigerstripe.internal.api......but we can tidy that up as a
next go round.)

Does this look a sensible set of things to be exposing? Are we confident
that stuff in here will be very stable? Note that this is not put back
yet - so it exists only on my machine.

Comments welcome from all..


Back to the top