Hi Eric,
hope
you're having fun. I'm wildly jetlagged so am sleeping at odd
times!
So I've
been working on packages and have come up with a few items where I have had to
make some decisions and I'd like to run them past you...
Naming
:
1. When we do a getPackage() I think we should return the "parent"
package, and getName() should return the name of this package - so the FQN is
the same as the package we are representing.
2. isAbstract makes no sense -
so I removed it from the wizard - same for Extending Artifact.
ED> Yes. This
makes sense.
We
proposed that the packageArtifact lives in a ".package" file in the package
concerned. I struggled with the extract stuff, as I was trying todo some dodgy
mapping between "real" and imagined packages...I now realise that I can put
anything I like in the .package file because the java auditor won't look at
it!
So - having crossed that pointless barrier...I realised that the
explorer behaviour needs to be different based on whether the Package Artifact
type is enabled in the profile.
If
ENABLED:
Wizard will create a true package plus a
PackageArtifact
Explorer will have an "Open in Editor" option for the
package (right click).
If the corresponding PackageArtifact does not exist,
then this should create it "under the covers".
The "New Package" action
should call the New Package Wizard - (as will an explicit
NewWizardAction).
Creating
ANY artifact should check for PackageArtifacts up the tree and create "under
the covers" for all packages. SHOULD WE OPEN THE EDITOR FOR ALL NEWLY CREATED
PACKAGEARTIFACTS?
ED> I think we
should avoid changing the behavior as much as we can. So I’d be in favor of
not opening the packages in editors. Unless users want to explicitly store
additional information (version/description/stereotype), that editor shouldn’t
be needed?
RC >> That's good - and
easy :-)
So we only open editor on a
PackageArtifactCreate (ie straight after a wizard) and an explicit "Open in Editor"
HOW DO
WE HANDLE PACKAGES WITH NO PACKAGEARTIFACT IN MODULES OR REFERENCED
PROJECTS?
ED> It seems we can
create a IPAckageArtifact on the fly, and not have it stored? If a user starts
setting details on it, he/she would need to hit a “save” at some point which
would create the package (if not a module).
RC>> I'll have to try this - I think it
might be better if they got a message saying they can't edit it before
they type in and then gets rejected.
AbstractArtifact.getContainingComponent() will return a
PackageArtifact
ED> or any
other artifact is this is a field, method, literal.
RC >> Yes. My
bad
AbstractArtifact.getContainedComponents()
will return lots of things for a Package, nothing for other ArtifactTypes (or
should they return all the children - Fields etc)
ED> for other ArtifactTypes, they should
definitely return the fields, methods, literals.
RC >> OK
Question
here is whether this stuff should be cached?
ED> well, what do you mean caching? The contained/containing
components will need to be up2date at all time and should return the list
directly without having to walk any other data structure. What will be needed
is a filtering mechanism (and possibly caching) for facets. The same stuff is
currently in place for the Fields at least now.
RC >> OK - More investigating
needed.
Plugins
should have a getPackageArtifacts() collection in the context and the ability
to select that as a Artifact type in a rule.
This collection may need to be
filled with "dummy" PackageArtifacts if there are any missing .package files
for a "real" package.
ED> Yes.
“volatile” packages that are not stored.
RC >> OK
Add an
audit rule to check for .package files for all real packages. (This will be
horrible if we enable packageArtifacts for existing large
projects!)
ED> This is why we need
to lazy create them...
RC >> If we lazy create them (ie only on edit),
there will be tons of audit messages right up until they are properly
created.... which is what I was trying to say
here.
If
DISABLED:
Explorer will just have the basic "new Package" action (ie as
now)
AbstractArtifact.getContainingComponent() will return an empty
collection.
ED> except for Field,
methods, literals which should return their containing artfiact.
RC >> Sure
AbstractArtifact.getContainedComponents() - will not have any
artifacts in - same question as above re Fields etc.
I'm getting near to looking at some of these odd cases, so let me
know of any thoughts!
ED> sounds like a lot
of Junit testing :-).
RC >> and
UI.........
I also
need some icons!
RC
