[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.... ]
Work on ARTIF-499 started by Brett Meyer.
-----------------------------------------
> 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.Beta2
>
>
> 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.15#6346)
9 years, 6 months
[JBoss JIRA] (ARTIF-725) Use new 'expandedFromArchivePath' field, rather than custom property
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-725?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-725:
------------------------------
Description:
Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry.
Add to the web UI's artifact details.
was:Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry.
> Use new 'expandedFromArchivePath' field, rather than custom property
> --------------------------------------------------------------------
>
> Key: ARTIF-725
> URL: https://issues.jboss.org/browse/ARTIF-725
> Project: Artificer
> Issue Type: Enhancement
> Affects Versions: 1.0.0.Beta1
> Reporter: Brett Meyer
> Assignee: Brett Meyer
> Fix For: 1.0.0.Beta2
>
>
> Currently, if an artifact is expanded, it populates a 'expanded.from.archive.path' custom property. Instead, move this to a new field on the Artifact itself. Note that, for now, this will need to be bound to an expansion entry.
> Add to the web UI's artifact details.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (ARTIF-709) Allow artifact expansion to be dynamically configurable during runtime
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-709:
------------------------------
Description:
Expansion is useful and necessary, especially for relationship definitions. However, in some contexts, it can expand too much. Ex: uploading a large WAR, how do we differentiate between 3rd party dependency JARs (probably shouldn't be expanded) and application-provided JARs (should be expanded)?
The answer could be some sort of UI interactivity that allows users to configure the expansion (nested lists with checkboxes?) prior to persisting...
was:
Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out.
Suggestion:
1.) Expansion disabled by default
2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc.
3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact.
> Allow artifact expansion to be dynamically configurable during runtime
> ----------------------------------------------------------------------
>
> Key: ARTIF-709
> URL: https://issues.jboss.org/browse/ARTIF-709
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Expansion is useful and necessary, especially for relationship definitions. However, in some contexts, it can expand too much. Ex: uploading a large WAR, how do we differentiate between 3rd party dependency JARs (probably shouldn't be expanded) and application-provided JARs (should be expanded)?
> The answer could be some sort of UI interactivity that allows users to configure the expansion (nested lists with checkboxes?) prior to persisting...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (ARTIF-709) Allow artifact expansion to be dynamically configurable during runtime
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-709:
------------------------------
Summary: Allow artifact expansion to be dynamically configurable during runtime (was: Allow artifact expansion to be enabled/disabled during each upload)
> Allow artifact expansion to be dynamically configurable during runtime
> ----------------------------------------------------------------------
>
> Key: ARTIF-709
> URL: https://issues.jboss.org/browse/ARTIF-709
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out.
> Suggestion:
> 1.) Expansion disabled by default
> 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc.
> 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (ARTIF-709) Allow artifact expansion to be enabled/disabled during each upload
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-709?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-709:
------------------------------
Fix Version/s: (was: 1.0.0.Beta2)
> Allow artifact expansion to be enabled/disabled during each upload
> ------------------------------------------------------------------
>
> Key: ARTIF-709
> URL: https://issues.jboss.org/browse/ARTIF-709
> Project: Artificer
> Issue Type: Feature Request
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> Expansion is useful in some cases (especially API jars, etc.). However, in others, it's actually pretty harmful. Ex: pushing in a project's ZIP distro, a large WAR with all its dependency JARs, etc. Currently, Artificer would get overwhelmed with the amount of info to pull out.
> Suggestion:
> 1.) Expansion disabled by default
> 2.) Enable with checkbox on web UI, argument on CLI, argument on Java client, etc.
> 3.) If *not* expanded, the relationship builders should still kick in. So, the contents would still be parsed. If it contains, for example, a WSDL that imports an XSD or a Java class that impls an API interface, the relationships should still be created. But those relationships would point to the archive itself, rather than an expanded/derived artifact.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 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 reopened ARTIF-499:
-------------------------------
Taking back what I said. Definitely needed, especially for large archives...
> 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.15#6346)
9 years, 6 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.Beta2
> 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.Beta2
>
>
> 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.15#6346)
9 years, 6 months