| Re: [tigerstripe-dev] RE: Packages |
OK, so I guess the creation of an explicit inter-package dependency would force the creation of .package files (if they did not already exist)?
Sounds fine to me.
Cheers,
JohnW
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Eric Dillon (erdillon)
Sent: 25 June 2008 14:16
To: Tigerstripe developers list; Richard Craddock (rcraddoc)
Subject: Re: [tigerstripe-dev] RE: Packages
Indeed, the idea is “lazy creation” of the underlying package files on disk. Only create them when the user needs them, i.e. When the user needs to store something in it.
Otherwise, simply create volatile objects...
Eric
On 6/25/08 7:38 AM, "Richard Craddock (rcraddoc)" <rcraddoc@xxxxxxxxx> wrote:
_______________________________________________
Yes, and No,
We will not go through and create .package files for each package - the idea is that we "spoof" packageArtifacts if there is not a .package file associated with a given package.
If the user edits the packageArtifact, then we will create the "proper" artifact. The only thing that is held in a package Artifact is really a comment and stereotypes. The containment can be calculated using real or "spoofed" ones, and thus used at generate time.
I guess we will also need to do the behind the scenes creation of a real one if the user does a drag&drop onto the class diagrams - but we don't plan to do that part just yet.
Richard
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of John Worrell (jworrell)
Sent: 25 June 2008 12:15
To: Tigerstripe developers list; Eric Dillon (erdillon)
Subject: RE: [tigerstripe-dev] RE: Packages
Will we be able to load an existing project (eg. existing Chameleon) and have TS just sort out the packages for us on that first load?
Cheers,
JohnW
From: tigerstripe-dev-bounces@xxxxxxxxxxx [mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Richard Craddock (rcraddoc)
Sent: 24 June 2008 19:18
To: Eric Dillon (erdillon)
Cc: Tigerstripe Developers
Subject: [tigerstripe-dev] RE: Packages
Some responses below.
From: Eric Dillon (erdillon)
Sent: 24 June 2008 18:24
To: Richard Craddock (rcraddoc)
Cc: Tigerstripe Developers
Subject: Re: Packages
Hi Richard,
Yes, I am having a lot of fun :-).
See my comments below.
Eric
On 6/24/08 10:24 AM, "Richard Craddock (rcraddoc)" <rcraddoc@xxxxxxxxx> wrote:
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
_______________________________________________
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev