Re: Gump3:Dependency.dependencyInfo[]
I've been wondering whether its a smart idea to change a whole lot of this now. I think the Normalizer code and friends shows we can keep the model the same for now yet develop most of our code the way we see fit. The new model will fall out, and we'll immediately know what the transformation steps are: the Normalizer ends up being the conversion step between the old GOM and the new GOM. Does that make sense to you? It can wait. Of course, I'm now seeing that this is very bad communication-wise, since you'll have to understand all that ugly xml code in order to understand what the code does. Hmm. Maybe we should take it further. I'm thinking here that we should forget about the xml there and build the example model completely in code. Sounds good for a test model we can write unit tests against. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump3:Dependency.dependencyInfo[]
I meant to send this yesterday, but somehow failed to pres send... What is the thinking behind this being an array? Do we want to support multiple dependencies from one project to another? BTW: Per [1] I've change DependencyInfo.specific_output_id to ids (plural). Now an array. regards Adam [1] http://gump.apache.org/metadata/project.html#depend - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
On 25-04-2005 15:12, Adam Jack [EMAIL PROTECTED] wrote:
What is the thinking behind this being an array? Do we want to support
multiple dependencies from one project to another?
Well, either a project depends on another or it doesn't, but it can depend
on various things (for example multiple jars, an environment variable a home
directory and a .so/dll).
If you think of a Project as a node, a Dependency as a vertex, then you can
have an array of DependencyInfo as multiple vertex colorings. Was my
thinking.
BTW: Per [1] I've change DependencyInfo.specific_output_id to ids (plural).
Now an array.
So that's sort-of redundant. We don't need both to be an array. We could
create multiple DependencyInfo objects, one for each id, instead. I think it
actually needs to be that way, since dependency on one of the specified ids
might be optional, but dependency on another one is not.
I.e, in xml:
project name=a
depend project=b ids=basic, extension1 runtime=true/
depend project=b ids=fancy-feature optional=true/
/project
in code:
a = Project(a)
b = Project(b)
d = Dependency(dependency=b, dependee=a)
d.add_depedencyinfo(DependencyInfo(specific_output_id=basic,
runtime=true)
d.add_depedencyinfo(DependencyInfo(specific_output_id=extension1,
runtime=true)
d.add_depedencyinfo(DependencyInfo(specific_output_id=fancy-feature,
runtime=true)
In fact, I'd much prefer the xml to be:
project name=a
depend project=b id=basic runtime=true/
depend project=b id=extension1 runtime=true/
depend project=b id=fancy-feature optional=true/
/project
Or rather:
project name=a
depend project=b
output type=jar id=basic runtime=true/
output type=jar id=extension1 runtime=true/
output type=native-lib id=fancy-feature optional=true/
/depend
/project
It doesn't make sense to do enumerations inside an xml attribute. It's much
clearer to make enumerations by well, enumerating elements.
(...)
Anyway, I guess the code isn't as clear as I thought it was. Similarly I
couldn't quite figure out what you were trying to do in your commit, further
indication that this really needs more change than you introduced :-D
Any suggestion on how to clean this up further? I feel its somewhat
important to get this mostly right the first time around (including making
things intuitive) as changing relationships between model elements gets more
expensive as the codebase size increases.
Maybe we should call DependencyInfo something else. I thought for a long
time about a better name. Couldn't really come up with something.
Or maybe we should make DependencyInfo into a map-like object; in fact, make
Dependency into a map-like object.
a = Project(a)
b = Project(b)
d = Dependency(dependency=b, dependee=a)
d.append({specific_output_id=basic,
runtime=true})
d.append({specific_output_id=fancy-feature,
runtime=true})
Hmm. Doesn't look much clearer.
WDYT?
Cheers,
LSD
PS: that e-mail certainly ended up longer than expected! :-D
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
If you think of a Project as a node, a Dependency as a vertex, then you
can
have an array of DependencyInfo as multiple vertex colorings. Was my
thinking.
I sorta got it, but I guess I was thinking based upon existing Gump
metadata/documentation. I had no metadata sample for Ant, so built it based
upon what I knew.
It doesn't make sense to do enumerations inside an xml attribute. It's
much
clearer to make enumerations by well, enumerating elements.
(...)
Anyway, I guess the code isn't as clear as I thought it was. Similarly I
couldn't quite figure out what you were trying to do in your commit,
further
indication that this really needs more change than you introduced :-D
Any suggestion on how to clean this up further?
We miscommunicated based of what I believed the XML to be, and applying my
read of the code to that input. I (honestly) can't tell you which form is
better ('ids' w/ N or N of depend 'id') but I lean towards yours. Let's
restore it to your way, and then create some good sample XML metadata. I
need a small stack of dependencies (up to an ant command, not a script
command ) to work on ClasspathPlugin and AntPlugin.
BTW: If we are changing metadata, let's fix it so that we know what is Ant
over Java not Ant over (say) C# or whatever.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump3:Dependency.dependencyInfo[]
In fact, I'd much prefer the xml to be: [...] Or rather: project name=a depend project=b output type=jar id=basic runtime=true/ output type=jar id=extension1 runtime=true/ output type=native-lib id=fancy-feature optional=true/ /depend /project I'd go for this (although perhaps artifact not output) and maybe have more attributes on the depend element, to avoid repetition (e.g. have runtime setable there.) That said, I think it really comes down to how much complexity we want to allow here, or even ... how much is actually needed by users. Let's at least split out these sub-elements, and work on attributes in time. BTW: I suspect 'type' ought be on the declaration, not the dependency, right? No point duplicating that information, is there? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
