xwiki-devs April 2011

xwiki-devs@xwiki.org

39 participants
91 discussions

[xwiki-devs] XEclipse Navigator node filtering (pages with dots in names are missing)

by Karel Gardas

Hello, with using latest Eduard's fix (r36321) I'm able to get XEclipse plugins working in Eclipse 3.6.2. Now I see just more minor issue where pages with dots in their names are missing. I.e. my example is using bookstore idea and one of the author put there is "J.R.R.Tolkien". Its page is not shown in XEclipse navigator but is shown on web interface or more exactly in book store space document index in browser I see it but I don't see it inside book store space node in XEclipse Navigator. Is this expected behavior or known issue? Or shall I report it somewhere? Thanks, Karel

13 years, 8 months

[xwiki-devs] How to develop XEclipse? (compilation issue in latest source code)

by Karel Gardas

Hello, I've svn co https://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk xeclipse and following information provided on http://dev.xwiki.org/xwiki/bin/view/Community/BuildingInEclipse -- just on the bottom of the page, there is a paragraph describing building of XEclipse plugins inside Eclipse. Now, when I do first two steps: # Within the Eclipse IDE, select [File->Import->Existing Projects into Workspace]. # In the import projects dialog, point [root] directory to [xeclipse/plugins/org.xwiki.eclipse]. I end with the org.xwiki.eclipse project in my workspace, but this project fails with 12 errors like this: Description Resource Path Location Type The method execute(ExecutionEvent) of type ConnectHandler must override a superclass method ConnectHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 42 Java Problem The method execute(ExecutionEvent) of type DebugInfoHandler must override a superclass method DebugInfoHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 35 Java Problem The method execute(ExecutionEvent) of type DisconnectHandler must override a superclass method DisconnectHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 35 Java Problem The method execute(ExecutionEvent) of type GrabSpaceHandler must override a superclass method GrabSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 50 Java Problem The method execute(ExecutionEvent) of type NewConnectionHandler must override a superclass method NewConnectionHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 34 Java Problem The method execute(ExecutionEvent) of type NewPageHandler must override a superclass method NewPageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 36 Java Problem The method execute(ExecutionEvent) of type NewSpaceHandler must override a superclass method NewSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 36 Java Problem The method execute(ExecutionEvent) of type OpenPageHandler must override a superclass method OpenPageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 37 Java Problem The method execute(ExecutionEvent) of type RemoveConnectionHandler must override a superclass method RemoveConnectionHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 39 Java Problem The method execute(ExecutionEvent) of type RemovePageHandler must override a superclass method RemovePageHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 39 Java Problem The method execute(ExecutionEvent) of type RemoveSpaceHandler must override a superclass method RemoveSpaceHandler.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/handlers line 38 Java Problem The method execute(ExecutionEvent) of type XWikiExplorerView.RefreshHandler must override a superclass method XWikiExplorerView.java org.xwiki.eclipse/src/main/java/org/xwiki/eclipse/views line 109 Java Problem I've verified that this happen on Eclipse 3.4.1, 3.6.2 and also 3.7-M4. Is that a known issue? If so, is there any fix already available for it? Thanks, Karel

13 years, 8 months

[xwiki-devs] Need help fixing a bug

by Supreet Pal Singh

Hey I wanted to try and fix a bug. I feel the bug "Some top menu URLs are pointing to the skin wiki instead of the local wiki" <http://jira.xwiki.org/jira/browse/XWIKI-6544> (http://jira.xwiki.org/jira/browse/XWIKI-6544) can be worked upon by me as I have studied velocity and have gone through the code of menuview.vm but I am unable to understand the scenario in which the bug surfaces. If someone could help me understand it , it would be of great help to me. Thanks, Supreet

13 years, 8 months

Re: [xwiki-devs] Photo Album Application for GSOC 2011

by shweta agrawal

Hi, I have submitted my proposal of GSOC for idea "Photo Album Application" today. Looking for your feedback. Thanks Shweta Agrawal On Thu, Apr 7, 2011 at 3:01 AM, Ecaterina Moraru (Valica) <valicac(a)gmail.com > wrote: > Hi, > > On Wed, Apr 6, 2011 at 22:23, shweta agrawal <shweta.9996(a)gmail.com>wrote: > >> Hi, >> >> I have identified following task list. >> >> *File Uploading Part -* >> Allow upload of Zip files and Extracting image files from zip archive >> (java.util.zip package). >> //use storage implementation accordingly - filesystem or database. >> //image compression can be done by using java image io api. As Marius >> said there is only resizing capability available in xwiki and jpeg with >> quality near to 60% are optimum for web display, so compression can be used. >> >> >> *Extracting EXIF information from image files.* (This information can be >> stored in a separate db table. I found this >> http://www.drewnoakes.com/drewnoakes.com/code/exif/. It's a java metadata >> extractor library for jpeg image files. ) >> >> Tags - allowing *tagging of attachments*. We can have a separate column >> of tags in the attachment_content table where different tags can be stored >> (separeted via pipeline). WDYT? >> > > Tags can be displayed just for the attachments in the photo application. We > can make it general, but we need to see more use cases. Right now in XWiki > the only things you can add tags are pages. Tags are represented as objects. > > > >> Comments - associating *comments with an attachment*. As I have no idea >> how comments are stored so can't say anything about it right now. >> > > Just like tags, comments are stored as objects to pages. > > >> >> Designing and Implementing *Browsing Interface and Album/Photo >> manipulation interface* >> Browsing Interface - interface that allows users to browse albums easily >> thumbnail view and slide show >> browse based on some metadata info like author or location >> Album manipulation interface >> Add Photos >> Delete Photos >> Managing manipulation rights for the album >> Editing basic info about Album >> Photo Manipulation Interface >> Using canvas element - manipulate rotation, opacity, cropping, adjusting >> gamma, contrast, brightness etc >> Editing basic info about Photo >> >> Currently I am working on gsoc proposal and basic drafts of album browsing >> interface. >> Is this task list ok? >> > > The list is ok. Go ahead and complete your proposal. > > Thanks, > Caty > > >> Further, I am thinking that I should start with Browsing Interface, then >> after that file uploading part and EXIF information extraction will be >> implemented. What do you say? (I need it for describing project plan and >> timeline in gsoc proposal). >> >> Looking for your feedback. >> >> Thanks >> Shweta Agrawal >> >> On Mon, Apr 4, 2011 at 8:05 PM, Ecaterina Moraru (Valica) < >> valicac(a)gmail.com> wrote: >> >> Hi, >>> >>> >>> On Sat, Apr 2, 2011 at 14:03, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>> >>> Hi, >>>> >>>> >>>> I have checked out the HTML 5 specifications for geo-location api, file >>>> uploading api and canvas container. >>>> >>>> At present, all the attachments are stored in database irrespective of >>>> their nature (the old photo album also uses db to store images). I browsed >>>> to find out which is better for storing image files - database or file >>>> system and found that most of the posts favored filesystem (in case of large >>>> number of images). I need your suggestion regarding which one is better in >>>> xwiki's context. In case of using filesystem for storing image files, >>>> migration of older version photo albums will be complicated as image files >>>> will need to be imported from database to file system. >>>> >>> Right now from what I know attachments are stored in the database. Caleb >>> is working on a new storage that will use the filesystem. So IMO you don't >>> have to worry about this aspect and also it will not be very relevant for >>> this project (you will only have to use the storage, not implement it). See >>> http://markmail.org/thread/pl7v4sew2ujksrvv >>> >>> >>>> Secondly, most of the online photo album application (flickr, picasa >>>> web album, facebook) uses image compression for rendering images fastly on >>>> slower networks, so do we also intend to use some compression algorithm and >>>> optimize the image files for display on web. (xwiki can have something of >>>> this sort that is if image size is more than some threshold value (say 1 Mb >>>> or 512 kb) then it can be stored as a compressed image). I haven't checked >>>> out which algorithms are used and does there exist any library or API for >>>> image compression, so can't say how much time it will take to implement. >>>> >>>> I think we already have some image compression on the server side. >>> Marius can give more information about this. See >>> http://markmail.org/thread/kbazwdlgmrlsllcv >>> >>> >>>> what about sharing photo album only with a specific group not all users >>>> and also having manipulating rights to some users only (unlike the old photo >>>> album application, any registered user can add or delete photos created by >>>> some other user)? >>>> >>>> >>>> This won't be a problem either. If the application is located at space >>> level and let's say albums are identified at page level, then you can easily >>> play with the rights system and give permissions just to a group or user, >>> etc. See >>> http://platform.xwiki.org/xwiki/bin/view/Features/RightsManagement >>> >>> Thanks, >>> Caty >>> >>> >>>> Thanks >>>> Shweta Agrawal >>>> >>>> >>>> On Tue, Mar 29, 2011 at 2:35 AM, Ecaterina Moraru (Valica) < >>>> valicac(a)gmail.com> wrote: >>>> >>>> >>>>> >>>>> On Mon, Mar 28, 2011 at 16:38, shweta agrawal <shweta.9996(a)gmail.com>wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I am Shweta Agrawal, final year computer science student at IIT >>>>>> Roorkee, >>>>>> India. I want to apply for GSoC this year and am interested in working >>>>>> on >>>>>> Photo Album Application. I have four year experience in web >>>>>> development and >>>>>> have good understanding of HTML, CSS, Php, python and Javascript. I >>>>>> have >>>>>> worked on creating user interfaces for a couple of websites and >>>>>> developed >>>>>> applications like online music player (similar to grooveshark), online >>>>>> notice board etc for my Institute's intranet. >>>>>> >>>>>> As far as I understand the project, it's aimed at developing an >>>>>> application >>>>>> where users can >>>>>> >>>>>> - upload the photos (one by one or zip files or folders) with >>>>>> information like date, caption, location etc.- this info can be >>>>>> extracted by >>>>>> reading exif information. *additional* - multiple file selection and >>>>>> upload, drag and drop functionality (supported by HTML 5 compliant >>>>>> browsers). ** *doubt* that do we intend to create a default album >>>>>> for all >>>>>> the images uploaded/attached by user on any of the pages i.e. not >>>>>> only the >>>>>> images that are uploaded for some album. It will provide user an >>>>>> easy way to >>>>>> manipulate and browse through all uploaded image files. >>>>>> >>>>>> the intent is to have albums. This means the user specifies the >>>>> desired photos he wants to add to his album. >>>>> About your idea: to have an album with all the images uploaded by user: >>>>> this is already accessible if you go to Main/AllDocs?view=attachments and >>>>> filter the user. >>>>> >>>>> >>>>>> - create albums and add information like title, caption, >>>>>> description and >>>>>> location. *doubt* - will there be any limit on maximum number of >>>>>> photographs in an album? >>>>>> >>>>>> we don't have any limit on the number of attachments we add to a page, >>>>> so we shouldn't have a limit here either. >>>>> >>>>> >>>>>> - browse through the uploaded photographs (available in browsers >>>>>> not >>>>>> having javascript - It can be done using css3). >>>>>> >>>>> we recently have something like >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Gallery+Macro >>>>> and >>>>> >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Attachment+Selector+Ma… >>>>> to give you some example of extensions that handle attachment viewers. >>>>> >>>>> >>>>>> - view as thumbnails and slideshow (with adjustable timer and >>>>>> with >>>>>> manual browsing). >>>>>> >>>>>> >>>>>> - migration tool from the old version photo albums. *doubt* - what >>>>>> does >>>>>> old version photo albums refer to? >>>>>> >>>>> This is the very old Photo album application that we want to replace. >>>>> >>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Photo+Album+Application >>>>> >>>>> >>>>>> - ability to tag and associate comments with attachments. *doubt* - >>>>>> does >>>>>> attachments here refers to image files only or any type of files. >>>>>> >>>>> for the purpose of this project refers to images, but this should be >>>>> extensible so we could comment on any type of files. >>>>> >>>>> >>>>>> I have browsed through the code of older photo album application. I >>>>>> need >>>>>> guidance that is how should I start working on this application? I am >>>>>> thinking about starting with uploading part. >>>>>> >>>>>> Learn a bit XWiki structure and the way applications and extensions >>>>> are done, integrated and reused. >>>>> You can find lots of applications at >>>>> http://extensions.xwiki.org/xwiki/bin/view/Main/ >>>>> You can play with them, see also the source code, etc. >>>>> >>>>> The specifications for this project are very oriented towards the HTML5 >>>>> standard so you should check that out too. >>>>> >>>>> Thanks, >>>>> Caty >>>>> >>>>> >>>>>> Looking forward to your feedback. >>>>>> >>>>>> Regards >>>>>> >>>>>> Shweta Agrawal >>>>>> B.Tech IV YR CSE >>>>>> IIT Roorkee >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> devs(a)xwiki.org >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> >>>>> >>>>> >>>> >>> >> >> >

13 years, 8 months

[xwiki-devs] [PROPOSAL] Keep working on svn for 3.0 branch

by Thomas Mortagne

For simplicity I suggest we keep working on svn for the 3.0 branch. The project organization is very different between 3.1 and 3.0 and I don't see us doing the same refactoring on 3.0 branch. It means merging stuff by hand but it's not very hard. WDYT ? -- Thomas Mortagne

13 years, 8 months

[xwiki-devs] [Proposal] Remove usage of buildnumber plugin

by Vincent Massol

Hi devs, I'd like to propose to remove the usage if the buildnumber plugin. Initially the idea was to differentiate different snapshot version so that when a user reports an issue on a snapshot version we know exactly which svn rev it corresponds to and can reproduce the problem easily. In practice and AFAIK it has never happened. Now since we're moving to Git and since the buildnumber plugin generates a hash for git (less user friendly), I think we could drop its usage. This will allow to reduce the build complexity. WDYT? Thanks -Vincent

13 years, 8 months

[xwiki-devs] [proposal] Stop executing the reporting tool.

by Caleb James DeLisle

I have found that the reporting tool emails are more useful than the default hudson email but still not useful enough (to me) for me to spend time reading them all. When I want to know the state of hudson I look at the site. Since the reporting tool was broken by the switch to git, I'd like to stop running it. I'm not sure what an email report should look like but I know we're not getting it. If anyone is using those, just say something and I'd be glad to bring it back, otherwise I'll shut it down. Caleb

13 years, 8 months

[xwiki-devs] New development strategy

by Sergiu Dumitriu

Hi devs, Since we're moving to git / GitHub, it's time to re-evaluate the development / git usage strategy. = Short version: 1/ Where do developers commit: A. Always in the master branch B. In feature branches in the official repo, merged into the master branch when ready C. In their personal forks, requesting pulls in the official repo with a mandatory code review from another developer 2/ How to move code from development to release: A. Commit and release from the master branch B. Develop in feature branches, merge them in the master when ready, release from master C. Develop in feature branches, merge them in a development branch (master) for polishing, merge them in a release branch when done-done D. Develop in feature branches, merge them often in the development branch (master) for snapshot testing, move into the stabilization (pre-release) branch for polishing, move into the release branch when done-done. E. Develop in feature branches, merge them in a development branch for snapshot testing, move into a stabilization branch for the Next release, which becomes the Current release branch after the previous release is done, and which becomes a Maintenance branch after the new release is performed. Only bugfixes go in the Current release branch. I vote 1C and 2D. = Long version The common practice with Subversion is to have as few branches as possible, usually a trunk and a few maintenance branches, or development+stable+maintenance. This is a consequence of the perceived difficulty of merging changes between branches in svn, and the high cost of keeping multiple branches checked out. On the other hand, the git philosophy is to use branches as much as possible. Two core elements are "feature branches" and "forks". A feature branch is a branch where one feature is being developed, separated from the trunk and all the other features. While working on it, the developer "rebases" the branch on top of the trunk to keep his branch up to date with the trunk, and at the end "merges" the feature branch into the trunk. This way in-development features are kept out of the main trunk, but still allowing changes to be committed someplace public (no local uncommitted code anymore). A central element of GitHub is the ability to "fork" a repository. This means that a user clones a project in a personal repository where he can commit changes. He can later ask the maintainer of the original to "pull" those changes back into the original repository. This is the preferred way of contributing patches on GitHub. == Commit/Development-related strategies A. One central repository, one trunk (subversion-like) Developers clone the official trunks repository, prepare commits locally, then push back to the official repository. It's the same strategy that we're using now, except that we can also have an offline local repository. B. One central repository, feature branches Developers clone the official trunks repository, prepare commits locally in feature branches, then push back to the official repository in feature branches as well. When a feature is considered stable, it is merged into the master branch. Small bugfixes and improvements go directly in the master branch. B1. Also use specific helper branches Security fixes also go into a "security" branch so that users can cherry-pick them into older tags to build a custom patched version. Retired features can go into a "retired" branch so that users can re-include that feature in a custom build if they need it. C. One aggregated repository, pulling from developers Developers fork the official repositories, work on their fork (in feature branches as well), then make pull requests for integrating their work into the trunk. The rule would be that another developer has to do the pull after a code review (mandatory code reviews). This means more bugs spotted before committing, but also more work/time needed from the committers. We can relax the rule so that obvious bugfixes can be pulled by the same developer making the pull request. Personally, I prefer C, since it ensures better quality since at least two eyes see each line of code. == Integration/Release-related strategies Currently, we're developing on the trunk, and we're releasing from it during short breaks from live development. This is highly dangerous, and imposes a certain rhythm, with fast bursts of development right after a release, and imposed slowdown as the next release approaches (no work on new features after the last milestone). Short releases from a development branch is inline with agile development, but personally I find it too dangerous. Most big projects always keep the main development at least one branch away from the release branch. One example is the Linux kernel. While a kernel release lasts about 3 months, like our own releases, almost all of the code that goes into a release has been developed before the merge window opens. This means that after a kernel version is released, Linus opens a two-weeks merge window during which he accepts pull requests for existing, working, complete code. The next ~10 weeks are spent testing the new kernel and integrating bugfixes, while developers prepare the features for the next kernel version. This ensures that a released kernel has as few bugs as possible. They can afford to do that since there are hundreds or thousands of contributors. Still, this is entirely opposite to our way of working: after a release we barely start writing the code to go in the new release, and we get code in at the last minute (especially me). Another example that I'd like to present is the new proposed strategy for Mozilla Firefox: http://mozilla.github.com/process-releases/draft/development_overview/ Basically, the propose using 4 branches, from development to release, where code enters on the lowest branch, and moves up towards a release as it stabilizes and becomes release-ready. They use 6-weeks release cycles, and only stable-enough features get promoted from one branch to the next when a new cycle starts. This process ensures quality as well. I'd like to move closer to one of these two strategies, so that our releases are more polished. The mechanism for ensuring quality that we're currently using is to have an "investigation" phase during the previous release, which is supposed to help define the exact goals, so that during the current release the development should go smoothly towards that "idea goal". Unfortunately, this doesn't work that well. Without the code in place, investigations may miss important details/limitations that will shift the development in another direction. Or it can happen that the time is too short to fully implement something, so we can either release a very "in progress" feature, or decide near the end that it's not enough time to implement everything and focus on polishing what's already available to have a "partial" feature, but polished enough not to reek of low quality. The main problem here is that we're mixing feature- and time-based releases, with mandatory features that must find their way into a release, and a fixed deadline to make the release. This means that features have 8-10 weeks to be fully implemented, polished, tested, validated. And that doesn't always happen. So, here are some possible integration strategies: A. Master development (like now) All development is done in the master branch, from which we branch a few hours/days before the release, so that the master remains clear for development. B. Feature branches All new feature development is done in a separate branch for each feature, and we merge it in the trunk once it's considered done (or very close). When a release date comes, we release with the completed features, whatever those are. We don't force a merge of an incomplete feature just because it's in the roadmap if it's not stable enough. C. Feature+Development+Release branches All development is done in feature branches, but they get merged on the master branch more often to have test builds; the release branch is separate and it integrates features when they are considered ready. This has the advantage over B. that automated builds expose all the development features. D. Feature+Development+Stable+Release branches This is similar to the new Mozilla strategy. Developers merge their work in the Development branch very often. Users and other developers can contribute here as well, and preview the upcoming features. When they are close to finalization, they are also merged to the stable branch, where UX, QA and feature owners can test and improve the feature, preparing it for release. Once it's considered ready, it is merged into the release branch, where QA does a final thorough test. Releases happen from this branch. E. Feature+Development+Next+Release This is similar to D, with the exception that done features go into the next release, while the current release is staging. When the release is done, Release moves into Bugfix, Next becomes Release, and we create a new Next branch and start pulling in it. This would work well if we had very short release cycles (2 weeks), but it's not worth the effort for our current 3-month releases, since a feature would stagnate too much before being released. And it would also work if we had more beta testers. We can also impose windows, like 2-4 weeks for a feature to move into the next branch. We could also make faster releases, skipping milestones. and going to 6 week releases. This means that it would take longer for a feature to make its way from idea to release. One release for investigation, one or more for the main development, and one for integration and stabilization. But this also means that releases will be more solid, polished, with less bugs, and closer to the user needs. Personally I prefer option D, although it's a bit too much overkill with our current limited manpower. We need more contributors and committers! As for a change strategy, we can continue the way we're doing now, gradually switching to feature branches and release/pre-release branches during the following release. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 8 months

[xwiki-devs] Merge XWIKI-5296 and XWIKI-6546 in 2.7 branch

by Marius Dumitru Florea

Hi devs, I know 2.7 is a bug fixing branch but I need these two new features for a project that will use XE 2.7.2 (to be released soon). The changes are pretty safe. Let me know if you are against it. Thanks, Marius

13 years, 8 months

[xwiki-devs] Fwd: [ANN] New Release of Apache Sling 6

by Vincent Massol

Just a note to mention that I find apache sling to be relatively similar to what we're doing with XWiki: a web platform. Sling is slightly more generic though whereas we're more wiki-oriented but a wiki system could be implemented on top of Sling. I'm not suggesting that we move to sling I'm mentioning it so that we're aware it exists and that it fits a similar need and can thus be considered a competitor when considering XWiki as a platform for developing collaborative web applications. Thanks -Vincent Begin forwarded message: > From: Felix Meschberger <fmeschbe(a)apache.org> > Date: April 18, 2011 9:10:00 AM GMT+02:00 > To: Apache Announcements <announce(a)apache.org>, Sling Users <users(a)sling.apache.org> > Subject: [ANN] New Release of Apache Sling 6 > > Bringing Back the Fun > > Apache Sling brings back the fun to Java developers and makes the life > of a web developer much easier. It combines current state of the art > technologies and methods like OSGi, REST, scripting, and JCR. > > The main focus of Sling deals with the important task of bringing your > content into the web and providing a platform to manage/update the > content in a REST style. > > Sling is built as OSGi bundles and therefore benefits from all > advantages of OSGi. On the development side a scripting layer > (leveraging the Java Scripting API) allows to use any scripting language > with Sling (of course you can use plain old Java, too). And on top of > this, Sling helps in developing an application in a RESTful way. > > As the first web framework dedicated to JSR-283 Java Content > Repositories, Sling makes it very simple to implement simple > applications, while providing an enterprise-level framework for more > complex applications. Underneath the covers Apache Jackrabbit is used > for the repository implementation. > > Download the new release, Apache Sling 6, today and give it a try! > > Apache Sling currently comes in four flavors: > - A standalone Java application (a jar containing everything to get > started with Sling) > - A web application (just drop this into your favorite web container) > - The full source package (interested in reading the source?) > - Maven Artifacts (available from the Central Maven Repository) > > For more information, please visit the Apache Sling web site at > http://sling.apache.org/. > > or go directly to the download site at > http://sling.apache.org/site/downloads.cgi > > For those interested in numbers: Since the Apache Sling 5 > announcement ... > > * 22 months have passed > * 7 committers have been added to Apache Sling > * 3 members have been added to the Apache Sling PMC > * 158 releases have been cut and voted on > * ~2800 commits have been sent to the SVN repository > > I would like to thank every user, contributor, committer and member of > the PMC for their hard work and sometimes patience for making Apache > Sling 6 a reality. > > On behalf of the the Apache Sling PMC > Felix Meschberger

13 years, 8 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2011