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