incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly
Date Wed, 30 Nov 2011 17:10:59 GMT
On 11/30/11 1:31 PM, Rob Weir wrote:
> 2011/11/30 Jürgen Schmidt<>:
>> Hi,
>> somebody has already asked for the OOo NetBeans plugin that is a useful tool
>> for extensions developers. And it seems that there is interest to improve
>> the plugin and make it ready for the latest NetBeans versions. The source
>> code is part of the SGA but not yet available in our repo.
>> I have a general question. Where do we want to host such code or such sub
>> projects that are somewhat independent of the office code and should be kept
>> separately from my point of view. Means i wouldn't check in these projects
>> under trunk.
>> Instead i would propose a further svn tree where we can host such projects.
>> But i am not sure which name would be appropriate.
> Maybe just call it "extensions" ?  This could be the root for
> "standard extensions" that are produced by this project.  Some might
> be app dev related. But we might have other standard extensions in the
> future, e.g., a CMIS extension using Apache Chemistry.

i thought about "extensions" but in this particular case it is not an 
extension in the classical manner. But it is a developer tool for 
extensions and could be of course hosted there as well.

>> In this specific case it is a development tool for extension developers and
>> i can think of a similar tool for Eclipse in the future. How about a further
>> svn tree "devtools".
> Another question is how we think these extensions would be released?
> As part of (or in sync with) and AOO release?  If so, we might want
> this under the same trunk dir, so they can be easily tagged and
> branched with the reset of the AOO release.  But if we see these
> extensions as having an independent release cycle, not tied to AOO,
> then maybe they have an independent SVN tree.

I think we will not release such a dev tool with the office. We will 
potentially align it if necessary and if changes in the office require 
changes in the NB plugin or other potential extensions as well. But in 
general we should keep this independent. It allows us more flexibility.

I would prefer a new SVN tree and if nobody raised any concerns i would 
move forward with a further "extensions" tree besides "trunk".


View raw message