felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: State of maven-bundle-plugin
Date Fri, 23 Mar 2007 13:29:08 GMT
Alin Dreghiciu wrote:
> On 3/23/07, Richard S. Hall <heavy@ungoverned.org> wrote:
>> Alin Dreghiciu wrote:
>> > I'm not to much involved with felix development but as being part 
>> of the
>> > list for the past weeks I would say that you guys (commiters) should
>> > spent
>> > some time now on the development of maven-bundle-plugin. I see this 
>> very
>> > useful plugin as a key part for moving towards osgi development. What
>> > I also
>> > see is that due to slow advancements in the area people tend to branch
>> > and
>> > make their own versions. And there are a couple of people that are
>> > willing
>> > to put time in this plugin.
>> > So, let's first have a clear state of what is the state and what's
>> > required
>> > by:
>> >
>> > 1. create a new category in jira, something as Maven Bundle Plugin.
>> I, for one, don't want two OSGi plugins for maven in Felix. The goal for
>> me is to have one plugin, maven-bundle-plugin, and eliminate the other.
>> If your concern is that the JIRA component name doesn't match
>> "maven-bundle-plugin", then we can probably edit the name, but I don't
>> see a reason to have two JIRA components when there is only one path
>> forward as far as I am concerned. Others may disagree.
> Me, neither. Is just confusing because not once happened to look at 
> the old
> plugin issue. E.g. using a manifest from the project folder.
> But what's a component name? leave the existing one to maven plugin 
> category
> and move the osgi plugin ones to a new one: Maven OSGi Plugin - 
> Obsolete. Or
> even close the old ones as wont fix.

Okay, to avoid confusion, I just created another component and, 
hopefully, moved the correct issues to it.

>> 3. review them and assign the right priorities and close the "not 
>> useful"
>> > ones
>> Yes, I have posted messages saying that I would try to do this, but
>> clearly I am not the only one that is capable of doing this, so I
>> welcome any help in this area.
> How can I help?

Good question, just try something. I was going to try to review them and 
post an easy to understand summary of each one (and how involved they 
are and whether they impact current behavior or are completely 
independent, such as new goals) so that we might more easily elicit 
feedback and gain consensus on whether or not to include the feature.

In summary, I figured it would easier to get community involvement with 
some sort of executive summary.

>> 4. then let people repost patches at the current trunk version in the
>> > order
>> > of priority so applying patches will be easy
>> Agreed. This would be my suggestion too.
> How fast do you think you/commiters will be able to react?

The answer is the same as with every other Apache project, "when we get 
to it". However, if we gain consensus and get it organized, I am sure it 
won't take too long.

>> 5. Please start with the easy ones (as the latest resources  posted by
>> > Stuart)
>> >
>> > So, let's give it a fresh start. I'm willing to help if I can and I'm
>> > pretty
>> > sure that are a few other that will do the same.
>> >
>> > Alin Dreghiciu
>> >
>> > P.S. Sorry that I just jumped up into "organizing"
>> I am not sure that a "fresh start" is necessary. Some people are paid to
>> do this work and some of people volunteer to do this work. We tend to
>> try to be flexible with the demands in other peoples' schedules around
>> here, since we don't know which category they fall into.
> Okay , not a fresh start. Let's bring it back to life. I do not want to
> demand anything. I just see people really wanting to contribute. But if
> things are not moving the patches become obsolete. And since things are
> moving slow and some need the changes to move it further will force 
> them to
> branch.

Again, it is not in need of resurrection. It is only resting because no 
one has had the time to make any progress on it. Now it seems there is 
someone in the community that has some time to devote, namely you. So, 
now we can make progress again. Feel free to go with my "executive 
summary" approach above or, if you have a better approach, try it and we 
will see how it goes.

> And since we are leaving on the edge by using the incubator snapshot 
> why not
> just drop in some of the patches and let the real life proof the
> correctness. Of course that this has risks and can be frustrating...

Well, there is one good reason to not do this, because we are the ones 
that end up having to maintain, document, etc. So, I don't really want 
people just dumping stuff into our sub-projects just because they were 
tickled by some wild hair. I want to see reasoned evolution of our 
sub-projects. I think others would agree.

> Sorry, again, if I was impolite.

Generally, I would say it is bad form to go into any mailing list and 
imply that the community is just sitting on their asses to create an 
inconvenience you.

No worry, no grudges.

-> richard

View raw message