Uploaded image for project: 'ShrinkWrap'
  1. ShrinkWrap
  2. SHRINKWRAP-404

Expose underlying Asset source in the individual API's

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Major Major
    • 1.1.0-alpha-2
    • None
    • None
    • None

      In some cases it is interesting to get the 'real source' of an Asset beyond the InputStream. Where on disk is the FileAsset read from?

      Both for Tooling integration and e.g. the JRebel Arquillian extension it is needed to know where a source came from to do the linking.

      File FileAsset.getFile
      String ClassLoaderAsset.getResource
      Class<?> ClassAsset.getClass

      etc

            [SHRINKWRAP-404] Expose underlying Asset source in the individual API's

            Andrew Rubinger (Inactive) added a comment -

            Remaining implementations: https://github.com/shrinkwrap/shrinkwrap/commit/90a5bcf0bf1421424ae1d674152fe95780b002a9

            Andrew Rubinger (Inactive) added a comment - Remaining implementations: https://github.com/shrinkwrap/shrinkwrap/commit/90a5bcf0bf1421424ae1d674152fe95780b002a9

            Andrew Rubinger (Inactive) added a comment -

            Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/2189a9715e417b9be3516cdde819e2df14d66bef

            Andrew Rubinger (Inactive) added a comment - Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/2189a9715e417b9be3516cdde819e2df14d66bef

            Andrew Rubinger (Inactive) added a comment -

            I like "getSource()" as a convention; it's more descriptive than ie. "getFile" anyway.

            Andrew Rubinger (Inactive) added a comment - I like "getSource()" as a convention; it's more descriptive than ie. "getFile" anyway.

            Aslak Knutsen added a comment -

            In theory we could have had something like "T Asset<T>.getSource()" but it wouldn't really help, you would still need to do the type checking to figure out T and if T is something you can work with.

            We could standardise on Type getSource, even tho not enforced by the Asset interface.

            File FileAsset.getSource()
String ClassLoaderAsset.getSource()
Class<?> ClassAsset.getSource()

            Aslak Knutsen added a comment - In theory we could have had something like "T Asset<T>.getSource()" but it wouldn't really help, you would still need to do the type checking to figure out T and if T is something you can work with. We could standardise on Type getSource, even tho not enforced by the Asset interface. File FileAsset.getSource() String ClassLoaderAsset.getSource() Class <?> ClassAsset.getSource()

            Andrew Rubinger (Inactive) added a comment -

            Assuming that we don't intend on exposing this in Asset, but rather directly in some Asset impls as indicated, this looks OK to me. The user would have to do type checking and cast to the appropriate Asset subtype to get at the info.

            Andrew Rubinger (Inactive) added a comment - Assuming that we don't intend on exposing this in Asset, but rather directly in some Asset impls as indicated, this looks OK to me. The user would have to do type checking and cast to the appropriate Asset subtype to get at the info.

              rbattenfeld Ralf Battenfeld (Inactive)
              aslak@redhat.com Aslak Knutsen
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: