Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056898 - S-RAMP UI should recognize KieJarArchive automatically
Summary: S-RAMP UI should recognize KieJarArchive automatically
Keywords:
Status: NEW
Alias: None
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: DT Governance
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: FUTURE
Assignee: Thomas Heute
QA Contact: Matej Melko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-23 06:38 UTC by Jiri Pechanec
Modified: 2018-03-29 21:55 UTC (History)
4 users (show)

Doc Type: Bug Fix
Doc Text:
The KieJarArchive is not automatically recognised in the DTGov or S-RAMP interfaces. The KieExpander recognises it as JarArchive instead of KieJarArchive. This can be worked around by explicitly setting the type to KieJarArchive when you open the archive. As a result, the default "Document" type will be overridden and the archive will appear.
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker ARTIF-531 Major Closed Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side 2015-04-20 20:02:57 UTC
JBoss Issue Tracker ARTIF-580 Major Closed Server-side autodetection of artifact types 2015-04-20 20:02:56 UTC

Description Jiri Pechanec 2014-01-23 06:38:33 UTC
See bz1015251 - when deploying KIE archive from s-ramp-ui then the autodiscovery (best guess) process it as JarArchive. It should be recognized (by presence of kmodule.xml?) as KieJarArchive automatically without the need to set explicity type.

Comment 2 Kurt T Stam 2014-01-23 13:31:52 UTC
Hi Eric, I guess this feature request then goes for both dtgov-ui as well as s-ramp-ui.

Comment 4 Jiri Pechanec 2014-01-24 12:25:46 UTC
The same problem applies to VDB artifacts - see 1022586

Comment 5 Eric Wittmann 2014-08-18 17:33:34 UTC
I have switched this BZ up to be specific to S-RAMP as the original comment indicates the S-RAMP UI was used.

If the dtgov UI's "add deployment" feature should *also* be switched up to use auto-discovery, please open a separate feature-request BZ.  Currently the DTGov UI doesn't use auto-discovery at all - it forces the user to choose a deployment type (from a list of configured types).  Perhaps it should use auto-discovery as an option.

Comment 7 Brett Meyer 2015-02-03 02:16:12 UTC
Auto-detection of artifact types, based on contextual clues (such as the suggested kmodule.xml existence) was added under https://issues.jboss.org/browse/ARTIF-580 and https://issues.jboss.org/browse/ARTIF-531.  Theoretically, these *could* apply fairly cleanly to FSW, however:

The work is *not* backward compatible with custom implementations of the old org/overlord/sramp/atom/archive/expand contracts (ZipToSrampArchive, etc.).  It's highly unlikely that these were actually extended in the wild, but it's something to be aware of.

Without this, each client (especially the UI) having to inspect and attempt to auto-detect types is a bit of a nightmare.  Unless the removal of the above contracts is not an issue, I'd recommend rejecting this.

Full changes: https://github.com/ArtificerRepo/artificer/pull/511 (sorry, it's huge...)


Note You need to log in before you can comment on or make changes to this bug.