You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2011/11/22 19:32:57 UTC
Re: svn commit: r1203307 - in /aries/trunk/blueprint:
blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/
blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Hi Dan, I'm just catching up with what you're doing here. Back in
March we spent some time figuring out how to implement the OSGi
Semantic Versioning policy in our Maven build and release process. Zoe
documented it here:
http://aries.apache.org/development/versionpolicy.html
based discussions on the list, with the last one being here:
http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661.27234.33.camel%40meschbix%3E
There are some disparities with what you've change w.r.t what was
decided back then. I've made a comment in-line to this commit.
Cheers,
Jeremy
On 17 November 2011 17:59, <dk...@apache.org> wrote:
> Author: dkulp
> Date: Thu Nov 17 17:59:48 2011
> New Revision: 1203307
>
> URL: http://svn.apache.org/viewvc?rev=1203307&view=rev
> Log:
> Add a testcase for the Part1 fix for ARIES-626
> Update itests pom to use the versions of the blueprint stuff build in
> the build.
>
> Added:
> aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java (with props)
> aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd (with props)
> aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd (with props)
> Modified:
> aries/trunk/blueprint/blueprint-bundle/pom.xml
> aries/trunk/blueprint/blueprint-itests/pom.xml
> aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/config.xml
> aries/trunk/blueprint/blueprint-testbundleb/src/main/resources/OSGI-INF/blueprint/config.xml
>
> Modified: aries/trunk/blueprint/blueprint-bundle/pom.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-bundle/pom.xml?rev=1203307&r1=1203306&r2=1203307&view=diff
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-bundle/pom.xml (original)
> +++ aries/trunk/blueprint/blueprint-bundle/pom.xml Thu Nov 17 17:59:48 2011
> @@ -111,25 +111,25 @@
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.api</artifactId>
> - <version>0.3</version>
> + <version>0.3.2-SNAPSHOT</version>
This should stay at 0.3 as there is no difference between trunk and
0.3. blueprint 0.3.1 was released before we moved to the 'release by
bundle' process so it ended up releasing blueprint-api 0.3.1 even
there were no changes in it over 0.3. Can you describe how you have
decided what versions to use here and below? They really should be
depending on the released artifact. Thanks.
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.annotation.api</artifactId>
> - <version>0.3</version>
> + <version>0.3.3-SNAPSHOT</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.core</artifactId>
> - <version>0.4</version>
> + <version>0.4.1-SNAPSHOT</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.cm</artifactId>
> - <version>0.3.2</version>
> + <version>0.3.3-SNAPSHOT</version>
> <scope>provided</scope>
> </dependency>
> <dependency>
>
> Modified: aries/trunk/blueprint/blueprint-itests/pom.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-itests/pom.xml?rev=1203307&r1=1203306&r2=1203307&view=diff
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-itests/pom.xml (original)
> +++ aries/trunk/blueprint/blueprint-itests/pom.xml Thu Nov 17 17:59:48 2011
> @@ -60,13 +60,13 @@
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint</artifactId>
> <scope>test</scope>
> - <version>0.4</version>
> + <version>0.4.1-SNAPSHOT</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.jexl.evaluator</artifactId>
> <scope>test</scope>
> - <version>0.1.0</version>
> + <version>0.1.1-SNAPSHOT</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries</groupId>
> @@ -78,19 +78,19 @@
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.sample</artifactId>
> <scope>test</scope>
> - <version>0.4</version>
> + <version>0.3.3-SNAPSHOT</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.testbundlea</artifactId>
> <scope>test</scope>
> - <version>0.3.2</version>
> + <version>0.3.3-SNAPSHOT</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.testbundleb</artifactId>
> <scope>test</scope>
> - <version>0.3.2</version>
> + <version>0.3.3-SNAPSHOT</version>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.testsupport</groupId>
> @@ -179,25 +179,37 @@
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.testquiescebundle</artifactId>
> - <version>0.3.2</version>
> + <version>0.3.3-SNAPSHOT</version>
> <type>bundle</type>
> <scope>compile</scope>
> </dependency>
> <dependency>
> + <groupId>org.apache.aries.blueprint</groupId>
> + <artifactId>org.apache.aries.blueprint.api</artifactId>
> + <version>0.3.2-SNAPSHOT</version>
> + <scope>compile</scope>
> + </dependency>
> + <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.core</artifactId>
> - <version>0.4</version>
> + <version>0.4.1-SNAPSHOT</version>
> <type>bundle</type>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.apache.aries.blueprint</groupId>
> <artifactId>org.apache.aries.blueprint.cm</artifactId>
> - <version>0.3.2</version>
> + <version>0.3.3-SNAPSHOT</version>
> <type>bundle</type>
> <scope>compile</scope>
> </dependency>
> <dependency>
> + <groupId>org.apache.aries.blueprint</groupId>
> + <artifactId>blueprint-parser</artifactId>
> + <scope>provided</scope>
> + <version>0.4.1-SNAPSHOT</version>
> + </dependency>
> + <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>commons-jexl</artifactId>
> <version>2.0</version>
> @@ -210,6 +222,9 @@
> <testResource>
> <directory>${project.build.directory}/test-resources</directory>
> </testResource>
> + <testResource>
> + <directory>src/test/resources</directory>
> + </testResource>
> </testResources>
> <plugins>
> <plugin>
>
> Added: aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java?rev=1203307&view=auto
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java (added)
> +++ aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java Thu Nov 17 17:59:48 2011
> @@ -0,0 +1,76 @@
> +/**
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License. You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.aries.blueprint.testbundlea;
> +
> +import java.net.URL;
> +import java.util.Collections;
> +import java.util.List;
> +import java.util.Set;
> +
> +import org.apache.aries.blueprint.NamespaceHandler;
> +import org.apache.aries.blueprint.ParserContext;
> +import org.apache.aries.blueprint.PassThroughMetadata;
> +import org.apache.aries.blueprint.mutable.MutableBeanMetadata;
> +import org.apache.aries.blueprint.mutable.MutableRefMetadata;
> +import org.osgi.service.blueprint.reflect.BeanMetadata;
> +import org.osgi.service.blueprint.reflect.ComponentMetadata;
> +import org.osgi.service.blueprint.reflect.Metadata;
> +import org.osgi.service.blueprint.reflect.RefMetadata;
> +
> +import org.w3c.dom.Attr;
> +import org.w3c.dom.Element;
> +import org.w3c.dom.Node;
> +
> +public class NSHandlerFour implements NamespaceHandler{
> + public static String NSURI = "http://ns.handler.four";
> + private static String ELT_NAME = "nshandlerfour";
> + private static String ATTRIB_ID = "id";
> +
> +
> + public static class Four {
> + public Four() {
> + }
> + }
> + //process elements
> + public Metadata parse(Element element, ParserContext context) {
> + Metadata retval = null;
> + if( element.getLocalName().equals(ELT_NAME) ) {
> + final String id = element.getAttributeNS(NSURI, ATTRIB_ID);
> + MutableBeanMetadata bm = context.createMetadata(MutableBeanMetadata.class);
> + bm.setId(id);
> + bm.setClassName(Four.class.getName());
> + retval = bm;
> + }
> + return retval;
> + }
> +
> + //supply schema back to blueprint.
> + public URL getSchemaLocation(String namespace) {
> + return this.getClass().getResource("nshandlerfour.xsd");
> + }
> +
> + public Set<Class> getManagedClasses() {
> + Class cls = Four.class;
> + return Collections.singleton(cls);
> + }
> +
> + public ComponentMetadata decorate(Node node, ComponentMetadata component,
> + ParserContext context) {
> + return component;
> + }
> +
> +}
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/NSHandlerFour.java
> ------------------------------------------------------------------------------
> svn:keywords = Rev Date
>
> Modified: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/config.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/config.xml?rev=1203307&r1=1203306&r2=1203307&view=diff
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/config.xml (original)
> +++ aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/config.xml Thu Nov 17 17:59:48 2011
> @@ -27,6 +27,8 @@
>
> <bean id="NSHandlerThree" class="org.apache.aries.blueprint.testbundlea.NSHandlerThree">
> </bean>
> + <bean id="NSHandlerFour" class="org.apache.aries.blueprint.testbundlea.NSHandlerFour">
> + </bean>
>
> <service interface="org.apache.aries.blueprint.NamespaceHandler" ref="NSHandlerOne">
> <service-properties>
> @@ -45,6 +47,11 @@
> <entry key="osgi.service.blueprint.namespace" value="http://ns.handler.three"/>
> </service-properties>
> </service>
> + <service interface="org.apache.aries.blueprint.NamespaceHandler" ref="NSHandlerFour">
> + <service-properties>
> + <entry key="osgi.service.blueprint.namespace" value="http://ns.handler.four"/>
> + </service-properties>
> + </service>
>
> </blueprint>
>
>
> Added: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd?rev=1203307&view=auto
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd (added)
> +++ aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd Thu Nov 17 17:59:48 2011
> @@ -0,0 +1,35 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> + Licensed to the Apache Software Foundation (ASF) under one or more
> + contributor license agreements. See the NOTICE file distributed with
> + this work for additional information regarding copyright ownership.
> + The ASF licenses this file to You under the Apache License, Version 2.0
> + (the "License"); you may not use this file except in compliance with
> + the License. You may obtain a copy of the License at
> +
> + http://www.apache.org/licenses/LICENSE-2.0
> +
> + Unless required by applicable law or agreed to in writing, software
> + distributed under the License is distributed on an "AS IS" BASIS,
> + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + See the License for the specific language governing permissions and
> + limitations under the License.
> +-->
> +<schema xmlns="http://www.w3.org/2001/XMLSchema"
> + targetNamespace="http://ns.handler.four"
> + xmlns:tns="http://ns.handler.four"
> + xmlns:imp="http://ns.handler.four.import"
> + xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> + elementFormDefault="qualified"
> + attributeFormDefault="qualified" >
> + <import schemaLocation="nshandlerfourimport.xsd"
> + namespace="http://ns.handler.four.import"/>
> + <element name="nshandlerfour">
> + <complexType>
> + <sequence>
> + <element name="stuff" type="imp:Imported"/>
> + </sequence>
> + <attribute name="id" type="xsd:string"/>
> + </complexType>
> + </element>
> +</schema>
> \ No newline at end of file
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd
> ------------------------------------------------------------------------------
> svn:keywords = Rev Date
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfour.xsd
> ------------------------------------------------------------------------------
> svn:mime-type = text/xml
>
> Added: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd?rev=1203307&view=auto
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd (added)
> +++ aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd Thu Nov 17 17:59:48 2011
> @@ -0,0 +1,30 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> + Licensed to the Apache Software Foundation (ASF) under one or more
> + contributor license agreements. See the NOTICE file distributed with
> + this work for additional information regarding copyright ownership.
> + The ASF licenses this file to You under the Apache License, Version 2.0
> + (the "License"); you may not use this file except in compliance with
> + the License. You may obtain a copy of the License at
> +
> + http://www.apache.org/licenses/LICENSE-2.0
> +
> + Unless required by applicable law or agreed to in writing, software
> + distributed under the License is distributed on an "AS IS" BASIS,
> + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + See the License for the specific language governing permissions and
> + limitations under the License.
> +-->
> +<schema xmlns="http://www.w3.org/2001/XMLSchema"
> + targetNamespace="http://ns.handler.four.import"
> + xmlns:tns="http://ns.handler.four.import"
> + xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> + elementFormDefault="unqualified"
> + attributeFormDefault="unqualified" >
> +
> + <complexType name="Imported">
> + <sequence>
> + <element name="stuff" type="xsd:string"/>
> + </sequence>
> + </complexType>
> +</schema>
> \ No newline at end of file
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd
> ------------------------------------------------------------------------------
> svn:keywords = Rev Date
>
> Propchange: aries/trunk/blueprint/blueprint-testbundlea/src/main/resources/org/apache/aries/blueprint/testbundlea/nshandlerfourimport.xsd
> ------------------------------------------------------------------------------
> svn:mime-type = text/xml
>
> Modified: aries/trunk/blueprint/blueprint-testbundleb/src/main/resources/OSGI-INF/blueprint/config.xml
> URL: http://svn.apache.org/viewvc/aries/trunk/blueprint/blueprint-testbundleb/src/main/resources/OSGI-INF/blueprint/config.xml?rev=1203307&r1=1203306&r2=1203307&view=diff
> ==============================================================================
> --- aries/trunk/blueprint/blueprint-testbundleb/src/main/resources/OSGI-INF/blueprint/config.xml (original)
> +++ aries/trunk/blueprint/blueprint-testbundleb/src/main/resources/OSGI-INF/blueprint/config.xml Thu Nov 17 17:59:48 2011
> @@ -21,6 +21,8 @@
> xmlns:one="http://ns.handler.one"
> xmlns:two="http://ns.handler.two"
> xmlns:three="http://ns.handler.three"
> + xmlns:four="http://ns.handler.four"
> + xmlns:fourim="http://ns.handler.four.import"
> default-availability="optional">
>
> <!-- Default test.. no other ns interaction. -->
> @@ -62,5 +64,13 @@
> <reference activation="eager"
> availability="optional"
> interface="org.apache.aries.blueprint.testbundlea.InterfaceWithDependency" />
> +
> + <!-- NShandler four test, make sure the schema can be parsed - ARIES-626 Part 1 -->
> + <four:nshandlerfour four:id="FOUR">
> + <four:stuff>
> + <stuff xmlns="">foo</stuff>
> + </four:stuff>
> + </four:nshandlerfour>
> +
> </blueprint>
>
>
>
>
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
I went ahead and opened ARIES-798 and committed some changes to blueprint that implement the profile idea.
By default the build is against released versions.
If you want to build against snapshots run
mvn clean install -Pdev
For some reason it doesn't seem to be possible to put the stable versions in a profile (each project seems to work but a project that is a dependency doesn't seem to have defined version properties). Therefore in the dev profile any transitive dependencies will be the stable versions, not snapshots. We could make all the dependencies provided so you have to specify the versions in each project, but I don't think that would gain us much.
This is in rev 1210363 so we can revert it pretty easily if there are problems I didn't see.
Does anyone know how to set up jenkins to build twice, once plain and once with -Pdev?
thanks
david jencks
On Dec 2, 2011, at 2:59 PM, David Jencks wrote:
>
> On Dec 2, 2011, at 2:26 PM, Daniel Kulp wrote:
>
>> On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
>>> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
>>>> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>>>>> released - contains version properties for dependencies at the oldest
>>>>> released version we expect the project bundle to work against>
>>>> would we have to do this using a set of maintained properties files?
>>>> Where would this go - in the parent pom, the top level module pom or
>>>> the bundle pom. There's a file her
>>>> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
>>>> which is supposed to reflect the latest versions - although I think a
>>>> maven plugin could be written and teased into figuring out the latest.
>>>
>>> I think the versions need to be maintained in each (leaf) pom for artifacts
>>> we release. Otherwise there's no good way to release single artifacts.
>>>
>>> There's the versions-maven-plugin
>>> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
>>> versions but I don't know if it is smart enough to work with version
>>> properties in a profile. If the plugin doesn't work, if we use a
>>> consistent version naming scheme its easy enough to use an IDE's
>>> search-and-replace to update properties.
>>
>> We could also try an import scoped dependency of some sort.
>>
>> Basically, have a pom someplace that defines an dependencyManagement thing
>> that lists ALL the Aries jars and their current SNAPSHOT version and another
>> one that lists ALL of the latest releases (which means it would need to be
>> part of each release). A profile could selectively depend on the one that
>> is needed. Pretty much would remove all the version numbers from everywhere.
>>
> I don't think something like that would work here. The idea is to make each bundle independently releasable. Furthermore we don't really know what the next snapshot version is going to be for a while, I think the current idea is to on release update from e.g. 0.4.1-SNAPSHOT to 0.4.1-next-SNAPSHOT until we know what digit should get incremented. And we may not be sure that all users of a bundle want to use the same released version as "earliest compatibility". So the "last release" might not be what we want and would have to be released for every bundle release. While it's a pain I think keeping the versions in each leaf pom is the way to go for aries.
>
> thanks
> david jencks
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2011, at 2:26 PM, Daniel Kulp wrote:
> On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
>> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
>>> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>>>> released - contains version properties for dependencies at the oldest
>>>> released version we expect the project bundle to work against>
>>> would we have to do this using a set of maintained properties files?
>>> Where would this go - in the parent pom, the top level module pom or
>>> the bundle pom. There's a file her
>>> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
>>> which is supposed to reflect the latest versions - although I think a
>>> maven plugin could be written and teased into figuring out the latest.
>>
>> I think the versions need to be maintained in each (leaf) pom for artifacts
>> we release. Otherwise there's no good way to release single artifacts.
>>
>> There's the versions-maven-plugin
>> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
>> versions but I don't know if it is smart enough to work with version
>> properties in a profile. If the plugin doesn't work, if we use a
>> consistent version naming scheme its easy enough to use an IDE's
>> search-and-replace to update properties.
>
> We could also try an import scoped dependency of some sort.
>
> Basically, have a pom someplace that defines an dependencyManagement thing
> that lists ALL the Aries jars and their current SNAPSHOT version and another
> one that lists ALL of the latest releases (which means it would need to be
> part of each release). A profile could selectively depend on the one that
> is needed. Pretty much would remove all the version numbers from everywhere.
>
I don't think something like that would work here. The idea is to make each bundle independently releasable. Furthermore we don't really know what the next snapshot version is going to be for a while, I think the current idea is to on release update from e.g. 0.4.1-SNAPSHOT to 0.4.1-next-SNAPSHOT until we know what digit should get incremented. And we may not be sure that all users of a bundle want to use the same released version as "earliest compatibility". So the "last release" might not be what we want and would have to be released for every bundle release. While it's a pain I think keeping the versions in each leaf pom is the way to go for aries.
thanks
david jencks
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Daniel Kulp <dk...@apache.org>.
On Friday, December 02, 2011 10:15:22 AM David Jencks wrote:
> On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
> > On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
> >> released - contains version properties for dependencies at the oldest
> >> released version we expect the project bundle to work against>
> > would we have to do this using a set of maintained properties files?
> > Where would this go - in the parent pom, the top level module pom or
> > the bundle pom. There's a file her
> > http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
> > which is supposed to reflect the latest versions - although I think a
> > maven plugin could be written and teased into figuring out the latest.
>
> I think the versions need to be maintained in each (leaf) pom for artifacts
> we release. Otherwise there's no good way to release single artifacts.
>
> There's the versions-maven-plugin
> http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating
> versions but I don't know if it is smart enough to work with version
> properties in a profile. If the plugin doesn't work, if we use a
> consistent version naming scheme its easy enough to use an IDE's
> search-and-replace to update properties.
We could also try an import scoped dependency of some sort.
Basically, have a pom someplace that defines an dependencyManagement thing
that lists ALL the Aries jars and their current SNAPSHOT version and another
one that lists ALL of the latest releases (which means it would need to be
part of each release). A profile could selectively depend on the one that
is needed. Pretty much would remove all the version numbers from everywhere.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2011, at 2:39 AM, Jeremy Hughes wrote:
> On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
>> I think there are two valid goals here with conflicting requirements:
>>
>> - make sure that individual artifacts continue to work against at least one already-released version
>>
>> - make sure that all the individual artifacts continue to work together as they are developed.
>>
>> I think these are both really worthwhile goals.
>
> +1 I agree. This has been percolating through the back of my mind the
> last few days too.
>
>>
>> I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
>>
>> Anyway each bundle project would have two profiles perhaps
>>
>> released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
>
> would we have to do this using a set of maintained properties files?
> Where would this go - in the parent pom, the top level module pom or
> the bundle pom. There's a file her
> http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
> which is supposed to reflect the latest versions - although I think a
> maven plugin could be written and teased into figuring out the latest.
I think the versions need to be maintained in each (leaf) pom for artifacts we release. Otherwise there's no good way to release single artifacts.
There's the versions-maven-plugin http://mojo.codehaus.org/versions-maven-plugin/ that helps with updating versions but I don't know if it is smart enough to work with version properties in a profile. If the plugin doesn't work, if we use a consistent version naming scheme its easy enough to use an IDE's search-and-replace to update properties.
thanks
david jencks
>
>>
>> dev - contains version properties for dependencies at the current snapshot version
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>>
>> On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
>>
>>> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>>>> March we spent some time figuring out how to implement the OSGi
>>>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>>>> documented it here:
>>>>>
>>>>> http://aries.apache.org/development/versionpolicy.html
>>>>>
>>>>> based discussions on the list, with the last one being here:
>>>>>
>>>>>
>>>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>>>> .27234.33.camel%40meschbix%3E
>>>>>
>>>>> There are some disparities with what you've change w.r.t what was
>>>>> decided back then. I've made a comment in-line to this commit.
>>>>
>>>> ...........snip ..............
>>>>
>>>>>> - <version>0.3</version>
>>>>>> + <version>0.3.2-SNAPSHOT</version>
>>>>>
>>>>> This should stay at 0.3 as there is no difference between trunk and
>>>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>>>> there were no changes in it over 0.3. Can you describe how you have
>>>>> decided what versions to use here and below? They really should be
>>>>> depending on the released artifact. Thanks.
>>>>
>>>> Well, I would consider that a responsibility of the release manager (or on
>>>> release branches) now to figure that out. On trunk, things really need
>>>> to
>>>> be geared toward the day to day work of the developers doing the work and
>>>> making changes and fixing bugs. For that, they need to be pointing at the
>>>> snapshots for a variety of reasons:
>>>>
>>>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>>>> debugging and developing in the IDE works properly.
>>>>
>>>> 2) The tests (particularly the itests) actually test the code that is being
>>>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>>>> the
>>>> tests, it should test the changes, not some release made 3 months ago.
>>>> This
>>>> is very important to me. I want to be able to run "mvn test" before I
>>>> commit
>>>> and make sure everything works.
>>>>
>>>> 3) Related to (2), if a developer does make a change someplace, I really
>>>> don't
>>>> feel he should need to go off and find all the various places that need to
>>>> be
>>>> updated to make sure that change is fully tested.
>>>>
>>>> Remember, one of the goals of an Apache project is to expand the developer
>>>> community. That is best done by making sure the a new developer can jump
>>>> in
>>>> easily and start contributing without jumping through major learning curves
>>>> and wacky and non-standard policies to get there.
>>>>
>>>
>>> This "wacky and non-standard" policy is there to ensure we can do the
>>> "standard" OSGi practice of developing
>>> independently releasable artefacts which are versioned using the standard
>>> OSGi semantic versioning practice.
>>> The goal here is different from yours. If we move everything up all the
>>> time we may "know" that it works against
>>> the latest, but it probably (in some cases certainly) no longer works
>>> against the prior release of dependencies. So
>>> we want to ensure we only up the dependency when we need a new capability
>>> from it.
>>>
>>> I guess the downside is testing against the latest, so we need a solution
>>> to that, but it isn't to break our ability to work
>>> with compatible prior releases of dependencies.
>>>
>>>
>>>>
>>>>
>>>>
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>
Re: svn commit: r1203307 - in /aries/trunk/blueprint:
blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/
blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 December 2011 03:49, David Jencks <da...@yahoo.com> wrote:
> I think there are two valid goals here with conflicting requirements:
>
> - make sure that individual artifacts continue to work against at least one already-released version
>
> - make sure that all the individual artifacts continue to work together as they are developed.
>
> I think these are both really worthwhile goals.
+1 I agree. This has been percolating through the back of my mind the
last few days too.
>
> I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
>
> Anyway each bundle project would have two profiles perhaps
>
> released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
would we have to do this using a set of maintained properties files?
Where would this go - in the parent pom, the top level module pom or
the bundle pom. There's a file her
http://svn.apache.org/repos/asf/aries/trunk/aries_release_versions.txt
which is supposed to reflect the latest versions - although I think a
maven plugin could be written and teased into figuring out the latest.
>
> dev - contains version properties for dependencies at the current snapshot version
>
> thoughts?
>
> thanks
> david jencks
>
>
> On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
>
>> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>>
>>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>>> March we spent some time figuring out how to implement the OSGi
>>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>>> documented it here:
>>>>
>>>> http://aries.apache.org/development/versionpolicy.html
>>>>
>>>> based discussions on the list, with the last one being here:
>>>>
>>>>
>>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>>> .27234.33.camel%40meschbix%3E
>>>>
>>>> There are some disparities with what you've change w.r.t what was
>>>> decided back then. I've made a comment in-line to this commit.
>>>
>>> ...........snip ..............
>>>
>>>>> - <version>0.3</version>
>>>>> + <version>0.3.2-SNAPSHOT</version>
>>>>
>>>> This should stay at 0.3 as there is no difference between trunk and
>>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>>> there were no changes in it over 0.3. Can you describe how you have
>>>> decided what versions to use here and below? They really should be
>>>> depending on the released artifact. Thanks.
>>>
>>> Well, I would consider that a responsibility of the release manager (or on
>>> release branches) now to figure that out. On trunk, things really need
>>> to
>>> be geared toward the day to day work of the developers doing the work and
>>> making changes and fixing bugs. For that, they need to be pointing at the
>>> snapshots for a variety of reasons:
>>>
>>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>>> debugging and developing in the IDE works properly.
>>>
>>> 2) The tests (particularly the itests) actually test the code that is being
>>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>>> the
>>> tests, it should test the changes, not some release made 3 months ago.
>>> This
>>> is very important to me. I want to be able to run "mvn test" before I
>>> commit
>>> and make sure everything works.
>>>
>>> 3) Related to (2), if a developer does make a change someplace, I really
>>> don't
>>> feel he should need to go off and find all the various places that need to
>>> be
>>> updated to make sure that change is fully tested.
>>>
>>> Remember, one of the goals of an Apache project is to expand the developer
>>> community. That is best done by making sure the a new developer can jump
>>> in
>>> easily and start contributing without jumping through major learning curves
>>> and wacky and non-standard policies to get there.
>>>
>>
>> This "wacky and non-standard" policy is there to ensure we can do the
>> "standard" OSGi practice of developing
>> independently releasable artefacts which are versioned using the standard
>> OSGi semantic versioning practice.
>> The goal here is different from yours. If we move everything up all the
>> time we may "know" that it works against
>> the latest, but it probably (in some cases certainly) no longer works
>> against the prior release of dependencies. So
>> we want to ensure we only up the dependency when we need a new capability
>> from it.
>>
>> I guess the downside is testing against the latest, so we need a solution
>> to that, but it isn't to break our ability to work
>> with compatible prior releases of dependencies.
>>
>>
>>>
>>>
>>>
>>> Daniel Kulp
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by David Jencks <da...@yahoo.com>.
I think there are two valid goals here with conflicting requirements:
- make sure that individual artifacts continue to work against at least one already-released version
- make sure that all the individual artifacts continue to work together as they are developed.
I think these are both really worthwhile goals.
I suggest we solve this conflict using profiles and have jenkins run two builds using the profiles. We can discuss whether one of the profiles should be default, I think the "released version" profile would be a better default but I don't think this is very important.
Anyway each bundle project would have two profiles perhaps
released - contains version properties for dependencies at the oldest released version we expect the project bundle to work against
dev - contains version properties for dependencies at the current snapshot version
thoughts?
thanks
david jencks
On Nov 25, 2011, at 4:08 AM, Alasdair Nottingham wrote:
> On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
>>> Hi Dan, I'm just catching up with what you're doing here. Back in
>>> March we spent some time figuring out how to implement the OSGi
>>> Semantic Versioning policy in our Maven build and release process. Zoe
>>> documented it here:
>>>
>>> http://aries.apache.org/development/versionpolicy.html
>>>
>>> based discussions on the list, with the last one being here:
>>>
>>>
>> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
>>> .27234.33.camel%40meschbix%3E
>>>
>>> There are some disparities with what you've change w.r.t what was
>>> decided back then. I've made a comment in-line to this commit.
>>
>> ...........snip ..............
>>
>>>> - <version>0.3</version>
>>>> + <version>0.3.2-SNAPSHOT</version>
>>>
>>> This should stay at 0.3 as there is no difference between trunk and
>>> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
>>> bundle' process so it ended up releasing blueprint-api 0.3.1 even
>>> there were no changes in it over 0.3. Can you describe how you have
>>> decided what versions to use here and below? They really should be
>>> depending on the released artifact. Thanks.
>>
>> Well, I would consider that a responsibility of the release manager (or on
>> release branches) now to figure that out. On trunk, things really need
>> to
>> be geared toward the day to day work of the developers doing the work and
>> making changes and fixing bugs. For that, they need to be pointing at the
>> snapshots for a variety of reasons:
>>
>> 1) Things like eclipse:eclipse will wire the projects together correctly so
>> debugging and developing in the IDE works properly.
>>
>> 2) The tests (particularly the itests) actually test the code that is being
>> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
>> the
>> tests, it should test the changes, not some release made 3 months ago.
>> This
>> is very important to me. I want to be able to run "mvn test" before I
>> commit
>> and make sure everything works.
>>
>> 3) Related to (2), if a developer does make a change someplace, I really
>> don't
>> feel he should need to go off and find all the various places that need to
>> be
>> updated to make sure that change is fully tested.
>>
>> Remember, one of the goals of an Apache project is to expand the developer
>> community. That is best done by making sure the a new developer can jump
>> in
>> easily and start contributing without jumping through major learning curves
>> and wacky and non-standard policies to get there.
>>
>
> This "wacky and non-standard" policy is there to ensure we can do the
> "standard" OSGi practice of developing
> independently releasable artefacts which are versioned using the standard
> OSGi semantic versioning practice.
> The goal here is different from yours. If we move everything up all the
> time we may "know" that it works against
> the latest, but it probably (in some cases certainly) no longer works
> against the prior release of dependencies. So
> we want to ensure we only up the dependency when we need a new capability
> from it.
>
> I guess the downside is testing against the latest, so we need a solution
> to that, but it isn't to break our ability to work
> with compatible prior releases of dependencies.
>
>
>>
>>
>>
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: svn commit: r1203307 - in /aries/trunk/blueprint:
blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/
blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Alasdair Nottingham <no...@apache.org>.
On 22 November 2011 21:10, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
> > Hi Dan, I'm just catching up with what you're doing here. Back in
> > March we spent some time figuring out how to implement the OSGi
> > Semantic Versioning policy in our Maven build and release process. Zoe
> > documented it here:
> >
> > http://aries.apache.org/development/versionpolicy.html
> >
> > based discussions on the list, with the last one being here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
> > .27234.33.camel%40meschbix%3E
> >
> > There are some disparities with what you've change w.r.t what was
> > decided back then. I've made a comment in-line to this commit.
>
> ...........snip ..............
>
> > > - <version>0.3</version>
> > > + <version>0.3.2-SNAPSHOT</version>
> >
> > This should stay at 0.3 as there is no difference between trunk and
> > 0.3. blueprint 0.3.1 was released before we moved to the 'release by
> > bundle' process so it ended up releasing blueprint-api 0.3.1 even
> > there were no changes in it over 0.3. Can you describe how you have
> > decided what versions to use here and below? They really should be
> > depending on the released artifact. Thanks.
>
> Well, I would consider that a responsibility of the release manager (or on
> release branches) now to figure that out. On trunk, things really need
> to
> be geared toward the day to day work of the developers doing the work and
> making changes and fixing bugs. For that, they need to be pointing at the
> snapshots for a variety of reasons:
>
> 1) Things like eclipse:eclipse will wire the projects together correctly so
> debugging and developing in the IDE works properly.
>
> 2) The tests (particularly the itests) actually test the code that is being
> developed on trunk. If a developer makes a change in a SNAPSHOT and runs
> the
> tests, it should test the changes, not some release made 3 months ago.
> This
> is very important to me. I want to be able to run "mvn test" before I
> commit
> and make sure everything works.
>
> 3) Related to (2), if a developer does make a change someplace, I really
> don't
> feel he should need to go off and find all the various places that need to
> be
> updated to make sure that change is fully tested.
>
> Remember, one of the goals of an Apache project is to expand the developer
> community. That is best done by making sure the a new developer can jump
> in
> easily and start contributing without jumping through major learning curves
> and wacky and non-standard policies to get there.
>
This "wacky and non-standard" policy is there to ensure we can do the
"standard" OSGi practice of developing
independently releasable artefacts which are versioned using the standard
OSGi semantic versioning practice.
The goal here is different from yours. If we move everything up all the
time we may "know" that it works against
the latest, but it probably (in some cases certainly) no longer works
against the prior release of dependencies. So
we want to ensure we only up the dependency when we need a new capability
from it.
I guess the downside is testing against the latest, so we need a solution
to that, but it isn't to break our ability to work
with compatible prior releases of dependencies.
>
>
>
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Alasdair Nottingham
not@apache.org
Re: svn commit: r1203307 - in /aries/trunk/blueprint: blueprint-bundle/ blueprint-itests/ blueprint-testbundlea/src/main/java/org/apache/aries/blueprint/testbundlea/ blueprint-testbundlea/src/main/resources/OSGI-INF/blueprint/ blueprint-testbundlea/s
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, November 22, 2011 6:32:57 PM Jeremy Hughes wrote:
> Hi Dan, I'm just catching up with what you're doing here. Back in
> March we spent some time figuring out how to implement the OSGi
> Semantic Versioning policy in our Maven build and release process. Zoe
> documented it here:
>
> http://aries.apache.org/development/versionpolicy.html
>
> based discussions on the list, with the last one being here:
>
> http://mail-archives.apache.org/mod_mbox/aries-dev/201103.mbox/%3C1300364661
> .27234.33.camel%40meschbix%3E
>
> There are some disparities with what you've change w.r.t what was
> decided back then. I've made a comment in-line to this commit.
...........snip ..............
> > - <version>0.3</version>
> > + <version>0.3.2-SNAPSHOT</version>
>
> This should stay at 0.3 as there is no difference between trunk and
> 0.3. blueprint 0.3.1 was released before we moved to the 'release by
> bundle' process so it ended up releasing blueprint-api 0.3.1 even
> there were no changes in it over 0.3. Can you describe how you have
> decided what versions to use here and below? They really should be
> depending on the released artifact. Thanks.
Well, I would consider that a responsibility of the release manager (or on
release branches) now to figure that out. On trunk, things really need to
be geared toward the day to day work of the developers doing the work and
making changes and fixing bugs. For that, they need to be pointing at the
snapshots for a variety of reasons:
1) Things like eclipse:eclipse will wire the projects together correctly so
debugging and developing in the IDE works properly.
2) The tests (particularly the itests) actually test the code that is being
developed on trunk. If a developer makes a change in a SNAPSHOT and runs the
tests, it should test the changes, not some release made 3 months ago. This
is very important to me. I want to be able to run "mvn test" before I commit
and make sure everything works.
3) Related to (2), if a developer does make a change someplace, I really don't
feel he should need to go off and find all the various places that need to be
updated to make sure that change is fully tested.
Remember, one of the goals of an Apache project is to expand the developer
community. That is best done by making sure the a new developer can jump in
easily and start contributing without jumping through major learning curves
and wacky and non-standard policies to get there.
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com