Apache OpenOffice (AOO) Bugzilla – Issue 57722
create the extensions.openoffice.org incubator project
Last modified: 2006-02-16 19:47:52 UTC
Hi Louis as requested, here is the issue requesting extensions.openoffice.org creation Thanks Laurent
accepting. done. Extensions is now created. Congratulations :-) What needs to be done: add it to the incubator roster of projects edit IZ component add index.html page. See http://www.openoffice.org/styles/index.html for information on this. I have templates there you can use. let me know how else I can help... ciao louis
There is a conflict with an existing CVS module extensions. extensions util/extensions This will lead to the same confusion we see with lingucomponent. I think another available name should be used.
hm. well, I already created the extensions project. :-( I'm open to name change, and would thus ask CollabNet to extirpate extensions/www/* and the project associated with it. Laurent, other name? Louis
Hi this issue has been discussed on dev list it has been noted by developeprs that this name will not interact with cvs at all, as the extension incubator project is not dedicated to provide any OOo source and interact with CVS at source level i can point the tread if needed reassigning to laurentgodard ('laurent' is not me)
Thanks for the hint to the dev@ooo discussion. I also think extensions is a good name. But unfortunately there is a conflict in the CVS repository between the project "extensions" with its subdirectory "extensions/www" and the alias "extensions" (util/extensions). One result of this conflict happened during the creation of the project. SourceCast created a directory www at util/extensions/www. The index.html was also created there: http://util.openoffice.org/source/browse/util/extensions/www/Attic/ I was able to create extensions/www and to put files index.html and atestfile.html in this directory. If you check out with "cvs co extensions/www" you shoudl get the correct content. But access to these files via http://extensions.openoffice.org/index.html or http://extensions.openoffice.org/atestfile.html doesn't work. You might want to contact Louis and/or support and ask what went wrong with the creation of the www content for the webserver. Have fun, Stefan
thanks st. Laurent, I strongly suggest we change the name. A new name might be "addons" or "plus" or whatever. (not whatever :-) ) We need also to ask CollabNet support to delete the project extensions/www/* , so as to eliminate confusion. best louis
hum give me some days to make the synthetesis and ask for new ideas say - this week end ?
sure. best Louis
I think we should follow both approaches. Laurent will start the discussion about an alternative name. We will see whether the web area of the extensions area can be activated. Support, could you please make sure that the now current content of extensions/www http://extensions.openoffice.org/source/browse/extensions/www/ is used for the published webcontent for the project "extensions". A clean cvs co extensions/www worked for me.
i wouldn't change the name because of technical problems. I have already volunteered (during the name discussion) to change the name of the util/extensions module if necessary because this name is not important but the name of the new project is important because of visibility to our users. We should go the best way with the best outcome and not the easiest one. Pleae let me know if i should rename the module util/extensions ...
rt -> jsc: Thanks for volunteering, but are you sure about what all would have to be changed and how to organize it? It would not be sufficient to remove that module and create a new one with all its content. What is your idea about correct aliases? We would have to assure that checking out with the aliases OpenOffice, OpenOffice1, and OpenOffice2 works as desired for old workspaces/milestones, on the other hand people probably want to check out the new incubator project with just 'cvs co extensions'.
rename or create a new module, adapt all dependencies (build.lst) and remove old util/extensions from cvs and from the build process. I don't know all details on the alias problem but i hope that we can solve them. If it is a real alias we should be able to use a separate name for the alias, probaly the process can be adapted. People who want to work with the new extension project can live with the long name extesnions/www when they check it out. This new module should normally never come into our build process. We should discuss this on the mailing list.
> I don't know all details on the alias problem but i hope that we can solve them. I'd guess that exactly this alias problem is what caused the trouble we are talking about. Therefore it is not a solution to first rename an existing module and than think about this (probable) root cause. If we have to get rid of the alias extensions -> util/extensions, a rename would not be sufficient. If OTOH it is sufficient to check out the new incubator project as extensions/www, we probably need not take any action.
> If OTOH it is sufficient to check out the new incubator project as extensions/www, we probably need not take any action. that exactly is what i thought - renaming the exisitng cvs module util/extensions would simple reduce potential confusion. But of course it should be possible to rename/remove a cvs module and the alias from the build process.
There is no such thing as "the build process". People are build OOo 1.1.5, OOo 2.0, OOo 2.0.1, end more. Of course we can remove a module from current builds, but we still have to support old ones.
Hi I'd like to settle the naming of the new project as soon as possible and not enter into discussions on the ontological nature of the "build process" :-) Cheers Louis
i agreed with Ruediger (have talked with him directly) that we don't see a problem when the new extensions project will never be used in the build process and when people working on this project check in out with extensions/www. If other people have still any concerns please communicate your concerns asap
hi this is a good compromise imho - http://extensions.openoffice.org for end users --> the most understandable - cvs extensions/www for maintainers and deeper involved people - they can live with that, i think Provided it does not disturb nor break anything, it's ok for me Laurent
With louis and lgodard we confirmed the existing problem and agreed that we need "support" to help us. Again: I was able to create extensions/www and to put files index.html and atestfile.html in this directory. If you check out with "cvs co extensions/www" you should will the correct content. But access to these files via http://extensions.openoffice.org/index.html or http://extensions.openoffice.org/atestfile.html doesn't work. Support, could you make sure that the htdocs area has the correct CVS files.
Iam working on this and will update you as soon as possible. Regards, Sachin -Helpdesk.
Updating status whiteboard. Regards, Sachin -Helpdesk
Hi Laurent, I apologise for the delay in responding for this issue iam yet to get a responce from my engineers. I will let u know as soon as possible. Regards, Sachin -Helpdesk.
add to 2587 to accelerate review.
All , When a project is created in CEE with CVS as the version control repository CEE creates a top level directory of the same name in the repository root. A special www directory is created below this which is used to store content for the CEE project. This is currently how CEE works. If the CVS module file has custom mappings that have the same module name as a project, these will conflict with the CEE scheme. OpenOffice has dozens of these module mappings. The following entry in CVSROOT/modules is causing this particular problem: extensions util/extensions I can attach the entire modules file if it is OK with the Domain Admin. Possible solutions include: 1) Remove the mappings in the CVSROOT/modules file. - This could disrupt existing processes but would be easy. 2) Don't use project names which already contain these mappings - There isn't any way to enforce this. It would need to be a convention. Let us know how you want to proceed with this. Thanks
sorry for being lost :( is it a problem if we use utils/extensions/www as that was discussed ? <joke>if extensions is a problem, lets take extension and redirect extensions to it </joke> well seems that i'll have to change the name that was agreed hum ... thinking to it Laurent
Laurent, this is stalling. Let's just use "addons". Yes? Louis
no, i disagree here. Addons is only one specific kind of extension and it is commonly used in this sense. This can't be communicated quite well. Laurent we should think independent of the technical problems about another name. I will also talk with the release engineers about renaming of the util/extensions code module. New possible names (i have brainstormed again with Mathias): extensionplace extensionhome extdev = extension development (similar to mozdev)
after some further investigation with Ruediger, i won't accept another name. We have the same situation fro example for the project "tools" and the module "util/tools" and it seems to work. Why is it not possible for "extensions" and "util/extensions"? We discussed the name "extensions" in detail and it is the best and most intuitive name for this project. The name is important because of it's visibility and i am not willing to take another name only to make it easy. Laurent forget the new names as long this question isn't answered.
Louis : please make the question answered seems it is possible
ani, support, could you follow up on this? Stefan's suggestion of 25 Nov. seem good. That was over a month ago... thanks louis
Hi Louis, I have asked the ops to let us know whether recreation of runtime would be a feasible solution for this issue. Will let you know as soon as i get a response from them. Regards, Sachin -Helpdesk.
This issue is tagged as Top issue by virtue of blocking Issue 2587. Hence escalated the internal issue.
I would be happy to hear about the result of the escalation of the internal issue.
Engineering ran some scripts to resolve this. I can access the following files now: http://extensions.openoffice.org/index.html or http://extensions.openoffice.org/atestfile.html Is this problem considered fixed for now?
laurent, would you want to try checking out and working on the project directories, please? thanks Louis
Hi all i tried co extensions/www modifying index.html ci modifcation appears on the extensions.openoffice.org URL Seems we're ok :) Yeeaaah Thanks a lot guys for your hard work i set to FIXED Laurent
closing thanks all. next step: add extensions to the list of incubator projects and make a major announcement :-)