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 Fri, 14 Dec 2012 23:10:12 GMT
/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
View raw message