Hi Dan,

On Oct 25, 2012, at 4:08 PM, Dan Klco wrote:

> Antonio,
> 
> This is a really promising tool!  I really like the idea of the save hook.  I 
> was wondering how you were planning on doing the initial project population?  
> It would be really cool to have an import option where it would import the 
> files out of Sling through the regular project import process.   I would 
> maybe even think about extending the plugin to allow direct import/export 
> through the Eclipse project Import/Export dialog.

this sounds really good and technically would also be enough simple already 
with the current code base (at least the import operation, namely from file 
system to repository).


>  I could see usages where you'd update files directly in the Repository and 
> want to pull them into your workspace or where you may want to push files to 
> a remote repository.

For the export operation (namely from the repository to the file system) I do 
generally support the idea as long as this sync is on-demand and not an 
auto-sync (namely at every change in the repository) .
The reason is that I like to "drive" everything from my IDE without having "bad 
surprise"....

> 
> Also, have you thought about what would happen if the user attempted to save 
> a file while the Sling repo they were connected to was unavailable?  It seems 
> like you'd really want to have an option to synch changes.  This would also 
> come in handy when pulling changes from SCM.

I am afraid I did not entirely catch your idea here while I do understand the 
problem,....

> 
> Regarding property/content storage, I would think it would be best to choose 
> a schema which would allow you to both interact directly with the Sling Repo 
> through the plugin, but also allow for creating a code package which could be 
> deployed into the repository.  

+1 and I think this is where Stefan has some idea...

> 
> Finally, on a technical note, I'd suggest leveraging Sonatype's Tycho tool, 
> for creating the plugin through Maven.  I've built a plugin directly through 
> Eclipse's PDE and it feels really clunky compared to Maven builds.
> http://www.sonatype.org/tycho


Thanks for your hint it sounds a great suggestion.

> 
> I'd be happy to help with this.

Any contributions is more than welcome!!

Regards

Antonio


> 
> -Dan
> 
> -----Original Message-----
> From: Antonio Sanso [mailto:[email protected]] 
> Sent: Thursday, October 25, 2012 9:27 AM
> To: [email protected]
> Subject: Re: [Tooling] Experimental Plugin for Eclipse for Sling aka 
> Slingclipse
> 
> Hi Stefan,
> 
> On Oct 25, 2012, at 2:54 PM, Stefan Seifert wrote:
> 
>> hello antonio.
>> 
>> this sounds interesting!
>> 
>> what is the difference to the filesystem resource provider with which you 
>> can mount any folder in the filesystem to a JCR tree?
> 
> at least for the current implementation (the http one) there is yet another 
> level of abstraction since it mainly use the API of the SlingPostServlet.
> 
> 
>> the filesystem resource provider currently only supports nt:file and 
>> nt:folder nodes, but works very well for those (e.g. jsp, css, javascript 
>> files).
>> 
>> if i find some time i planned to improve the filesystem resource provider to 
>> support other JCR content structures stored in JSON files in the file system 
>> as well.
> 
> the plan is to have something similar for Slingclipse about the JCR content 
> structures stored in JSON so I would be really interested to brainstorm about 
> it (and maybe having this functionality in a common bundle?).
> 
> Regards
> 
> Antonio
> 
> 
>> this would be independent from any IDE and its plugin system.
>> 
>> stefan
>> 
>>> -----Original Message-----
>>> From: Antonio Sanso [mailto:[email protected]]
>>> Sent: Thursday, October 25, 2012 2:34 PM
>>> To: [email protected]
>>> Subject: [Tooling] Experimental Plugin for Eclipse for Sling aka 
>>> Slingclipse
>>> 
>>> Hi *,
>>> 
>>> I have started to work on an experimental plugin for Eclipse for 
>>> Sling named (at least for now :)) Slingclipse, see [0].
>>> 
>>> Slingclipse is an attempt to make easier the development phase while 
>>> using Sling.
>>> The scope is still open and I would be more than glad to hear some 
>>> feedbacks/ideas.
>>> 
>>> What I have committed for now are 3 plugins/bundles:
>>> 
>>> - org.apache.sling.slingclipse
>>> - org.apache.sling.slingclipse.api
>>> - org.apache.sling.slingclipse.http
>>> 
>>> The idea implemented for now is that at any save (this is 
>>> configurable) the correspondent "action" will be "transmitted" in the 
>>> repository (only if if this is in a project with a path name for the 
>>> file that contains jcr_root to be precise).
>>> The "actions" implemented for now are:
>>> 
>>> - create a  new file: the file is created also in the repository (if 
>>> the file is not empty, is a bug)
>>> - change the content of a file: the file is modified in the 
>>> repository
>>> - delete a file: the file is deleted in the repository
>>> 
>>> The trigger is the save action in Eclipse.
>>> At the moment there is not support for any jcr type other than 
>>> nt:file (but this is going to improve).
>>> Another important thing  to highlight for the moment is the way this 
>>> information is "transmitted" from the file system to the repository.
>>> Slingclipse uses Declarative Service and the implemented solution 
>>> uses HTTP for now (org.apache.sling.slingclipse.http bundle).
>>> Should somebody else would like to use some other way to achieve the 
>>> same result is enough to create another bundle implementing the api 
>>> contained in the  org.apache.sling.slingclipse.api bundle,
>>> 
>>> I would try to create some basic documentation somewhere in the wiki 
>>> soon
>>> 
>>> Regards
>>> 
>>> Antonio
>>> 
>>> [0] 
>>> http://svn.apache.org/viewvc/sling/whiteboard/asanso/plugins/eclipse/
>> 
> 
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2741 / Virus Database: 2616/5847 - Release Date: 10/22/12
> 

Reply via email to