Ralph Goers | 16 Apr 06:38 2012

Logging web sites

Do we have a process in place for updating the web site?  I'm trying to go through any issues that might exist
with doing a release of Log4j2 and this is one of them.
Christian Grobmeier | 16 Apr 09:14 2012
Picon

Re: Logging web sites

On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> Do we have a process in place for updating the web site?  I'm trying to go through any issues that might
exist with doing a release of Log4j2 and this is one of them.

I am not aware of a specific process (old timers might want to correct me).
So far I know we have updated the website whenever the release has
been published. I am not a huge fan of restricting website updates to
releases and think we should be able to update at any time we want.

This again touches the question with pubsub. We need to make a
decision if we move to mvn site:deploy or do something else.

Cheers
Christian

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 16 Apr 09:31 2012

Re: Logging web sites

I'm actually more concerned with us having to use svnpubsub (see http://www.apache.org/dev/project-site.html).  The maven team created a plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to aid in this but I haven't tired it. I also understand that it requires the main website to have something done to it first.

Log4j2 uses the Maven site plugin so I guess I really need to know is what the location of the svn directory would be to pass to svnpubsub:prepare. 

Ralph

On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:

On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
Do we have a process in place for updating the web site?  I'm trying to go through any issues that might exist with doing a release of Log4j2 and this is one of them.

I am not aware of a specific process (old timers might want to correct me).
So far I know we have updated the website whenever the release has
been published. I am not a huge fan of restricting website updates to
releases and think we should be able to update at any time we want.

This again touches the question with pubsub. We need to make a
decision if we move to mvn site:deploy or do something else.

Cheers
Christian


--
http://www.grobmeier.de
https://www.timeandbill.de

Christian Grobmeier | 16 Apr 09:37 2012
Picon

Re: Logging web sites

On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> I'm actually more concerned with us having to use svnpubsub
> (see http://www.apache.org/dev/project-site.html).  The maven team created a
> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
> aid in this but I haven't tired it. I also understand that it requires the
> main website to have something done to it first.

didn't know about the mvn plug - thanks!

> Log4j2 uses the Maven site plugin so I guess I really need to know is what
> the location of the svn directory would be to pass to svnpubsub:prepare.

What about:
http://svn.apache.org/repos/asf/logging/site/pubsub/$project

For example:
http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)

and so on

>
> Ralph
>
>
> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>
> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
> wrote:
>
> Do we have a process in place for updating the web site?  I'm trying to go
> through any issues that might exist with doing a release of Log4j2 and this
> is one of them.
>
>
> I am not aware of a specific process (old timers might want to correct me).
> So far I know we have updated the website whenever the release has
> been published. I am not a huge fan of restricting website updates to
> releases and think we should be able to update at any time we want.
>
> This again touches the question with pubsub. We need to make a
> decision if we move to mvn site:deploy or do something else.
>
> Cheers
> Christian
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 17 Apr 21:47 2012

Re: Logging web sites

I'm OK with this, but I'm not sure if infra is OK with that structure. Based on that I think what we want to
request is the following be added to the rules.

/x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging

/x1/www/logging.apache.org: %(ASF)s/logging/site/main
/x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
/x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
/x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
/x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
/x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net

chainsaw and log4j companions also show up on the main site. Do we also want those?

Ralph

On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:

> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> I'm actually more concerned with us having to use svnpubsub
>> (see http://www.apache.org/dev/project-site.html).  The maven team created a
>> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>> aid in this but I haven't tired it. I also understand that it requires the
>> main website to have something done to it first.
> 
> didn't know about the mvn plug - thanks!
> 
>> Log4j2 uses the Maven site plugin so I guess I really need to know is what
>> the location of the svn directory would be to pass to svnpubsub:prepare.
> 
> What about:
> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
> 
> For example:
> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
> 
> and so on
> 
> 
> 
> 
>> 
>> Ralph
>> 
>> 
>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>> 
>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>> wrote:
>> 
>> Do we have a process in place for updating the web site?  I'm trying to go
>> through any issues that might exist with doing a release of Log4j2 and this
>> is one of them.
>> 
>> 
>> I am not aware of a specific process (old timers might want to correct me).
>> So far I know we have updated the website whenever the release has
>> been published. I am not a huge fan of restricting website updates to
>> releases and think we should be able to update at any time we want.
>> 
>> This again touches the question with pubsub. We need to make a
>> decision if we move to mvn site:deploy or do something else.
>> 
>> Cheers
>> Christian
>> 
>> 
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>> 
>> 
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de

Christian Grobmeier | 19 Apr 07:20 2012
Picon

Re: Logging web sites

On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> I'm OK with this, but I'm not sure if infra is OK with that structure. Based on that I think what we want to
request is the following be added to the rules.
>
> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>
> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net

great, didn't know it is possible.

> chainsaw and log4j companions also show up on the main site. Do we also want those?

I think so. Imho we should start treat Chainsaw more as a product on
its own. Companions is small but we should treat it the same way. That
would ease things I think. But thats just my 2 cents.

Cheers
Christian

>
> Ralph
>
> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>
>> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>> I'm actually more concerned with us having to use svnpubsub
>>> (see http://www.apache.org/dev/project-site.html).  The maven team created a
>>> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>>> aid in this but I haven't tired it. I also understand that it requires the
>>> main website to have something done to it first.
>>
>> didn't know about the mvn plug - thanks!
>>
>>> Log4j2 uses the Maven site plugin so I guess I really need to know is what
>>> the location of the svn directory would be to pass to svnpubsub:prepare.
>>
>> What about:
>> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>>
>> For example:
>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>>
>> and so on
>>
>>
>>
>>
>>>
>>> Ralph
>>>
>>>
>>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>>>
>>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>> wrote:
>>>
>>> Do we have a process in place for updating the web site?  I'm trying to go
>>> through any issues that might exist with doing a release of Log4j2 and this
>>> is one of them.
>>>
>>>
>>> I am not aware of a specific process (old timers might want to correct me).
>>> So far I know we have updated the website whenever the release has
>>> been published. I am not a huge fan of restricting website updates to
>>> releases and think we should be able to update at any time we want.
>>>
>>> This again touches the question with pubsub. We need to make a
>>> decision if we move to mvn site:deploy or do something else.
>>>
>>> Cheers
>>> Christian
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>>
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 19 Apr 09:11 2012

Re: Logging web sites

Does anyone else have any other thoughts before I open an infra ticket?

Ralph

On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:

> On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> I'm OK with this, but I'm not sure if infra is OK with that structure. Based on that I think what we want to
request is the following be added to the rules.
>> 
>> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>> 
>> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
>> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
>> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
>> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
>> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
>> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net
> 
> great, didn't know it is possible.
> 
>> chainsaw and log4j companions also show up on the main site. Do we also want those?
> 
> I think so. Imho we should start treat Chainsaw more as a product on
> its own. Companions is small but we should treat it the same way. That
> would ease things I think. But thats just my 2 cents.
> 
> Cheers
> Christian
> 
>> 
>> Ralph
>> 
>> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>> 
>>> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>>> I'm actually more concerned with us having to use svnpubsub
>>>> (see http://www.apache.org/dev/project-site.html).  The maven team created a
>>>> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>>>> aid in this but I haven't tired it. I also understand that it requires the
>>>> main website to have something done to it first.
>>> 
>>> didn't know about the mvn plug - thanks!
>>> 
>>>> Log4j2 uses the Maven site plugin so I guess I really need to know is what
>>>> the location of the svn directory would be to pass to svnpubsub:prepare.
>>> 
>>> What about:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>>> 
>>> For example:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>>> 
>>> and so on
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>>>> 
>>>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>>> wrote:
>>>> 
>>>> Do we have a process in place for updating the web site?  I'm trying to go
>>>> through any issues that might exist with doing a release of Log4j2 and this
>>>> is one of them.
>>>> 
>>>> 
>>>> I am not aware of a specific process (old timers might want to correct me).
>>>> So far I know we have updated the website whenever the release has
>>>> been published. I am not a huge fan of restricting website updates to
>>>> releases and think we should be able to update at any time we want.
>>>> 
>>>> This again touches the question with pubsub. We need to make a
>>>> decision if we move to mvn site:deploy or do something else.
>>>> 
>>>> Cheers
>>>> Christian
>>>> 
>>>> 
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>> 
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de

Ivan Habunek | 19 Apr 10:10 2012
Picon

Re: Logging web sites

Sounds good to me. Having a separate folder (/site/main) for the main site is great. Currently it's in root and I'm not sure how I would go about updating it.


Regards,
Ivan

On 19 April 2012 09:11, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
Does anyone else have any other thoughts before I open an infra ticket?

Ralph

On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:

> On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> I'm OK with this, but I'm not sure if infra is OK with that structure. Based on that I think what we want to request is the following be added to the rules.
>>
>> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>>
>> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
>> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
>> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
>> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
>> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
>> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net
>
> great, didn't know it is possible.
>
>> chainsaw and log4j companions also show up on the main site. Do we also want those?
>
> I think so. Imho we should start treat Chainsaw more as a product on
> its own. Companions is small but we should treat it the same way. That
> would ease things I think. But thats just my 2 cents.
>
> Cheers
> Christian
>
>>
>> Ralph
>>
>> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>>
>>> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>>> I'm actually more concerned with us having to use svnpubsub
>>>> (see http://www.apache.org/dev/project-site.html).  The maven team created a
>>>> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>>>> aid in this but I haven't tired it. I also understand that it requires the
>>>> main website to have something done to it first.
>>>
>>> didn't know about the mvn plug - thanks!
>>>
>>>> Log4j2 uses the Maven site plugin so I guess I really need to know is what
>>>> the location of the svn directory would be to pass to svnpubsub:prepare.
>>>
>>> What about:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>>>
>>> For example:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>>>
>>> and so on
>>>
>>>
>>>
>>>
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>>>>
>>>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>>> wrote:
>>>>
>>>> Do we have a process in place for updating the web site?  I'm trying to go
>>>> through any issues that might exist with doing a release of Log4j2 and this
>>>> is one of them.
>>>>
>>>>
>>>> I am not aware of a specific process (old timers might want to correct me).
>>>> So far I know we have updated the website whenever the release has
>>>> been published. I am not a huge fan of restricting website updates to
>>>> releases and think we should be able to update at any time we want.
>>>>
>>>> This again touches the question with pubsub. We need to make a
>>>> decision if we move to mvn site:deploy or do something else.
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de


Ralph Goers | 20 Apr 19:27 2012

Re: Logging web sites

I've created https://issues.apache.org/jira/browse/INFRA-4699 and modeled it after Ant. That was the only project I know of that has sub sites.

Ralph

On Apr 19, 2012, at 1:10 AM, Ivan Habunek wrote:

Sounds good to me. Having a separate folder (/site/main) for the main site is great. Currently it's in root and I'm not sure how I would go about updating it.

Regards,
Ivan

On 19 April 2012 09:11, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
Does anyone else have any other thoughts before I open an infra ticket?

Ralph

On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:

> On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> I'm OK with this, but I'm not sure if infra is OK with that structure. Based on that I think what we want to request is the following be added to the rules.
>>
>> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>>
>> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
>> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
>> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
>> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
>> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
>> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net
>
> great, didn't know it is possible.
>
>> chainsaw and log4j companions also show up on the main site. Do we also want those?
>
> I think so. Imho we should start treat Chainsaw more as a product on
> its own. Companions is small but we should treat it the same way. That
> would ease things I think. But thats just my 2 cents.
>
> Cheers
> Christian
>
>>
>> Ralph
>>
>> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>>
>>> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>>> I'm actually more concerned with us having to use svnpubsub
>>>> (see http://www.apache.org/dev/project-site.html).  The maven team created a
>>>> plugin - http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>>>> aid in this but I haven't tired it. I also understand that it requires the
>>>> main website to have something done to it first.
>>>
>>> didn't know about the mvn plug - thanks!
>>>
>>>> Log4j2 uses the Maven site plugin so I guess I really need to know is what
>>>> the location of the svn directory would be to pass to svnpubsub:prepare.
>>>
>>> What about:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>>>
>>> For example:
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>>> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>>>
>>> and so on
>>>
>>>
>>>
>>>
>>>>
>>>> Ralph
>>>>
>>>>
>>>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>>>>
>>>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>>> wrote:
>>>>
>>>> Do we have a process in place for updating the web site?  I'm trying to go
>>>> through any issues that might exist with doing a release of Log4j2 and this
>>>> is one of them.
>>>>
>>>>
>>>> I am not aware of a specific process (old timers might want to correct me).
>>>> So far I know we have updated the website whenever the release has
>>>> been published. I am not a huge fan of restricting website updates to
>>>> releases and think we should be able to update at any time we want.
>>>>
>>>> This again touches the question with pubsub. We need to make a
>>>> decision if we move to mvn site:deploy or do something else.
>>>>
>>>> Cheers
>>>> Christian
>>>>
>>>>
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de



Christian Grobmeier | 20 Apr 20:14 2012
Picon

Re: Logging web sites

thank you Ralph!

On Fri, Apr 20, 2012 at 7:27 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> I've created https://issues.apache.org/jira/browse/INFRA-4699 and modeled it
> after Ant. That was the only project I know of that has sub sites.
>
> Ralph
>
>
> On Apr 19, 2012, at 1:10 AM, Ivan Habunek wrote:
>
> Sounds good to me. Having a separate folder (/site/main) for the main site
> is great. Currently it's in root and I'm not sure how I would go about
> updating it.
>
> Regards,
> Ivan
>
> On 19 April 2012 09:11, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>
>> Does anyone else have any other thoughts before I open an infra ticket?
>>
>> Ralph
>>
>> On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:
>>
>> > On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers
>> > <ralph.goers <at> dslextreme.com> wrote:
>> >> I'm OK with this, but I'm not sure if infra is OK with that structure.
>> >> Based on that I think what we want to request is the following be added to
>> >> the rules.
>> >>
>> >> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>> >>
>> >> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
>> >> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
>> >> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
>> >> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
>> >> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
>> >> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net
>> >
>> > great, didn't know it is possible.
>> >
>> >> chainsaw and log4j companions also show up on the main site. Do we also
>> >> want those?
>> >
>> > I think so. Imho we should start treat Chainsaw more as a product on
>> > its own. Companions is small but we should treat it the same way. That
>> > would ease things I think. But thats just my 2 cents.
>> >
>> > Cheers
>> > Christian
>> >
>> >>
>> >> Ralph
>> >>
>> >> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>> >>
>> >>> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers
>> >>> <ralph.goers <at> dslextreme.com> wrote:
>> >>>> I'm actually more concerned with us having to use svnpubsub
>> >>>> (see http://www.apache.org/dev/project-site.html).  The maven team
>> >>>> created a
>> >>>> plugin -
>> >>>> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>> >>>> aid in this but I haven't tired it. I also understand that it
>> >>>> requires the
>> >>>> main website to have something done to it first.
>> >>>
>> >>> didn't know about the mvn plug - thanks!
>> >>>
>> >>>> Log4j2 uses the Maven site plugin so I guess I really need to know is
>> >>>> what
>> >>>> the location of the svn directory would be to pass to
>> >>>> svnpubsub:prepare.
>> >>>
>> >>> What about:
>> >>> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>> >>>
>> >>> For example:
>> >>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>> >>> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>> >>> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>> >>>
>> >>> and so on
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> Ralph
>> >>>>
>> >>>>
>> >>>> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>> >>>>
>> >>>> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers
>> >>>> <ralph.goers <at> dslextreme.com>
>> >>>> wrote:
>> >>>>
>> >>>> Do we have a process in place for updating the web site?  I'm trying
>> >>>> to go
>> >>>> through any issues that might exist with doing a release of Log4j2
>> >>>> and this
>> >>>> is one of them.
>> >>>>
>> >>>>
>> >>>> I am not aware of a specific process (old timers might want to
>> >>>> correct me).
>> >>>> So far I know we have updated the website whenever the release has
>> >>>> been published. I am not a huge fan of restricting website updates to
>> >>>> releases and think we should be able to update at any time we want.
>> >>>>
>> >>>> This again touches the question with pubsub. We need to make a
>> >>>> decision if we move to mvn site:deploy or do something else.
>> >>>>
>> >>>> Cheers
>> >>>> Christian
>> >>>>
>> >>>>
>> >>>> --
>> >>>> http://www.grobmeier.de
>> >>>> https://www.timeandbill.de
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> http://www.grobmeier.de
>> >>> https://www.timeandbill.de
>> >>
>> >
>> >
>> >
>> > --
>> > http://www.grobmeier.de
>> > https://www.timeandbill.de
>>
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 20 Apr 20:46 2012

Re: Logging web sites

I had a conversation with Daniel.  From what I can tell the current Logging web site is maintained at https://svn.apache.org/repos/asf/logging/site/trunk/docs.  I've never maintained the logging web site but some of the sub projects there, such as log4j, were definitely built by Maven. What daniel is telling me is that as far as Infra is concerned we can continue to use that same location with svnpubsub.  However, editing the main site only would either require checking out all the subproject sites too or using svn checkout --depth=immediates.

My question is, how has the web site been maintained in the past?  

Ralph

On Apr 20, 2012, at 11:14 AM, Christian Grobmeier wrote:

thank you Ralph!

On Fri, Apr 20, 2012 at 7:27 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
I've created https://issues.apache.org/jira/browse/INFRA-4699 and modeled it
after Ant. That was the only project I know of that has sub sites.

Ralph


On Apr 19, 2012, at 1:10 AM, Ivan Habunek wrote:

Sounds good to me. Having a separate folder (/site/main) for the main site
is great. Currently it's in root and I'm not sure how I would go about
updating it.

Regards,
Ivan

On 19 April 2012 09:11, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:

Does anyone else have any other thoughts before I open an infra ticket?

Ralph

On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:

On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers
<ralph.goers <at> dslextreme.com> wrote:
I'm OK with this, but I'm not sure if infra is OK with that structure.
Based on that I think what we want to request is the following be added to
the rules.

/x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging

/x1/www/logging.apache.org: %(ASF)s/logging/site/main
/x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
/x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
/x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
/x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
/x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net

great, didn't know it is possible.

chainsaw and log4j companions also show up on the main site. Do we also
want those?

I think so. Imho we should start treat Chainsaw more as a product on
its own. Companions is small but we should treat it the same way. That
would ease things I think. But thats just my 2 cents.

Cheers
Christian


Ralph

On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:

On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers
<ralph.goers <at> dslextreme.com> wrote:
I'm actually more concerned with us having to use svnpubsub
(see http://www.apache.org/dev/project-site.html).  The maven team
created a
plugin -
http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
aid in this but I haven't tired it. I also understand that it
requires the
main website to have something done to it first.

didn't know about the mvn plug - thanks!

Log4j2 uses the Maven site plugin so I guess I really need to know is
what
the location of the svn directory would be to pass to
svnpubsub:prepare.

What about:
http://svn.apache.org/repos/asf/logging/site/pubsub/$project

For example:
http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)

and so on





Ralph


On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:

On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers
<ralph.goers <at> dslextreme.com>
wrote:

Do we have a process in place for updating the web site?  I'm trying
to go
through any issues that might exist with doing a release of Log4j2
and this
is one of them.


I am not aware of a specific process (old timers might want to
correct me).
So far I know we have updated the website whenever the release has
been published. I am not a huge fan of restricting website updates to
releases and think we should be able to update at any time we want.

This again touches the question with pubsub. We need to make a
decision if we move to mvn site:deploy or do something else.

Cheers
Christian


--
http://www.grobmeier.de
https://www.timeandbill.de





--
http://www.grobmeier.de
https://www.timeandbill.de




--
http://www.grobmeier.de
https://www.timeandbill.de






--
http://www.grobmeier.de
https://www.timeandbill.de

Christian Grobmeier | 20 Apr 21:14 2012
Picon

Re: Logging web sites

On Fri, Apr 20, 2012 at 8:46 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> I had a conversation with Daniel.  From what I can tell the current Logging
> web site is maintained at
> https://svn.apache.org/repos/asf/logging/site/trunk/docs.  I've never
> maintained the logging web site but some of the sub projects there, such as
> log4j, were definitely built by Maven. What daniel is telling me is that as
> far as Infra is concerned we can continue to use that same location with
> svnpubsub.  However, editing the main site only would either require
> checking out all the subproject sites too or using svn checkout
> --depth=immediates.
>
> My question is, how has the web site been maintained in the past?

I have no clue , never did it (the main site and log4j site). Maybe
Ivan can answer this i think he has he has digged that.

I found this:
http://svn.apache.org/repos/asf/logging/log4j/trunk/BUILD-INFO.txt

"
The website content will automatically be staged to the ASF SVN repo
by "mvn site-deploy".
This phase checks out
https://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2
into target/site-deploy, copys the generated documentation to that
directory using
scp to localhost and then commits the changed content.  You will be
prompted for an
SVN commit message using the configured SVN_EDITOR.  A commit message
must be entered or the
site commit will be aborted.

The staged content can be tested by opening
http://svn.apache.org/repos/asf/logging/site/trunk/docs/1.2/index.html,
however some links may be broken due to the staged location.
The staged version can be published to the main public site by executing
"svn update" in /www/logging.apache.org/log4j/1.2 on people.apache.org.
"

What i thought was, why not to clean it up? Your proposed solutions
seem to be the cleanest way and updating everything just when we need
an update to the main site feels somehow wrong

Cheers

>
> Ralph
>
> On Apr 20, 2012, at 11:14 AM, Christian Grobmeier wrote:
>
> thank you Ralph!
>
> On Fri, Apr 20, 2012 at 7:27 PM, Ralph Goers <ralph.goers <at> dslextreme.com>
> wrote:
>
> I've created https://issues.apache.org/jira/browse/INFRA-4699 and modeled it
>
> after Ant. That was the only project I know of that has sub sites.
>
>
> Ralph
>
>
>
> On Apr 19, 2012, at 1:10 AM, Ivan Habunek wrote:
>
>
> Sounds good to me. Having a separate folder (/site/main) for the main site
>
> is great. Currently it's in root and I'm not sure how I would go about
>
> updating it.
>
>
> Regards,
>
> Ivan
>
>
> On 19 April 2012 09:11, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
>
> Does anyone else have any other thoughts before I open an infra ticket?
>
>
> Ralph
>
>
> On Apr 18, 2012, at 10:20 PM, Christian Grobmeier wrote:
>
>
> On Tue, Apr 17, 2012 at 9:47 PM, Ralph Goers
>
> <ralph.goers <at> dslextreme.com> wrote:
>
> I'm OK with this, but I'm not sure if infra is OK with that structure.
>
> Based on that I think what we want to request is the following be added to
>
> the rules.
>
>
> /x1/www/www.apache.org/dist/logging: %(DIST)s/release/logging
>
>
> /x1/www/logging.apache.org: %(ASF)s/logging/site/main
>
> /x1/www/logging.apache.org/log4j: %(ASF)s/logging/site/log4j
>
> /x1/www/logging.apache.org/log4j2: %(ASF)s/logging/site/log4j2
>
> /x1/www/logging.apache.org/log4php: %(ASF)s/logging/site/log4php
>
> /x1/www/logging.apache.org/log4cxx: %(ASF)s/logging/site/log4cxx
>
> /x1/www/logging.apache.org/log4net: %(ASF)s/logging/site/log4net
>
>
> great, didn't know it is possible.
>
>
> chainsaw and log4j companions also show up on the main site. Do we also
>
> want those?
>
>
> I think so. Imho we should start treat Chainsaw more as a product on
>
> its own. Companions is small but we should treat it the same way. That
>
> would ease things I think. But thats just my 2 cents.
>
>
> Cheers
>
> Christian
>
>
>
> Ralph
>
>
> On Apr 16, 2012, at 12:37 AM, Christian Grobmeier wrote:
>
>
> On Mon, Apr 16, 2012 at 9:31 AM, Ralph Goers
>
> <ralph.goers <at> dslextreme.com> wrote:
>
> I'm actually more concerned with us having to use svnpubsub
>
> (see http://www.apache.org/dev/project-site.html).  The maven team
>
> created a
>
> plugin -
>
> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/  to
>
> aid in this but I haven't tired it. I also understand that it
>
> requires the
>
> main website to have something done to it first.
>
>
> didn't know about the mvn plug - thanks!
>
>
> Log4j2 uses the Maven site plugin so I guess I really need to know is
>
> what
>
> the location of the svn directory would be to pass to
>
> svnpubsub:prepare.
>
>
> What about:
>
> http://svn.apache.org/repos/asf/logging/site/pubsub/$project
>
>
> For example:
>
> http://svn.apache.org/repos/asf/logging/site/pubsub/log4j2
>
> http://svn.apache.org/repos/asf/logging/site/pubsub/log4php
>
> http://svn.apache.org/repos/asf/logging/site/pubsub/main (start site)
>
>
> and so on
>
>
>
>
>
>
> Ralph
>
>
>
> On Apr 16, 2012, at 12:14 AM, Christian Grobmeier wrote:
>
>
> On Mon, Apr 16, 2012 at 6:38 AM, Ralph Goers
>
> <ralph.goers <at> dslextreme.com>
>
> wrote:
>
>
> Do we have a process in place for updating the web site?  I'm trying
>
> to go
>
> through any issues that might exist with doing a release of Log4j2
>
> and this
>
> is one of them.
>
>
>
> I am not aware of a specific process (old timers might want to
>
> correct me).
>
> So far I know we have updated the website whenever the release has
>
> been published. I am not a huge fan of restricting website updates to
>
> releases and think we should be able to update at any time we want.
>
>
> This again touches the question with pubsub. We need to make a
>
> decision if we move to mvn site:deploy or do something else.
>
>
> Cheers
>
> Christian
>
>
>
> --
>
> http://www.grobmeier.de
>
> https://www.timeandbill.de
>
>
>
>
>
>
> --
>
> http://www.grobmeier.de
>
> https://www.timeandbill.de
>
>
>
>
>
> --
>
> http://www.grobmeier.de
>
> https://www.timeandbill.de
>
>
>
>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 20 Apr 22:33 2012

Re: Logging web sites


On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:

> On Fri, Apr 20, 2012 at 8:46 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> I had a conversation with Daniel.  From what I can tell the current Logging
>> web site is maintained at
>> https://svn.apache.org/repos/asf/logging/site/trunk/docs.  I've never
>> maintained the logging web site but some of the sub projects there, such as
>> log4j, were definitely built by Maven. What daniel is telling me is that as
>> far as Infra is concerned we can continue to use that same location with
>> svnpubsub.  However, editing the main site only would either require
>> checking out all the subproject sites too or using svn checkout
>> --depth=immediates.
>> 
>> My question is, how has the web site been maintained in the past?
> 
> I have no clue , never did it (the main site and log4j site). Maybe
> Ivan can answer this i think he has he has digged that.
> 
> I found this:
> http://svn.apache.org/repos/asf/logging/log4j/trunk/BUILD-INFO.txt
> 
> "
> The website content will automatically be staged to the ASF SVN repo
> by "mvn site-deploy".
> This phase checks out
> https://svn.apache.org/repos/asf/logging/site/trunk/docs/log4j/1.2
> into target/site-deploy, copys the generated documentation to that
> directory using
> scp to localhost and then commits the changed content.  You will be
> prompted for an
> SVN commit message using the configured SVN_EDITOR.  A commit message
> must be entered or the
> site commit will be aborted.

Gee - this sounds a lot like what the svnpubsub plugin does.

> 
> The staged content can be tested by opening
> http://svn.apache.org/repos/asf/logging/site/trunk/docs/1.2/index.html,
> however some links may be broken due to the staged location.
> The staged version can be published to the main public site by executing
> "svn update" in /www/logging.apache.org/log4j/1.2 on people.apache.org.
> "
> 

This part will be automatic once infra creates the link.

> 
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
> 

Yeah - but infra would prefer that they not have to maintain multiple links per project.  I would suggest you
jump on #infra and speak with danielsh or update the Jira issue.

Ralph

Ralph Goers | 23 Apr 04:06 2012

Re: Logging web sites


On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:


What i thought was, why not to clean it up? Your proposed solutions
seem to be the cleanest way and updating everything just when we need
an update to the main site feels somehow wrong

Joe has now proposed using the CMS for the main Logging web site along with expaths.txt + svnpubsub for each sub-project. Each sub-project would then use svn externals so they could be independently managed. This sounds perfect to me.

Ralph 
Christian Grobmeier | 2 May 10:44 2012
Picon

Re: Logging web sites

On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>
>
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
>
>
> Joe has now proposed using the CMS for the main Logging web site along
> with expaths.txt + svnpubsub for each sub-project. Each sub-project would
> then use svn externals so they could be independently managed. This sounds
> perfect to me.

OK I understand svn externals is like "symlinks for svn". Sounds ok.

I am a bit concerned on the CMS. Ivan has put much effort in the website design:
http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

I will ask infra (on the ticket) if it is possible to either use that
design for the CMS or if we can bypass the CMS feature for this one
too...

Cheers
Christian

> Ralph

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ivan Habunek | 2 May 11:11 2012
Picon

Re: Logging web sites

Hi all, 


I was away for a bit so I didn't comment earlier. 

My idea is to generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...).

I have already converted the logging web site. The code can be found here:

And I have deployed the generated web for demo here:

This idea is obviously not compatible with the Apache CMS solution. Frankly, I would prefer this solution to the CMS since, from what I have seen, the CMS is quite a pain to use.

Regards,
Ivan



On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>
>
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
>
>
> Joe has now proposed using the CMS for the main Logging web site along
> with expaths.txt + svnpubsub for each sub-project. Each sub-project would
> then use svn externals so they could be independently managed. This sounds
> perfect to me.

OK I understand svn externals is like "symlinks for svn". Sounds ok.

I am a bit concerned on the CMS. Ivan has put much effort in the website design:
http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

I will ask infra (on the ticket) if it is possible to either use that
design for the CMS or if we can bypass the CMS feature for this one
too...

Cheers
Christian


> Ralph

Ralph Goers | 18 May 17:54 2012

Re: Logging web sites

This topic has died down a bit.  My concern here is that I am pretty much read to do a release of Log4j 2 but I really don't know how to publish the web site. The process I use to build Log4j 2 is

1. Check it out from SVN.
2. Run "mvn -P release-notes generate-resources (then commit the generated notes for a real release).
3. Run "mvn -P apache-release install  (this step would be replaced by mvn release:prepare release:package in a real release)
4. Run mvn site (would be on the tagged branch).
5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site somewhere.

I'm imagining that I would need to use the maven-site-scm-publish plugin to commit the site to where it needs to go but we haven't agreed on what to tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.  

I'm not really sure where to go from here.

Ralph

On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:

Hi all, 

I was away for a bit so I didn't comment earlier. 

My idea is to generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...).

I have already converted the logging web site. The code can be found here:

And I have deployed the generated web for demo here:

This idea is obviously not compatible with the Apache CMS solution. Frankly, I would prefer this solution to the CMS since, from what I have seen, the CMS is quite a pain to use.

Regards,
Ivan



On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>
>
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
>
>
> Joe has now proposed using the CMS for the main Logging web site along
> with expaths.txt + svnpubsub for each sub-project. Each sub-project would
> then use svn externals so they could be independently managed. This sounds
> perfect to me.

OK I understand svn externals is like "symlinks for svn". Sounds ok.

I am a bit concerned on the CMS. Ivan has put much effort in the website design:
http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

I will ask infra (on the ticket) if it is possible to either use that
design for the CMS or if we can bypass the CMS feature for this one
too...

Cheers
Christian


> Ralph


Christian Grobmeier | 19 May 17:30 2012
Picon

Re: Logging web sites

On Fri, May 18, 2012 at 5:54 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> This topic has died down a bit.  My concern here is that I am pretty much
> read to do a release of Log4j 2 but I really don't know how to publish the
> web site. The process I use to build Log4j 2 is

Thanks for brining up the topic again.

> 1. Check it out from SVN.
> 2. Run "mvn -P release-notes generate-resources (then commit the generated
> notes for a real release).
> 3. Run "mvn -P apache-release install  (this step would be replaced by mvn
> release:prepare release:package in a real release)
> 4. Run mvn site (would be on the tagged branch).
> 5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site
> somewhere.
>
> I'm imagining that I would need to use the maven-site-scm-publish plugin to
> commit the site to where it needs to go but we haven't agreed on what to
> tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.
>
> I'm not really sure where to go from here.

Me either :-|

Lets sum up what we have now:
- log4j1 does "mvn site" to localhost and then commits the generated
file to svn trunk. From there it will be taken with "svn up". This
process does not work well with pubsub because changes are visible
instantly. It needs to be changed.

- log4j2 seem to do everything locally and just upload the generated
files to either a staging folder or the real folder. This is my
preferred approach

- log4php does it (if i remember correctly) like log4j2

- I don't know bout the other logging sites.

- Infra wants to see svnpubsub in action or that we use the CMS

Honestly my preferred approach is to have the rules in place you
mentioned in the issue. Ivans new main site is so simple, it really
does not need a CMS. The other pages should be taken with maven, as
usual.

That being said, it seems there is a maven plugin which works with the
CMS. Even when I really have no fun trying out the CMS, we might ask
if we can get some kind of a sandbox to try it out. Probably we can
work as we always did and we don't need to use the CMS interface
directly.

If we can use the CMS, we need to touch all pom files to enable it.
Basically it looks pretty straightforward, just moving the site-folder
to $project/content

So, how about asking about getting access to a sandbox CMS and trying
the maven build?

Cheers
Christian

>
> Ralph
>
> On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:
>
> Hi all,
>
> I was away for a bit so I didn't comment earlier.
>
> My idea is to generate the site using Twig [1], a nice PHP templating
> engine, in combination with Textile markup [2], which is much more versatile
> than most other common markup languages (such as markdown, apt, ...).
>
> I have already converted the logging web site. The code can be found here:
> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
>
> And I have deployed the generated web for demo here:
> http://bezdomni.net/logging/
>
> This idea is obviously not compatible with the Apache CMS solution. Frankly,
> I would prefer this solution to the CMS since, from what I have seen, the
> CMS is quite a pain to use.
>
> Regards,
> Ivan
>
> [1] http://twig.sensiolabs.org/
> [2] http://textile.sitemonks.com/
>
>
> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>>
>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>> wrote:
>> >
>> > On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>> >
>> >
>> > What i thought was, why not to clean it up? Your proposed solutions
>> > seem to be the cleanest way and updating everything just when we need
>> > an update to the main site feels somehow wrong
>> >
>> >
>> > Joe has now proposed using the CMS for the main Logging web site along
>> > with expaths.txt + svnpubsub for each sub-project. Each sub-project
>> > would
>> > then use svn externals so they could be independently managed. This
>> > sounds
>> > perfect to me.
>>
>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
>>
>> I am a bit concerned on the CMS. Ivan has put much effort in the website
>> design:
>>
>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
>>
>> I will ask infra (on the ticket) if it is possible to either use that
>> design for the CMS or if we can bypass the CMS feature for this one
>> too...
>>
>> Cheers
>> Christian
>>
>>
>> > Ralph
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Christian Grobmeier | 19 May 18:12 2012
Picon

Re: Logging web sites

I just found this:
http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/index.html

Did we consider that one? It looks nice and integrates well with
maven. It seems to checkout a specific url from svn, compares it with
the locally generated site and then commits a diff to the publishing
tree. From there its taken by svnpubsub.

From what I understood so far, it should be easiest to use that
plugin. We would need to check out every site with every change, but
as the pubsub works on a separate tree, i think its no problem.

WDYT?

On Sat, May 19, 2012 at 5:30 PM, Christian Grobmeier
<grobmeier <at> gmail.com> wrote:
> On Fri, May 18, 2012 at 5:54 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> This topic has died down a bit.  My concern here is that I am pretty much
>> read to do a release of Log4j 2 but I really don't know how to publish the
>> web site. The process I use to build Log4j 2 is
>
> Thanks for brining up the topic again.
>
>> 1. Check it out from SVN.
>> 2. Run "mvn -P release-notes generate-resources (then commit the generated
>> notes for a real release).
>> 3. Run "mvn -P apache-release install  (this step would be replaced by mvn
>> release:prepare release:package in a real release)
>> 4. Run mvn site (would be on the tagged branch).
>> 5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site
>> somewhere.
>>
>> I'm imagining that I would need to use the maven-site-scm-publish plugin to
>> commit the site to where it needs to go but we haven't agreed on what to
>> tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.
>>
>> I'm not really sure where to go from here.
>
> Me either :-|
>
> Lets sum up what we have now:
> - log4j1 does "mvn site" to localhost and then commits the generated
> file to svn trunk. From there it will be taken with "svn up". This
> process does not work well with pubsub because changes are visible
> instantly. It needs to be changed.
>
> - log4j2 seem to do everything locally and just upload the generated
> files to either a staging folder or the real folder. This is my
> preferred approach
>
> - log4php does it (if i remember correctly) like log4j2
>
> - I don't know bout the other logging sites.
>
> - Infra wants to see svnpubsub in action or that we use the CMS
>
>
> Honestly my preferred approach is to have the rules in place you
> mentioned in the issue. Ivans new main site is so simple, it really
> does not need a CMS. The other pages should be taken with maven, as
> usual.
>
> That being said, it seems there is a maven plugin which works with the
> CMS. Even when I really have no fun trying out the CMS, we might ask
> if we can get some kind of a sandbox to try it out. Probably we can
> work as we always did and we don't need to use the CMS interface
> directly.
>
> If we can use the CMS, we need to touch all pom files to enable it.
> Basically it looks pretty straightforward, just moving the site-folder
> to $project/content
>
> So, how about asking about getting access to a sandbox CMS and trying
> the maven build?
>
> Cheers
> Christian
>
>
>
>>
>> Ralph
>>
>> On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:
>>
>> Hi all,
>>
>> I was away for a bit so I didn't comment earlier.
>>
>> My idea is to generate the site using Twig [1], a nice PHP templating
>> engine, in combination with Textile markup [2], which is much more versatile
>> than most other common markup languages (such as markdown, apt, ...).
>>
>> I have already converted the logging web site. The code can be found here:
>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
>>
>> And I have deployed the generated web for demo here:
>> http://bezdomni.net/logging/
>>
>> This idea is obviously not compatible with the Apache CMS solution. Frankly,
>> I would prefer this solution to the CMS since, from what I have seen, the
>> CMS is quite a pain to use.
>>
>> Regards,
>> Ivan
>>
>> [1] http://twig.sensiolabs.org/
>> [2] http://textile.sitemonks.com/
>>
>>
>> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>>>
>>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>> wrote:
>>> >
>>> > On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>>> >
>>> >
>>> > What i thought was, why not to clean it up? Your proposed solutions
>>> > seem to be the cleanest way and updating everything just when we need
>>> > an update to the main site feels somehow wrong
>>> >
>>> >
>>> > Joe has now proposed using the CMS for the main Logging web site along
>>> > with expaths.txt + svnpubsub for each sub-project. Each sub-project
>>> > would
>>> > then use svn externals so they could be independently managed. This
>>> > sounds
>>> > perfect to me.
>>>
>>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
>>>
>>> I am a bit concerned on the CMS. Ivan has put much effort in the website
>>> design:
>>>
>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
>>>
>>> I will ask infra (on the ticket) if it is possible to either use that
>>> design for the CMS or if we can bypass the CMS feature for this one
>>> too...
>>>
>>> Cheers
>>> Christian
>>>
>>>
>>> > Ralph
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>
>>
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 19 May 22:33 2012
Picon

Re: Logging web sites

My understanding is the asf-svnpubsub-plugin is the predecessor to the maven-site-scm-plugin that I mentioned.

Ralph

On May 19, 2012, at 9:12 AM, Christian Grobmeier <grobmeier <at> gmail.com> wrote:

> I just found this:
> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/index.html
> 
> Did we consider that one? It looks nice and integrates well with
> maven. It seems to checkout a specific url from svn, compares it with
> the locally generated site and then commits a diff to the publishing
> tree. From there its taken by svnpubsub.
> 
> From what I understood so far, it should be easiest to use that
> plugin. We would need to check out every site with every change, but
> as the pubsub works on a separate tree, i think its no problem.
> 
> WDYT?
> 
> On Sat, May 19, 2012 at 5:30 PM, Christian Grobmeier
> <grobmeier <at> gmail.com> wrote:
>> On Fri, May 18, 2012 at 5:54 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>> This topic has died down a bit.  My concern here is that I am pretty much
>>> read to do a release of Log4j 2 but I really don't know how to publish the
>>> web site. The process I use to build Log4j 2 is
>> 
>> Thanks for brining up the topic again.
>> 
>>> 1. Check it out from SVN.
>>> 2. Run "mvn -P release-notes generate-resources (then commit the generated
>>> notes for a real release).
>>> 3. Run "mvn -P apache-release install  (this step would be replaced by mvn
>>> release:prepare release:package in a real release)
>>> 4. Run mvn site (would be on the tagged branch).
>>> 5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site
>>> somewhere.
>>> 
>>> I'm imagining that I would need to use the maven-site-scm-publish plugin to
>>> commit the site to where it needs to go but we haven't agreed on what to
>>> tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.
>>> 
>>> I'm not really sure where to go from here.
>> 
>> Me either :-|
>> 
>> Lets sum up what we have now:
>> - log4j1 does "mvn site" to localhost and then commits the generated
>> file to svn trunk. From there it will be taken with "svn up". This
>> process does not work well with pubsub because changes are visible
>> instantly. It needs to be changed.
>> 
>> - log4j2 seem to do everything locally and just upload the generated
>> files to either a staging folder or the real folder. This is my
>> preferred approach
>> 
>> - log4php does it (if i remember correctly) like log4j2
>> 
>> - I don't know bout the other logging sites.
>> 
>> - Infra wants to see svnpubsub in action or that we use the CMS
>> 
>> 
>> Honestly my preferred approach is to have the rules in place you
>> mentioned in the issue. Ivans new main site is so simple, it really
>> does not need a CMS. The other pages should be taken with maven, as
>> usual.
>> 
>> That being said, it seems there is a maven plugin which works with the
>> CMS. Even when I really have no fun trying out the CMS, we might ask
>> if we can get some kind of a sandbox to try it out. Probably we can
>> work as we always did and we don't need to use the CMS interface
>> directly.
>> 
>> If we can use the CMS, we need to touch all pom files to enable it.
>> Basically it looks pretty straightforward, just moving the site-folder
>> to $project/content
>> 
>> So, how about asking about getting access to a sandbox CMS and trying
>> the maven build?
>> 
>> Cheers
>> Christian
>> 
>> 
>> 
>>> 
>>> Ralph
>>> 
>>> On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:
>>> 
>>> Hi all,
>>> 
>>> I was away for a bit so I didn't comment earlier.
>>> 
>>> My idea is to generate the site using Twig [1], a nice PHP templating
>>> engine, in combination with Textile markup [2], which is much more versatile
>>> than most other common markup languages (such as markdown, apt, ...).
>>> 
>>> I have already converted the logging web site. The code can be found here:
>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
>>> 
>>> And I have deployed the generated web for demo here:
>>> http://bezdomni.net/logging/
>>> 
>>> This idea is obviously not compatible with the Apache CMS solution. Frankly,
>>> I would prefer this solution to the CMS since, from what I have seen, the
>>> CMS is quite a pain to use.
>>> 
>>> Regards,
>>> Ivan
>>> 
>>> [1] http://twig.sensiolabs.org/
>>> [2] http://textile.sitemonks.com/
>>> 
>>> 
>>> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>>>> 
>>>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>>> wrote:
>>>>> 
>>>>> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>>>>> 
>>>>> 
>>>>> What i thought was, why not to clean it up? Your proposed solutions
>>>>> seem to be the cleanest way and updating everything just when we need
>>>>> an update to the main site feels somehow wrong
>>>>> 
>>>>> 
>>>>> Joe has now proposed using the CMS for the main Logging web site along
>>>>> with expaths.txt + svnpubsub for each sub-project. Each sub-project
>>>>> would
>>>>> then use svn externals so they could be independently managed. This
>>>>> sounds
>>>>> perfect to me.
>>>> 
>>>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
>>>> 
>>>> I am a bit concerned on the CMS. Ivan has put much effort in the website
>>>> design:
>>>> 
>>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
>>>> 
>>>> I will ask infra (on the ticket) if it is possible to either use that
>>>> design for the CMS or if we can bypass the CMS feature for this one
>>>> too...
>>>> 
>>>> Cheers
>>>> Christian
>>>> 
>>>> 
>>>>> Ralph
>>>> 
>>>> 
>>>> 
>>>> --
>>>> http://www.grobmeier.de
>>>> https://www.timeandbill.de
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de

Ralph Goers | 19 May 22:35 2012
Picon

Re: Logging web sites

Oops. I meant maven-site-scm-publish plugin

Ralph

On May 19, 2012, at 1:33 PM, Ralph Goers <rgoers <at> apache.org> wrote:

> My understanding is the asf-svnpubsub-plugin is the predecessor to the maven-site-scm-plugin that I mentioned.
> 
> Ralph
> 
> On May 19, 2012, at 9:12 AM, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
> 
>> I just found this:
>> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/index.html
>> 
>> Did we consider that one? It looks nice and integrates well with
>> maven. It seems to checkout a specific url from svn, compares it with
>> the locally generated site and then commits a diff to the publishing
>> tree. From there its taken by svnpubsub.
>> 
>> From what I understood so far, it should be easiest to use that
>> plugin. We would need to check out every site with every change, but
>> as the pubsub works on a separate tree, i think its no problem.
>> 
>> WDYT?
>> 
>> On Sat, May 19, 2012 at 5:30 PM, Christian Grobmeier
>> <grobmeier <at> gmail.com> wrote:
>>> On Fri, May 18, 2012 at 5:54 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>>> This topic has died down a bit.  My concern here is that I am pretty much
>>>> read to do a release of Log4j 2 but I really don't know how to publish the
>>>> web site. The process I use to build Log4j 2 is
>>> 
>>> Thanks for brining up the topic again.
>>> 
>>>> 1. Check it out from SVN.
>>>> 2. Run "mvn -P release-notes generate-resources (then commit the generated
>>>> notes for a real release).
>>>> 3. Run "mvn -P apache-release install  (this step would be replaced by mvn
>>>> release:prepare release:package in a real release)
>>>> 4. Run mvn site (would be on the tagged branch).
>>>> 5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site
>>>> somewhere.
>>>> 
>>>> I'm imagining that I would need to use the maven-site-scm-publish plugin to
>>>> commit the site to where it needs to go but we haven't agreed on what to
>>>> tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.
>>>> 
>>>> I'm not really sure where to go from here.
>>> 
>>> Me either :-|
>>> 
>>> Lets sum up what we have now:
>>> - log4j1 does "mvn site" to localhost and then commits the generated
>>> file to svn trunk. From there it will be taken with "svn up". This
>>> process does not work well with pubsub because changes are visible
>>> instantly. It needs to be changed.
>>> 
>>> - log4j2 seem to do everything locally and just upload the generated
>>> files to either a staging folder or the real folder. This is my
>>> preferred approach
>>> 
>>> - log4php does it (if i remember correctly) like log4j2
>>> 
>>> - I don't know bout the other logging sites.
>>> 
>>> - Infra wants to see svnpubsub in action or that we use the CMS
>>> 
>>> 
>>> Honestly my preferred approach is to have the rules in place you
>>> mentioned in the issue. Ivans new main site is so simple, it really
>>> does not need a CMS. The other pages should be taken with maven, as
>>> usual.
>>> 
>>> That being said, it seems there is a maven plugin which works with the
>>> CMS. Even when I really have no fun trying out the CMS, we might ask
>>> if we can get some kind of a sandbox to try it out. Probably we can
>>> work as we always did and we don't need to use the CMS interface
>>> directly.
>>> 
>>> If we can use the CMS, we need to touch all pom files to enable it.
>>> Basically it looks pretty straightforward, just moving the site-folder
>>> to $project/content
>>> 
>>> So, how about asking about getting access to a sandbox CMS and trying
>>> the maven build?
>>> 
>>> Cheers
>>> Christian
>>> 
>>> 
>>> 
>>>> 
>>>> Ralph
>>>> 
>>>> On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I was away for a bit so I didn't comment earlier.
>>>> 
>>>> My idea is to generate the site using Twig [1], a nice PHP templating
>>>> engine, in combination with Textile markup [2], which is much more versatile
>>>> than most other common markup languages (such as markdown, apt, ...).
>>>> 
>>>> I have already converted the logging web site. The code can be found here:
>>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
>>>> 
>>>> And I have deployed the generated web for demo here:
>>>> http://bezdomni.net/logging/
>>>> 
>>>> This idea is obviously not compatible with the Apache CMS solution. Frankly,
>>>> I would prefer this solution to the CMS since, from what I have seen, the
>>>> CMS is quite a pain to use.
>>>> 
>>>> Regards,
>>>> Ivan
>>>> 
>>>> [1] http://twig.sensiolabs.org/
>>>> [2] http://textile.sitemonks.com/
>>>> 
>>>> 
>>>> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>>>>> 
>>>>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>>>> wrote:
>>>>>> 
>>>>>> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>>>>>> 
>>>>>> 
>>>>>> What i thought was, why not to clean it up? Your proposed solutions
>>>>>> seem to be the cleanest way and updating everything just when we need
>>>>>> an update to the main site feels somehow wrong
>>>>>> 
>>>>>> 
>>>>>> Joe has now proposed using the CMS for the main Logging web site along
>>>>>> with expaths.txt + svnpubsub for each sub-project. Each sub-project
>>>>>> would
>>>>>> then use svn externals so they could be independently managed. This
>>>>>> sounds
>>>>>> perfect to me.
>>>>> 
>>>>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
>>>>> 
>>>>> I am a bit concerned on the CMS. Ivan has put much effort in the website
>>>>> design:
>>>>> 
>>>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
>>>>> 
>>>>> I will ask infra (on the ticket) if it is possible to either use that
>>>>> design for the CMS or if we can bypass the CMS feature for this one
>>>>> too...
>>>>> 
>>>>> Cheers
>>>>> Christian
>>>>> 
>>>>> 
>>>>>> Ralph
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>> 
>> 
>> 
>> -- 
>> http://www.grobmeier.de
>> https://www.timeandbill.de

Christian Grobmeier | 19 May 23:35 2012
Picon

Re: Logging web sites


On May 19, 2012 10:35 PM, "Ralph Goers" <rgoers <at> apache.org> wrote:
>
> Oops. I meant maven-site-scm-publish plugin
>
> Ralph
>
> On May 19, 2012, at 1:33 PM, Ralph Goers <rgoers <at> apache.org> wrote:
>
> > My understanding is the asf-svnpubsub-plugin is the predecessor to the maven-site-scm-plugin that I mentioned.

It starts to make sense :-)
Looking at the plug its in sandbox but might be useable already. Actually it feels pretty comfortable to me assuming it works.

Do we have an issue using unreleased code for building our sites?

> > Ralph
> >
> > On May 19, 2012, at 9:12 AM, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
> >
> >> I just found this:
> >> http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/index.html
> >>
> >> Did we consider that one? It looks nice and integrates well with
> >> maven. It seems to checkout a specific url from svn, compares it with
> >> the locally generated site and then commits a diff to the publishing
> >> tree. From there its taken by svnpubsub.
> >>
> >> From what I understood so far, it should be easiest to use that
> >> plugin. We would need to check out every site with every change, but
> >> as the pubsub works on a separate tree, i think its no problem.
> >>
> >> WDYT?
> >>
> >> On Sat, May 19, 2012 at 5:30 PM, Christian Grobmeier
> >> <grobmeier <at> gmail.com> wrote:
> >>> On Fri, May 18, 2012 at 5:54 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> >>>> This topic has died down a bit.  My concern here is that I am pretty much
> >>>> read to do a release of Log4j 2 but I really don't know how to publish the
> >>>> web site. The process I use to build Log4j 2 is
> >>>
> >>> Thanks for brining up the topic again.
> >>>
> >>>> 1. Check it out from SVN.
> >>>> 2. Run "mvn -P release-notes generate-resources (then commit the generated
> >>>> notes for a real release).
> >>>> 3. Run "mvn -P apache-release install  (this step would be replaced by mvn
> >>>> release:prepare release:package in a real release)
> >>>> 4. Run mvn site (would be on the tagged branch).
> >>>> 5. Run mvn site:stage-deploy or mvn site:deploy to deploy the site
> >>>> somewhere.
> >>>>
> >>>> I'm imagining that I would need to use the maven-site-scm-publish plugin to
> >>>> commit the site to where it needs to go but we haven't agreed on what to
> >>>> tell INFRA regarding https://issues.apache.org/jira/browse/INFRA-4699.
> >>>>
> >>>> I'm not really sure where to go from here.
> >>>
> >>> Me either :-|
> >>>
> >>> Lets sum up what we have now:
> >>> - log4j1 does "mvn site" to localhost and then commits the generated
> >>> file to svn trunk. From there it will be taken with "svn up". This
> >>> process does not work well with pubsub because changes are visible
> >>> instantly. It needs to be changed.
> >>>
> >>> - log4j2 seem to do everything locally and just upload the generated
> >>> files to either a staging folder or the real folder. This is my
> >>> preferred approach
> >>>
> >>> - log4php does it (if i remember correctly) like log4j2
> >>>
> >>> - I don't know bout the other logging sites.
> >>>
> >>> - Infra wants to see svnpubsub in action or that we use the CMS
> >>>
> >>>
> >>> Honestly my preferred approach is to have the rules in place you
> >>> mentioned in the issue. Ivans new main site is so simple, it really
> >>> does not need a CMS. The other pages should be taken with maven, as
> >>> usual.
> >>>
> >>> That being said, it seems there is a maven plugin which works with the
> >>> CMS. Even when I really have no fun trying out the CMS, we might ask
> >>> if we can get some kind of a sandbox to try it out. Probably we can
> >>> work as we always did and we don't need to use the CMS interface
> >>> directly.
> >>>
> >>> If we can use the CMS, we need to touch all pom files to enable it.
> >>> Basically it looks pretty straightforward, just moving the site-folder
> >>> to $project/content
> >>>
> >>> So, how about asking about getting access to a sandbox CMS and trying
> >>> the maven build?
> >>>
> >>> Cheers
> >>> Christian
> >>>
> >>>
> >>>
> >>>>
> >>>> Ralph
> >>>>
> >>>> On May 2, 2012, at 2:11 AM, Ivan Habunek wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I was away for a bit so I didn't comment earlier.
> >>>>
> >>>> My idea is to generate the site using Twig [1], a nice PHP templating
> >>>> engine, in combination with Textile markup [2], which is much more versatile
> >>>> than most other common markup languages (such as markdown, apt, ...).
> >>>>
> >>>> I have already converted the logging web site. The code can be found here:
> >>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
> >>>>
> >>>> And I have deployed the generated web for demo here:
> >>>> http://bezdomni.net/logging/
> >>>>
> >>>> This idea is obviously not compatible with the Apache CMS solution. Frankly,
> >>>> I would prefer this solution to the CMS since, from what I have seen, the
> >>>> CMS is quite a pain to use.
> >>>>
> >>>> Regards,
> >>>> Ivan
> >>>>
> >>>> [1] http://twig.sensiolabs.org/
> >>>> [2] http://textile.sitemonks.com/
> >>>>
> >>>>
> >>>> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
> >>>>>
> >>>>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
> >>>>>>
> >>>>>>
> >>>>>> What i thought was, why not to clean it up? Your proposed solutions
> >>>>>> seem to be the cleanest way and updating everything just when we need
> >>>>>> an update to the main site feels somehow wrong
> >>>>>>
> >>>>>>
> >>>>>> Joe has now proposed using the CMS for the main Logging web site along
> >>>>>> with expaths.txt + svnpubsub for each sub-project. Each sub-project
> >>>>>> would
> >>>>>> then use svn externals so they could be independently managed. This
> >>>>>> sounds
> >>>>>> perfect to me.
> >>>>>
> >>>>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
> >>>>>
> >>>>> I am a bit concerned on the CMS. Ivan has put much effort in the website
> >>>>> design:
> >>>>>
> >>>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
> >>>>>
> >>>>> I will ask infra (on the ticket) if it is possible to either use that
> >>>>> design for the CMS or if we can bypass the CMS feature for this one
> >>>>> too...
> >>>>>
> >>>>> Cheers
> >>>>> Christian
> >>>>>
> >>>>>
> >>>>>> Ralph
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://www.grobmeier.de
> >>>>> https://www.timeandbill.de
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.grobmeier.de
> >>> https://www.timeandbill.de
> >>
> >>
> >>
> >> --
> >> http://www.grobmeier.de
> >> https://www.timeandbill.de

Ralph Goers | 20 May 05:26 2012
Picon

Re: Logging web sites


On May 19, 2012, at 2:35 PM, Christian Grobmeier <grobmeier <at> gmail.com> wrote:


On May 19, 2012 10:35 PM, "Ralph Goers" <rgoers <at> apache.org> wrote:
>
> Oops. I meant maven-site-scm-publish plugin
>
> Ralph
>
> On May 19, 2012, at 1:33 PM, Ralph Goers <rgoers <at> apache.org> wrote:
>
> > My understanding is the asf-svnpubsub-plugin is the predecessor to the maven-site-scm-plugin that I mentioned.

It starts to make sense :-)
Looking at the plug its in sandbox but might be useable already. Actually it feels pretty comfortable to me assuming it works.

Do we have an issue using unreleased code for building our sites?


Not that I am aware of.

Ralph
Christian Grobmeier | 20 May 14:24 2012
Picon

Re: Logging web sites

>> > My understanding is the asf-svnpubsub-plugin is the predecessor to the
>> > maven-site-scm-plugin that I mentioned.
>
> It starts to make sense :-)
> Looking at the plug its in sandbox but might be useable already. Actually it
> feels pretty comfortable to me assuming it works.
>
> Do we have an issue using unreleased code for building our sites?
>
> Not that I am aware of.

I have asked on the maven mailinglist about the state of this plugin.
Maybe its already usable and just needs alittle tweaks to get out of
the sandbox.

Cheers
Christian

>
> Ralph

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Christian Grobmeier | 20 May 18:48 2012
Picon

Re: Logging web sites

On Sun, May 20, 2012 at 2:24 PM, Christian Grobmeier
<grobmeier <at> gmail.com> wrote:
>>> > My understanding is the asf-svnpubsub-plugin is the predecessor to the
>>> > maven-site-scm-plugin that I mentioned.
>>
>> It starts to make sense :-)
>> Looking at the plug its in sandbox but might be useable already. Actually it
>> feels pretty comfortable to me assuming it works.
>>
>> Do we have an issue using unreleased code for building our sites?
>>
>> Not that I am aware of.
>
> I have asked on the maven mailinglist about the state of this plugin.
> Maybe its already usable and just needs alittle tweaks to get out of
> the sandbox.

In case you are not following the discussion on maven dev, here is the
link to my message:
http://bit.ly/JutniC

Already got a very interesting response from Hervé. He seems to
understand all that stuff very well and offered his help. I explained
to him what we try to do (which is: use mvn to deploy our site
easily). Lets see what he response. Feel free to jump into the
dicussion.

Cheers

> Cheers
> Christian
>
>>
>> Ralph
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 20 May 20:58 2012

Re: Logging web sites

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.

To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph



On May 20, 2012, at 9:48 AM, Christian Grobmeier wrote:

On Sun, May 20, 2012 at 2:24 PM, Christian Grobmeier
<grobmeier <at> gmail.com> wrote:
My understanding is the asf-svnpubsub-plugin is the predecessor to the
maven-site-scm-plugin that I mentioned.

It starts to make sense :-)
Looking at the plug its in sandbox but might be useable already. Actually it
feels pretty comfortable to me assuming it works.

Do we have an issue using unreleased code for building our sites?

Not that I am aware of.

I have asked on the maven mailinglist about the state of this plugin.
Maybe its already usable and just needs alittle tweaks to get out of
the sandbox.

In case you are not following the discussion on maven dev, here is the
link to my message:
http://bit.ly/JutniC

Already got a very interesting response from Hervé. He seems to
understand all that stuff very well and offered his help. I explained
to him what we try to do (which is: use mvn to deploy our site
easily). Lets see what he response. Feel free to jump into the
dicussion.

Cheers


Cheers
Christian


Ralph



--
http://www.grobmeier.de
https://www.timeandbill.de



--
http://www.grobmeier.de
https://www.timeandbill.de

Hervé BOUTEMY | 20 May 21:06 2012
Picon

Re: Logging web sites

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 

Ralph Goers | 20 May 21:53 2012

Re: Logging web sites

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E

Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging
Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 


Christian Grobmeier | 20 May 22:18 2012
Picon

Re: Logging web sites

and here comes the same link with slightly improved formatting :-)
http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg <at> mail.gmail.com%3E

On Sun, May 20, 2012 at 9:53 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> Here was what Ivan proposed
> - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E
>
> Ralph
>
>
> On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:
>
> I'm now subscribed to general <at> logging
> Thanks Ralph for INFRA-4669: it gives me good information on actual status.
>
>
>
> The main question IMHO for the moment is: how are you planning to generate
> main site html? Maven, CMS's markdown, another tool?
> Then each component will have its own generation tool, with the only
> expectation is to output html to svn
>
>
>
> Regards,
>
>
>
> Hervé
>
>
>
> Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :
>
> If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.
>  However, I haven't done any work there in a very long time.  This list
> would seem to be more appropriate for a logging related discussion.
>
>
> To reiterate a bit for Hervé's sake, I've
> opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in
> a state of limbo waiting for us to tell infra what we actually want. We
> haven't responded because we aren't really sure. So the first piece we need
> is something to tell infra so that we can actually start doing something.
>
> Ralph
>
>
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 20 May 22:23 2012

Re: Logging web sites

Thanks, I didn't realize what I had posted was so ugly.

Ralph

On May 20, 2012, at 1:18 PM, Christian Grobmeier wrote:

> and here comes the same link with slightly improved formatting :-)
> http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg <at> mail.gmail.com%3E
> 
> 
> On Sun, May 20, 2012 at 9:53 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> Here was what Ivan proposed
>> - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E
>> 
>> Ralph
>> 
>> 
>> On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:
>> 
>> I'm now subscribed to general <at> logging
>> Thanks Ralph for INFRA-4669: it gives me good information on actual status.
>> 
>> 
>> 
>> The main question IMHO for the moment is: how are you planning to generate
>> main site html? Maven, CMS's markdown, another tool?
>> Then each component will have its own generation tool, with the only
>> expectation is to output html to svn
>> 
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Hervé
>> 
>> 
>> 
>> Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :
>> 
>> If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.
>>  However, I haven't done any work there in a very long time.  This list
>> would seem to be more appropriate for a logging related discussion.
>> 
>> 
>> To reiterate a bit for Hervé's sake, I've
>> opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in
>> a state of limbo waiting for us to tell infra what we actually want. We
>> haven't responded because we aren't really sure. So the first piece we need
>> is something to tell infra so that we can actually start doing something.
>> 
>> Ralph
>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de

Hervé BOUTEMY | 20 May 22:28 2012
Picon

Re: Logging web sites

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 




Ralph Goers | 20 May 22:49 2012

Re: Logging web sites

I'm still unclear on a bit of the details.

My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  

So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.

Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 





Hervé BOUTEMY | 20 May 23:21 2012
Picon

Re: Logging web sites

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)

To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk

notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:

1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>

2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants

Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/

(notice this in in infra repo)

(notice this does not contain subsites, look at plugins directory)

(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:

https://svn.apache.org/repos/infra/websites/production/maventest/content/

This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:

- add trunk

- move src/site to content

- add resources/extpath.txt

- add a way to configure output directory from command line

Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  


So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.


Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 







Ralph Goers | 20 May 23:37 2012

Re: Logging web sites

See below.

On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)
To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk
notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:
1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>
2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants
Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

The above concerns me a bit.  Log4j2 is a multi-module site.  My plan has always been to use site:deploy or site:stage-deploy to get the site to wherever it has to go to be processed by svnpubsub. From what you are saying I can't tell if that will work or not as I would not modify the output directory for a multi-module build as it won't accomplish anything and I'm not sure at all why I would want to modify the siteDirectory to build the Log4j2 site.

Ralph


 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/
(notice this in in infra repo)
(notice this does not contain subsites, look at plugins directory)
(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:
This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:
- add trunk
- move src/site to content
- add resources/extpath.txt
- add a way to configure output directory from command line
Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  

So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.

Ralph
On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 








Hervé BOUTEMY | 21 May 00:07 2012
Picon

Re: Logging web sites

The only modifications from classical "mvn site" build are:

1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>

2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants

Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt


The above concerns me a bit.  Log4j2 is a multi-module site.  My plan has always been to use site:deploy or site:stage-deploy to get the site to wherever it has to go to be processed by svnpubsub. From what you are saying I can't tell if that will work or not as I would not modify the output directory for a multi-module build as it won't accomplish anything and I'm not sure at all why I would want to modify the siteDirectory to build the Log4j2 site.


Ralph


No problem with Log4j2, it wil work with "mvn site-stage" followed by "mvn scm-publish:publish-scm" without modifying siteDirectory nor outputDirectory.

 

The modification to source and output directories are necessary for the CMS to take care of the build (detect changes, then publish the built result to svn).

 

But sub-sites will be built by developers (while releasing), not by the CMS: there is no source nor output directories constraints.

 

Hervé

Ralph Goers | 9 Jun 18:13 2012

Re: Logging web sites

Hervé, now that the main site is there I am still trying to figure out how the extpath stuff works.  Below you say when the staging area is promoted to production, "This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.". How does this happen? How does the production structure know where to get them from. Or do you manually commit them to the production site? I'm thinking it has to be the latter.

Ralph


On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)
To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk
notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:
1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>
2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants
Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/
(notice this in in infra repo)
(notice this does not contain subsites, look at plugins directory)
(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:
This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:
- add trunk
- move src/site to content
- add resources/extpath.txt
- add a way to configure output directory from command line
Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  

So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.

Ralph
On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 








Hervé BOUTEMY | 9 Jun 19:19 2012
Picon

Re: Logging web sites

yes, that's it, you manually commit them to the production site.

Then extpath is there to avoid deleting them when staging area is promoted to production (or mre precisely to put them back after the production site has been overrided with staging area content)

 

Regards,

 

Hervé

 

Le samedi 9 juin 2012 09:13:05 Ralph Goers a écrit :

Hervé, now that the main site is there I am still trying to figure out how the extpath stuff works.  Below you say when the staging area is promoted to production, "This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.". How does this happen? How does the production structure know where to get them from. Or do you manually commit them to the production site? I'm thinking it has to be the latter.


Ralph



On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)

To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk

notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:

1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>

2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants

Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/

(notice this in in infra repo)

(notice this does not contain subsites, look at plugins directory)

(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:

https://svn.apache.org/repos/infra/websites/production/maventest/content/

This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:

- add trunk

- move src/site to content

- add resources/extpath.txt

- add a way to configure output directory from command line

Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  


So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.


Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 










Ralph Goers | 10 Jun 00:31 2012

Re: Logging web sites

Thanks, that did the trick.  I have published both the 1.2 and 2.0 sites to loggingtest.apache.org

This is actually pretty easy but we will want a way to exclude the sub-sites when the production site is checked out to add a new project.  We really don't need to use the maven publish plugin as I've checked in the each project in its own release directly and then used a symlink to point the project site to the specific release.  Each of the other sub-sites should do the same thing.

Ralph

On Jun 9, 2012, at 10:19 AM, Hervé BOUTEMY wrote:

yes, that's it, you manually commit them to the production site.
Then extpath is there to avoid deleting them when staging area is promoted to production (or mre precisely to put them back after the production site has been overrided with staging area content)

 

Regards,

 

Hervé

 

Le samedi 9 juin 2012 09:13:05 Ralph Goers a écrit :

Hervé, now that the main site is there I am still trying to figure out how the extpath stuff works.  Below you say when the staging area is promoted to production, "This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.". How does this happen? How does the production structure know where to get them from. Or do you manually commit them to the production site? I'm thinking it has to be the latter.


Ralph


On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)
To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk
notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:
1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>
2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants
Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/
(notice this in in infra repo)
(notice this does not contain subsites, look at plugins directory)
(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:
This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:
- add trunk
- move src/site to content
- add resources/extpath.txt
- add a way to configure output directory from command line
Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  

So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.

Ralph
On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 











Hervé BOUTEMY | 10 Jun 07:56 2012
Picon

Re: Logging web sites

Le samedi 9 juin 2012 15:31:36 Ralph Goers a écrit :

Thanks, that did the trick.  I have published both the 1.2 and 2.0 sites to loggingtest.apache.org

yeah!


This is actually pretty easy but we will want a way to exclude the sub-sites when the production site is checked out to add a new project.

"svn co --depth n" is an easy workaround

 

 We really don't need to use the maven publish plugin as I've checked in the each project in its own release directly and then used a symlink to point the project site to the specific release.

the publish plugin does not only check-in html, but it normalizes newlines too (for the case where the skin hasn't been published from the same platform as the site using it). But these 2 simple tasks can be done without publish plugin: the plugin more complex task is to update content, which you don't seem to expect (simple independent imports for each version)

 

 Each of the other sub-sites should do the same thing.

+1, whatever their html generation engine is, release procedure should now contain publishing the documentation html content to svn and doing a symlink


Ralph

On Jun 9, 2012, at 10:19 AM, Hervé BOUTEMY wrote:

yes, that's it, you manually commit them to the production site.

Then extpath is there to avoid deleting them when staging area is promoted to production (or mre precisely to put them back after the production site has been overrided with staging area content)

 

Regards,

 

Hervé

 

Le samedi 9 juin 2012 09:13:05 Ralph Goers a écrit :

Hervé, now that the main site is there I am still trying to figure out how the extpath stuff works.  Below you say when the staging area is promoted to production, "This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.". How does this happen? How does the production structure know where to get them from. Or do you manually commit them to the production site? I'm thinking it has to be the latter.


Ralph



On May 20, 2012, at 2:21 PM, Hervé BOUTEMY wrote:

from my experience with maventest

 

- the whole generated html goes into https://svn.apache.org/repos/infra/websites/production/logging/content/ (actually does not exist: replace logging with maventest and you have maventest)

To me, the generated html structure is the same with every option.

 

- yes, with extpath.txt, the main site content is completely divorced from sub sites: notice that extpath.txt is a CMS publish feature, ie that's the CMS that is generating htlm from sources, even if it's not with its native engine but with an external one

 

 

look at maven-site source updated for CMS build support: https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk

notice it is in asf repo, not infra, ie it is in the normal source repo

 

The only modifications from classical "mvn site" build are:

1. the source directory: <siteDirectory>${basedir}/content</siteDirectory>

2. the output directory: <outputDirectory>${site.output}</outputDirectory>, to be set from command line as -Dsite.output=... whatever infra wants

Then extpath.txt is in content/resources, which will be available from generated html (copied during "mvn site"): https://svn.apache.org/repos/asf/maven/site/branches/INFRA-4466/trunk/content/resources/extpaths.txt

 

When source svn is modified, either through CMS web interface, either directly in svn, the CMS builds html and stages content to staging svn area: https://svn.apache.org/repos/infra/websites/staging/maventest/trunk/content/

(notice this in in infra repo)

(notice this does not contain subsites, look at plugins directory)

(notice the extpaths.txt file at root)

 

Then with the CMS gui, this staging area is promoted to production:

https://svn.apache.org/repos/infra/websites/production/maventest/content/

This time, subsites are here (like in plugins directory), which were directly imported to the svn production structure in their generated html form.

 

 

 

To make the same for logging website source in http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/, here are the steps Joe would need:

- add trunk

- move src/site to content

- add resources/extpath.txt

- add a way to configure output directory from command line

Then infra will need to integrate build.php as external site build tool (like they did for "mvn site"): I don't know if they have prerequisite installed on the build machine.

 

The way I managed to do things was on IRC, to get rapid tests and feedback, because there can be a myriad of little problems to fix. When I'm here, I am connected on #asfinfra, so don't hesitate to ping me if you try to work with infra.

 

HTH

 

Hervé

 

Le dimanche 20 mai 2012 13:49:54 Ralph Goers a écrit :

I'm still unclear on a bit of the details.


My understanding is that with svnpubsub we are committing stuff into subversion.  Where would that directory be? Immediately under the main site or somewhere else? In other words, does extpath.txt  provide the ability to divorce the main site content from the sub sites completely?  


So if we chose option 1 what would the subversion site structure look like?  What about with option 2?  We do not want to have to play a bunch of games with a complicated set of svn commands to build each of the components individually.


Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 













Stefan Bodewig | 10 Jun 11:18 2012
Picon

Steps for Producr Sites? (was Re: Logging web sites)

Hi all,

On 2012-06-10, Ralph Goers wrote:

> We really don't need to use the maven publish plugin as I've checked
> in the each project in its own release directly and then used a
> symlink to point the project site to the specific release.  Each of
> the other sub-sites should do the same thing.

I missed most of the thread, been busy elsewhere, sorry.  I'd like to
add log4net to the site "the right way", what do I need to do?

This is my understanding

(1) check in the log4net site wherever I want

(2) create a symlink from where I commited the site to content/log4net

(3) un-indent log4net in extpath.txt

Is this correct?

Problems I currently see:

* the log4net site is generated by Maven and has inconsistent line-ends,
  is there any better way than Ant's fixcrlf task to fix that?  Our
  build already includes NAnt and Maven, I'd prefer to avoid adding a
  third build tool 8-)

  Mid-term log4net may be better off using the CMS directly, but that's
  something we need to discuss.

* I don't know how and where to perform step (2) from above.

Stefan

Ralph Goers | 10 Jun 17:58 2012
Picon

Re: Steps for Producr Sites? (was Re: Logging web sites)

I plan to document this on the wiki when I get home later today. The process isn't quite as you have listed.  

1. Check out the production web site.
2. Create a log4xxx directory adjacent to the log4j directory,
3. Underneath that directory create a directory for the releases of the component such as log4xxx-1.8.
4. Copy the release website into that directory.
5. In your log4xxx directory create a symlink of 1.x to log4xxx-1.8. "ln -s log4xxx-1.8 1.x" on a Mac or unix
system. Windows doesn't support links afaik.
6. Make sure all that is added to svn and commit it.
7. In the main web site check that index.twig and the navbar template reference your component as "log4xxx/1.x".
8. Unindent your component in extpaths.txt. 

If you want to use the CMS directly it is certainly easy to do.

Sent from my iPad

On Jun 10, 2012, at 2:18 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:

> Hi all,
> 
> On 2012-06-10, Ralph Goers wrote:
> 
>> We really don't need to use the maven publish plugin as I've checked
>> in the each project in its own release directly and then used a
>> symlink to point the project site to the specific release.  Each of
>> the other sub-sites should do the same thing.
> 
> I missed most of the thread, been busy elsewhere, sorry.  I'd like to
> add log4net to the site "the right way", what do I need to do?
> 
> This is my understanding
> 
> (1) check in the log4net site wherever I want
> 
> (2) create a symlink from where I commited the site to content/log4net
> 
> (3) un-indent log4net in extpath.txt
> 
> Is this correct?
> 
> Problems I currently see:
> 
> * the log4net site is generated by Maven and has inconsistent line-ends,
>  is there any better way than Ant's fixcrlf task to fix that?  Our
>  build already includes NAnt and Maven, I'd prefer to avoid adding a
>  third build tool 8-)
> 
>  Mid-term log4net may be better off using the CMS directly, but that's
>  something we need to discuss.
> 
> * I don't know how and where to perform step (2) from above.
> 
> Stefan

Stefan Bodewig | 11 Jun 06:22 2012
Picon

Re: Steps for Producr Sites?

On 2012-06-10, Ralph Goers wrote:

> I plan to document this on the wiki when I get home later today.

Many thanks.

> The process isn't quite as you have listed.

Good I haven't done much, yet 8-)

> 1. Check out the production web site.

Please remember to put the svn URL here.

> 2. Create a log4xxx directory adjacent to the log4j directory,
> 3. Underneath that directory create a directory for the releases of
> the component such as log4xxx-1.8.
> 4. Copy the release website into that directory.
> 5. In your log4xxx directory create a symlink of 1.x to
> log4xxx-1.8. "ln -s log4xxx-1.8 1.x" on a Mac or unix system. Windows
> doesn't support links afaik.

Not a problem for me, but may be problematic for future log4net release
managers.  Windows is certainly the "natural" development environment
there.

> 6. Make sure all that is added to svn and commit it.
> 7. In the main web site check that index.twig and the navbar template
> reference your component as "log4xxx/1.x".
> 8. Unindent your component in extpaths.txt.

Thanks

        Stefan

Stefan Bodewig | 11 Jun 06:28 2012
Picon

Re: Steps for Producr Sites?

On 2012-06-11, Stefan Bodewig wrote:

> On 2012-06-10, Ralph Goers wrote:

>> 1. Check out the production web site.

> Please remember to put the svn URL here.

I think it is
<https://svn.apache.org/repos/infra/websites/production/loggingtest/content/>

Stefan

Ralph Goers | 11 Jun 07:22 2012

Re: Steps for Producr Sites?


On Jun 10, 2012, at 9:28 PM, Stefan Bodewig wrote:

On 2012-06-11, Stefan Bodewig wrote:

On 2012-06-10, Ralph Goers wrote:

1. Check out the production web site.

Please remember to put the svn URL here.

I think it is
<https://svn.apache.org/repos/infra/websites/production/loggingtest/content/>

Stefan


Yes, that is the production url.   To edit the stuff managed by the CMS you want https://svn.apache.org/repos/asf/logging/site/branches/cms/trunk/.  Every time you edit something there the CMS will rebuild the staging site. You can use https://cms.apache.org/#bookmark to view the staging site, edit content and promote to production.

As for symbolic links, I'll have to look at the svn documentation but I'm pretty sure there is a way to create the link in svn without doing it on your local file system.  However, on unix-based systems an svn commit propagates the links automatically into svn.

Ralph
Hervé BOUTEMY | 11 Jun 08:23 2012
Picon

Re: Steps for Producr Sites?

Le dimanche 10 juin 2012 22:22:06 Ralph Goers a écrit :
As for symbolic links, I'll have to look at the svn documentation but I'm pretty sure there is a way to create the link in svn without doing it on your local file system.  However, on unix-based systems an svn commit propagates the links automatically into svn.

 

 

I fear it's not as easy as expected: when I worked on it for Maven, Daniel gave me a complex magic recipe with svnmucc and opened an issue in svnmucc to add native support for it

see http://subversion.tigris.org/issues/show_bug.cgi?id=4142

 

But this hasn't been implemented yet, and last time I tried to use the magic recipe, I couldn't make it work...

 

 

Regards,

 

Hervé

Ralph Goers | 11 Jun 16:10 2012
Picon

Re: Steps for Producr Sites?

On Jun 10, 2012, at 11:23 PM, Hervé BOUTEMY <herve.boutemy <at> free.fr> wrote:

> Le dimanche 10 juin 2012 22:22:06 Ralph Goers a écrit :
> As for symbolic links, I'll have to look at the svn documentation but I'm pretty sure there is a way to create
the link in svn without doing it on your local file system.  However, on unix-based systems an svn commit
propagates the links automatically into svn.
>  
>  
> I fear it's not as easy as expected: when I worked on it for Maven, Daniel gave me a complex magic recipe with
svnmucc and opened an issue in svnmucc to add native support for it
> see http://subversion.tigris.org/issues/show_bug.cgi?id=4142
>  
> But this hasn't been implemented yet, and last time I tried to use the magic recipe, I couldn't make it work...
> 

Wonderful.  During this process someone else mentioned svnmucc but it isn't installed on my Mac and I
couldn't find it in any of the downloads.

Ralph
Christian Grobmeier | 11 Jun 16:20 2012
Picon

Re: Steps for Producr Sites?

On Mon, Jun 11, 2012 at 4:10 PM, Ralph Goers <rgoers <at> apache.org> wrote:
> On Jun 10, 2012, at 11:23 PM, Hervé BOUTEMY <herve.boutemy <at> free.fr> wrote:
>
>> Le dimanche 10 juin 2012 22:22:06 Ralph Goers a écrit :
>> As for symbolic links, I'll have to look at the svn documentation but I'm pretty sure there is a way to
create the link in svn without doing it on your local file system.  However, on unix-based systems an svn
commit propagates the links automatically into svn.
>>
>>
>> I fear it's not as easy as expected: when I worked on it for Maven, Daniel gave me a complex magic recipe with
svnmucc and opened an issue in svnmucc to add native support for it
>> see http://subversion.tigris.org/issues/show_bug.cgi?id=4142
>>
>> But this hasn't been implemented yet, and last time I tried to use the magic recipe, I couldn't make it work...
>>
>
> Wonderful.  During this process someone else mentioned svnmucc but it isn't installed on my Mac and I
couldn't find it in any of the downloads.

hm, i found the source here:
http://opensource.apple.com/source/subversion/subversion-44/subversion/tools/client-side/svnmucc/svnmucc.c

but not here:
http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/

> Ralph

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ivan Habunek | 11 Jun 16:26 2012
Picon

Re: Steps for Producr Sites?

On 11 June 2012 16:20, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>> Wonderful.  During this process someone else mentioned svnmucc but it isn't installed on my Mac and I
couldn't find it in any of the downloads.
>
> hm, i found the source here:
> http://opensource.apple.com/source/subversion/subversion-44/subversion/tools/client-side/svnmucc/svnmucc.c
>
> but not here:
> http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/

My windows distribution (SilkSVN) has svnmucc included.

You should look through the SVN OSX binary distributions linked on the
official site:
http://subversion.apache.org/packages.html#osx

Regards,
Ivan

Stefan Bodewig | 11 Jun 17:31 2012
Picon

Re: Steps for Producr Sites?

On 2012-06-11, Ralph Goers wrote:

> On Jun 10, 2012, at 11:23 PM, Hervé BOUTEMY <herve.boutemy <at> free.fr> wrote:

>> Le dimanche 10 juin 2012 22:22:06 Ralph Goers a écrit :

>> As for symbolic links, I'll have to look at the svn documentation but
>> I'm pretty sure there is a way to create the link in svn without
>> doing it on your local file system.  However, on unix-based systems
>> an svn commit propagates the links automatically into svn.

>> I fear it's not as easy as expected: when I worked on it for Maven,
>> Daniel gave me a complex magic recipe with svnmucc and opened an
>> issue in svnmucc to add native support for it see
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4142

>> But this hasn't been implemented yet, and last time I tried to use
>> the magic recipe, I couldn't make it work...

> Wonderful.  During this process someone else mentioned svnmucc but it
> isn't installed on my Mac and I couldn't find it in any of the
> downloads.

Let's not make this a blocker.

Yes, most of log4net's development will happen on Windows but right now
this is not an issue as I can deal with the docs and my primary platform
is Linux.  Once we need a Windows solution, svnmucc may be ready.

Stefan

Ralph Goers | 11 Jun 19:18 2012

Re: Steps for Producr Sites? (was Re: Logging web sites)


Ralph

On Jun 10, 2012, at 8:58 AM, Ralph Goers wrote:

I plan to document this on the wiki when I get home later today. The process isn't quite as you have listed.  

1. Check out the production web site.
2. Create a log4xxx directory adjacent to the log4j directory,
3. Underneath that directory create a directory for the releases of the component such as log4xxx-1.8.
4. Copy the release website into that directory.
5. In your log4xxx directory create a symlink of 1.x to log4xxx-1.8. "ln -s log4xxx-1.8 1.x" on a Mac or unix system. Windows doesn't support links afaik.
6. Make sure all that is added to svn and commit it.
7. In the main web site check that index.twig and the navbar template reference your component as "log4xxx/1.x".
8. Unindent your component in extpaths.txt.

If you want to use the CMS directly it is certainly easy to do.

Sent from my iPad

On Jun 10, 2012, at 2:18 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:

Hi all,

On 2012-06-10, Ralph Goers wrote:

We really don't need to use the maven publish plugin as I've checked
in the each project in its own release directly and then used a
symlink to point the project site to the specific release.  Each of
the other sub-sites should do the same thing.

I missed most of the thread, been busy elsewhere, sorry.  I'd like to
add log4net to the site "the right way", what do I need to do?

This is my understanding

(1) check in the log4net site wherever I want

(2) create a symlink from where I commited the site to content/log4net

(3) un-indent log4net in extpath.txt

Is this correct?

Problems I currently see:

* the log4net site is generated by Maven and has inconsistent line-ends,
is there any better way than Ant's fixcrlf task to fix that?  Our
build already includes NAnt and Maven, I'd prefer to avoid adding a
third build tool 8-)

Mid-term log4net may be better off using the CMS directly, but that's
something we need to discuss.

* I don't know how and where to perform step (2) from above.

Stefan

Christian Grobmeier | 12 Jun 08:38 2012
Picon

Re: Steps for Producr Sites? (was Re: Logging web sites)

Thank you Ralph for this excellent guide.

Do I understand correctly - so far we cannot use something like "mvn
site:deploy". We bascially need to generate the site locally and copy
the content locally to a new repository (the cms one). Is that
correct?

Cheers

On Mon, Jun 11, 2012 at 7:18 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> See http://wiki.apache.org/logging/ManagingTheWebSite
>
> Ralph
>
> On Jun 10, 2012, at 8:58 AM, Ralph Goers wrote:
>
> I plan to document this on the wiki when I get home later today. The process
> isn't quite as you have listed.
>
> 1. Check out the production web site.
> 2. Create a log4xxx directory adjacent to the log4j directory,
> 3. Underneath that directory create a directory for the releases of the
> component such as log4xxx-1.8.
> 4. Copy the release website into that directory.
> 5. In your log4xxx directory create a symlink of 1.x to log4xxx-1.8. "ln -s
> log4xxx-1.8 1.x" on a Mac or unix system. Windows doesn't support links
> afaik.
> 6. Make sure all that is added to svn and commit it.
> 7. In the main web site check that index.twig and the navbar template
> reference your component as "log4xxx/1.x".
> 8. Unindent your component in extpaths.txt.
>
> If you want to use the CMS directly it is certainly easy to do.
>
> Sent from my iPad
>
> On Jun 10, 2012, at 2:18 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:
>
> Hi all,
>
>
> On 2012-06-10, Ralph Goers wrote:
>
>
> We really don't need to use the maven publish plugin as I've checked
>
> in the each project in its own release directly and then used a
>
> symlink to point the project site to the specific release.  Each of
>
> the other sub-sites should do the same thing.
>
>
> I missed most of the thread, been busy elsewhere, sorry.  I'd like to
>
> add log4net to the site "the right way", what do I need to do?
>
>
> This is my understanding
>
>
> (1) check in the log4net site wherever I want
>
>
> (2) create a symlink from where I commited the site to content/log4net
>
>
> (3) un-indent log4net in extpath.txt
>
>
> Is this correct?
>
>
> Problems I currently see:
>
>
> * the log4net site is generated by Maven and has inconsistent line-ends,
>
> is there any better way than Ant's fixcrlf task to fix that?  Our
>
> build already includes NAnt and Maven, I'd prefer to avoid adding a
>
> third build tool 8-)
>
>
> Mid-term log4net may be better off using the CMS directly, but that's
>
> something we need to discuss.
>
>
> * I don't know how and where to perform step (2) from above.
>
>
> Stefan
>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 12 Jun 08:57 2012

Re: Steps for Producr Sites? (was Re: Logging web sites)

Well, I use mvn site:stage-deploy for Log4j 2 to get the full site content. But that is required for a
multi-project site.  So, yes, you are correct.  If mvn site:deploy could deploy directly into svn we could
then use it.

Ralph

On Jun 11, 2012, at 11:38 PM, Christian Grobmeier wrote:

> Thank you Ralph for this excellent guide.
> 
> Do I understand correctly - so far we cannot use something like "mvn
> site:deploy". We bascially need to generate the site locally and copy
> the content locally to a new repository (the cms one). Is that
> correct?
> 
> Cheers
> 
> On Mon, Jun 11, 2012 at 7:18 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> See http://wiki.apache.org/logging/ManagingTheWebSite
>> 
>> Ralph
>> 
>> On Jun 10, 2012, at 8:58 AM, Ralph Goers wrote:
>> 
>> I plan to document this on the wiki when I get home later today. The process
>> isn't quite as you have listed.
>> 
>> 1. Check out the production web site.
>> 2. Create a log4xxx directory adjacent to the log4j directory,
>> 3. Underneath that directory create a directory for the releases of the
>> component such as log4xxx-1.8.
>> 4. Copy the release website into that directory.
>> 5. In your log4xxx directory create a symlink of 1.x to log4xxx-1.8. "ln -s
>> log4xxx-1.8 1.x" on a Mac or unix system. Windows doesn't support links
>> afaik.
>> 6. Make sure all that is added to svn and commit it.
>> 7. In the main web site check that index.twig and the navbar template
>> reference your component as "log4xxx/1.x".
>> 8. Unindent your component in extpaths.txt.
>> 
>> If you want to use the CMS directly it is certainly easy to do.
>> 
>> Sent from my iPad
>> 
>> On Jun 10, 2012, at 2:18 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:
>> 
>> Hi all,
>> 
>> 
>> On 2012-06-10, Ralph Goers wrote:
>> 
>> 
>> We really don't need to use the maven publish plugin as I've checked
>> 
>> in the each project in its own release directly and then used a
>> 
>> symlink to point the project site to the specific release.  Each of
>> 
>> the other sub-sites should do the same thing.
>> 
>> 
>> I missed most of the thread, been busy elsewhere, sorry.  I'd like to
>> 
>> add log4net to the site "the right way", what do I need to do?
>> 
>> 
>> This is my understanding
>> 
>> 
>> (1) check in the log4net site wherever I want
>> 
>> 
>> (2) create a symlink from where I commited the site to content/log4net
>> 
>> 
>> (3) un-indent log4net in extpath.txt
>> 
>> 
>> Is this correct?
>> 
>> 
>> Problems I currently see:
>> 
>> 
>> * the log4net site is generated by Maven and has inconsistent line-ends,
>> 
>> is there any better way than Ant's fixcrlf task to fix that?  Our
>> 
>> build already includes NAnt and Maven, I'd prefer to avoid adding a
>> 
>> third build tool 8-)
>> 
>> 
>> Mid-term log4net may be better off using the CMS directly, but that's
>> 
>> something we need to discuss.
>> 
>> 
>> * I don't know how and where to perform step (2) from above.
>> 
>> 
>> Stefan
>> 
>> 
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de

Christian Grobmeier | 12 Jun 13:33 2012
Picon

Re: Steps for Producr Sites? (was Re: Logging web sites)

On Tue, Jun 12, 2012 at 8:57 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
> Well, I use mvn site:stage-deploy for Log4j 2 to get the full site content. But that is required for a
multi-project site.  So, yes, you are correct.  If mvn site:deploy could deploy directly into svn we
could then use it.

OK cool. When I committed the site, then it can be seen here:
loggingtest.staging.apache.org

until I manually promote it to production, right?
How can I promote a site?

Cheers

>
> Ralph
>
>
>
> On Jun 11, 2012, at 11:38 PM, Christian Grobmeier wrote:
>
>> Thank you Ralph for this excellent guide.
>>
>> Do I understand correctly - so far we cannot use something like "mvn
>> site:deploy". We bascially need to generate the site locally and copy
>> the content locally to a new repository (the cms one). Is that
>> correct?
>>
>> Cheers
>>
>> On Mon, Jun 11, 2012 at 7:18 PM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>>> See http://wiki.apache.org/logging/ManagingTheWebSite
>>>
>>> Ralph
>>>
>>> On Jun 10, 2012, at 8:58 AM, Ralph Goers wrote:
>>>
>>> I plan to document this on the wiki when I get home later today. The process
>>> isn't quite as you have listed.
>>>
>>> 1. Check out the production web site.
>>> 2. Create a log4xxx directory adjacent to the log4j directory,
>>> 3. Underneath that directory create a directory for the releases of the
>>> component such as log4xxx-1.8.
>>> 4. Copy the release website into that directory.
>>> 5. In your log4xxx directory create a symlink of 1.x to log4xxx-1.8. "ln -s
>>> log4xxx-1.8 1.x" on a Mac or unix system. Windows doesn't support links
>>> afaik.
>>> 6. Make sure all that is added to svn and commit it.
>>> 7. In the main web site check that index.twig and the navbar template
>>> reference your component as "log4xxx/1.x".
>>> 8. Unindent your component in extpaths.txt.
>>>
>>> If you want to use the CMS directly it is certainly easy to do.
>>>
>>> Sent from my iPad
>>>
>>> On Jun 10, 2012, at 2:18 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:
>>>
>>> Hi all,
>>>
>>>
>>> On 2012-06-10, Ralph Goers wrote:
>>>
>>>
>>> We really don't need to use the maven publish plugin as I've checked
>>>
>>> in the each project in its own release directly and then used a
>>>
>>> symlink to point the project site to the specific release.  Each of
>>>
>>> the other sub-sites should do the same thing.
>>>
>>>
>>> I missed most of the thread, been busy elsewhere, sorry.  I'd like to
>>>
>>> add log4net to the site "the right way", what do I need to do?
>>>
>>>
>>> This is my understanding
>>>
>>>
>>> (1) check in the log4net site wherever I want
>>>
>>>
>>> (2) create a symlink from where I commited the site to content/log4net
>>>
>>>
>>> (3) un-indent log4net in extpath.txt
>>>
>>>
>>> Is this correct?
>>>
>>>
>>> Problems I currently see:
>>>
>>>
>>> * the log4net site is generated by Maven and has inconsistent line-ends,
>>>
>>> is there any better way than Ant's fixcrlf task to fix that?  Our
>>>
>>> build already includes NAnt and Maven, I'd prefer to avoid adding a
>>>
>>> third build tool 8-)
>>>
>>>
>>> Mid-term log4net may be better off using the CMS directly, but that's
>>>
>>> something we need to discuss.
>>>
>>>
>>> * I don't know how and where to perform step (2) from above.
>>>
>>>
>>> Stefan
>>>
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 12 Jun 15:40 2012

Re: Steps for Producr Sites? (was Re: Logging web sites)


On Jun 12, 2012, at 4:33 AM, Christian Grobmeier wrote:

> On Tue, Jun 12, 2012 at 8:57 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>> Well, I use mvn site:stage-deploy for Log4j 2 to get the full site content. But that is required for a
multi-project site.  So, yes, you are correct.  If mvn site:deploy could deploy directly into svn we could
then use it.
> 
> 
> OK cool. When I committed the site, then it can be seen here:
> loggingtest.staging.apache.org
> 
> until I manually promote it to production, right?
> How can I promote a site?

No.  The sub-projects go directly from your local area into the production site. They do not get committed to
staging. The staging site is used only by stuff that directly uses the CMS build process.  The ext paths.txt
file identifies the directories in the production site that are to be ignored by the CMS system.

Ralph

Christian Grobmeier | 12 Jun 16:38 2012
Picon

Re: Steps for Producr Sites? (was Re: Logging web sites)

>> until I manually promote it to production, right?
>> How can I promote a site?
>
> No.  The sub-projects go directly from your local area into the production site. They do not get
committed to staging. The staging site is used only by stuff that directly uses the CMS build process.
 The ext paths.txt file identifies the directories in the production site that are to be ignored by the
CMS system.
>

OK. In this case we might consider implementing a mvn site:stage which
"deploys" a test site to p.a.o or somewhere else.
I think this is useful for voting

Ralph Goers | 12 Jun 00:00 2012

Logging site

I should have added that I'd appreciate you adding log4net to the site.  I'd really like to have all the sub
projects added as once they are all there then we can simply ask Infra to replace the existing site with the
new one.  I've been waiting for that to do the first Log4j 2 release.

Ralph

On Jun 10, 2012, at 2:18 AM, Stefan Bodewig wrote:

> Hi all,
> 
> On 2012-06-10, Ralph Goers wrote:
> 
>> We really don't need to use the maven publish plugin as I've checked
>> in the each project in its own release directly and then used a
>> symlink to point the project site to the specific release.  Each of
>> the other sub-sites should do the same thing.
> 
> I missed most of the thread, been busy elsewhere, sorry.  I'd like to
> add log4net to the site "the right way", what do I need to do?
> 
> This is my understanding
> 
> (1) check in the log4net site wherever I want
> 
> (2) create a symlink from where I commited the site to content/log4net
> 
> (3) un-indent log4net in extpath.txt
> 
> Is this correct?
> 
> Problems I currently see:
> 
> * the log4net site is generated by Maven and has inconsistent line-ends,
>  is there any better way than Ant's fixcrlf task to fix that?  Our
>  build already includes NAnt and Maven, I'd prefer to avoid adding a
>  third build tool 8-)
> 
>  Mid-term log4net may be better off using the CMS directly, but that's
>  something we need to discuss.
> 
> * I don't know how and where to perform step (2) from above.
> 
> Stefan

Stefan Bodewig | 12 Jun 06:19 2012
Picon

Re: Logging site

On 2012-06-12, Ralph Goers wrote:

> I should have added that I'd appreciate you adding log4net to the
> site.

Understood, and yes, I'll do that.  It's only a matter of solving a few
problems and finding the time to do so.  Can't promise I'll be able to
get around to it before the weekend.

> I'd really like to have all the sub projects added as once they are
> all there then we can simply ask Infra to replace the existing site
> with the new one.  I've been waiting for that to do the first Log4j 2
> release.

OK, if this is holding up the release then I'll simply tar up the
existing site and add it to svn - I can figure out a better way to do it
later.

Stefan

Christian Grobmeier | 12 Jun 06:30 2012
Picon

Re: Logging site

On Tue, Jun 12, 2012 at 6:19 AM, Stefan Bodewig <bodewig <at> apache.org> wrote:

>> I'd really like to have all the sub projects added as once they are
>> all there then we can simply ask Infra to replace the existing site
>> with the new one.  I've been waiting for that to do the first Log4j 2
>> release.
>
> OK, if this is holding up the release then I'll simply tar up the
> existing site and add it to svn - I can figure out a better way to do it
> later.

Nice option. Probably we should do that for log4cxx

Cheers
Christian

>
> Stefan

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de

Ralph Goers | 12 Jun 06:59 2012

Re: Logging site


On Jun 11, 2012, at 9:19 PM, Stefan Bodewig wrote:

> On 2012-06-12, Ralph Goers wrote:
> 
>> I should have added that I'd appreciate you adding log4net to the
>> site.
> 
> Understood, and yes, I'll do that.  It's only a matter of solving a few
> problems and finding the time to do so.  Can't promise I'll be able to
> get around to it before the weekend.
> 
>> I'd really like to have all the sub projects added as once they are
>> all there then we can simply ask Infra to replace the existing site
>> with the new one.  I've been waiting for that to do the first Log4j 2
>> release.
> 
> OK, if this is holding up the release then I'll simply tar up the
> existing site and add it to svn - I can figure out a better way to do it
> later.

Yes, that is an option. However, I think it is important that we all get a feel for how this works. That said, I
almost did that for Log4j 1.2 if I hadn't been able to run mvn site on the last release tag an upload that.
Since each release will exist as its own directory in the new site (hopefully deleting old releases after
some time) it should be fairly simple to use whatever you want to generate the site.

Ralph
Stefan Bodewig | 12 Jun 14:02 2012
Picon

Re: Logging site

On 2012-06-12, Ralph Goers wrote:

> On Jun 11, 2012, at 9:19 PM, Stefan Bodewig wrote:

>> OK, if this is holding up the release then I'll simply tar up the
>> existing site and add it to svn - I can figure out a better way to do
>> it later.

> Yes, that is an option. However, I think it is important that we all
> get a feel for how this works.

The site building process in log4net is too brittle anyway, it involves
creating API docs which I currently don't manage to do at all.  Fixing
that is so far down on my TODO list that it would have delayed the log4j
release for an unaceptable time.

Stefan

Stefan Bodewig | 12 Jun 14:06 2012
Picon

Re: Logging site

On 2012-06-12, Stefan Bodewig wrote:

> OK, if this is holding up the release then I'll simply tar up the
> existing site and add it to svn - I can figure out a better way to do it
> later.

Done.

The log4net site now appears on loggingtest, but there are some issues.

One is that http://logging.apache.org/log4net/ would no longer be the
canonical entry point.  I plan to add a .htaccess to send people to the
1.x directory from there.  Too many existing links to leave it the way
it is.

In a similar way I'll have to go through the log4net site looking for
links to other parts of logging, in particular log4j but also chainsaw,
and adapt them.

Stefan

Ralph Goers | 21 May 00:15 2012

Re: Logging web sites

Based on your other answers I'm in favor of going with option 1.  I think we should start by having infra set up a loggingtest site. and then see if we can't get Ivan's build to work (preferably in English).

Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 





Hervé BOUTEMY | 21 May 22:55 2012
Picon

Re: Logging web sites

seems a good step, IMHO, because your main site has its own templating engine that won't be used by many people, then don't deserve CMS dedicated code to integrate it: pure svnpubsub will be the simplest choice for everybody

 

and as done in the main site source, a pom.xml can provide html publish to svn: just need to check if excludes works well to avoid deleting components subsites when publishing main site update

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 15:15:46 Ralph Goers a écrit :

Based on your other answers I'm in favor of going with option 1.  I think we should start by having infra set up a loggingtest site. and then see if we can't get Ivan's build to work (preferably in English).


Ralph


On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 







Ralph Goers | 22 May 08:11 2012

Re: Logging web sites

Wait - I thought option 1 used the CMS and could invoke the site build.

Ralph

On May 21, 2012, at 1:55 PM, Hervé BOUTEMY wrote:

seems a good step, IMHO, because your main site has its own templating engine that won't be used by many people, then don't deserve CMS dedicated code to integrate it: pure svnpubsub will be the simplest choice for everybody

 

and as done in the main site source, a pom.xml can provide html publish to svn: just need to check if excludes works well to avoid deleting components subsites when publishing main site update

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 15:15:46 Ralph Goers a écrit :

Based on your other answers I'm in favor of going with option 1.  I think we should start by having infra set up a loggingtest site. and then see if we can't get Ivan's build to work (preferably in English).


Ralph

On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.
With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph

On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?
Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.

Ralph

 








Hervé BOUTEMY | 22 May 08:36 2012
Picon

Re: Logging web sites

oh, yes, sorry, I described option 2.

 

Then option 1 will require infra to work on integrating your templating engine as external task : someone knowing this engine, its prerequisites and so on has to work with infra to help them run the tool by hand then be able to launch it from build system (with source files in content directory, output directory set by a command line attribute)

 

Notice that if you explain infra that /whatever/file.html is generated from /content/pages/file.twig, it should be easy for infra to add support for online content editing = a really nice feature of the CMS. You can even add a "CMS boormarklet" in your bookmarks, and jump into content editing in one click from browse. This one is very nice. If this is not clear, I can explain more this feature, because the "CMS bookmarklet" isn't something everybody knows.

 

Regards,

 

Hervé

 

Le lundi 21 mai 2012 23:11:47 Ralph Goers a écrit :

Wait - I thought option 1 used the CMS and could invoke the site build.


Ralph


On May 21, 2012, at 1:55 PM, Hervé BOUTEMY wrote:

seems a good step, IMHO, because your main site has its own templating engine that won't be used by many people, then don't deserve CMS dedicated code to integrate it: pure svnpubsub will be the simplest choice for everybody

 

and as done in the main site source, a pom.xml can provide html publish to svn: just need to check if excludes works well to avoid deleting components subsites when publishing main site update

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 15:15:46 Ralph Goers a écrit :

Based on your other answers I'm in favor of going with option 1.  I think we should start by having infra set up a loggingtest site. and then see if we can't get Ivan's build to work (preferably in English).


Ralph


On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 










Hervé BOUTEMY | 22 May 08:43 2012
Picon

Re: Logging web sites

(please ignore previous post, sending a fixed version)

 

oh, yes, sorry, I described option 2.

Then option 1 will require infra to work on integrating your templating engine as external task : someone knowing this engine, its prerequisites and so on has to work with infra to help them run the tool by hand then be able to launch it from build system (with source files in content directory, output directory set by a command line attribute, and and everything in a trunk directory)

Notice that if you explain infra that /whatever/file.html is generated from /content/pages/whatever/file.twig, it should be easy for infra to add support for online content editing = a really nice feature of the CMS. You can even add a "CMS boormarklet" in your bookmarks, and jump into content editing in one click from browse. This one is very nice. If this is not clear, I can explain more this feature, because the "CMS bookmarklet" isn't something everybody knows.

Regards,

Hervé

 

Le lundi 21 mai 2012 23:11:47 Ralph Goers a écrit :

Wait - I thought option 1 used the CMS and could invoke the site build.


Ralph


On May 21, 2012, at 1:55 PM, Hervé BOUTEMY wrote:

seems a good step, IMHO, because your main site has its own templating engine that won't be used by many people, then don't deserve CMS dedicated code to integrate it: pure svnpubsub will be the simplest choice for everybody

 

and as done in the main site source, a pom.xml can provide html publish to svn: just need to check if excludes works well to avoid deleting components subsites when publishing main site update

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 15:15:46 Ralph Goers a écrit :

Based on your other answers I'm in favor of going with option 1.  I think we should start by having infra set up a loggingtest site. and then see if we can't get Ivan's build to work (preferably in English).


Ralph


On May 20, 2012, at 1:28 PM, Hervé BOUTEMY wrote:

ok, so it's a custom rendering engine

 

so I see 2 solutions:

 

1. either infra adds this engine as external, like it did with "mvn site": you'll have to put sources in content, to trigger html generation on each source update, buildbot will build the html, then you'll use the CMS web interface to publish staged content

 

2. either infra simply adds svnpubsub, without any CMS integration, ie any source modification integration nor html build from sources. I don't know if they do that. But that way, you're completely free, you only use svnpubsub: it's up to you to get the tooling to put html content to svn.

 

With 1st solution, main site is automatically published at each commit, each component being protected from erase by extpath.txt.

With 2nd solution, main site is manually published when somebody does it, like components during releases, and you'll have to take care of not removing components content when publishing.

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 12:53:27 Ralph Goers a écrit :

Here was what Ivan proposed - http://mail-archives.apache.org/mod_mbox/logging-general/201205.mbox/ajax/%3CCAKpWnhTiVEe0M54UOFHGXTUOPq3TX2Jd_Z-a7B9H_pfnxQmCDg%40mail.gmail.com%3E


Ralph


On May 20, 2012, at 12:06 PM, Hervé BOUTEMY wrote:

I'm now subscribed to general <at> logging

Thanks Ralph for INFRA-4669: it gives me good information on actual status.

 

The main question IMHO for the moment is: how are you planning to generate main site html? Maven, CMS's markdown, another tool?

Then each component will have its own generation tool, with the only expectation is to output html to svn

 

Regards,

 

Hervé

 

Le dimanche 20 mai 2012 11:58:16 Ralph Goers a écrit :

If you meant me, of course I'm subscribed to Maven Dev as I'm on the PMC.  However, I haven't done any work there in a very long time.  This list would seem to be more appropriate for a logging related discussion.


To reiterate a bit for Hervé's sake, I've opened https://issues.apache.org/jira/browse/INFRA-4699 which is sort of in a state of limbo waiting for us to tell infra what we actually want. We haven't responded because we aren't really sure. So the first piece we need is something to tell infra so that we can actually start doing something.


Ralph

 










Ralph Goers | 22 May 13:40 2012
Picon

Re: Logging web sites

Ivan, 

Daniel has updated the Jira and asked "Can you provide a list of dependencies of your site's build process?  (as port names -- see www.freshports.org -- for those deps that are in ports)"

Since you have actually built the test site could you possibly help with this? The issue is https://issues.apache.org/jira/browse/INFRA-4699.

Ralph

On May 2, 2012, at 2:11 AM, Ivan Habunek <ivan.habunek <at> gmail.com> wrote:

Hi all, 

I was away for a bit so I didn't comment earlier. 

My idea is to generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...).

I have already converted the logging web site. The code can be found here:

And I have deployed the generated web for demo here:

This idea is obviously not compatible with the Apache CMS solution. Frankly, I would prefer this solution to the CMS since, from what I have seen, the CMS is quite a pain to use.

Regards,
Ivan



On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>
>
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
>
>
> Joe has now proposed using the CMS for the main Logging web site along
> with expaths.txt + svnpubsub for each sub-project. Each sub-project would
> then use svn externals so they could be independently managed. This sounds
> perfect to me.

OK I understand svn externals is like "symlinks for svn". Sounds ok.

I am a bit concerned on the CMS. Ivan has put much effort in the website design:
http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

I will ask infra (on the ticket) if it is possible to either use that
design for the CMS or if we can bypass the CMS feature for this one
too...

Cheers
Christian


> Ralph

Ivan Habunek | 22 May 14:52 2012
Picon

Re: Logging web sites

Yeah, sorry I haven't been more involved in the discussion. I've been to the phpday conference in Verona, and haven't had time to catch up.


I posted a comment to the INFRA ticket with the required information. I'll keep in the loop from now on to answer any other questions.

Regards,
Ivan


On 22 May 2012 13:40, Ralph Goers <rgoers <at> apache.org> wrote:
Ivan, 

Daniel has updated the Jira and asked "Can you provide a list of dependencies of your site's build process?  (as port names -- see www.freshports.org -- for those deps that are in ports)"

Since you have actually built the test site could you possibly help with this? The issue is https://issues.apache.org/jira/browse/INFRA-4699.

Ralph

On May 2, 2012, at 2:11 AM, Ivan Habunek <ivan.habunek <at> gmail.com> wrote:

Hi all, 

I was away for a bit so I didn't comment earlier. 

My idea is to generate the site using Twig [1], a nice PHP templating engine, in combination with Textile markup [2], which is much more versatile than most other common markup languages (such as markdown, apt, ...).

I have already converted the logging web site. The code can be found here:

And I have deployed the generated web for demo here:

This idea is obviously not compatible with the Apache CMS solution. Frankly, I would prefer this solution to the CMS since, from what I have seen, the CMS is quite a pain to use.

Regards,
Ivan



On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com> wrote:
>
> On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>
>
> What i thought was, why not to clean it up? Your proposed solutions
> seem to be the cleanest way and updating everything just when we need
> an update to the main site feels somehow wrong
>
>
> Joe has now proposed using the CMS for the main Logging web site along
> with expaths.txt + svnpubsub for each sub-project. Each sub-project would
> then use svn externals so they could be independently managed. This sounds
> perfect to me.

OK I understand svn externals is like "symlinks for svn". Sounds ok.

I am a bit concerned on the CMS. Ivan has put much effort in the website design:
http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/

I will ask infra (on the ticket) if it is possible to either use that
design for the CMS or if we can bypass the CMS feature for this one
too...

Cheers
Christian


> Ralph


Christian Grobmeier | 22 May 17:47 2012
Picon

Re: Logging web sites

Thanks Ralph, Ivan and Hervé.
I agree on Option 1, it sounds very good to me!

On Tue, May 22, 2012 at 2:52 PM, Ivan Habunek <ivan.habunek <at> gmail.com> wrote:
> Yeah, sorry I haven't been more involved in the discussion. I've been to the
> phpday conference in Verona, and haven't had time to catch up.
>
> I posted a comment to the INFRA ticket with the required information. I'll
> keep in the loop from now on to answer any other questions.
>
> Regards,
> Ivan
>
>
> On 22 May 2012 13:40, Ralph Goers <rgoers <at> apache.org> wrote:
>>
>> Ivan,
>>
>> Daniel has updated the Jira and asked "Can you provide a list of
>> dependencies of your site's build process?  (as port names --
>> see www.freshports.org -- for those deps that are in ports)"
>>
>> Since you have actually built the test site could you possibly help with
>> this? The issue is https://issues.apache.org/jira/browse/INFRA-4699.
>>
>> Ralph
>>
>> On May 2, 2012, at 2:11 AM, Ivan Habunek <ivan.habunek <at> gmail.com> wrote:
>>
>> Hi all,
>>
>> I was away for a bit so I didn't comment earlier.
>>
>> My idea is to generate the site using Twig [1], a nice PHP templating
>> engine, in combination with Textile markup [2], which is much more versatile
>> than most other common markup languages (such as markdown, apt, ...).
>>
>> I have already converted the logging web site. The code can be found here:
>>
>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-twig-textile/
>>
>> And I have deployed the generated web for demo here:
>> http://bezdomni.net/logging/
>>
>> This idea is obviously not compatible with the Apache CMS solution.
>> Frankly, I would prefer this solution to the CMS since, from what I have
>> seen, the CMS is quite a pain to use.
>>
>> Regards,
>> Ivan
>>
>> [1] http://twig.sensiolabs.org/
>> [2] http://textile.sitemonks.com/
>>
>>
>> On 2 May 2012 10:44, Christian Grobmeier <grobmeier <at> gmail.com> wrote:
>>>
>>> On Mon, Apr 23, 2012 at 4:06 AM, Ralph Goers <ralph.goers <at> dslextreme.com>
>>> wrote:
>>> >
>>> > On Apr 20, 2012, at 12:14 PM, Christian Grobmeier wrote:
>>> >
>>> >
>>> > What i thought was, why not to clean it up? Your proposed solutions
>>> > seem to be the cleanest way and updating everything just when we need
>>> > an update to the main site feels somehow wrong
>>> >
>>> >
>>> > Joe has now proposed using the CMS for the main Logging web site along
>>> > with expaths.txt + svnpubsub for each sub-project. Each sub-project
>>> > would
>>> > then use svn externals so they could be independently managed. This
>>> > sounds
>>> > perfect to me.
>>>
>>> OK I understand svn externals is like "symlinks for svn". Sounds ok.
>>>
>>> I am a bit concerned on the CMS. Ivan has put much effort in the website
>>> design:
>>>
>>> http://svn.apache.org/repos/asf/logging/site/branches/experimental-redesign/src/site/pages/
>>>
>>> I will ask infra (on the ticket) if it is possible to either use that
>>> design for the CMS or if we can bypass the CMS feature for this one
>>> too...
>>>
>>> Cheers
>>> Christian
>>>
>>>
>>> > Ralph
>>>
>>>
>>>
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>
>>
>

--

-- 
http://www.grobmeier.de
https://www.timeandbill.de


Gmane