You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2006/03/11 18:47:52 UTC
[PROPOSAL][all] Break dependency on commons-build
At the moment, each project depends on commons-build:
- maven.css - single commons css
- commons-site.jsl - single commons style
- menus.dtd - shared menu components
As the recent IO release has shown, this dependency isn't great when
releasing.
I propose we remove the css dependency as follows:
1) Add the following one line project.css to each project:
@import url("http://jakarta.apache.org/style/jakarta.css");
2) Upload jakarta.css to this location (I've created a suitable one)
which contains our colours and designs (eg. blue headers)
Each page in commons will then use the maven-base and maven-theme css
files as per default maven. The jakarta.css file then overrides these as
needed. Thus most users will see no change.
If the user is running a copy of the website on their own box and they
are offline, then the standard maven colours and design will be used
(eg. grey and red headers).
If we want to update all commons websites, we just update jakarta.css.
I propose we remove the menus.dtd dependency by just removing it. Users
will just have to click a couple more links to move between components.
IMHO, the simplicity of the resulting design overrides the loss of
functionality.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-03-12 at 11:38 -0800, Henri Yandell wrote:
> On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > I propose we remove the css dependency as follows:
> >
> > 1) Add the following one line project.css to each project:
> > @import url("http://jakarta.apache.org/style/jakarta.css");
>
> Why not use relative urls? Using absolutes will make it harder to test
> changes to the css.
I think the whole point is so that sites can be built without having the
commons-build directory checked out locally.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Henri Yandell <fl...@gmail.com>.
On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I propose we remove the css dependency as follows:
>
> 1) Add the following one line project.css to each project:
> @import url("http://jakarta.apache.org/style/jakarta.css");
Why not use relative urls? Using absolutes will make it harder to test
changes to the css.
>From jakarta.apache.org:
<link rel="stylesheet" href="/style/style.css" type="text/css"/>
> 2) Upload jakarta.css to this location (I've created a suitable one)
> which contains our colours and designs (eg. blue headers)
Where is jakarta.css going to go in SVN?
> Each page in commons will then use the maven-base and maven-theme css
> files as per default maven. The jakarta.css file then overrides these as
> needed. Thus most users will see no change.
Are maven-base and theme css's in svn too?
> If the user is running a copy of the website on their own box and they
> are offline, then the standard maven colours and design will be used
> (eg. grey and red headers).
Relative url :)
> If we want to update all commons websites, we just update jakarta.css.
>
> I propose we remove the menus.dtd dependency by just removing it. Users
> will just have to click a couple more links to move between components.
> IMHO, the simplicity of the resulting design overrides the loss of
> functionality.
+1.
Simplified site, simplified build.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Arnaud HERITIER <ah...@gmail.com>.
>
>
>
> I hope that a mavenite may be able to tell us if this helps us use maven
> 1.1 as I understood that the relative paths were a headache.
yes, it helps a lot.
I succesfully built the site with maven 1.1 (I just skipped the tests
because I have the same errors in IO as reported in the release thread).
We have problems with entities (in pom) because we removed xerces and with
entities with relative path (in xdoc) because of a bug in dom4j.
Arnaud
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
robert burrell donkin wrote:
> why not give it a try and see if it improves things?
Both [lang] and [io] main sites are now updated via this new mechanism.
Thus both [io] and [lang] now have no direct dependency on commons-build
when building, whether from an svn checkout or from a released dist.
The full information is here:
http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture
A key aspect of what I tried to do was KISS. It basically uses the
internet and web standards (like @import in CSS) to make the direct
connections rather than relative paths. The same is true of the entities
- http entities are better supported than relative ones.
The single central CSS should also prove very useful at ApacheCon time.
I hope that a mavenite may be able to tell us if this helps us use maven
1.1 as I understood that the relative paths were a headache.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-03-12 at 16:45 +0000, Stephen Colebourne wrote:
> IIRC, we've been advised against overuse of svn:externals before.
this is a classic use case for svn:externals (including a common
directory). i see any technical reason not to use it.
> The mechanism I've described is simple enough - just use the Internet for
> what it was supposed to be used for. And no duplicated files at all.
i played around with the svn:externals approach yesterday and the
problems with the resolution of entities in maven make it harder than it
should be. it's fragile and has taken a lot of maintenance over the
years so maybe it's time that we gave another approach a try.
generally speaking, hosting DTD's on apache hardware is very much
frowned up: DTD look ups eat a surprising amount of bandwidth. in this
case, though, i don't think that it should cause a problem.
why not give it a try and see if it improves things?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Niall Pemberton <ni...@gmail.com>.
On 3/12/06, Simon Kitching <sk...@apache.org> wrote:
> On Sun, 2006-03-12 at 11:36 -0800, Henri Yandell wrote:
> > On 3/12/06, Niall Pemberton <ni...@gmail.com> wrote:
> > > On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > > > IIRC, we've been advised against overuse of svn:externals before. The
> > > > mechanism I've described is simple enough - just use the Internet for
> > > > what it was supposed to be used for. And no duplicated files at all.
> > >
> > > I agree that lots of svn:externals for each component would be a PITA
> > > - but if we put everything in a single directory in commons-build then
> > > that would be one per component, which once added shouldn't need to
> > > ever change. One svn:external per component isn't overuse IMO and is
> > > exactly what its designed for.
> > >
> > > +1 to Sandy's suggestion from me.
> >
> > Biggest problem with svn externals is that they're not hooked into svn
> > moves. So have to be kept up to date when we move a component from one
> > place to another, or just change the svn url structure.
>
> Fair point.
>
> To give an example, a path "svn.apache.org/repos/asf/foo/bar" will break
> if foo is renamed to baz.
>
> Externals can take a revision#, eg
> "bar -r1000 http://svn.apache.org/repos/asf/foo/bar"
> however this still doesn't handle renames, as this syntax *first* causes
> svn to look for the path in the current revision of the repo, then track
> backwards on that object to find revision 1000.
>
> This should be fixable, though, by using "peg" syntax in the externals
> url. According to the svn book,
> http://svn.apache.org/repos/asf/foo/bar@1000
> should look into version 1000 of the repository to find the specified
> directory. This would make the externals URL safe against renames.
>From what I can see this means we would be tieing the svn:external to
a specified revision - which means if something in commons-build
changed then it wouldn't get picked up without re-doing the
svn:external - have got that right?
If that is the case, looks like a nightmare to me - we'll be forever
updating externals. I think if we created something like a
"shared-build" directory in commons-build then we could just link
svn:externals to that - anything that gets dropped into it, gets
picked up. Maybe we should do it through a versioned branch so that if
someone wants to change something that would break older versions
working, then they create a new versioned branch.
I think the "things getting renamed" if we used a directory wouldn't
be a big issue.
Niall
> http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
>
> Unfortunately I can't get "peg revisions" to work for me using svn 1.1.4
> on debian, though the documentation does say the functionality was added
> in release 1.1.
>
> Can anyone else get peg revisions to work? eg:
> svn cat
> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/project.xml@377182
>
> Cheers,
>
> Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-03-12 at 11:36 -0800, Henri Yandell wrote:
> On 3/12/06, Niall Pemberton <ni...@gmail.com> wrote:
> > On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > > IIRC, we've been advised against overuse of svn:externals before. The
> > > mechanism I've described is simple enough - just use the Internet for
> > > what it was supposed to be used for. And no duplicated files at all.
> >
> > I agree that lots of svn:externals for each component would be a PITA
> > - but if we put everything in a single directory in commons-build then
> > that would be one per component, which once added shouldn't need to
> > ever change. One svn:external per component isn't overuse IMO and is
> > exactly what its designed for.
> >
> > +1 to Sandy's suggestion from me.
>
> Biggest problem with svn externals is that they're not hooked into svn
> moves. So have to be kept up to date when we move a component from one
> place to another, or just change the svn url structure.
Fair point.
To give an example, a path "svn.apache.org/repos/asf/foo/bar" will break
if foo is renamed to baz.
Externals can take a revision#, eg
"bar -r1000 http://svn.apache.org/repos/asf/foo/bar"
however this still doesn't handle renames, as this syntax *first* causes
svn to look for the path in the current revision of the repo, then track
backwards on that object to find revision 1000.
This should be fixable, though, by using "peg" syntax in the externals
url. According to the svn book,
http://svn.apache.org/repos/asf/foo/bar@1000
should look into version 1000 of the repository to find the specified
directory. This would make the externals URL safe against renames.
http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
Unfortunately I can't get "peg revisions" to work for me using svn 1.1.4
on debian, though the documentation does say the functionality was added
in release 1.1.
Can anyone else get peg revisions to work? eg:
svn cat
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/project.xml@377182
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Henri Yandell <fl...@gmail.com>.
On 3/12/06, Niall Pemberton <ni...@gmail.com> wrote:
> On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > IIRC, we've been advised against overuse of svn:externals before. The
> > mechanism I've described is simple enough - just use the Internet for
> > what it was supposed to be used for. And no duplicated files at all.
>
> I agree that lots of svn:externals for each component would be a PITA
> - but if we put everything in a single directory in commons-build then
> that would be one per component, which once added shouldn't need to
> ever change. One svn:external per component isn't overuse IMO and is
> exactly what its designed for.
>
> +1 to Sandy's suggestion from me.
Biggest problem with svn externals is that they're not hooked into svn
moves. So have to be kept up to date when we move a component from one
place to another, or just change the svn url structure.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-03-12 at 19:31 +0000, Niall Pemberton wrote:
> On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > IIRC, we've been advised against overuse of svn:externals before. The
> > mechanism I've described is simple enough - just use the Internet for
> > what it was supposed to be used for. And no duplicated files at all.
>
> I agree that lots of svn:externals for each component would be a PITA
> - but if we put everything in a single directory in commons-build then
> that would be one per component, which once added shouldn't need to
> ever change. One svn:external per component isn't overuse IMO and is
> exactly what its designed for.
If svn:external is used, it must not point to the *trunk* branch of the
project, as that could undergo changes that would break checkouts of old
versions of projects. svn:external links should only point to *tag*
directories.
Of course that then makes life difficult on the trunk of a project.
Example:
commons-lang/trunk has an svn:externals link to
commons-build/tags/r1. This works nicely when commons-lang
is tagged for release; the tagdir has an external that points
to a nice stable version of commons-build. However obviously
the *trunk* of commons-lang will never see updates to
commons-build/trunk.
The alternate approach of having commons-lang/trunk have
an externals link to commons-build/trunk. This is a REALLY
bad idea, as when commons-lang is tagged for release it is
very easy to forget to change the svn:externals link. And
if commons-lang/tags/... contains an svn:external link to
commons-build/trunk then when someone checks it out later
and tries to build the site rebuild might fail (or just be
different) due to changes in commons-build/trunk.
I would prefer to avoid svn:externals *completely*, but if they must be
used then I suggest *never* linking to a trunk or branch, only a tag.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Niall Pemberton <ni...@gmail.com>.
On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> IIRC, we've been advised against overuse of svn:externals before. The
> mechanism I've described is simple enough - just use the Internet for
> what it was supposed to be used for. And no duplicated files at all.
I agree that lots of svn:externals for each component would be a PITA
- but if we put everything in a single directory in commons-build then
that would be one per component, which once added shouldn't need to
ever change. One svn:external per component isn't overuse IMO and is
exactly what its designed for.
+1 to Sandy's suggestion from me.
Niall
> Stehen
>
>
> Sandy McArthur wrote:
> > Seems to me we should use svn externals to link the files that would
> > be in commons-build so they appear as part of the checkout. This way
> > you don't have to get two things from svn to build a project's site
> > and we don't have the same files repeadted over and over.
> >
> > http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
> >
> > On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >
> >>At the moment, each project depends on commons-build:
> >>- maven.css - single commons css
> >>- commons-site.jsl - single commons style
> >>- menus.dtd - shared menu components
> >>
> >>As the recent IO release has shown, this dependency isn't great when
> >>releasing.
> >>
> >>
> >>I propose we remove the css dependency as follows:
> >>
> >>1) Add the following one line project.css to each project:
> >>@import url("http://jakarta.apache.org/style/jakarta.css");
> >>
> >>2) Upload jakarta.css to this location (I've created a suitable one)
> >>which contains our colours and designs (eg. blue headers)
> >>
> >>Each page in commons will then use the maven-base and maven-theme css
> >>files as per default maven. The jakarta.css file then overrides these as
> >>needed. Thus most users will see no change.
> >>
> >>If the user is running a copy of the website on their own box and they
> >>are offline, then the standard maven colours and design will be used
> >>(eg. grey and red headers).
> >>
> >>If we want to update all commons websites, we just update jakarta.css.
> >>
> >>
> >>I propose we remove the menus.dtd dependency by just removing it. Users
> >>will just have to click a couple more links to move between components.
> >>IMHO, the simplicity of the resulting design overrides the loss of
> >>functionality.
> >>
> >>Stephen
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Sandy McArthur
> >
> > "He who dares not offend cannot be honest."
> > - Thomas Paine
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
IIRC, we've been advised against overuse of svn:externals before. The
mechanism I've described is simple enough - just use the Internet for
what it was supposed to be used for. And no duplicated files at all.
Stehen
Sandy McArthur wrote:
> Seems to me we should use svn externals to link the files that would
> be in commons-build so they appear as part of the checkout. This way
> you don't have to get two things from svn to build a project's site
> and we don't have the same files repeadted over and over.
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
>
> On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
>>At the moment, each project depends on commons-build:
>>- maven.css - single commons css
>>- commons-site.jsl - single commons style
>>- menus.dtd - shared menu components
>>
>>As the recent IO release has shown, this dependency isn't great when
>>releasing.
>>
>>
>>I propose we remove the css dependency as follows:
>>
>>1) Add the following one line project.css to each project:
>>@import url("http://jakarta.apache.org/style/jakarta.css");
>>
>>2) Upload jakarta.css to this location (I've created a suitable one)
>>which contains our colours and designs (eg. blue headers)
>>
>>Each page in commons will then use the maven-base and maven-theme css
>>files as per default maven. The jakarta.css file then overrides these as
>>needed. Thus most users will see no change.
>>
>>If the user is running a copy of the website on their own box and they
>>are offline, then the standard maven colours and design will be used
>>(eg. grey and red headers).
>>
>>If we want to update all commons websites, we just update jakarta.css.
>>
>>
>>I propose we remove the menus.dtd dependency by just removing it. Users
>>will just have to click a couple more links to move between components.
>>IMHO, the simplicity of the resulting design overrides the loss of
>>functionality.
>>
>>Stephen
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
>
> --
> Sandy McArthur
>
> "He who dares not offend cannot be honest."
> - Thomas Paine
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Sandy McArthur <sa...@apache.org>.
Seems to me we should use svn externals to link the files that would
be in commons-build so they appear as part of the checkout. This way
you don't have to get two things from svn to build a project's site
and we don't have the same files repeadted over and over.
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> At the moment, each project depends on commons-build:
> - maven.css - single commons css
> - commons-site.jsl - single commons style
> - menus.dtd - shared menu components
>
> As the recent IO release has shown, this dependency isn't great when
> releasing.
>
>
> I propose we remove the css dependency as follows:
>
> 1) Add the following one line project.css to each project:
> @import url("http://jakarta.apache.org/style/jakarta.css");
>
> 2) Upload jakarta.css to this location (I've created a suitable one)
> which contains our colours and designs (eg. blue headers)
>
> Each page in commons will then use the maven-base and maven-theme css
> files as per default maven. The jakarta.css file then overrides these as
> needed. Thus most users will see no change.
>
> If the user is running a copy of the website on their own box and they
> are offline, then the standard maven colours and design will be used
> (eg. grey and red headers).
>
> If we want to update all commons websites, we just update jakarta.css.
>
>
> I propose we remove the menus.dtd dependency by just removing it. Users
> will just have to click a couple more links to move between components.
> IMHO, the simplicity of the resulting design overrides the loss of
> functionality.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
> What happens when you build offline?
The build fails. You could remove the offending link and entity from
navigation.xml and then it would work (just without the shared menu).
I'm planning on applying this to [lang] and [collections] next.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Phil Steitz <ph...@gmail.com>.
What happens when you build offline? Personally, I think it is fine
to depend on connection for site build, so am +1 in any case.
Phil
On 3/12/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Stephen Colebourne wrote:
> > Could we publish menus.dtd at a fixed URL and solve the problem that way?
>
> Well, this works. Change the relative declaration at the top of the
> navigation.xml to this:
>
> <!DOCTYPE org.apache.commons.menus SYSTEM
> 'http://jakarta.apache.org/commons/build/maven-build.dtd'>
>
> And change &common-menus to &commons. And Voila! Now commons-io has no
> dependency on commons-build.
>
> This change just means that changing the definition of the shared menus
> across commons involves uploading the file to the website.
>
> The main commons site will still need a dependency on commons-build at
> the moment, as it uses many more entities, and I haven't set those up.
> Components can change however.
>
> BTW, for things like the ApacheCon image, we can just add a background
> image to the top of the left navigation column using the shared CSS. It
> will update everywhere instantly without any site regeneration!
That is a slick idea, can the image link target be updated that way?
Phil
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-03-12 at 18:30 +0100, Dennis Lundberg wrote:
> Stephen Colebourne wrote:
> > Stephen Colebourne wrote:
> >> Could we publish menus.dtd at a fixed URL and solve the problem that way?
> >
> > Well, this works. Change the relative declaration at the top of the
> > navigation.xml to this:
> >
> > <!DOCTYPE org.apache.commons.menus SYSTEM
> > 'http://jakarta.apache.org/commons/build/maven-build.dtd'>
> >
> > And change &common-menus to &commons. And Voila! Now commons-io has no
> > dependency on commons-build.
>
> Cool!
A different approach to this problem would be to publish commons-build
as a maven "bundle" to ibiblio. The build could then declare a
"dependency" on this bundle, and unpack it into the site being built.
Ant builds could presumably use "ant get" to download it, though that's
not as elegant as maven's dependency declaration.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Dennis Lundberg <de...@apache.org>.
Stephen Colebourne wrote:
> Stephen Colebourne wrote:
>> Could we publish menus.dtd at a fixed URL and solve the problem that way?
>
> Well, this works. Change the relative declaration at the top of the
> navigation.xml to this:
>
> <!DOCTYPE org.apache.commons.menus SYSTEM
> 'http://jakarta.apache.org/commons/build/maven-build.dtd'>
>
> And change &common-menus to &commons. And Voila! Now commons-io has no
> dependency on commons-build.
Cool!
> This change just means that changing the definition of the shared menus
> across commons involves uploading the file to the website.
Each component will still need to have its site rebuilt and republished,
to reflect the changes in the menus.
> The main commons site will still need a dependency on commons-build at
> the moment, as it uses many more entities, and I haven't set those up.
> Components can change however.
The commons site *is* in commons-build, right?
> BTW, for things like the ApacheCon image, we can just add a background
> image to the top of the left navigation column using the shared CSS. It
> will update everywhere instantly without any site regeneration!
>
> Stephen
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Stephen Colebourne wrote:
> Could we publish menus.dtd at a fixed URL and solve the problem that way?
Well, this works. Change the relative declaration at the top of the
navigation.xml to this:
<!DOCTYPE org.apache.commons.menus SYSTEM
'http://jakarta.apache.org/commons/build/maven-build.dtd'>
And change &common-menus to &commons. And Voila! Now commons-io has no
dependency on commons-build.
This change just means that changing the definition of the shared menus
across commons involves uploading the file to the website.
The main commons site will still need a dependency on commons-build at
the moment, as it uses many more entities, and I haven't set those up.
Components can change however.
BTW, for things like the ApacheCon image, we can just add a background
image to the top of the left navigation column using the shared CSS. It
will update everywhere instantly without any site regeneration!
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
New version of site updated to
http://people.apache.org/~scolebourne/commons-io/site/
This includes a simplified shared menu. The new design greatly reduces
the clutter (there were too many submenus before). It also places the
shared menu below the project menu, which is correct.
I have removed
- the contributors list (use the team list of the project, or navigate
to commons)
- the charter (navigate to commons)
- jakarta get involved (use volunteering which links to get involved)
- mailing lists (use project mailing lists)
- related (not related to project, but related to commons)
I would still like to see some way to remove any dependency on
commons-build. At the moment, my release plan is
a) delete commons-build dependency from navigation.xml
b) build dist
c) reinstate dependency
d) build site
This isn't fun.
Could we publish menus.dtd at a fixed URL and solve the problem that way?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
>>All I can think is that its caused by no longer using the commons-site.jsl.
>>
> Oh crap, I think that is the case. I remember fussing with this:
>
> <jsl:applyTemplates select="$nav/body/menu[@type='header']"/>
> <jsl:applyTemplates select="$nav/body/menu[not(@type)] | $nav/body/search"/>
> <jsl:applyTemplates select="$projectNav/body/menu"/>
> <jsl:applyTemplates select="$nav/body/menu[@type='footer']"/>
>
> when getting the jsl to work with xdoc 1.9. I think it is because the
> entities use the type attrbute that the stock jsl does not pay
> attention to.
I'd just got to the same conclusion. I've got a solution for the moment.
It will move the AboutUs menu to the bottom, but thats no bad thing. My
change will also sort out the excess of external link symbols.
(I think this is a bug in the xdoc plugin - it doesn't actually put
header things first)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Phil Steitz <ph...@gmail.com>.
On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Dennis Lundberg wrote:
> > Stephen Colebourne wrote:
> > It looks good. Personally I like this l&f better than the "old" one, but
> > that's a matter of taste I guess.
> I deliberately chose to 'enhance' a few things :-)
>
> > - The breadcrumbs line uses a smaller font with less padding, in your
> > example
> > - Copyright notice is now smaller and to the right instead of left
> > - Navbar headings are now underlined
> > - Navbar has arrows indicating folded menus, for "Project Info" and
> > "Project Reports"
> > - Icons for external links have been added
> > - The content area seem identical to me.
> Deliberate
>
> > - Links in the non-content areas have a slightly different color
> Ah. Maybe should make a little brighter, although the old colour was too
> bright IMHO.
>
> > - The sections "About us" and "Commons Resources (Unofficial)" are
> > missing from the navbar. I guess this is due to not using the menus from
> > commons-build.
> This is a problem, and I can't figure out why. You may be able to help
> here. No matter what entity I use, the sections aren't picked up.
>
> All I can think is that its caused by no longer using the commons-site.jsl.
>
Oh crap, I think that is the case. I remember fussing with this:
<jsl:applyTemplates select="$nav/body/menu[@type='header']"/>
<jsl:applyTemplates select="$nav/body/menu[not(@type)] | $nav/body/search"/>
<jsl:applyTemplates select="$projectNav/body/menu"/>
<jsl:applyTemplates select="$nav/body/menu[@type='footer']"/>
when getting the jsl to work with xdoc 1.9. I think it is because the
entities use the type attrbute that the stock jsl does not pay
attention to.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Dennis Lundberg wrote:
> Stephen Colebourne wrote:
> It looks good. Personally I like this l&f better than the "old" one, but
> that's a matter of taste I guess.
I deliberately chose to 'enhance' a few things :-)
> - The breadcrumbs line uses a smaller font with less padding, in your
> example
> - Copyright notice is now smaller and to the right instead of left
> - Navbar headings are now underlined
> - Navbar has arrows indicating folded menus, for "Project Info" and
> "Project Reports"
> - Icons for external links have been added
> - The content area seem identical to me.
Deliberate
> - Links in the non-content areas have a slightly different color
Ah. Maybe should make a little brighter, although the old colour was too
bright IMHO.
> - The sections "About us" and "Commons Resources (Unofficial)" are
> missing from the navbar. I guess this is due to not using the menus from
> commons-build.
This is a problem, and I can't figure out why. You may be able to help
here. No matter what entity I use, the sections aren't picked up.
All I can think is that its caused by no longer using the commons-site.jsl.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Dennis Lundberg <de...@apache.org>.
Stephen Colebourne wrote:
> Phil Steitz wrote:
>> I am +1 on the style stuff. By all means, lets get rid of
>> commons-site.jsl. If you personally are OK with the l&f that you can
>> get, this will probably be fine, since IIRC, you were the one with
>> reservations in the past on just using the maven classic syle. That
>> will get rid of the xdoc 1.9.2 requirement. Can you post an example?
>
> See http://people.apache.org/~scolebourne/commons-io/site/
> Its pretty close to the current commons site
It looks good. Personally I like this l&f better than the "old" one, but
that's a matter of taste I guess.
If we are aiming for something that looks as close to the original as
possible, there are a few things that are different:
- The breadcrumbs line uses a smaller font with less padding, in your
example
- Copyright notice is now smaller and to the right instead of left
- Links in the non-content areas have a slightly different color
- Navbar headings are now underlined
- The sections "About us" and "Commons Resources (Unofficial)" are
missing from the navbar. I guess this is due to not using the menus from
commons-build.
- Navbar has arrows indicating folded menus, for "Project Info" and
"Project Reports"
- Icons for external links have been added
The content area seem identical to me.
Let me know I can help with something.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Stephen Colebourne wrote:
> See http://people.apache.org/~scolebourne/commons-io/site/
> Its pretty close to the current commons site
BTW, to achieve this I checked in the following to jakarta-site
- docs/style/jakarta-maven.css
- docs/images/nw_maj_rond.gif
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Phil Steitz wrote:
> I am +1 on the style stuff. By all means, lets get rid of
> commons-site.jsl. If you personally are OK with the l&f that you can
> get, this will probably be fine, since IIRC, you were the one with
> reservations in the past on just using the maven classic syle. That
> will get rid of the xdoc 1.9.2 requirement. Can you post an example?
See http://people.apache.org/~scolebourne/commons-io/site/
Its pretty close to the current commons site
> The menus is giving me a little hesitation, though I want to support
> the completely independent builds objective. Maybe we can just agree
> to duplicate the basic stuff into the individual navs.
Possibly. Prefer not to though. Robert indicated he had an idea too. For
now, commons-io will still use commons-build for the live website, but
not for that in the download (which is a pain as it requires fiddling
with the fles)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Phil Steitz <ph...@gmail.com>.
I am +1 on the style stuff. By all means, lets get rid of
commons-site.jsl. If you personally are OK with the l&f that you can
get, this will probably be fine, since IIRC, you were the one with
reservations in the past on just using the maven classic syle. That
will get rid of the xdoc 1.9.2 requirement. Can you post an example?
The menus is giving me a little hesitation, though I want to support
the completely independent builds objective. Maybe we can just agree
to duplicate the basic stuff into the individual navs. The things that
I would personally not like to see go are the "About us..." at the
top and "General Information" bits. Maybe there is a more clever way
(other than moving to m2 ;-) to get the necessary files assembled at
build time. In the past, I thought about playing with the scm plugin
to update duplicate local copies, but never did this, because I
thought a cleaner solution should be possible. The nav dependency is
also the reason that maven 1.1 does not work at present.
Phil
On 3/11/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> At the moment, each project depends on commons-build:
> - maven.css - single commons css
> - commons-site.jsl - single commons style
> - menus.dtd - shared menu components
>
> As the recent IO release has shown, this dependency isn't great when
> releasing.
>
>
> I propose we remove the css dependency as follows:
>
> 1) Add the following one line project.css to each project:
> @import url("http://jakarta.apache.org/style/jakarta.css");
>
> 2) Upload jakarta.css to this location (I've created a suitable one)
> which contains our colours and designs (eg. blue headers)
>
> Each page in commons will then use the maven-base and maven-theme css
> files as per default maven. The jakarta.css file then overrides these as
> needed. Thus most users will see no change.
>
> If the user is running a copy of the website on their own box and they
> are offline, then the standard maven colours and design will be used
> (eg. grey and red headers).
>
> If we want to update all commons websites, we just update jakarta.css.
>
>
> I propose we remove the menus.dtd dependency by just removing it. Users
> will just have to click a couple more links to move between components.
> IMHO, the simplicity of the resulting design overrides the loss of
> functionality.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL][all] Break dependency on commons-build
Posted by Dennis Lundberg <de...@apache.org>.
Stephen Colebourne wrote:
> At the moment, each project depends on commons-build:
> - maven.css - single commons css
> - commons-site.jsl - single commons style
> - menus.dtd - shared menu components
>
> As the recent IO release has shown, this dependency isn't great when
> releasing.
I agree that the current setup is less than optimal, but I have two
reservations
1. Are you sure that a component build only relies on these 3 files (+
the menus folder)? To me it seems that there are more files in
commons-build that would be picked up by a component. Perhaps this only
happens when a component extends the project.xml in commons-build? This
only affects chain at the moment, but it should be investigated.
2. Do we want to try this now? This would have to be made fairly
transparent for each component. Otherwise we will have complaints like
"it's difficult to build component X without common-build"
instead of
"it's difficult to build component X with common-build"
> I propose we remove the css dependency as follows:
>
> 1) Add the following one line project.css to each project:
> @import url("http://jakarta.apache.org/style/jakarta.css");
>
> 2) Upload jakarta.css to this location (I've created a suitable one)
> which contains our colours and designs (eg. blue headers)
>
> Each page in commons will then use the maven-base and maven-theme css
> files as per default maven. The jakarta.css file then overrides these as
> needed. Thus most users will see no change.
>
> If the user is running a copy of the website on their own box and they
> are offline, then the standard maven colours and design will be used
> (eg. grey and red headers).
>
> If we want to update all commons websites, we just update jakarta.css.
+1
I'd be glad to help test/develop this.
> I propose we remove the menus.dtd dependency by just removing it. Users
> will just have to click a couple more links to move between components.
> IMHO, the simplicity of the resulting design overrides the loss of
> functionality.
+0
Can't really see how this would look, perhaps you can provide an example?
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org