You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Guillaume Nodet (JIRA)" <ji...@apache.org> on 2010/02/18 14:37:27 UTC
[jira] Created: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
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.
[jira] Commented: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835229#action_12835229 ]
Guillaume Nodet commented on ARIES-182:
---------------------------------------
Committing to https://svn.apache.org/repos/asf/incubator/aries/trunk ...
M application/application-management/src/main/java/org/apache/aries/application/management/impl/AriesApplicationImpl.java
M application/application-management/src/main/java/org/apache/aries/application/management/impl/AriesApplicationManagerImpl.java
M application/application-management/src/test/java/org/apache/aries/application/management/impl/AriesApplicationManagerImplTest.java
Committed r911424
> 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
> Components: Application
> Affects Versions: 1.0
> Reporter: Guillaume Nodet
> Assignee: 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.
[jira] Assigned: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet reassigned ARIES-182:
-------------------------------------
Assignee: Guillaume Nodet
> 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
> Assignee: 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.
[jira] Commented: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835190#action_12835190 ]
Guillaume Nodet commented on ARIES-182:
---------------------------------------
So I propose to:
* move the resolution process from createApplication() to resolve()
* have install() call resolve() if needed
* add a isResolved() method on the AriesApplication and javadoc to explain that the new application should be obtained from the ApplicationContext in case the application was not resolved before installation
> 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.
[jira] Updated: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Jeremy Hughes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Hughes updated ARIES-182:
--------------------------------
Fix Version/s: 0.1
> 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
> Components: Application
> Affects Versions: 1.0
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Fix For: 0.1
>
>
> 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.
[jira] Resolved: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet resolved ARIES-182.
-----------------------------------
Resolution: Fixed
Committing to https://svn.apache.org/repos/asf/incubator/aries/trunk ...
M application/application-api/src/main/java/org/apache/aries/application/management/AriesApplication.java
M application/application-api/src/main/java/org/apache/aries/application/management/AriesApplicationManager.java
M application/application-management/src/main/java/org/apache/aries/application/management/impl/AriesApplicationImpl.java
M application/application-management/src/main/java/org/apache/aries/application/management/impl/AriesApplicationManagerImpl.java
Committed r911409
> 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
> Components: Application
> Affects Versions: 1.0
> Reporter: Guillaume Nodet
> Assignee: 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.
[jira] Updated: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Guillaume Nodet updated ARIES-182:
----------------------------------
Component/s: Application
Affects Version/s: 1.0
> 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
> Components: Application
> Affects Versions: 1.0
> Reporter: Guillaume Nodet
> Assignee: 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.
[jira] Commented: (ARIES-182) The resolution process should be able
to be done separatly from the AriesApplication creation
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ 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.