Users of Sling, by which I really mean people building applications on top of Sling , should not need to modify the Sling source tree. Cases where this is either necessary or perceived to be necessary is one or more of: a) a bug in the build b) room for improvement in the code c) a documentation gap
I personally would welcome any JIRA submissions from users along the lines of "I wanted to customize X and the only way I could do it is by modifying the Sling source in module Y." Justin On 6/18/10 2:25 PM, Tony Giaccone wrote: > > Let me start out by saying that this maybe more of a Dev issue, then a users > issue. However, given that to do things like change the location of the > repository, you need to rebuild Sling, I think there's a reasonable case to > be made for posting this to the users list. > > The build process for Sling is pretty simple. If you know maven and are > reasonably facile at the command line, you can build sling with out much > trouble. That said today I've had a miserable build problem, and it's cost > me all day figuring this out (which perhaps suggests my understanding of > maven isn't as good as it should be, I should have recognized this sooner). > > I wanted to make a change to the web.xml file, and I made that change, and > did the build and the change wasn't propagating through to the war file. The > problem was, that the component that contains the web.xml file was building > to a different version (version-something-SNAPSHOT), then the launchpad was > dependent upon (version-something). > > So my change was making it into the maven repository but not making it back > out into the build of the war file. > > I should have recognized this as a problem sooner, but Sling is a fairly > complicated build with a lot of moving pieces. It wasn't clear to me till > quite late in the process that there was a trip to the maven repository > involved in the build. > > I'm reasonably certain that I pulled this source code based on the > instructions on the building page. > > http://sling.apache.org/site/getting-and-building-sling.html > > > Grabbing source from the trunk is probably the right thing to do for folks > doing development on the Apache Sling project. However, there are also guys > like me, who have to do builds and make changes based on stable versions of > the code. Guys like me HATE pulling from the trunk. The trunk is by it's > very nature unstable and inconsistent. > > It's not clear to me how release management works on this project, but it > would be nice, to have a sources tar file, to go along with a stable release > version. That way you could just download the tar file and have the sources > for a complete version which you could modify to do things like change the > location of the repository, or add JDBC driver support and not worry that > you're playing with the "latest" code base, or having to deal with > inconsistent version dependencies. > > Or at least publish tags for released versions , and change the check out > instructions to reflect the tag of most recent stable version. > > I hate pointing out a problem which ends up being a call for someone else to > do work, but Sling is a sophisticated piece of software, the project and the > build take time to understand and having a stable consistent code base to > work from, would make the whole process much more approachable. > > > Tony
