commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Tue, 18 Dec 2012 04:21:55 GMT
On 12/17/12 5:55 AM, Olivier Lamy wrote:
> ETA of the migration:
> collections and lang done.
>
> results:
> * http://people.apache.org/~olamy/commons/lang/
> * http://people.apache.org/~olamy/commons/collections/
>
> As Gary suggested old javadocs are
> http://people.apache.org/~olamy/commons/lang/javadocs
>
> NOTE I didn't import all previous versions. Does it make sense ?

Makes sense to me.  Older javadocs can be retrieved from the archives.

THANKS for jumping on this, Olivier!

Other than helping getting site builds working where they may be
broken, what can the rest of us do to help?

Phil
>
> digester I have issues while building trunk
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
> (default-testCompile) on project commons-digester3-ap: Compilation
> failure: Compilation failure:
> [ERROR] error: Impossible to generate class
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
> Attempt to recreate a file for type
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
> [ERROR] error: Impossible to generate class
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
> Attempt to recreate a file for type
> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> So I stop for it as no idea on WTF here
>
> 2012/12/15 Olivier Lamy <olamy@apache.org>:
>> 2012/12/15 Olivier Lamy <olamy@apache.org>:
>>> 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/.
>> I will start with digester and collections.
>> As I can see there is a lot of content deployed manually. I think
>> about versionned documentation
>> (http://commons.apache.org/digester/commons-digester-3.1) so this will
>> need to be imported manually 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
>>>>
>>
>>
>> --
>> 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