aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <>
Subject [jira] Commented: (ARIES-182) The resolution process should be able to be done separatly from the AriesApplication creation
Date Thu, 18 Feb 2010 13:37:27 GMT


Guillaume Nodet commented on ARIES-182:

We had a length discussion on IRC:

gnodet: notatibm: are you still working on the obr resolver ?  the trader sample eba can't
resolve anymore atm
[1:24pm] notatibm: Hi, I am still working on it.
[1:25pm] notatibm: The trader sample should be resolving using the noop resolver shouldn't
[1:26pm] gnodet: well, actually i think it deploy the first time, but if i reinstall the app,
there is a failure
[1:26pm] gnodet: let me retry from a clean state
[1:27pm] notatibm: I'm currently working on the code to resolve against the bundle info in
the app, but it is a bit involved, so it probably wont be done today.
[1:28pm] gnodet: i think it's unrelated to what i'm seeing
[1:31pm] gnodet: notatibm: btw, what would you think of splitting  (or at least being able
to) the creation of the AriesApplication from its resolution
[1:31pm] gnodet: i just have the use case right now
[1:32pm] gnodet: my appliction fails to resolve, so i can't call createApplicaiton()
[1:32pm] notatibm: So you want an AriesApplication you can't install?
[1:32pm] gnodet: but then, i have no easy way to see the metadata
[1:32pm] gnodet: well, we could move the resolve() method onto the AriesAppplication
[1:33pm] gnodet: or call it automatically when an installation is requested
[1:33pm] notatibm: I think it would be good if we could call createAriesApplication and get
something back if it doesn't resolve, but I would still like the resolve to occur.
[1:35pm] gnodet: but waht if you want to impose constraints on the resolution ? this mean
you need to resovle twice, don't you ?
[1:36pm] notatibm: Leaving resolve to one side I would like to know if any failures occurred
when converting artefacts to bundles, but I would like to get the messages, but still be able
to install.
[1:36pm] notatibm: Resolve is similar to that.
[1:36pm] notatibm: On the subject of resolve there is a resolve method on the AriesApplicaationManager
[1:36pm] notatibm: So if we had an isInstallable method on AriesApplication we could then
just call the app manager to resolve later.
[1:37pm] gnodet: i don't get it
[1:37pm] notatibm: which?
[1:37pm] gnodet: if you want to call AriesApplicationManager#resolve(), you need an application
[1:37pm] gnodet: which has to be resolved
[1:38pm] gnodet: so if you want to impose constraints, you need to first have a resolved application
[1:38pm] gnodet: let's say the search space is too big, you may not be able to resovle it
without constraints ...
[1:39pm] gnodet: or do i misunderstand the use of constraints ?
[1:39pm] gnodet: they *could* be used to reduce the search space, right ?
[1:39pm] notatibm: ok, so we could either not resolve during create, which I'm not sure about,
or we could add teh ResolveConstraints var args onto create.
[1:40pm] gnodet: what's the need to resolve the applicaton automatically ?
[1:40pm] notatibm: give me a sec to have a peek.
[1:40pm] gnodet: not automatically, but systematically
[1:41pm] notatibm: OK, so I'll describe in terms of an example.
[1:42pm] notatibm: Assume we have the following Application-Content: a;version="[1.0.0,2.0.0)",b;version="[2.0.0,3.0.0)"
[1:42pm] notatibm: The constraint would allow you to say resolve, but with a locked down to
version 1.5
[1:43pm] notatibm: So you would resolve the following: a;version="[1.5,1.5]",b;version="[2.0.0,3.0.0)"
[1:44pm] gnodet: are constrainsts only usable on bundles from the Application-Content ?
[1:44pm] notatibm: No
[1:44pm] gnodet: so you add a constraint to lock down dependency c to a given version, right
[1:44pm] notatibm: yes
[1:45pm] notatibm: although we don't implement this right now and the resolver api wouldn't
support it, which is not good.
[1:45pm] gnodet: what if c isn't actually a dependency but you add a constraint on it ?
[1:46pm] gnodet: we can always enhance the resolver if needed
[1:46pm] gnodet: would c be ignored or deployed along ?
[1:47pm] gnodet: and btw, the version on the constraint should be a range in theory, because
you may want to say a;version="[1.5,2.0)"
[1:49pm] notatibm: If you don't need c you shouldn't bring it in just because it is a resolve
[1:49pm] gnodet: notatibm: well, i'm not asking about best practive 
[1:49pm] notatibm: You are right a range would be useful.
[1:49pm] gnodet: saying something is not good to do doesn't mean you can prevent it
[1:50pm] notatibm: In general I agree, but in this case I would say that the resolver shouldn't
bring it in.
[1:51pm] gnodet: just created a jira for the version range
[1:51pm] notatibm: you are efficient 
[1:53pm] jbohn joined the chat room.
[1:53pm] gnodet: haven't fixed it yet
[1:54pm] notatibm: In that case I'll raise a bug for not passing ResolveConstraints down to
the resolver.
[1:55pm] gnodet: during the first resolution ? ok
[1:55pm] notatibm: not specifically.
[1:56pm] notatibm: Just that if you call resolve passing in constraints they cannot be given
to the resolver.
[1:56pm] gnodet: well, the fact that's not implemented is different from the fact that the
api does not allow it at all
[1:56pm] notatibm: I haven't raised one for the create vs resolve, I'm still pondering it.
[1:56pm] notatibm: The AriesApplicationResolver API doesn't allow it.
[1:56pm] gnodet: yeah
[1:57pm] gnodet: i think we need more flexibility for creating applications
[1:57pm] gnodet: for example, i can't see a way to easily install an application simply from
[1:57pm] gnodet: which should be possible given it's the only required thing
[1:57pm] notatibm: Ah, well it is possible, just not necessarily very nicely.
[1:58pm] notatibm: You can provide an implementation of IDirectory that will delegate to a
single file.
[1:58pm] gnodet: yeah, that's a bit cumbersome, but you have a point
[1:58pm] notatibm: quick question, the bundle symbolic name can have directives, do you know
if it can also have attributes?
[1:59pm] gnodet: notatibm: well, i can't say for sure, but i would not see why
[1:59pm] notatibm: I'm updating BundleInfo so I can get to the directives/attributes.
[2:00pm] notatibm: The spec says you can have parameters on a symbolic name, which means attributes/directives.
[2:04pm] gnodet: and i think the case i exposed earlier with a constraint on a non-dependency
is valid, if you think about enforcing a set of constraints without really knowing the application
[2:07pm] notatibm: OK, so I think it is ok to break out the resolve so it isn't done implicitly,
but the AriesApplication is currently immutable and I want it to stay that way.
[2:10pm] gnodet: yeah, i was gonna say that about the immutability
[2:10pm] gnodet: but what would you propose then ?
[2:11pm] gnodet: just move the Set<BundleInfo> out of the application somehow ?
[2:11pm] notatibm: Erm, what do you think Set<BundleInfo> is for?
[2:12pm] gnodet: that's the output of the resolution, right ?
[2:12pm] notatibm: no
[2:13pm] notatibm: The output of the resolution is stored in the DeploymentMetadata interface.
[2:13pm] notatibm: An aries application archive can contain within it bundles which feed into
the resolution process.
[2:13pm] notatibm: The Set<BundleInfo> is how we access the bundles contained in the
archive to use during resolution.
[2:14pm] notatibm: I think I should update the Javadoc for that perhaps.
[2:14pm] gnodet: mmh, i don't follow
[2:14pm] gnodet: the resolver actually returns a Set<BundleInfo>
[2:15pm] gnodet: and that's what will get installed later
[2:15pm] gnodet: ah, found the problem
[2:15pm] notatibm: ok?
[2:17pm] gnodet: yeah
[2:17pm] notatibm: I think I'm going to update the javadoc for AriesApplication.
[2:17pm] notatibm: On the subject of the javadoc is it possible to get a copy of the javadoc
published on our website?
[2:18pm] gnodet: yeah, not sure how easy we can do that automatically, but a "mvn site:deploy"
should work
[2:18pm] gnodet: if it does not, we need to fix the maven build
[2:19pm] notatibm: I'm guessing we will have to fix the maven build 
[2:20pm] gnodet: so what about the following changes on the AriesApplicationManager:
[2:20pm] gnodet:   * createApplication() does not resolve the app
[2:21pm] gnodet:   * resolve() returns a DeploymentMetadata
[2:21pm] gnodet:   * install has an additional argument of type DeploymentMetadata
[2:22pm] gnodet: when install is called, either the application must have a DeploymentMetadata
already (coming from the eba archive) or one must be given
[2:22pm] gnodet: if none is given, one will be computed wiout any constraints
[2:23pm] notatibm: It doesn't work for me.
[2:23pm] gnodet: why ?
[2:23pm] notatibm: one of the key things I want to be able to do is store a resolved AriesApplication.
[2:23pm] notatibm: In your model that doesn't work because the DeploymentMetadata is separate
from the Application.
[2:23pm] gnodet: ah, i was gonna ask about that, what's the point in doing that ?
[2:23pm] gnodet: and at which point do you need that ?
[2:24pm] notatibm: I can store the resolved app away and use it later without having to re-resolve.
[2:24pm] notatibm: So I want to have a resolved app I can deploy to multiple different running
JVM's and know they are the same.
[2:26pm] gnodet: so keep the resolve() method the way it is
[2:26pm] gnodet: so move the resolution process from createApplication() to resolve() and
have install() call resolve() if needed
[2:27pm] gnodet: if install() calls resolve(), the resolved application will be available
from ApplicationContext#getApplication()
[2:28pm] gnodet: or have install() throw an exception is the application is not resolved
[2:28pm] notatibm: Thinking...
[2:29pm] gnodet: but i'd like an easy api to use, so forcing the user the resolve() the application
does not always make sense, i think this should be able to happen automatically
[2:30pm] notatibm: I agree
[2:30pm] notatibm: ok, so I would go with install resolves the application.
[2:31pm] gnodet: and you retrieve the resolved application from the ApplicationContext, keeping
the application immutable
[2:31pm] notatibm: AriesApplication has a method isResolved, or something similar and we doc
on the install method that if isResolved returns false the ApplicationContext.getApplication
will return something different.
[2:31pm] notatibm: yes
[2:31pm] gnodet: isResolved() actually comes down to getDeploymentMetadata() != null, right
[2:32pm] notatibm: good point.
[2:32pm] gnodet: doesn't mean we don't need the method, but just to make sure i understand
[2:32pm] notatibm: but an isResolved looks nicer.
[2:32pm] gnodet: yeah, i do agree
[2:33pm] gnodet: i'll create a jira

> The resolution process should be able to be done separatly from the AriesApplication
> ---------------------------------------------------------------------------------------------
>                 Key: ARIES-182
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>            Reporter: Guillaume Nodet
> Several use cases:
>   * the user wants to impose constraints without having to resolve the application twice
>   * the resolution fails but we'd like to understand why and have some informations about
the application 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message