[
https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835189#action_12835189
]
Guillaume Nodet commented on ARIES-182:
---------------------------------------
We had a length discussion on IRC:
{code}
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 it?
[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 first
[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 constraint.
[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 the APPLICATION.MF
[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 beforehand
[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
{code}
> The resolution process should be able to be done separatly from the
> AriesApplication creation
> ---------------------------------------------------------------------------------------------
>
> Key: ARIES-182
> URL: https://issues.apache.org/jira/browse/ARIES-182
> 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.
