[JBoss JIRA] (ARTIF-554) Improve the UI search capabilities and query syntax support
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-554?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-554:
------------------------------
Fix Version/s: 1.0.0.Alpha1
> Improve the UI search capabilities and query syntax support
> -----------------------------------------------------------
>
> Key: ARTIF-554
> URL: https://issues.jboss.org/browse/ARTIF-554
> Project: Artificer
> Issue Type: Enhancement
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Priority: Critical
> Fix For: 1.0.0.Alpha1
>
>
> Ideas:
> - Completely replace the top "Search" bar with a field explicitly for S-RAMP queries.
> - When left sidebar search is used, automatically add the equivalent query in the new bar.
> - Include a link to the S-RAMP query docs.
> - Add "name" and "uuid" fields to the search sidebar.
> - Also on the sidebar, differentiate between search fields that are encompassed by the query language and ones that extend it (literally use a linebreak, etc.).
> This would gain us both more powerful search capabilities, as well as "teaching" users the query language as they go.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARTIF-509) Unify s-ramp maven code
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-509?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-509:
------------------------------
Fix Version/s: 1.0.0.Alpha1
> Unify s-ramp maven code
> -----------------------
>
> Key: ARTIF-509
> URL: https://issues.jboss.org/browse/ARTIF-509
> Project: Artificer
> Issue Type: Enhancement
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
> Fix For: 1.0.0.Alpha1
>
>
> Both the S-ramp Wagon, Maven Repository Servlet Facade and Deploy Command (shell) uses the s-ramp client to store maven artifacts in the system.
> They make more or less the same, use the same methods to find existing artifacts and to save the artifact. Also all of them have methods that parse the input string that contains the gav, and store this info in different mojos.
> This means there is lot of common duplicate code. The idea is to create in s-ramp common project a new package maven and there include only one MavenMetadata class, and include one Factory class that transform from Metadata to BaseArtifactType.
> Also it is required a MavenUtil class where will be included the common operations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 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: 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
> Fix For: 1.0.0.Alpha1
>
>
> 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, 11 months
[JBoss JIRA] (ARTIF-202) The not() function doesn't quite work with relationships
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-202?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-202:
------------------------------
Fix Version/s: 1.0.0.Alpha1
> The not() function doesn't quite work with relationships
> --------------------------------------------------------
>
> Key: ARTIF-202
> URL: https://issues.jboss.org/browse/ARTIF-202
> Project: Artificer
> Issue Type: Bug
> Reporter: Eric Wittmann
> Assignee: Brett Meyer
> Priority: Minor
> Fix For: 1.0.0.Alpha1
>
>
> The not() function works well with properties, but not quite with relationships. An example of what doesn't work:
> /s-ramp/wsdl/Part[not(element)]
> That should return all Parts that do *not* have an element relationship. Since relationships are found by doing a JOIN, it's actually tricky to invert. Right now I think the query engine will produce something that would return all Parts that have some *other* relationship - but it won't return Parts without any relationships at all. I'm not sure how to do the latter other than by using an IN with a subquery (which is supported by ModeShape but is non-standard).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months