[JBoss JIRA] (ARTIF-604) Show relationships targeting the current artifact in the UI
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-604?page=com.atlassian.jira.plugin.... ]
Brett Meyer resolved ARTIF-604.
-------------------------------
Resolution: Done
> Show relationships targeting the current artifact in the UI
> -----------------------------------------------------------
>
> Key: ARTIF-604
> URL: https://issues.jboss.org/browse/ARTIF-604
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 1.0.0.Alpha1
>
>
> Great idea from [~eric.wittmann] on an email thread:
> {quote}
> I also think there is room in the UI for some way to show all artifacts
> that point to the current artifact by a specific relationship. So
> perhaps an editable drop-down control allowing the user to select a
> common relationship or type their own, which would result in this query:
> /s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
> The <model>, <type>, and <uuid> values come from the currently selected
> artifact. The <relationship> comes from the dropdown. Populate a table
> with the results!
> {quote}
> Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/\{uuid\}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ARTIF-604) Show relationships targeting the current artifact in the UI
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-604?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-604:
------------------------------
Description:
Great idea from [~eric.wittmann] on an email thread:
{quote}
I also think there is room in the UI for some way to show all artifacts
that point to the current artifact by a specific relationship. So
perhaps an editable drop-down control allowing the user to select a
common relationship or type their own, which would result in this query:
/s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
The <model>, <type>, and <uuid> values come from the currently selected
artifact. The <relationship> comes from the dropdown. Populate a table
with the results!
{quote}
Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/\{uuid\}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
was:
Great idea from [~eric.wittmann] on an email thread:
{quote}
I also think there is room in the UI for some way to show all artifacts
that point to the current artifact by a specific relationship. So
perhaps an editable drop-down control allowing the user to select a
common relationship or type their own, which would result in this query:
/s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
The <model>, <type>, and <uuid> values come from the currently selected
artifact. The <relationship> comes from the dropdown. Populate a table
with the results!
{quote}
Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/{uuid}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
> Show relationships targeting the current artifact in the UI
> -----------------------------------------------------------
>
> Key: ARTIF-604
> URL: https://issues.jboss.org/browse/ARTIF-604
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 1.0.0.Alpha1
>
>
> Great idea from [~eric.wittmann] on an email thread:
> {quote}
> I also think there is room in the UI for some way to show all artifacts
> that point to the current artifact by a specific relationship. So
> perhaps an editable drop-down control allowing the user to select a
> common relationship or type their own, which would result in this query:
> /s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
> The <model>, <type>, and <uuid> values come from the currently selected
> artifact. The <relationship> comes from the dropdown. Populate a table
> with the results!
> {quote}
> Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/\{uuid\}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ARTIF-604) Show relationships targeting the current artifact in the UI
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-604?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-604:
------------------------------
Description:
Great idea from [~eric.wittmann] on an email thread:
{quote}
I also think there is room in the UI for some way to show all artifacts
that point to the current artifact by a specific relationship. So
perhaps an editable drop-down control allowing the user to select a
common relationship or type their own, which would result in this query:
/s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
The <model>, <type>, and <uuid> values come from the currently selected
artifact. The <relationship> comes from the dropdown. Populate a table
with the results!
{quote}
Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/{uuid}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
was:
Great idea from [~eric.wittmann] on an email thread:
{quote}
I also think there is room in the UI for some way to show all artifacts
that point to the current artifact by a specific relationship. So
perhaps an editable drop-down control allowing the user to select a
common relationship or type their own, which would result in this query:
/s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
The <model>, <type>, and <uuid> values come from the currently selected
artifact. The <relationship> comes from the dropdown. Populate a table
with the results!
{quote}
> Show relationships targeting the current artifact in the UI
> -----------------------------------------------------------
>
> Key: ARTIF-604
> URL: https://issues.jboss.org/browse/ARTIF-604
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 1.0.0.Alpha1
>
>
> Great idea from [~eric.wittmann] on an email thread:
> {quote}
> I also think there is room in the UI for some way to show all artifacts
> that point to the current artifact by a specific relationship. So
> perhaps an editable drop-down control allowing the user to select a
> common relationship or type their own, which would result in this query:
> /s-ramp/<model>/<type>[<relationship>[@uuid = <uuid>]]
> The <model>, <type>, and <uuid> values come from the currently selected
> artifact. The <relationship> comes from the dropdown. Populate a table
> with the results!
> {quote}
> Instead of using a drop-down selection of relationship types, I instead plan on displaying *all* relationships targeting the artifact. This will require a new Atom feed, outside of the S-RAMP spec. So, I'm creating something like /artificer/reverseRelationships/{uuid}. Note the /artificer path, as opposed to /s-ramp. This will create a feed of artifacts that target the given artifact. The specific relationship type will be populated as an extension attribute.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived)
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.... ]
Brett Meyer closed ARTIF-499.
-----------------------------
Resolution: Won't Fix
For now, passing on this one. Instead of a search filter, it seems more natural to 1.) see all artifacts expanded from an archive artifact and 2.) see expandedFrom on an artifact. This would be in the individual artifact view or new "vertical views"
> Include another filter for Expanded (similar to Derived)
> --------------------------------------------------------
>
> Key: ARTIF-499
> URL: https://issues.jboss.org/browse/ARTIF-499
> Project: Artificer
> Issue Type: Enhancement
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
>
> Reported by David via his 0.5.0.Beta1 testing:
> "S-ramp Artifacts --> include another column called Expanded.
> Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded.
> I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them.
> If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property).
> I will prepare a html mock with my idea..."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (ARTIF-499) Include another filter for Expanded (similar to Derived)
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-499?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-499:
------------------------------
Fix Version/s: (was: 1.0.0.Alpha1)
> Include another filter for Expanded (similar to Derived)
> --------------------------------------------------------
>
> Key: ARTIF-499
> URL: https://issues.jboss.org/browse/ARTIF-499
> Project: Artificer
> Issue Type: Enhancement
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
>
> Reported by David via his 0.5.0.Beta1 testing:
> "S-ramp Artifacts --> include another column called Expanded.
> Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded.
> I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them.
> If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property).
> I will prepare a html mock with my idea..."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (RTGOV-644) Enable MVELExpressionEvaluator to evaluate more complex scripts (with Variables)
by ivan mckinley (JIRA)
ivan mckinley created RTGOV-644:
-----------------------------------
Summary: Enable MVELExpressionEvaluator to evaluate more complex scripts (with Variables)
Key: RTGOV-644
URL: https://issues.jboss.org/browse/RTGOV-644
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Components: Information Processor
Affects Versions: 1.0.0.M1
Reporter: ivan mckinley
Assignee: Gary Brown
if a user wishes to execute more complex mvel scripts with variables during information processing then MVEL fails with exception, {1}.
The following test case,2, demonstrates this behaviour in action.
Recommendation is to update line 44
https://github.com/Governance/rtgov/blob/master/modules/activity-manageme...
Object result=MVEL.executeExpression(_compiledExpression, information, new HashMap());
{1}Exception
activity event: org.mvel2.ScriptRuntimeException: cannot assign variables; no variable resolver factory available.
at org.mvel2.integration.impl.ImmutableDefaultFactory.throwError(ImmutableDefaultFactory.java:32)
at org.mvel2.integration.impl.ImmutableDefaultFactory.createVariable(ImmutableDefaultFactory.java:36)
at org.mvel2.integration.impl.ClassImportResolverFactory.createVariable(ClassImportResolverFactory.java:61)
at org.mvel2.ast.TypedVarNode.getReducedValueAccelerated(TypedVarNode.java:70)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:86)
at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
at org.mvel2.MVEL.executeExpression(MVEL.java:954)
at org.overlord.rtgov.activity.processor.mvel.MVELExpressionEvaluator.evaluate(MVELExpressionEvaluator.java:44)
at org.overlord.rtgov.activity.processor.TypeProcessor$PropertyEvaluator.process(TypeProcessor.java:310)
at org.overlord.rtgov.activity.processor.TypeProcessor.process(TypeProcessor.java:166)
at org.overlord.rtgov.activity.processor.InformationProcessor.process(InformationProcessor.java:137)
at org.overlord.rtgov.activity.processor.AbstractInformationProcessorManager.process(AbstractInformationProcessorManager.ja
{2} Test Case
@Test
public void testTransformDOM2() {
org.w3c.dom.Document doc=null;
try {
doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
org.w3c.dom.Element elem=doc.createElement("test");
doc.appendChild(elem);
elem.appendChild(doc.createTextNode("This is a test"));
} catch (Exception e) {
fail("Failed to build DOM: "+e);
}
String expression = "import javax.xml.transform.TransformerFactory; import javax.xml.transform.Transformer; import javax.xml.transform.dom.DOMSource; import javax.xml.transform.stream.StreamResult; import java.io.ByteArrayOutputStream; ByteArrayOutputStream out = new ByteArrayOutputStream(); DOMSource source = new DOMSource(this); StreamResult result = new StreamResult(out); TransformerFactory transFactory = TransformerFactory.newInstance(); Transformer transformer = transFactory.newTransformer(); transformer.transform(source, result); out.close(); return new String(out.toByteArray());";
Object _compiledExpression=null;
_compiledExpression = MVEL.compileExpression(expression);
Object result=MVEL.executeExpression(_compiledExpression, doc);
if (result == null) {
fail("Failed to parse");
}
System.out.println(result);
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months