Re: Disabling flaky tests

[Carsten Ziegeler]

I agree as well, especially for the error handling as this is partially not
a problem of the test but really a bug in Sling - we have an issue for
that, it just needs to be done :)

Carsten


2013/6/3 Felix Meschberger 

> I agree here: Disabling the test and having an issue keeps the build green
> but bears the danger of forgetting about it ...
>
> Regards
> Felix
>
> Am 02.06.2013 um 16:04 schrieb Eric Norman:
>
> > Personally, I'm not a big fan of hiding flaky/failing tests since it
> tends
> > to remove some of the motivation to stabilize/fix them in a timely
> manner.
> >
> > That's my 2 cents.
> >
> > Regards,
> > Eric
> >
> > On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu  >wrote:
> >
> >> Hi,
> >>
> >> It seems that the ErrorHandlingTest fails sporadically when run inside a
> >> full maven build. I've tried locating the root cause for a couple of
> >> hours but failed. For this test, and for future flaky/failing tests, I
> >> suggest that we
> >>
> >> 1. Create an issue for the failing test
> >> 2. Disable the test and mark it with the issue key
> >> 3. Re-enable the test when it is stable/passing ( which may be
> >> considerably later than step 2)
> >> 4. Close the issue after the test is re-enabled
> >>
> >> This has the advantage of keeping the build green and making it easier
> >> to find regressions since a failing or unstable build will actually mean
> >> something.
> >>
> >> What do you think?
> >>
> >> Robert
> >>
> >>
>
>


-- 
Carsten Ziegeler
cziege...@apache.org

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler]

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üß 

> 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 seems what
> everybody needs and agrees on
> c) Not directly mentioned but what I think should be defined as well how
> and when bundlebased (JAVA) code gets synced to the repository
> d) where I didn't hear consensus is about syncing from Sling to FS. The
> reason why I have my problem with that,  is that autosync needs an explicit
> definition how structures get mapped. In direction repository this is easy
> since this unwraps the filebased (xml or json) wrappers and creates a lot
> of finegrained strucures, but the other way around there would be the need
> of an implicit way how those structures get serialized to the FS or some
> (potentially) complex definition that a dev would have to make (possible
> with vault afaik, but IMHO errorprone).
> e) one of the main reasons for d is to see changes from the repository
> within the IDE. I here fully second Carsten that this shouldn't be
> automagically resolved but be controlled from the dev.  The IDE here can
> create some tooling to identify and display changes and support the job to
> reestablish synchronity (this might be the hardest part for the tooling
> since I  havent seen a proper ui doing such a job).
> f) regarding "sample" content mentioned by Ruben I think some
> packagingmechanism and a maven task to upload/download this package should
> besufficient (lock package, upload, change content in repo, download
> package, check in vcs)
>
> Cheers
> Dominik
>
>
> On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser  wrote:
>
> > we frequently have a content project during development with a sample
> site
> > that can be deployed over maven to a local dev instance. Maintaining the
> > sample content in the project requires to author in the cms and then sync
> > back to file system. Making bulk changes to the structure (for example,
> > globally rename a sling:resourceSuperType) is easier done in the IDE.
> > Content is then pushed back into the repository. I am not saying a
> constant
> > sync is needed, but a way for the IDE to 'update from repository' would
> > really help.
> >
> > The vlt sync command has another issue. Since it stores its state in the
> > local file system but relies on the server to manage the files your
> server
> > instance and file system can get out of sync (say your server crashes and
> > you have to reinstall it). Switching instances (say current version vs
> new
> > version) for testing purposes (is everything still working fine) is not
> > well supported either.
> >
> > Ruben
> >
> >
> > On 6/2/2013 6:35 AM, Antonio Sanso wrote:
> >
> >> 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 usually Java - this might also
> >>> include
> >>> coding in client side stuff like js and css. There is the central tool
> >>> you
> >>> use for developing and that's the IDE with a strong integration into
> the
> >>> SCM (svn, git etc). The dev never has to leave this IDE for anything.
> In
> >>> this scenario, there is only a sync from IDE to Sling required - but
> not
> >>> the other way round.
> >>>
> >> +1
> >>
> >>  Whenever that's needed (syncing data from Sling into the file system)
> >>> this
> >>> should imho be an explicit decision by the dev - simply by invoking an
> >>> action from the IDE.
> >>>
> >> +1
> >>
> >> Regards
> >>
> >> Antonio
> >>
> >>
> >>  An automatic sync in both directions is dangerous and
> >>> imho in most cases not wanted/desired/required.
> >>>
> >>> As soon as we're talking about automatic sync from Sling to the project
> >>> checkout, this has a different style of development in mind - which I
> >>> think
> >>> we should not support when talking about IDE support. Either we support
> >>> IDE
> >>> development and then we do it right and have a style of working that
> does
> >>> not require to leave the IDE - or we do something different, but then
> >>> let's
> >>> make it clear that we don't plan to provide a true dev experience.
> >>>
> >>>
> >>> Carsten
> >>>
> >>>
> >>> 2013/6/1 Ian Boston 
> >>>
> >>>  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 ID

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler]

Hi Ian,

2013/6/2 Ian Boston 

>
>
> 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 rebuilds). To say to use Sling tooling you
> can only use the IDE will be too restrictive.
>
> right, I totally agree. And usually I use the most efficient tool
available for the job as well - however, I believe that most jobs where
today I have to leave the IDE can be done as efficient (and even more
efficient) through the IDE with the right tooling.


> However the question you raise is not should developers be allowed to use
> command line, its should changes in a Sling repo be automatically reflected
> on the filesystem ? (I agree auto syncing between Sling and the internal
> IDE state without reference to the file system is not useful).
>
> Yepp.


> 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. Because of 1 and 2 I can be certain that what I am editing is what I am
> testing and the repo:
> a) Hasn't mysteriously branched.
> b) Hasn't overwritten the change I just made with one of its own. (try one
> way sync to experience this, its very frustrating until you work out whats
> happening)
> 4. I can load things into the repo and have them appear in the IDE.
>
> But I dont want to steer this thread if the intention was for tooling that
> would only work if everything is done in the IDE.
>
> I think you're bringing up very good points - and I totally agree to
address them in one way or the other. But :) we should really think before
we implement the "we need everything in all possible combinations" solution
(I'm exaggerating here of course to make a point).
For example in the above scenario, it's pretty easy to accidentally change
content in the repo which then overwrites your project checkout without
noticing it, especially if you haven't opened your IDE in that time. Which
in turn would require to check all changes in your project checkout before
committing it back. Doable, but I've seen many problems in this area where
people blindly commit their project changes without thinking about why they
are in their project. Sure, we can't prevent every potential human error -
but I would like to define a workflow which covers mostly everything from
working within the IDE. This would also be inline with efforts in the OSGi
world where you would be able to do everything within your IDE.
And of course, things like Maven would still be used for automated building
etc.

Carsten



-- 
Carsten Ziegeler
cziege...@apache.org

[jira] [Commented] (SLING-2897) [LOG] Enhance web console plugin with edit feature

[Felix Meschberger (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672716#comment-13672716
 ] 

Felix Meschberger commented on SLING-2897:
--

Thank you very much for the patch.

While I appreciate the goal of inline editing, I am a bit concerned about the 
implementation:

(a) The LogConfigManager now has a ConfigurationAdmin service dependency; which 
sounds like missing separation of concern. At the very least the service 
reference should be retrieved with the class name as a string (otherwise the 
logging will only be available when the Configuration Admin API is available). 
Plus reading and writing the configuration should be moved to the SlingLogPanel 
(the actual Web Console Plugin) class. The LogConfigManager should really only 
consume configuration and not be a management agent.

(b) Having the login form defined, we basically have two locations where we map 
the configuration properties to fields/values: The MetaType definintion class 
used by the Web Console's Configuration Panel (and other MetaType Service 
consumers) and the new form definition in the SlingLogPanel. I am a bit 
concerned, that these two locations may become disconnected leading to all 
sorts of problems.

While the first problem can be solved I am not sure about the second one.

> [LOG] Enhance web console plugin with edit feature
> --
>
> Key: SLING-2897
> URL: https://issues.apache.org/jira/browse/SLING-2897
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Log 3.0.0
>Reporter: Bjoern Weide
>Priority: Minor
> Attachments: org.apache.sling.commons.log.patch
>
>
> The current web console plugin only lists the configured loggers but links 
> for the actual configuration to the OSGi Configuration Manager. 
> It should be improved so the logging configuration can be edited in the web 
> console plugin directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failed in Jenkins: sling-trunk-1.7 #53

[Apache Jenkins Server]

See 

Changes:

[enorman] SLING-2898 fixed failed integration tests for the new Resource Access 
Tags

--
[...truncated 21067 lines...]
[INFO] Apache Sling JCR Resource Resolver  SUCCESS [1:12.396s]
[INFO] Apache Sling JCR Repository Registration .. SUCCESS [5.890s]
[INFO] Apache Sling Simple WebDAV Access to repositories . SUCCESS [3.571s]
[INFO] Apache Sling DavEx Access to repositories . SUCCESS [4.053s]
[INFO] Apache Sling JCR WebConsole Bundle  SUCCESS [2.948s]
[INFO] Apache Sling Servlet Resolver . SUCCESS [4.635s]
[INFO] Apache Sling Default GET Servlets . SUCCESS [6.358s]
[INFO] Apache Sling Default POST Servlets  SUCCESS [5.204s]
[INFO] Apache Sling Compat Servlets .. SUCCESS [2.883s]
[INFO] Apache Sling Scripting Implementation API . SUCCESS [4.798s]
[INFO] Apache Sling Scripting Core implementation  SUCCESS [5.263s]
[INFO] Apache Sling Scripting JavaScript Support . SUCCESS [21.300s]
[INFO] Apache Sling Scripting JSP Support  SUCCESS [6.754s]
[INFO] Apache Sling JSP Tag Library .. SUCCESS [4.185s]
[INFO] Apache Sling JSP Standard Tag Library . SUCCESS [2.916s]
[INFO] Apache Sling Adapter Manager Implementation ... SUCCESS [3.617s]
[INFO] Apache Sling Bundle Resource Provider . SUCCESS [2.651s]
[INFO] Apache Sling Discovery API  SUCCESS [2.792s]
[INFO] Apache Sling Resource-Based Discovery Service . SUCCESS [59.934s]
[INFO] Apache Sling Discovery Support Bundle . SUCCESS [4.606s]
[INFO] Apache Sling Discovery Standalone Implementation .. SUCCESS [4.659s]
[INFO] Apache Sling Event Support  SUCCESS [7:03.765s]
[INFO] Apache Sling Filesystem Resource Provider . SUCCESS [3.131s]
[INFO] Apache Sling javax.activation bundle .. SUCCESS [2.796s]
[INFO] Apache Sling Settings . SUCCESS [3.366s]
[INFO] Apache Sling Thread Dumper  SUCCESS [2.749s]
[INFO] Apache Sling Web Console Branding . SUCCESS [2.648s]
[INFO] Apache Sling Web Console Security Provider  SUCCESS [2.836s]
[INFO] Apache Sling Groovy Extensions  SUCCESS [3.345s]
[INFO] Apache Sling Explorer . SUCCESS [4.034s]
[INFO] Apache Sling Test Tools ... SUCCESS [5.529s]
[INFO] Apache Sling JUnit Core ... SUCCESS [4.094s]
[INFO] Apache Sling JUnit Scriptable Tests Provider .. SUCCESS [3.779s]
[INFO] Apache Sling JUnit Remote Tests Runners ... SUCCESS [3.928s]
[INFO] Apache Sling Testing Resource Resolver Mock ... SUCCESS [3.037s]
[INFO] Apache Sling Installer API  SUCCESS [3.668s]
[INFO] Apache Sling Installer  SUCCESS [4.705s]
[INFO] Apache Sling Installer WebConsole Plugin .. SUCCESS [2.992s]
[INFO] Apache Sling File Installer ... SUCCESS [2.886s]
[INFO] Apache Sling JCR Installer  FAILURE [2:10.408s]
[INFO] Apache Sling Installer Configuration Admin Support  SKIPPED
[INFO] Apache Sling Deployment Package Installer . SKIPPED
[INFO] Apache Sling Installer Integration Tests .. SKIPPED
[INFO] Apache Sling Launchpad API  SKIPPED
[INFO] Apache Sling Launchpad Base ... SKIPPED
[INFO] Apache Sling Launchpad Installer .. SKIPPED
[INFO] Apache Sling Launchpad Content  SKIPPED
[INFO] Apache Sling Launchpad Application Builder  SKIPPED
[INFO] Apache Sling Sample Server-Side Tests . SKIPPED
[INFO] Apache Sling Failing Server-Side Tests  SKIPPED
[INFO] Apache Sling Sample Integration Tests . SKIPPED
[INFO] Apache Sling Launchpad Testing Services ... SKIPPED
[INFO] Apache Sling Launchpad Testing Services WAR ... SKIPPED
[INFO] Apache Sling Launchpad Testing Fragment Bundle  SKIPPED
[INFO] Apache Sling Launchpad Test Bundles ... SKIPPED
[INFO] Apache Sling Integration Tests  SKIPPED
[INFO] Apache Sling Launchpad Testing  SKIPPED
[INFO] Apache Sling Launchpad Testing WAR version  SKIPPED
[INFO] Apache Sling (Builder)  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 18:53.137s
[INFO] Finished at: Sun Jun 02 23:11:31 UTC 2013
[INFO] Final Memory: 156M/379M
[INFO] 
[JENKINS] Archiving disabled
[JENKINS] Archiving disabled
[JENKINS] Ar

Build failed in Jenkins: sling-trunk-1.7 » Apache Sling JCR Installer #53

[Apache Jenkins Server]

See 


--
[...truncated 473 lines...]
23:10:44.426 INFO  [main] TransientRepository.java:423  Session closed
23:10:44.428 INFO  [main] TransientRepository.java:384  Session opened
23:10:44.431 INFO  [main] JcrInstaller.java:319 Activating Apache 
Sling JCR Installer
23:10:44.433 INFO  [JcrInstaller.16] JcrInstaller.java:218  Background thread 
JcrInstaller.16 starting
23:10:44.435 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:44.435 INFO  [JcrInstaller.16] RootFolderListener.java:49 Watching /apps 
to detect potential changes in subfolders
23:10:44.436 INFO  [JcrInstaller.16] RootFolderListener.java:49 Watching /libs 
to detect potential changes in subfolders
23:10:44.437 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:44.437 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:44.438 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:44.439 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:44.440 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/libs not found, ignored
23:10:44.440 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:45.472 INFO  [ObservationManager] JcrInstaller.java:563 Got event for 
root /libs, scheduling scanning of new folders
23:10:46.442 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:46.442 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:46.443 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:46.444 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:46.444 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:46.445 INFO  [JcrInstaller.16] WatchedFolder.java:92  Watching folder 
/libs/foo/install (priority 100)
23:10:46.946 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:46.947 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:46.947 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:46.948 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:46.949 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:47.950 INFO  [JcrInstaller.16] JcrInstaller.java:611  Registering 
resource with OSGi installer: [InstallableResource, priority=100, 
id=/libs/foo/install/somefile.jar]
23:10:47.952 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:47.952 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:47.953 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:47.954 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:47.955 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:50.457 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:50.457 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:50.458 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:50.459 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:50.460 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:50.460 INFO  [JcrInstaller.16] JcrInstaller.java:550  Deleting 
WatchedFolder:/libs/foo/install, path does not exist anymore
23:10:50.460 INFO  [JcrInstaller.16] JcrInstaller.java:635  Removing resource 
from OSGi installer (folder deleted): [/libs/foo/install/somefile.jar]
23:10:53.951 INFO  [ObservationManager] JcrInstaller.java:563 Got event for 
root /libs, scheduling scanning of new folders
23:10:54.462 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:54.463 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/apps not found, ignored
23:10:54.464 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:54.465 INFO  [JcrInstaller.16] TransientRepository.java:384 Session opened
23:10:54.465 INFO  [JcrInstaller.16] JcrInstaller.java:469  Bundles root node 
/libs not found, ignored
23:10:54.468 INFO  [JcrInstaller.16] TransientRepository.java:423 Session closed
23:10:56.059 INFO  [main] TransientRepository.java:423  Session closed
23:10:56.060 INFO  [main] JcrInstaller.java:380 Deactivating Apache 
Sling JCR Installer
23:10:56.060 INFO  [JcrInstaller.16] JcrInstaller.java:296  Background thread 
JcrInstaller.16 done
23:10:56.061 INFO  [main] TransientRepository.java:423  Session closed
23:10:56.063 INFO  [main] TransientRepository.java:384  Session opened
23:10:56.066 INFO  [main] JcrInstaller.java:319 Activating Apache 
Sling JCR Installer
23:10:56.067 INFO  [

Re: Disabling flaky tests

[Felix Meschberger]

I agree here: Disabling the test and having an issue keeps the build green but 
bears the danger of forgetting about it ...

Regards
Felix

Am 02.06.2013 um 16:04 schrieb Eric Norman:

> Personally, I'm not a big fan of hiding flaky/failing tests since it tends
> to remove some of the motivation to stabilize/fix them in a timely manner.
> 
> That's my 2 cents.
> 
> Regards,
> Eric
> 
> On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu wrote:
> 
>> Hi,
>> 
>> It seems that the ErrorHandlingTest fails sporadically when run inside a
>> full maven build. I've tried locating the root cause for a couple of
>> hours but failed. For this test, and for future flaky/failing tests, I
>> suggest that we
>> 
>> 1. Create an issue for the failing test
>> 2. Disable the test and mark it with the issue key
>> 3. Re-enable the test when it is stable/passing ( which may be
>> considerably later than step 2)
>> 4. Close the issue after the test is re-enabled
>> 
>> This has the advantage of keeping the build green and making it easier
>> to find regressions since a failing or unstable build will actually mean
>> something.
>> 
>> What do you think?
>> 
>> Robert
>> 
>> 

Jenkins build is unstable: sling-trunk-1.6 #1680

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1680

[Apache Jenkins Server]

See 

Jenkins build is unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1680

[Apache Jenkins Server]

See 

Re: Disabling flaky tests

[Eric Norman]

Personally, I'm not a big fan of hiding flaky/failing tests since it tends
to remove some of the motivation to stabilize/fix them in a timely manner.

That's my 2 cents.

Regards,
Eric

On Fri, May 31, 2013 at 12:14 PM, Robert Munteanu wrote:

> Hi,
>
> It seems that the ErrorHandlingTest fails sporadically when run inside a
> full maven build. I've tried locating the root cause for a couple of
> hours but failed. For this test, and for future flaky/failing tests, I
> suggest that we
>
> 1. Create an issue for the failing test
> 2. Disable the test and mark it with the issue key
> 3. Re-enable the test when it is stable/passing ( which may be
> considerably later than step 2)
> 4. Close the issue after the test is re-enabled
>
> This has the advantage of keeping the build green and making it easier
> to find regressions since a failing or unstable build will actually mean
> something.
>
> What do you think?
>
> Robert
>
>

[jira] [Resolved] (SLING-2898) Failed integration tests for the new Resource Access Tags

[Eric Norman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Norman resolved SLING-2898.


   Resolution: Fixed
Fix Version/s: JCR Resource 2.2.10
   Launchpad Testing 7

fixed in revision 1488784.

> Failed integration tests for the new Resource Access Tags
> -
>
> Key: SLING-2898
> URL: https://issues.apache.org/jira/browse/SLING-2898
> Project: Sling
>  Issue Type: Bug
>  Components: API, Testing
>Affects Versions: Launchpad Testing 7
>Reporter: Eric Norman
>Assignee: Eric Norman
> Fix For: Launchpad Testing 7, JCR Resource 2.2.10
>
>
> The 
> org.apache.sling.launchpad.webapp.integrationtest.scripting.SlingJSPTaglibTest.testTaglib
>  test fails with 2 different errors:
> 1. mkdir(http://localhost:59005/apps/integration-test/taglib-test) failed, 
> status code=409
>-- this happens when the tests don't run in a specific order.  Some of the 
> parent folders don't exist yet, so it reports an error.  Changing the code to 
> use testClient.mkdirs(..) intstead of testClient.mkdir(..) seems to resolve 
> this issue.
> 2. java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not 
> access a member of class 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResource with 
> modifiers "public"
>   -- this happens because the EL implementation uses reflection to retrieve 
> the getPath method for the JcrNodeResource class.  However the declaring 
> class for the method (JcrItemResource) was not declared as public, so the 
> reflection code could not read it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2898) Failed integration tests for the new Resource Access Tags

[Eric Norman (JIRA)]

Eric Norman created SLING-2898:
--

 Summary: Failed integration tests for the new Resource Access Tags
 Key: SLING-2898
 URL: https://issues.apache.org/jira/browse/SLING-2898
 Project: Sling
  Issue Type: Bug
  Components: API, Testing
Affects Versions: Launchpad Testing 7
Reporter: Eric Norman
Assignee: Eric Norman


The 
org.apache.sling.launchpad.webapp.integrationtest.scripting.SlingJSPTaglibTest.testTaglib
 test fails with 2 different errors:

1. mkdir(http://localhost:59005/apps/integration-test/taglib-test) failed, 
status code=409

   -- this happens when the tests don't run in a specific order.  Some of the 
parent folders don't exist yet, so it reports an error.  Changing the code to 
use testClient.mkdirs(..) intstead of testClient.mkdir(..) seems to resolve 
this issue.

2. java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not 
access a member of class 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrItemResource with 
modifiers "public"

  -- this happens because the EL implementation uses reflection to retrieve the 
getPath method for the JcrNodeResource class.  However the declaring class for 
the method (JcrItemResource) was not declared as public, so the reflection code 
could not read it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser]

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 through a hook that allows me to manage them in the repository and 
then at save bring the generated structure back to the IDE).


Also, editing the XML's in an IDE has a couple of shortcomings due to 
the fact that the XML structure currently used is very finicky and does 
not allow for a DTD for example. This makes it IMHO pretty hard to 
manage the structures in an IDE. (for example, list of child nodes has 
to be at the end of the .content.xml file, can't be in the beginning and 
the xml tag names are used to drive the node names in the repository, 
not allowing a clear validation of the options).


Ruben

On 6/2/2013 9:33 AM, Dominik Süß wrote:

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 seems what
everybody needs and agrees on
c) Not directly mentioned but what I think should be defined as well how
and when bundlebased (JAVA) code gets synced to the repository
d) where I didn't hear consensus is about syncing from Sling to FS. The
reason why I have my problem with that,  is that autosync needs an explicit
definition how structures get mapped. In direction repository this is easy
since this unwraps the filebased (xml or json) wrappers and creates a lot
of finegrained strucures, but the other way around there would be the need
of an implicit way how those structures get serialized to the FS or some
(potentially) complex definition that a dev would have to make (possible
with vault afaik, but IMHO errorprone).
e) one of the main reasons for d is to see changes from the repository
within the IDE. I here fully second Carsten that this shouldn't be
automagically resolved but be controlled from the dev.  The IDE here can
create some tooling to identify and display changes and support the job to
reestablish synchronity (this might be the hardest part for the tooling
since I  havent seen a proper ui doing such a job).
f) regarding "sample" content mentioned by Ruben I think some
packagingmechanism and a maven task to upload/download this package should
besufficient (lock package, upload, change content in repo, download
package, check in vcs)

Cheers
Dominik


On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser  wrote:


we frequently have a content project during development with a sample site
that can be deployed over maven to a local dev instance. Maintaining the
sample content in the project requires to author in the cms and then sync
back to file system. Making bulk changes to the structure (for example,
globally rename a sling:resourceSuperType) is easier done in the IDE.
Content is then pushed back into the repository. I am not saying a constant
sync is needed, but a way for the IDE to 'update from repository' would
really help.

The vlt sync command has another issue. Since it stores its state in the
local file system but relies on the server to manage the files your server
instance and file system can get out of sync (say your server crashes and
you have to reinstall it). Switching instances (say current version vs new
version) for testing purposes (is everything still working fine) is not
well supported either.

Ruben


On 6/2/2013 6:35 AM, Antonio Sanso wrote:


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 usually Java - this might also
include
coding in client side stuff like js and css. There is the central tool
you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.


+1

  Whenever that's needed (syncing data from Sling into the file system)

this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE.


+1

Regards

Antonio


  An automatic sync in both directions is dangerous and

imho in most cases not wanted/desired/required.

As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I
think
we should not support when talking about IDE support. Either we support
IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different, but then
let's
make

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß]

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 seems what
everybody needs and agrees on
c) Not directly mentioned but what I think should be defined as well how
and when bundlebased (JAVA) code gets synced to the repository
d) where I didn't hear consensus is about syncing from Sling to FS. The
reason why I have my problem with that,  is that autosync needs an explicit
definition how structures get mapped. In direction repository this is easy
since this unwraps the filebased (xml or json) wrappers and creates a lot
of finegrained strucures, but the other way around there would be the need
of an implicit way how those structures get serialized to the FS or some
(potentially) complex definition that a dev would have to make (possible
with vault afaik, but IMHO errorprone).
e) one of the main reasons for d is to see changes from the repository
within the IDE. I here fully second Carsten that this shouldn't be
automagically resolved but be controlled from the dev.  The IDE here can
create some tooling to identify and display changes and support the job to
reestablish synchronity (this might be the hardest part for the tooling
since I  havent seen a proper ui doing such a job).
f) regarding "sample" content mentioned by Ruben I think some
packagingmechanism and a maven task to upload/download this package should
besufficient (lock package, upload, change content in repo, download
package, check in vcs)

Cheers
Dominik


On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser  wrote:

> we frequently have a content project during development with a sample site
> that can be deployed over maven to a local dev instance. Maintaining the
> sample content in the project requires to author in the cms and then sync
> back to file system. Making bulk changes to the structure (for example,
> globally rename a sling:resourceSuperType) is easier done in the IDE.
> Content is then pushed back into the repository. I am not saying a constant
> sync is needed, but a way for the IDE to 'update from repository' would
> really help.
>
> The vlt sync command has another issue. Since it stores its state in the
> local file system but relies on the server to manage the files your server
> instance and file system can get out of sync (say your server crashes and
> you have to reinstall it). Switching instances (say current version vs new
> version) for testing purposes (is everything still working fine) is not
> well supported either.
>
> Ruben
>
>
> On 6/2/2013 6:35 AM, Antonio Sanso wrote:
>
>> 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 usually Java - this might also
>>> include
>>> coding in client side stuff like js and css. There is the central tool
>>> you
>>> use for developing and that's the IDE with a strong integration into the
>>> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
>>> this scenario, there is only a sync from IDE to Sling required - but not
>>> the other way round.
>>>
>> +1
>>
>>  Whenever that's needed (syncing data from Sling into the file system)
>>> this
>>> should imho be an explicit decision by the dev - simply by invoking an
>>> action from the IDE.
>>>
>> +1
>>
>> Regards
>>
>> Antonio
>>
>>
>>  An automatic sync in both directions is dangerous and
>>> imho in most cases not wanted/desired/required.
>>>
>>> As soon as we're talking about automatic sync from Sling to the project
>>> checkout, this has a different style of development in mind - which I
>>> think
>>> we should not support when talking about IDE support. Either we support
>>> IDE
>>> development and then we do it right and have a style of working that does
>>> not require to leave the IDE - or we do something different, but then
>>> let's
>>> make it clear that we don't plan to provide a true dev experience.
>>>
>>>
>>> Carsten
>>>
>>>
>>> 2013/6/1 Ian Boston 
>>>
>>>  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 converted into a IDE plugin.

 Having thought about it, I think the reason vlt sync works well is that
 Sling is on the same box, monitoring the file system for changes, (I
 think
 thats right, there is no local process with vlt sync) and monitoring JCR
 for changes, which avoids lots of processing and http 

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser]

we frequently have a content project during development with a sample 
site that can be deployed over maven to a local dev instance. 
Maintaining the sample content in the project requires to author in the 
cms and then sync back to file system. Making bulk changes to the 
structure (for example, globally rename a sling:resourceSuperType) is 
easier done in the IDE. Content is then pushed back into the repository. 
I am not saying a constant sync is needed, but a way for the IDE to 
'update from repository' would really help.


The vlt sync command has another issue. Since it stores its state in the 
local file system but relies on the server to manage the files your 
server instance and file system can get out of sync (say your server 
crashes and you have to reinstall it). Switching instances (say current 
version vs new version) for testing purposes (is everything still 
working fine) is not well supported either.


Ruben

On 6/2/2013 6:35 AM, Antonio Sanso wrote:

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 usually Java - this might also include
coding in client side stuff like js and css. There is the central tool you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.

+1


Whenever that's needed (syncing data from Sling into the file system) this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE.

+1

Regards

Antonio



An automatic sync in both directions is dangerous and
imho in most cases not wanted/desired/required.

As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I think
we should not support when talking about IDE support. Either we support IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different, but then let's
make it clear that we don't plan to provide a true dev experience.


Carsten


2013/6/1 Ian Boston 


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 converted into a IDE plugin.

Having thought about it, I think the reason vlt sync works well is that
Sling is on the same box, monitoring the file system for changes, (I think
thats right, there is no local process with vlt sync) and monitoring JCR
for changes, which avoids lots of processing and http traffic. When I have
used other forms of integration on large repositories, the volume http
traffic and speed of response has nearly always made them unusable.

What ever is used or reimplemented it must not rely on scanning a
repository to know what has changed. It must relay on notification of some
form so that Edit->Save->Refresh is never more than a few seconds, and
doesn't impact the Sling server resource usage. Ideally notification should
not rely on the IDE, since changes can be made without the IDE running, and
routing it via the IDE is going to get really confusing with 3 or more
potential sources of updates. (assuming code under version control)

HTH
Ian

1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases


On 31 May 2013 14:07, Ian Boston  wrote:


@Justin, will do.

@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
internals).


On 31 May 2013 13:48, Ruben Reusser  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 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  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
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
made
much more rapid progress. UI dev work needs file-save-refresh. The in
browser editing UIs deliver this, as does VLT in sync mode, but
unfortunately native eclipse based tooling is just too slow (on my
machine,
might be my machine). Using VLT since I joined Adobe, has been a joy,
and I
am very glad to know its being donated to the ASF.

Had we had VLT then, we would have developed in a very different way,
and
might not have had half the problems we had with tooling and team
s

[jira] [Updated] (SLING-2897) [LOG] Enhance web console plugin with edit feature

[Bjoern Weide (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SLING-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bjoern Weide updated SLING-2897:


Attachment: org.apache.sling.commons.log.patch

The patch is extending the webconsole and the logmanager as follows:

- logger configurations are now editable directly in the web console
- typeahead search added for logger names
-  json-view of the config added (/system/console/slinglog.json)
- the logger table is now sortable

> [LOG] Enhance web console plugin with edit feature
> --
>
> Key: SLING-2897
> URL: https://issues.apache.org/jira/browse/SLING-2897
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: Commons Log 3.0.0
>Reporter: Bjoern Weide
>Priority: Minor
> Attachments: org.apache.sling.commons.log.patch
>
>
> The current web console plugin only lists the configured loggers but links 
> for the actual configuration to the OSGi Configuration Manager. 
> It should be improved so the logging configuration can be edited in the web 
> console plugin directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2897) [LOG] Enhance web console plugin with edit feature

[Bjoern Weide (JIRA)]

Bjoern Weide created SLING-2897:
---

 Summary: [LOG] Enhance web console plugin with edit feature
 Key: SLING-2897
 URL: https://issues.apache.org/jira/browse/SLING-2897
 Project: Sling
  Issue Type: Improvement
  Components: Commons
Affects Versions: Commons Log 3.0.0
Reporter: Bjoern Weide
Priority: Minor


The current web console plugin only lists the configured loggers but links for 
the actual configuration to the OSGi Configuration Manager. 
It should be improved so the logging configuration can be edited in the web 
console plugin directly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [tooling] Moving forward with IDE tooling

[Antonio Sanso]

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 usually Java - this might also include
> coding in client side stuff like js and css. There is the central tool you
> use for developing and that's the IDE with a strong integration into the
> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
> this scenario, there is only a sync from IDE to Sling required - but not
> the other way round.

+1

> Whenever that's needed (syncing data from Sling into the file system) this
> should imho be an explicit decision by the dev - simply by invoking an
> action from the IDE.

+1 

Regards

Antonio


> An automatic sync in both directions is dangerous and
> imho in most cases not wanted/desired/required.
> 
> As soon as we're talking about automatic sync from Sling to the project
> checkout, this has a different style of development in mind - which I think
> we should not support when talking about IDE support. Either we support IDE
> development and then we do it right and have a style of working that does
> not require to leave the IDE - or we do something different, but then let's
> make it clear that we don't plan to provide a true dev experience.
> 
> 
> Carsten
> 
> 
> 2013/6/1 Ian Boston 
> 
>> 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 converted into a IDE plugin.
>> 
>> Having thought about it, I think the reason vlt sync works well is that
>> Sling is on the same box, monitoring the file system for changes, (I think
>> thats right, there is no local process with vlt sync) and monitoring JCR
>> for changes, which avoids lots of processing and http traffic. When I have
>> used other forms of integration on large repositories, the volume http
>> traffic and speed of response has nearly always made them unusable.
>> 
>> What ever is used or reimplemented it must not rely on scanning a
>> repository to know what has changed. It must relay on notification of some
>> form so that Edit->Save->Refresh is never more than a few seconds, and
>> doesn't impact the Sling server resource usage. Ideally notification should
>> not rely on the IDE, since changes can be made without the IDE running, and
>> routing it via the IDE is going to get really confusing with 3 or more
>> potential sources of updates. (assuming code under version control)
>> 
>> HTH
>> Ian
>> 
>> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>> 
>> 
>> On 31 May 2013 14:07, Ian Boston  wrote:
>> 
>>> @Justin, will do.
>>> 
>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
>>> internals).
>>> 
>>> 
>>> On 31 May 2013 13:48, Ruben Reusser  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 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  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
>> 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
>> made
>> much more rapid progress. UI dev work needs file-save-refresh. The in
>> browser editing UIs deliver this, as does VLT in sync mode, but
>> unfortunately native eclipse based tooling is just too slow (on my
>> machine,
>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>> and I
>> am very glad to know its being donated to the ASF.
>> 
>> Had we had VLT then, we would have developed in a very different way,
>> and
>> might not have had half the problems we had with tooling and team
>> structure.
>> Ian
>> 
>> 
>> On 31 May 2013 10:16, 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, it will be clear that it provides a good
>>> low-level
>>> interface for this type of UI.
>>> 
>>> While it is true that VLT currently only works with DavEX servers, I
>>> suspect it would not be hard to isolate the "Ex" b

Jenkins build is still unstable: sling-trunk-1.7 #52

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #52

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Sample Integration Tests #52

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #52

[Apache Jenkins Server]

See 

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #1679

[Apache Jenkins Server]

See 

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #1679

[Apache Jenkins Server]

See 


--
[...truncated 1024 lines...]
at java.lang.Thread.run(Thread.java:662)
2013-06-02 11:45:34.788:INFO:/:sling: Apache Sling successfully started in 

2013-06-02 11:45:34.788:INFO:/:sling: Startup completed
2013-06-02 11:45:34.788:INFO:/:sling: Servlet sling initialized
2013-06-02 11:45:34.807:INFO::Extract 

 to /tmp/Jetty_0_0_0_0_53511_cargocpc.war__cargocpc__bldk0c/webapp
2013-06-02 11:45:34.863:INFO::Started SelectChannelConnector@0.0.0.0:53511
[INFO] [beddedLocalContainer] Jetty 6.x Embedded started on port [53511]
[WARNING] The  element under the inner  element is 
deprecated. Please use  under the plugin  instead.
[WARNING] The  element under the inner  element is 
deprecated. Please use  under the plugin  instead.
[INFO] Surefire report directory: 

[INFO] 
---
 T E S T S
---

[INFO] --- maven-surefire-plugin:2.12.4:test (surefire-integration-test) @ 
org.apache.sling.launchpad.testing-war ---
Running org.apache.sling.launchpad.testing.TestAll
Running org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest
Checking if the required Sling services are started (timeout 300 seconds)...
(base URLs=http://localhost:53511 and http://localhost:53511; servlet context=)
Sling services seem to be started, continuing with integration tests.
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.resolution.PrefixTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.auth.AuthenticationResponseCodeTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.NodetypeRenderingTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.ExportedPackagesTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2094Test
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.resourceprovider.PlanetsResourceProviderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostResponseCreatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.StaticContentTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.resolution.PathsServletTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.GroovySlingResourceTypeRenderingTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.EspLoadTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.userManager.UpdateGroupTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostToRootTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.PostRedirectTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.ScriptBindingsValuesProviderTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletAtMoveTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.WebdavOptionsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.LaunchpadConfigInstallerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp.integrationtest.PropertyRenderingTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
Running 
org.apache.sling.launchpad.webapp.integrationtest.servlets.post.PostServletCreateTest
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0
Running org.apache.sling.launchpad.webapp

Re: [tooling] Moving forward with IDE tooling

[Ian Boston]

Hi Carsten,


On 2 June 2013 18:41, 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 usually Java - this might also include
> coding in client side stuff like js and css. There is the central tool you
> use for developing and that's the IDE with a strong integration into the
> SCM (svn, git etc). The dev never has to leave this IDE for anything.

In
> this scenario, there is only a sync from IDE to Sling required - but not
> the other way round.
>
Whenever that's needed (syncing data from Sling into the file system) this
> should imho be an explicit decision by the dev - simply by invoking an
> action from the IDE. An automatic sync in both directions is dangerous and
> imho in most cases not wanted/desired/required.


> As soon as we're talking about automatic sync from Sling to the project
> checkout, this has a different style of development in mind - which I think
> we should not support when talking about IDE support.

Either we support IDE development and then we do it right and have a style
> of working that does
> not require to leave the IDE - or we do something different, but then let's
> make it clear that we don't plan to provide a true dev experience.


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 rebuilds). To say to use Sling tooling you
can only use the IDE will be too restrictive.

However the question you raise is not should developers be allowed to use
command line, its should changes in a Sling repo be automatically reflected
on the filesystem ? (I agree auto syncing between Sling and the internal
IDE state without reference to the file system is not useful).

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. Because of 1 and 2 I can be certain that what I am editing is what I am
testing and the repo:
a) Hasn't mysteriously branched.
b) Hasn't overwritten the change I just made with one of its own. (try one
way sync to experience this, its very frustrating until you work out whats
happening)
4. I can load things into the repo and have them appear in the IDE.

But I dont want to steer this thread if the intention was for tooling that
would only work if everything is done in the IDE.

Best Regards
Ian



>
>
> Carsten
>
>
> 2013/6/1 Ian Boston 
>
> > 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 converted into a IDE plugin.
> >
> > Having thought about it, I think the reason vlt sync works well is that
> > Sling is on the same box, monitoring the file system for changes, (I
> think
> > thats right, there is no local process with vlt sync) and monitoring JCR
> > for changes, which avoids lots of processing and http traffic. When I
> have
> > used other forms of integration on large repositories, the volume http
> > traffic and speed of response has nearly always made them unusable.
> >
> > What ever is used or reimplemented it must not rely on scanning a
> > repository to know what has changed. It must relay on notification of
> some
> > form so that Edit->Save->Refresh is never more than a few seconds, and
> > doesn't impact the Sling server resource usage. Ideally notification
> should
> > not rely on the IDE, since changes can be made without the IDE running,
> and
> > routing it via the IDE is going to get really confusing with 3 or more
> > potential sources of updates. (assuming code under version control)
> >
> > HTH
> > Ian
> >
> > 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
> >
> >
> > On 31 May 2013 14:07, Ian Boston  wrote:
> >
> > > @Justin, will do.
> > >
> > > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
> its
> > > internals).
> > >
> > >
> > > On 31 May 2013 13:48, Ruben Reusser  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 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  wrote:
> > >>>
> > >>>  Hi,
> >  +1 to that. After working on sling for many 

[jira] [Commented] (SLING-2896) Job might be executed twice if a topology event occurs

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672350#comment-13672350
 ] 

Carsten Ziegeler commented on SLING-2896:
-

I've committed a potential fix in rev 1488653

> Job might be executed twice if a topology event occurs
> --
>
> Key: SLING-2896
> URL: https://issues.apache.org/jira/browse/SLING-2896
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Extensions Event 3.2.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Extensions Event 3.2.0
>
>
> If a parallel queue is used (either parallel or round robing) with a limit of 
> N parallel jobs and there are X > N jobs in the queue, the (N+1) job might 
> get processed twice if a topology change occurs:
> Assume we have a parallel queue with max parallel processing set to 8 and 15 
> jobs entering the queue.
> The AbstractParallelJobQueue.start is called with the first 8 jobs - all 
> fine, limit is not yet hit, those jobs are started
> When AbstractParallelJobQueue.start is called with job #9 the acquireSlot() 
> method waits, since the queue is full/busy: The waiting is done in 
> acquireSlot(), in the syncLock.wait() (line 78 of AbstractParallelJobQueue). 
> The calling method - start(JobHandler) - keeps a reference to job #9 !
> In the meantime a TopologyEvent occurs. AFAICS this triggers 'outdating' the 
> existing and recreating a new queue.
> The BackgroundLoader.loadJobsInTheBackground starts filling the new queue.
> Unfortunatelly, this Backgroundloader schedules job #9 too - since it is 
> not yet marked in the repository in any way (there's only the previous queue 
> which has a reference to it in above mentioned start(JobHandler) method - but 
> the job #9 is not yet marked as running in the repository).
> => Thus job #9 is executed the first time by the new queue.
> Eventually the outdated queue is finished with execution. The above 
> acquireSlot() method returns, and:
> => job #9 is executed the second time (by the outdated queue).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SLING-2896) Job might be executed twice if a topology event occurs

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-2896:
---

 Summary: Job might be executed twice if a topology event occurs
 Key: SLING-2896
 URL: https://issues.apache.org/jira/browse/SLING-2896
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: Extensions Event 3.2.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Extensions Event 3.2.0


If a parallel queue is used (either parallel or round robing) with a limit of N 
parallel jobs and there are X > N jobs in the queue, the (N+1) job might get 
processed twice if a topology change occurs:

Assume we have a parallel queue with max parallel processing set to 8 and 15 
jobs entering the queue.
The AbstractParallelJobQueue.start is called with the first 8 jobs - all fine, 
limit is not yet hit, those jobs are started
When AbstractParallelJobQueue.start is called with job #9 the acquireSlot() 
method waits, since the queue is full/busy: The waiting is done in 
acquireSlot(), in the syncLock.wait() (line 78 of AbstractParallelJobQueue). 
The calling method - start(JobHandler) - keeps a reference to job #9 !

In the meantime a TopologyEvent occurs. AFAICS this triggers 'outdating' the 
existing and recreating a new queue.

The BackgroundLoader.loadJobsInTheBackground starts filling the new queue.
Unfortunatelly, this Backgroundloader schedules job #9 too - since it is 
not yet marked in the repository in any way (there's only the previous queue 
which has a reference to it in above mentioned start(JobHandler) method - but 
the job #9 is not yet marked as running in the repository).
=> Thus job #9 is executed the first time by the new queue.

Eventually the outdated queue is finished with execution. The above 
acquireSlot() method returns, and:
=> job #9 is executed the second time (by the outdated queue).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler]

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 stuff like js and css. There is the central tool you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.
Whenever that's needed (syncing data from Sling into the file system) this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE. An automatic sync in both directions is dangerous and
imho in most cases not wanted/desired/required.

As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I think
we should not support when talking about IDE support. Either we support IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different, but then let's
make it clear that we don't plan to provide a true dev experience.


Carsten


2013/6/1 Ian Boston 

> 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 converted into a IDE plugin.
>
> Having thought about it, I think the reason vlt sync works well is that
> Sling is on the same box, monitoring the file system for changes, (I think
> thats right, there is no local process with vlt sync) and monitoring JCR
> for changes, which avoids lots of processing and http traffic. When I have
> used other forms of integration on large repositories, the volume http
> traffic and speed of response has nearly always made them unusable.
>
> What ever is used or reimplemented it must not rely on scanning a
> repository to know what has changed. It must relay on notification of some
> form so that Edit->Save->Refresh is never more than a few seconds, and
> doesn't impact the Sling server resource usage. Ideally notification should
> not rely on the IDE, since changes can be made without the IDE running, and
> routing it via the IDE is going to get really confusing with 3 or more
> potential sources of updates. (assuming code under version control)
>
> HTH
> Ian
>
> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>
>
> On 31 May 2013 14:07, Ian Boston  wrote:
>
> > @Justin, will do.
> >
> > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
> > internals).
> >
> >
> > On 31 May 2013 13:48, Ruben Reusser  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 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  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
>  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
>  made
>  much more rapid progress. UI dev work needs file-save-refresh. The in
>  browser editing UIs deliver this, as does VLT in sync mode, but
>  unfortunately native eclipse based tooling is just too slow (on my
>  machine,
>  might be my machine). Using VLT since I joined Adobe, has been a joy,
>  and I
>  am very glad to know its being donated to the ASF.
> 
>  Had we had VLT then, we would have developed in a very different way,
>  and
>  might not have had half the problems we had with tooling and team
>  structure.
>  Ian
> 
> 
>  On 31 May 2013 10:16, 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, it will be clear that it provides a good
> > low-level
> > interface for this type of UI.
> >
> > While it is true that VLT currently only works with DavEX servers, I
> > suspect it would not be hard to isolate the "Ex" bits and have a
> > "WebDAV"
> > only driver which could be used on non-JCR applications for basic
> file
> > operations.
> >
> > My concern is that we end up building one more abs