[ https://issues.apache.org/jira/browse/SLING-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Munteanu updated SLING-3733: ----------------------------------- Fix Version/s: (was: Sling Eclipse IDE 1.2.0) Sling Eclipse IDE 1.2.2 > Remodel API for more natural usage of IO operations > --------------------------------------------------- > > Key: SLING-3733 > URL: https://issues.apache.org/jira/browse/SLING-3733 > Project: Sling > Issue Type: Improvement > Components: IDE > Reporter: Robert Munteanu > Priority: Critical > Fix For: Sling Eclipse IDE 1.2.2 > > > The current approach for working with I/O is a bit convoluted. To make sure > we integrate properly with multiple potential environments - Eclipse, > IntelliJ, Netbeans, CLI - our APIs work mainly with Strings and InputStreams > ( or byte-arrays ). > Although it works fine, it's starting to become awkward, as a single > operation can consist of multiple calls to API methods due to this > back-and-forth. For instance: > {code} > // Sling IDE API > String serializationFilePath = > serializationManager.getSerializationFilePath(resourceLocation, > serializationKind); > // Eclipse API > IPath serializationFilePath2 = > Path.fromPortableString(serializationFilePath); > // Eclipse API > IResource serializationResource = > syncDirectory.findMember(serializationFilePath2); > // a bit later... > // Sling IDE API > serializationManager.readSerializationData(serializationFilePath, > serializationResource.getContents(); > {code} > We should overhaul the I/O-based APIs to work with I/O abstractios ( e.g. > FileReader -> EclipseFileReader ) and make those operations more coherent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)