karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Karaf first birthday concall minute notes
Date Fri, 17 Jun 2011 11:59:09 GMT
Hi Guillaume,

this might be a good place to put in the wiki, as long as it isn't
disabled. That way we can keep our "non-Versioned" documentation
from beeing updated through a build process (kind of a overhead)
just embed this stuff like the "Roadmap" in the Main Page.

Just my 2 cents :-)

Achim

2011/6/17 Guillaume Nodet <gnodet@gmail.com>:
> The setup is slightly different as we have two web sites, one for the
> manuals which is versioned and one for the main web site which isn't.
> Things such as committers list, board reports and such aren't really
> tied to a release schedule imho.
>
> On Fri, Jun 17, 2011 at 13:38, James Strachan <james@fusesource.com> wrote:
>> BTW we found on the Scalate project we wanted 2 continuous website
>> builds; the current production site branch (i.e. docs for the last
>> major release); so the thing to make http://karaf.apache.org/. Then a
>> continuous build of the new version (trunk);
>> http://karaf.apache.org/versions/3.0-SNAPSHOT (or whatever).
>>
>> Then folks can update the current production website in one branch; or
>> update what will be the next major release (which may be months away);
>> but folks can still view/read the docs for trunk on the website if
>> they want.
>>
>> Also when a release is made, the docs are deployed to a fixed area:
>> http://karaf.apache.org/versions/2.2.3/ or whatever. Then you've just
>> gotta maintain the http://karaf.apache.org/versions/index.html page to
>> link to the various available versions etc.
>>
>>
>> On 17 June 2011 12:28, James Strachan <james@fusesource.com> wrote:
>>> On 17 June 2011 12:16, Christian Schneider <chris@die-schneider.net> wrote:
>>>> Am 17.06.2011 12:53, schrieb Guillaume Nodet:
>>>>>
>>>>> Over the last 5 years, I've rarely seen people contributing a lot to
>>>>> the doc without being or becoming committers.
>>>>> I don't want to change a technical decision based on the fact that
>>>>> people *might* need something, but rather what people actually need.
>>>>> You are a committer, so you can access / modify the documentation
>>>>> without any problems.  So what are your real problems with the current
>>>>> solution ?  We can easily set up nightly uploads or even an hourly
>>>>> cron job (though given the change rate, i think a nightly one should
>>>>> be sufficient).   If you need an editor, you always find some software
>>>>> I think such as
>>>>> http://www.labnol.org/software/wysiwyg-wiki-editor/18062/ though I
>>>>> tend to use the "mvn jetty:run" which works quite well as you can see
>>>>> your changes immediately.
>>>>
>>>> For me as a committer now it is ok. I also do not have problems with editing
>>>> wiki syntax text files by hand. After reading all the comments I think that
>>>> the solution is good for now. I just fear that we might not really attract
>>>> people to help. But you are right people who just work on the documentation
>>>> are rare anyway.
>>>>
>>>> It would be great if we could establish an automatic update of the website
>>>> for trunk and the current production branch. Ideal would be a script like
in
>>>> jenkins that only fires when there are real changes then it can be run in
>>>> very short cycles.
>>>
>>> Its really no different from a regular continuous integration build
>>> really; building & deploying the website is just a different mvn
>>> plugin so its like doing snapshot deploy builds.
>>>
>>>
>>>> Btw. How about using jenkins to update the website? The
>>>> update just has to be callable from maven and we have to authenticate in
>>>> some way. Jenkins would also allow to track when and why updates have beem
>>>> done.
>>>
>>> We've been doing this on the Scalate project for a while btw; its just
>>> a matter of setting up a jenkins build in the right branch and using a
>>> profile in the maven build to do the deploy of the website project (as
>>> you probably don't want other builds deploying the website by
>>> default).
>>>
>>> This kinda thing does the trick in the website pom...
>>>
>>>      <plugin>
>>>        <groupId>org.fusesource.scalate</groupId>
>>>        <artifactId>maven-scalate-plugin</artifactId>
>>>        <version>${project.version}</version>
>>>        <configuration>
>>>
>>>          <remoteServerId>people.apache.org</remoteServerId>
>>>
>>>           <!-- server stuff here - scp or dav or whatnot... -->
>>>           <!-- TODO fixme - i just made this up .... --->
>>>          <remoteServerUrl>scp:people.apache.org:/www/karaf.apache.org/versions/${project.version}</remoteServerUrl>
>>>        </configuration>
>>>        <executions>
>>>          <execution>
>>>            <id>sitegen</id>
>>>            <goals>
>>>              <goal>sitegen</goal>
>>>            </goals>
>>>            <phase>package</phase>
>>>          </execution>
>>>          <execution>
>>>            <id>deploy</id>
>>>            <goals>
>>>              <goal>deploy</goal>
>>>            </goals>
>>>            <phase>deploy</phase>
>>>          </execution>
>>>        </executions>
>>>      </plugin>
>>>
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email: james@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: jstrachan, fusenews
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration and Messaging
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: james@fusesource.com
>> Web: http://fusesource.com
>> Twitter: jstrachan, fusenews
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration and Messaging
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



-- 
--
*Achim Nierbeck*


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead

Mime
View raw message