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 00:33:51 GMT
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


Mime
View raw message