[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [tigerstripe-dev] API refactoring (Bug 215255)
|
One more...
The Enum for TypeMultiplicity is in the IAssociationEnd purely for
historical reasons - it should be moved IMHO.
RC
-----Original Message-----
From: Richard Craddock (rcraddoc)
Sent: 23 January 2008 16:31
To: 'Tigerstripe developers list'; Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] API refactoring (Bug 215255)
Eric,
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?
RC
/***********************************************************************
********
* 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
* http://www.eclipse.org/legal/epl-v10.html
*
* 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)
Eric,
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
here.
/**
* Returns the details contained in the project that this artifact
belongs
* 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..
RC
