Alin Dreghiciu wrote:
On 3/23/07, Richard S. Hall <[EMAIL PROTECTED]> 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
