Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tigerstripe-dev] RE: Packages

Title: Re: [tigerstripe-dev] RE: Packages
Hmmm... No. You don’t need the .package to store a depedency as the dependency object only needs the “fullyQualifiedName” of both ends.
As a user of the framework, you wont know whether the .package is there or not. In fact you don’t care, you’ll get a IPackageArtifact when looking up a package by its fully qualified name in the Art Manager no matter what.

Hope this helps,

On 6/25/08 9:16 AM, "John Worrell (jworrell)" <jworrell@xxxxxxxxx> wrote:

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.



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...


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.



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?




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.

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.

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"

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.

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!




tigerstripe-dev  mailing  list

tigerstripe-dev mailing list

Back to the top