just a heads up about naming conventions, in Maven we were discussing
about the OSGi schema, and decided to go for
OSGi bundle name = groupId + "." + artifactId
eg. org.apache.felix.bundleplugin should have
groupId=org.apache.felix
artifactId=bundleplugin
and later it'd be the tools/plugins the ones renaming appropriately
for the target environment
it'd also map easier to the maven repo
WDYT?
On 5/21/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Tim Moloney wrote:
> 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.
Is there some reason for this convention? It ends up violating our own
convention of naming generated artifacts after their own package root in
our repo (e.g., org.apache.felix.bundleplugin-0.9.0.jar).
If the general view is that we should follow this convention (which I
wasn't aware of), then I will change it back.
-> richard
>
>
> 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 <[EMAIL PROTECTED]> 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
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>
>>>>
>>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
