To sum up this long discussion thread
1. I've updated the two wiki pages( [1],[2] ) to contain the topics
we've discussed here. I see Dan has been doing the same, so thanks for
that. Any omissions are accidental, please update the pages if I missed
something.
2. We don't have a definite answer
On Fri, May 31, 2013 at 2:08 PM, Robert Munteanu romb...@apache.org wrote:
...I'm frankly more of an IDE guy than a VLT guy from a development
experience point of view
IMO focusing on filesystem operations (which can be driven by IDEs)
would be the right abstraction level, so that people
Including Toby, who is planning to contribute vault to Apache Jackrabbit.
I think the plan was to simplify vault CLI sync along the way, and only allow
full pushs in either direction, instead of having commit update work on
individual files. This would mean some operation like get all changes
I have found Sling - FS auto syncing useful for several reasons.
1. The IDE lets me know if files in the repo are being changed, with the
message, 'do you want to reload this file.'
2. When I do a svn status, or git status I know I am looking at an exact
copy of what I just tested.
3.
On Sun, 2013-06-02 at 10:53 -0700, Ruben Reusser wrote:
I was trying to dumb down the example with 'content', however, in the CQ
world there are a couple of areas where the tool comes with an editor
for certain functionalities, for example workflows. While I can manage
them in XML, it would
When skipping Javacode and Bundles (which I'm not so happy with) one option
would also be to have something like a ResourceProvider that for dev time
redirects and takes data from the FS. As long as we have the mentioned same
machine scenario the synchronisation is IMHO not necessary, better have
Hi Robert,
regarding your sample - this kind of annotation does work for sure, what I
was talking about is the finegrained control over serialisation and
breakpoints (when to build a complete serialized file and where to split up
in subfolder and subsequent metafiles) - I'm sure someone can come
On Mon, 2013-06-03 at 14:25 +0200, Dominik Süß wrote:
Hi Robert,
regarding your sample - this kind of annotation does work for sure, what I
was talking about is the finegrained control over serialisation and
breakpoints (when to build a complete serialized file and where to split up
in
On Mon, 2013-06-03 at 14:21 +0200, Dominik Süß wrote:
When skipping Javacode and Bundles (which I'm not so happy with) one option
would also be to have something like a ResourceProvider that for dev time
redirects and takes data from the FS. As long as we have the mentioned same
machine
I think usercontroll is here the essential point. Serialization FS - Sling
does not have this problem since it completely unfolds the structure.
Looking at CQ as sample does come up with some usecases where you want to
handle complete structures in one file for a proper overview like the
dialog
On Mon, Jun 3, 2013 at 2:34 PM, Robert Munteanu romb...@apache.org wrote:
...I'm not sure how we would achieve a fine control over
serialisation. Is think something you would see as user-controllable?...
Maybe just a someNamespace:deepSerialize resource property would be sufficient?
If it's
Afaik, Felix can already load exploaded bundles - and I guess this
integration into Eclipse shouldn't be too hard.
Maybe my previous wording was not good, I think this is an important area
where we're currently lacking tooling, however I wouldn't see this as
Sling's primary goal to provide tools
One point about taking those into account is to get a full Resourcetree
view. Even if development and synching between FS and Sling is just enabled
on the repository layer (and propably mounted bundles) It think it would be
really important to have at least optionally a complete view of the
definition level and
persist across repositories instead of being saved within the IDE.
-Dan
-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
Sent: Monday, June 03, 2013 8:42 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling
On Mon
.
-Dan
-Original Message-
From: Robert Munteanu [mailto:romb...@apache.org]
Sent: Monday, June 03, 2013 8:18 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling
I have found Sling - FS auto syncing useful for several reasons.
1. The IDE lets me know
I think a sync in both directions is problematic and I wouldn't go there -
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code including scripts and usually Java - this might also include
coding in client side
Hi Carsten,
On 2 June 2013 18:41, Carsten Ziegeler cziege...@apache.org wrote:
I think a sync in both directions is problematic and I wouldn't go there -
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code
On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
I think a sync in both directions is problematic and I wouldn't go there -
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code including scripts and
I'm trying to summarize my thoughts including the several opinions
scenarios stated:
a) The main usecase seems to be development from IDE (persisted to FS and
therefore to be integreated with any FS based versioning tool of choice)
b) a (on save) sync the application from FS to Sling via IDE
I was trying to dumb down the example with 'content', however, in the CQ
world there are a couple of areas where the tool comes with an editor
for certain functionalities, for example workflows. While I can manage
them in XML, it would be much nicer to manage them in CQ (or in the IDE,
maybe
Hi Ian,
2013/6/2 Ian Boston i...@tfd.co.uk
If by true dev you mean IDE only, then I will find that too restrictive,
others may too. I use whatever is most efficient to get the job done,
sometimes thats the IDE (refactoring), sometimes its the command line
(branch management, full scale
For c) java code and bundles, I would suggest to leave this out for now and
see if we can integrate other tooling for that work. I'm currently
exploring options and maybe we can leverage other peoples work for that
Carsten
2013/6/2 Dominik Süß dominik.su...@gmail.com
I'm trying to summarize
Hi *,
just my cents.
First of all I am really happy to see this moving forward (thanks Robert for
bring this up).
About the usage of VLT I am not against it but I do not see any problem on
having a further level of abstraction between the tooling and
the transport layer (e.g. VLT)
Regards
Hi Justin,
(and this will address Ian's comments as well )
On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson wrote:
Hi,
I would strongly suggest that this effort be based on VLT. As mentioned on
the wiki page, we're in the process of moving that to ASF and I think once
the code is available,
On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote:
is the vlt sync now actually updating .content.xml files? I thought it
can only sync regular files.
I'm frankly more of an IDE guy than a VLT guy from a development
experience point of view.
However, I think that the IDE is the right
Here my 2 cents about Sling Tooling vault,
IMHO vault is pure JCR Tooling. And even if some people do not like the
fact, but the resourcetree is different from the jcr tree. So in
consequence this additional abstraction of the Resource API is there (even
without additional resource resolvers,
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling
@Justin, will do.
@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
internals).
On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote:
is the vlt sync now actually
, but is this something that might
be worth looking into as well?
-Dan
-Original Message-
From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian
Boston
Sent: Friday, May 31, 2013 12:07 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward
Some time ago I thought about this and had the following idea:
- we define a packaging for resources - this can be used to represent the
resources in the file system or in a zip file
- if a resource is a file, it is represented as a file with the same name
- if a resource is not a file, it is
-Original Message-
From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of
Ian
Boston
Sent: Friday, May 31, 2013 12:07 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling
@Justin, will do.
@Ruben, it doesnt :(, but IMHO
One comment about content.xml - in our CQ solutions we do use the
Sling-Initialcontent (with the much nicer json files placed parallel to
the folders with the same name instead of .content.xml underneath) instead
of packing it directly in the vault based packages. This leads to a clean
and much
On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote:
Some time ago I thought about this and had the following idea:
- we define a packaging for resources - this can be used to represent the
resources in the file system or in a zip file
- if a resource is a file, it is represented as a
I think the use case of doing maven/jenkins builds and continuous
integrations should also be considered here. Most CQ projects at this
time seem to be using maven builds that create packages that can be
deployed to CQ. Since VLT is open sourced and since the packaging part
is also in VLT I'd
One problematic part about serialisation is structuredepth. In development
you might not want to handle complex structures by shifting folders around,
so it would be nice to have a format that allows to define a substructure,
so in the Sling Initialcontent you might even define one big JSON that
That's why I think a resource packaging format is the way to go:
a) it makes syncing easy during development
b) it can directly be packaged together to create a package, so maven/ci
builds simply work
c) installation of those packages is easy as well
I think it's important to note that this is
Hi,
These are all excellent points.
I am a bit confused about mentions of the Sling Resource API. This is a
server-side API while we are discussing client code. AFAIK we don't have a
client implementation of the Resource API nor do we have a standard
transport mechanism. We do have the default
I personally think creating a new thing from scratch is easier, sure there
might a little bit of work - but on the other hand it comes with a lot of
benefits.
However, whoever does the work can decide - and why not having more than
one prototype and then see whats the better way?
Or in other
Before you read this, please a) excuse my ignorance of Sling build tools,
I'm just getting started with pure Sling and b) feel free to inform my of
said ignorance :D
I use Maven and Jenkins to do automated builds of our CQ project at work.
For development we use a combination of maven and vault
On Fri, 2013-05-31 at 10:40 -0400, Justin Edelson wrote:
Hi,
These are all excellent points.
I am a bit confused about mentions of the Sling Resource API. This is a
server-side API while we are discussing client code. AFAIK we don't have a
client implementation of the Resource API nor do we
Hi Adam,
On Fri, 2013-05-31 at 10:58 -0400, Adam Yocum wrote:
It would be nice to have vault working with Sling, it has a lot of
functionality including
copying content between two separate servers (vault rcp) and an already
complete eclipse plugin 'vaultclipse'
Once open-sourced, you will
Hi,
I've added the requirements for autosync to [1]. Although VLT does a good
job of this once setup I don't use CLI for editing and manipulating. I use
the IDE 100% with all its other tooling and just File Save.
Setup with VLT is 2 commands and a 1 line config file edit, which could
easily be
Hi,
I would strongly suggest that this effort be based on VLT. As mentioned on
the wiki page, we're in the process of moving that to ASF and I think once
the code is available, it will be clear that it provides a good low-level
interface for this type of UI.
While it is true that VLT currently
Hi,
+1 to that. After working on sling for many years doing a mixture of bundle
and UI work, mainly using the FileSystemResolver bundle, I realise now if
VLT had been available with sync mode (ie auto syncing the repo and the
file system), we (the team I was working with at the time) would have
Ian - please do add the autosync use case to the wiki page I created.
On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
+1 to that. After working on sling for many years doing a mixture of bundle
and UI work, mainly using the FileSystemResolver bundle, I realise now if
is the vlt sync now actually updating .content.xml files? I thought it
can only sync regular files.
Ruben
On 5/30/2013 7:24 PM, Justin Edelson wrote:
Ian - please do add the autosync use case to the wiki page I created.
On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote:
Hi,
@Justin, will do.
@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
internals).
On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote:
is the vlt sync now actually updating .content.xml files? I thought it can
only sync regular files.
Ruben
On 5/30/2013 7:24
with a UI yet, but is this something that might be worth
looking into as well?
-Dan
-Original Message-
From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston
Sent: Friday, May 31, 2013 12:07 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE
: Friday, May 31, 2013 12:07 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling
@Justin, will do.
@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
internals).
On 31 May 2013 13:48, Ruben Reusser r...@headwire.com wrote:
is the vlt sync
48 matches
Mail list logo
