June 2015 - overlord-issues - Jboss List Archives

[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

1
0
0 / 0

[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.... ] Work on ARTIF-725 started by Brett Meyer. ----------------------------------------- > 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

1
0
0 / 0

[JBoss JIRA] (ARTIF-726) If an archive is deleted, also delete its expanded artifacts

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-726?page=com.atlassian.jira.plugin.... ] Work on ARTIF-726 started by Brett Meyer. ----------------------------------------- > If an archive is deleted, also delete its expanded artifacts > ------------------------------------------------------------ > > Key: ARTIF-726 > URL: https://issues.jboss.org/browse/ARTIF-726 > Project: Artificer > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 1.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ARTIF-726) If an archive is deleted, also delete its expanded artifacts

by Brett Meyer (JIRA)

Brett Meyer created ARTIF-726: --------------------------------- Summary: If an archive is deleted, also delete its expanded artifacts Key: ARTIF-726 URL: https://issues.jboss.org/browse/ARTIF-726 Project: Artificer Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0.0.Beta2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2015