commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: We will not be able to update our websites...
Date Sat, 15 Dec 2012 07:54:10 GMT
2012/12/15 Ralph Goers <ralph.goers@dslextreme.com>:
> And now I'm even more confused since I just saw your commits to build the CMS site using
Maven.
I started with main site and as I'm in eu I wanted to sleep a bit :-).
I will try to work on sub projects today (it's only a matter of
configuring parent pom normally)
And test with deploying to
http://svn.apache.org/repos/asf/commons/cms-site/trunk/.


>
> Ralph
>
> On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote:
>
>> So now I'm confused.  You are proposing to bypass the CMS altogether and only publish
to the live site.  Why?  Even projects like Flume that use maven for the site build still
do it in the CMS.
>>
>> Ralph
>>
>> On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote:
>>
>>> 2012/12/15 Olivier Lamy <olamy@apache.org>:
>>>> 2012/12/15 Matt Benson <gudnabrsam@gmail.com>:
>>>>> Olivier,
>>>>> Thanks for your response and offer to contribute!  We do have a few
>>>>> multi-module components here.  Of "proper" components, there is only
[jci]
>>>>> that I know of, but [proxy]'s 2.0 branch is multimodule, and we had
>>>>> intended to take [functor] multimodule before a release is made.  I'm
>>>>> perusing your wiki link now.
>>>>>
>>>>
>>>> Maybe you can update the jira entry to say you want a solution "à la" maven
?
>>>> and website content from
>>>> https://svn.apache.org/repos/infra/websites/production/commons/content/
>>>>
>>>> I will update commons-site now to get it working for cms.
>>>>
>>>
>>> Done.
>>>
>>>> For deploying I can try make configuration easy if you accept to use
>>>> something like: mvn site site:stage scm-publish:publish-scm rather
>>>> than mvn site-deploy (btw that won't be possible for multi modules :-)
>>>> ).
>>>>
>>>> Note that will need a release of your parent pom.
>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <olamy@apache.org>
wrote:
>>>>>
>>>>>> /me listening here
>>>>>>
>>>>>> Note maven.apache.org has been migrated this week.
>>>>>>
>>>>>> If you want to mix cms and maven site generation, we do that.
>>>>>> Note: even the main site is generated with a maven build but we can
>>>>>> edit files (apt/xdoc/markdown) with the cms editor
>>>>>>
>>>>>> The source tree need some modifications: see
>>>>>> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of
>>>>>> documentation here: http://apache.org/dev/cmsadoption#maven .
>>>>>>
>>>>>> Let me know if you need some help (I think I have karma here so I
can
>>>>>> do a bit of pom.xml stuff :-) )
>>>>>>
>>>>>> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/
>>>>>> you could use https://svn.apache.org/repos/infra/websites/production/
>>>>>> which is dedicated to this purpose.
>>>>>>
>>>>>> As I can see you are using this module
>>>>>> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/
>>>>>> for main site ?
>>>>>> If you want I can do the necessary changes to make it working with
>>>>>> both cms and mvn site.
>>>>>>
>>>>>> For sub projects, that's easy if all are mono modules projects (in
>>>>>> this case mvn site-deploy works)
>>>>>> For multi modules, it's a bit different. Is there any multi modules
>>>>>> projects here ?
>>>>>>
>>>>>> --
>>>>>> Olivier
>>>>>>
>>>>>> 2012/12/14 Matt Benson <gudnabrsam@gmail.com>:
>>>>>>> I never questioned that the individual components would most
likely
>>>>>>> continue with the Maven-generated content.  I do question whether
we want
>>>>>>> to bother laying out the main site when we have something that
works.
>>>>>>>
>>>>>>> br,
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 14, 2012 at 4:07 PM, Gilles Sadowski <
>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>
>>>>>>>> On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
>>>>>>>>> I've just added the directory to our svn tree so that
there would be
>>>>>>>>> someplace at which to point it.  I think the next step
is to determine
>>>>>>>>> whether we want a "normal" CMS site like Logging has,
in which case we
>>>>>>>>> could prop something up with e.g. Twitter bootstrap as
is becoming
>>>>>> quite
>>>>>>>>> popular among ASF TLPs.  If we like to keep a Maven-generated
look,
>>>>>> we'd
>>>>>>>>> probably be best advised to consult the Maven folks on
how they're
>>>>>> doing
>>>>>>>>> this.
>>>>>>>>
>>>>>>>> If I interpret correctly what I see, the "logging" site has
both: The
>>>>>>>> top-level site is "powered by Twitter Bootstrap" while the
"components"
>>>>>> are
>>>>>>>> "built by maven".
>>>>>>>> That looks like a nice starting point. I.e. we should have
the top-level
>>>>>>>> web
>>>>>>>> CMS-site set up to replace the "Commons" homepage, and every
"sub-sites"
>>>>>>>> button would point to the corresponding legacy site (until
the
>>>>>> components'
>>>>>>>> sites themselves are ready).
>>>>>>>>
>>>>>>>>
>>>>>>>> Gilles
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
>>>>>>>>> gilles@harfang.homelinux.org> wrote:
>>>>>>>>>
>>>>>>>>>> Hi.
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson
wrote:
>>>>>>>>>>> I've been talking to Joe S. on #asfinfra about
this; rather than
>>>>>>>> using a
>>>>>>>>>>> test site infra would prefer we request the CMS
site, just not
>>>>>>>> exposed to
>>>>>>>>>>> commons.a.o until we're satisfied with it.  Do
we want to use the
>>>>>>>> CMS a
>>>>>>>>>> la
>>>>>>>>>>> Apache Logging, or do we want to explore keeping
the main site
>>>>>>>>>>> Maven-generated?  The Maven guys, particularly
Olivier Lamy (do
>>>>>> you
>>>>>>>>>> follow
>>>>>>>>>>> Commons MLs?) may be able to help us if we want
to go that way.
>>>>>>>> Actually
>>>>>>>>>>> Maven still seems to be using the CMS at some
level [1], so I
>>>>>> guess
>>>>>>>> we
>>>>>>>>>> can
>>>>>>>>>>> just request the CMS site and go from there.
 Issue created.  [2]
>>>>>>>>>>
>>>>>>>>>> Is the new (empty, I guess) cms-web site accessible?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Gilles
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Matt
>>>>>>>>>>>
>>>>>>>>>>> [1] http://maventest.apache.org
>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-5657
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers
<
>>>>>>>> ralph.goers@dslextreme.com
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> At the very least, someone should file a
Jira asking for a
>>>>>>>> commons-test
>>>>>>>>>>>> site.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 10, 2012, at 10:14 PM, Phil Steitz
wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/10/12 5:10 PM, Ralph Goers wrote:
>>>>>>>>>>>>>> On Dec 10, 2012, at 4:12 PM, sebb
wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 10 December 2012 21:53, Phil
Steitz <
>>>>>> phil.steitz@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On 12/10/12 1:27 PM, Ralph
Goers wrote:
>>>>>>>>>>>>>>>>> Yes, I think you are
missing something fundamental.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you check in "the
whole mess" you will never again be
>>>>>>>> able to
>>>>>>>>>>>> properly build a sub-project's site with
Maven.  This is because
>>>>>>>> the
>>>>>>>>>>>> process of updating the site would require
first doing a diff
>>>>>> and
>>>>>>>> then
>>>>>>>>>>>> deleting items that are not included in the
new version. Someone
>>>>>>>>>> created a
>>>>>>>>>>>> Maven plugin to try to do this but it is
not the way I would
>>>>>> want
>>>>>>>> to
>>>>>>>>>> go at
>>>>>>>>>>>> all.
>>>>>>>>>>>>>>>> Sorry, I don't get it.  Why
won't the following work:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 0) Grab all of, say p.a.o/www/commons.apache.org
>>>>>>>>>>>>>>>> 1) check all of that into
an svn repo
>>>>>>>>>>>>>>>> 2) when I want to update,
say, math, I generate the content
>>>>>>>>>> locally,
>>>>>>>>>>>>>>>> copy it to the /math subtree
and check it in.
>>>>>>>>>>>>>>> There would need to be some extra
work done to ensure that
>>>>>>>> stale
>>>>>>>>>> files
>>>>>>>>>>>>>>> are deleted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I get it now.  In practice, with maven
sites, is this a big
>>>>>>>> deal?  I
>>>>>>>>>>>>> don't remember seeing lots of cruft accumulating
on p.a.o,
>>>>>> which
>>>>>>>>>>>>> would happen if this were common.  If
it is not that common,
>>>>>> then
>>>>>>>>>>>>> manual svn rm's would not be that onerous.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Phil
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For some projects, it would be
possible to just delete the
>>>>>>>> existing
>>>>>>>>>>>>>>> sub-tree and check the whole
new site in.
>>>>>>>>>>>>>>> [This can be done as one transaction
in svnmucc]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, for sites that retain
Javadoc etc. for older
>>>>>>>> releases, one
>>>>>>>>>>>>>>> would need to re-instate that
part of the tree somehow.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Given that svnpubsub immediately
publishes what is checked
>>>>>> in,
>>>>>>>> it
>>>>>>>>>>>>>>> might be sensible to have a parallel
staging directory tree
>>>>>>>> where
>>>>>>>>>>>>>>> files can be updated piecemeal
if necessary, and then use
>>>>>>>> svnmucc
>>>>>>>>>> to
>>>>>>>>>>>>>>> replace the live component subtree
with the staging
>>>>>> component
>>>>>>>>>> subtree
>>>>>>>>>>>>>>> as part of a single transaction.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There would need to be some co-ordination
between committers
>>>>>>>> when
>>>>>>>>>>>>>>> updating commons parent, as that
would affect the whole
>>>>>> tree.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes. This is why Logging used the
extpath approach where each
>>>>>>>>>>>> subproject commits directly to production.
Each release goes to
>>>>>> a
>>>>>>>>>> release
>>>>>>>>>>>> subdirectory under each subproject's directory.
 Then you can
>>>>>> just
>>>>>>>>>> perform
>>>>>>>>>>>> your maven site build to a local directory,
copy that into the
>>>>>>>>>> production
>>>>>>>>>>>> svn location, and commit it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See "Managing the subproject sites"
at
>>>>>>>>>>>> http://wiki.apache.org/logging/ManagingTheWebSite
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ralph
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>>>
>>> --
>>> Olivier Lamy
>>> Talend: http://coders.talend.com
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message