Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (herse.apache.org: domain of t.moloney@verizon.net
 designates 206.46.252.40 as permitted sender)
Date: Mon, 21 May 2007 07:28:53 -0400
From: Tim Moloney <t.moloney@verizon.net>
Subject: Re: Roadmap
In-reply-to: <4650D062.2090905@ungoverned.org>
To: dev@felix.apache.org
Message-id: <46518275.7050202@verizon.net>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <487a994c0705201211gaa8f51bmfd818c96947c2996@mail.gmail.com>
 <1a5b6c410705201225u62283ee1v821a99614e96c754@mail.gmail.com>
 <4650B28A.6020505@ungoverned.org> <4650D062.2090905@ungoverned.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)

I agree with the proposed roadmap.  My only comment is on the name of 
the plugin.  bundleplugin doesn't follow the Maven convention of 
maven-foo-plugin or foo-maven-plugin.


Richard S. Hall wrote:
> Richard S. Hall wrote:
>> Carlos Sanchez wrote:
>>> A release as TLP is very important as it's going to be available in
>>> the main maven repository instead of the incubating one which other
>>> projects can't use to make releases.
>>> I'd love to see the release of the bundle plugin to use it in the 
>>> Maven project.
>>
>> The maven-bundle-plugin would be included in the release since it is 
>> used by the framework and the shell bundles.
>>
>> Actually, I have been wanting to 1) change the plugin to be a 
>> top-level subproject in the svn repo, which would also mean 2) 
>> changing its package (from 
>> org.apache.felix.framework.tools.maven2.bundleplugin to 
>> org.apache.felix.bundleplugin), and I would also 3) like to change 
>> its name from maven-bundle-plugin to perhaps just bundleplugin.
>
> Ok, rather than just say that I want to do the above, I decided to 
> just go ahead and do it. I have moved maven-bundle-plugin to the trunk 
> directory, renamed it to bundleplugin (and artifactId to 
> org.apache.felix.bundleplugin), changed its package structure, and 
> updated all POM files that used the plugin to refer to the new name 
> (thanks to Karl for a shell script to do that). I rebuilt everything 
> from scratch with an empty repo and it build for me...and I made Karl 
> try it too.
>
> After doing "svn update", you will need to delete the directory 
> 'tools/maven2/maven-bundle-plugin'...
>
>> This will be part of the previous discussion that we had about 
>> reorganizing the svn repo to have all subprojects have their own 
>> top-level directory in the trunk, with related modules of the 
>> sub-project under the sub-project directory rather than in the trunk. 
>> I plan to start making this mods to the repo shortly.
>
> Just like the above, Karl and I have started to reorganize the repo. 
> The eventadmin project was refactored and I will do iPOJO next. Once 
> we get UPnP and MOSGi moved to the new approach, we should have a 
> manageable trunk directory! :-)
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>> my 0.02
>>>
>>> On 5/20/07, Karl Pauls <karlpauls@gmail.com> wrote:
>>>> Dear Felix Community,
>>>>
>>>> in order to follow-up on recent discussions - and our new status as a
>>>> TLP - I'd like to get a roadmap towards a new release going. Let me
>>>> try to get a few thoughts across and see what the general reactions
>>>> are :-)
>>>>
>>>> Looking back at recent comments and events I believe it would be
>>>> beneficial to get a new (and first) official release out of the door
>>>> as soon as possible. That would make it more clear where we are at the
>>>> moment and give Felix users something to build trust upon.
>>>>
>>>> Personally, I'd prefer to get a "core release" out quickly. I know
>>>> that a lot of the subprojects are eager to get something out but we
>>>> need to discuss how to handle those releases and I don't want to delay
>>>> the core release because of that.
>>>>
>>>> That said, taking the last release into account I guess, it would be
>>>> fairly easy to get the involved parts into shape and released within
>>>> the next month or two (namely, main, framework, plugin, shell,
>>>> shell.tui, bundlerepository, and org.osgi.core).
>>>>
>>>> Richard tells me that he has still some stuff to commit to clean-up
>>>> the required bundle functionality, wants to address FELIX-203, and I
>>>> do have two small patches for the extension bundle stuff.
>>>>
>>>> Other then that, we would need to remove the incubator references,
>>>> create proper NOTICE files, figure out a changelog, and tackle a few
>>>> questions namely,
>>>>
>>>> 1) Should it be yet another tarball release or does somebody 
>>>> volunteer to
>>>> get our installer up and running again?
>>>>
>>>> 2) Is this going to be our 1.0 release?
>>>>
>>>> In regard to 2), I'm leaning towards a 1.0 release to emphasize our 
>>>> status as a
>>>> graduated project and the fact that the core Felix technology is 
>>>> stable
>>>> and usable now. I do not think it is necessary to tie the 1.0 
>>>> release to
>>>> complete spec compliance, since being below 1.0 generally has a "not
>>>> quite ready" stigma attached to it, which is not the case. Our goal is
>>>> spec compliance and we will have to be clear in which areas we are not
>>>> yet compliant, but Felix is definitely far enough along to be 
>>>> considered
>>>> stable and a 1.0 release. However, if there are strong feelings to the
>>>> contrary, my opinion could be changed.
>>>>
>>>> What do you all think?
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> -- 
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>
>>>
>