You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alin Dreghiciu <ad...@gmail.com> on 2007/03/23 09:29:42 UTC

State of maven-bundle-plugin

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.
2. change the open issues related to mavne-bundle-plugin to the new
category.
3. review them and assign the right priorities and close the "not useful"
ones
4. then let people repost patches at the current trunk version in the order
of priority so applying patches will be easy
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"

Re: State of maven-bundle-plugin

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> Hi Richard,
>
>> > On 3/23/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> >>
>> >> 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.
>
> I'm willing to help out where I can - I've found this bundle really 
> useful,
> so it would be good to contribute something back to the community.
>
> On 23/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
>>
>> 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.
>>
>
> Executive summary for FELIX-218:
>
>    Can't pass bnd directives starting with '-' through the bundle plugin
>    (such as '-include') because XML doesn't allow tags starting with '-'.
>
>    Solution: use '_' prefix in XML and convert to '-' before passing 
> to bnd.
>
>    Why we need this: lets you share, inherit & structure bundle settings

Yeah, this is one of the easier ones. We just recently updated the BND 
dependency that makes this possible, so hopefully this one should be 
fairly easy to sort out. Perhaps we should start the executive summaries 
on a thread of their own for each issue...

-> richard
>
> On 23/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
>>
>> Again, it is not in need of resurrection. It is only resting
>
> http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm  (sorry,
> couldn't resist!)
>

Re: State of maven-bundle-plugin

Posted by Stuart McCulloch <st...@jayway.net>.
Hi Richard,

> > On 3/23/07, Richard S. Hall <he...@ungoverned.org> wrote:
> >>
> >> 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.

I'm willing to help out where I can - I've found this bundle really useful,
so it would be good to contribute something back to the community.

On 23/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
>
> 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.
>

Executive summary for FELIX-218:

    Can't pass bnd directives starting with '-' through the bundle plugin
    (such as '-include') because XML doesn't allow tags starting with '-'.

    Solution: use '_' prefix in XML and convert to '-' before passing to bnd.

    Why we need this: lets you share, inherit & structure bundle settings

On 23/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Again, it is not in need of resurrection. It is only resting

http://www.mtholyoke.edu/~ebarnes/python/dead-parrot.htm  (sorry,
couldn't resist!)

-- 
Cheers, Stuart

Re: State of maven-bundle-plugin

Posted by Alin Dreghiciu <ad...@gmail.com>.
Thanx for all,

I did not had any slight intention to say that somebody was just "sitting on
their asses'.
 If this was the effect, then please accept my apologies to you all.
Just wanted to have maven-bundle-plugin moving further (or faster?).

But maybe is just my English,
Alin Dreghiciu

On 3/23/07, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Alin Dreghiciu wrote:
> > On 3/23/07, Richard S. Hall <he...@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
>

Re: State of maven-bundle-plugin

Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alin Dreghiciu wrote:
> On 3/23/07, Richard S. Hall <he...@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

Re: State of maven-bundle-plugin

Posted by Alin Dreghiciu <ad...@gmail.com>.
Richard,

Thanx for Maven OSGi Plugin
(Deprecated)<https://issues.apache.org/jira/secure/IssueNavigator.jspa?sorter/order=ASC&sorter/field=priority&component=12311680&reset=true&pid=12310100&mode=hide>
.

Alin Dreghiciu

Re: State of maven-bundle-plugin

Posted by Alin Dreghiciu <ad...@gmail.com>.
On 3/23/07, Richard S. Hall <he...@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.

> 2. change the open issues related to mavne-bundle-plugin to the new
> > category.
>
> See above.


See above :)

> 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?

> 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?

> 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.
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...

But thank you for your suggestions of how we committers should spend our
> time.


Sorry, again, if I was impolite.

-> richard
>

Re: State of maven-bundle-plugin

Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.

> 2. change the open issues related to mavne-bundle-plugin to the new
> category.

See above.

> 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.

> 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.

> 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.

But thank you for your suggestions of how we committers should spend our 
time.

-> richard