commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Fri, 14 Dec 2012 23:14:53 GMT
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.

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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message