You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stuart McCulloch <st...@jayway.net> on 2007/03/25 13:45:42 UTC
Executive summary of maven-bundle-plugin issues
Hi folks,
Currently there are 8 open issues for the maven-bundle-plugin. I've written up a
short one-line status for each of them (inc. # of votes, whether a patch exists)
along with a suggested course of action in another table. (see attached file)
The suggested actions are all MHO, so apologies if I've misrepresented any
of the issues, or the patches. Please post a follow-up message pointing out
any mistakes, updates or alternative suggestions.
Basically I recommend looking at FELIX-199 first, as it also solves several
other issues. The one thorny area is over maven dependencies: whether to
get the user to handle this outside in the pom with other plugins, or to add
options to the bundle plugin for the sake of convenience (FELIX-255/262).
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Tim Moloney <t....@verizon.net>.
Stuart McCulloch wrote:
> Hi Tim,
>
> Yes, sorry: 247 and 257 suggested actions are switched, cut & paste
> error :)
I thought so. Just making sure.
> So how urgent is the need for the ant solution?
I'm not in a big hurry. I know that Richard Hall expressed an interest
in releasing Felix so that it can be built without Maven. However, I
suspect that he isn't in a rush either. I know that it is a capability
that I will need in the future (4-6 months?) and something I could
contribute fairly easily.
> If the next version of the ant plugin will provide a better solution,
> can we wait for that to be
> released first?
I honestly don't know when the next version of the ant plugin will be
released. 2.0-beta-1 (which is available in the repository) has the
methods marked as private. 2.0-beta-2-SNAPSHOT (trunk) has the methods
marked as protected.
> Also, since FELIX-199 seems more popular (in # of votes) and also touches
> similar files, I think that should go in first and then people can
> refactor their
> patches around it - does that sound ok?
I have no problem with that.
> Cheers, Stuart
>
> On 26/03/07, Tim Moloney <t....@verizon.net> wrote:
>> Stuart McCulloch wrote:
>> > [...]
>> > FELIX-247 | Minor | 0 | YES | NEW: Add ant goal to create
>> build.xml and MANIFEST.MF
>> >
>> I believe that you switched FELIX-247 and FELIX-257 in your list of
>> suggested actions. The following makes sense for FELIX-247.
>> > |
>> > FELIX-257 | CLOSE: MANIFEST.MF requirement covered by FELIX-199.
>> The build.xml part of the patch
>> > | relies on code copied from ant-plugin, which I don't
>> believe is the best solution.
>> > | (Why not just run the current maven-ant-plugin goal
>> 'ant:ant' to get the build.xml?)
>> >
>> Running ant:ant creates a build.xml file that causes ant to
>> automatically generates a MANIFEST.MF file. What we need is a
>> MANIFEST.MF file that captures the bundle dependencies and ant can't
>> automatically generate that.
>>
>> I whole-heartedly agree with you that copying a file from the ant plugin
>> isn't the best solution. However, it is the only solution that I could
>> think of since the methods that need to be customize/overridden are
>> marked private in the released version of the ant plugin. (I really
>> hate this solution since all I'm doing is adding the manifest attribute
>> to build.xml, so I explain it in the first 10 lines of the patch.) The
>> next released version of the ant plugin should allow us to use a cleaner
>> solution since the trunk has most methods marked as protected.
>>
>> The rest of the patch is just moving existing code around so that it can
>> be reused by multiple goals.
>>
>> Tim
>>
>
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
Hi Tim,
Yes, sorry: 247 and 257 suggested actions are switched, cut & paste error :)
So how urgent is the need for the ant solution? If the next version of the ant
plugin will provide a better solution, can we wait for that to be
released first?
Also, since FELIX-199 seems more popular (in # of votes) and also touches
similar files, I think that should go in first and then people can
refactor their
patches around it - does that sound ok?
Cheers, Stuart
On 26/03/07, Tim Moloney <t....@verizon.net> wrote:
> Stuart McCulloch wrote:
> > [...]
> > FELIX-247 | Minor | 0 | YES | NEW: Add ant goal to create build.xml and MANIFEST.MF
> >
> I believe that you switched FELIX-247 and FELIX-257 in your list of
> suggested actions. The following makes sense for FELIX-247.
> > |
> > FELIX-257 | CLOSE: MANIFEST.MF requirement covered by FELIX-199. The build.xml part of the patch
> > | relies on code copied from ant-plugin, which I don't believe is the best solution.
> > | (Why not just run the current maven-ant-plugin goal 'ant:ant' to get the build.xml?)
> >
> Running ant:ant creates a build.xml file that causes ant to
> automatically generates a MANIFEST.MF file. What we need is a
> MANIFEST.MF file that captures the bundle dependencies and ant can't
> automatically generate that.
>
> I whole-heartedly agree with you that copying a file from the ant plugin
> isn't the best solution. However, it is the only solution that I could
> think of since the methods that need to be customize/overridden are
> marked private in the released version of the ant plugin. (I really
> hate this solution since all I'm doing is adding the manifest attribute
> to build.xml, so I explain it in the first 10 lines of the patch.) The
> next released version of the ant plugin should allow us to use a cleaner
> solution since the trunk has most methods marked as protected.
>
> The rest of the patch is just moving existing code around so that it can
> be reused by multiple goals.
>
> Tim
>
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Tim Moloney <t....@verizon.net>.
Stuart McCulloch wrote:
> [...]
> FELIX-247 | Minor | 0 | YES | NEW: Add ant goal to create build.xml and MANIFEST.MF
>
I believe that you switched FELIX-247 and FELIX-257 in your list of
suggested actions. The following makes sense for FELIX-247.
> |
> FELIX-257 | CLOSE: MANIFEST.MF requirement covered by FELIX-199. The build.xml part of the patch
> | relies on code copied from ant-plugin, which I don't believe is the best solution.
> | (Why not just run the current maven-ant-plugin goal 'ant:ant' to get the build.xml?)
>
Running ant:ant creates a build.xml file that causes ant to
automatically generates a MANIFEST.MF file. What we need is a
MANIFEST.MF file that captures the bundle dependencies and ant can't
automatically generate that.
I whole-heartedly agree with you that copying a file from the ant plugin
isn't the best solution. However, it is the only solution that I could
think of since the methods that need to be customize/overridden are
marked private in the released version of the ant plugin. (I really
hate this solution since all I'm doing is adding the manifest attribute
to build.xml, so I explain it in the first 10 lines of the patch.) The
next released version of the ant plugin should allow us to use a cleaner
solution since the trunk has most methods marked as protected.
The rest of the patch is just moving existing code around so that it can
be reused by multiple goals.
Tim
Re: Executive summary of maven-bundle-plugin issues
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> > haven't tried, but should use them
> >
> > i don't see the scope as the solution, is a workaround, it's not
> > designed to do that
>
> Yep, I'd like to avoid mis-using the maven dependency system if pos.
> BTW, what do you think about using the maven-dependency-plugin as
> another way to wrap library artifacts? (for the non-recursive use-case)
>
> >
> > there are two cases here:
> >
> > - bundle = original library + OSGi manifest
> > I think this is the best solution, if you do it from the original
> > library pom, you just need the bundle:manifest goal, if you do it from
> > outside somehow you should deploy the dependencies section from the
> > pom in the original library instead of the current one.
>
> Would this be in a separate 'wrap' goal - personally, I prefer plugins which
> have many, simple goals that you can combine as necessary, rather than
> one swiss-army-knife goal with lots of options.
yes, it's easy, and probably a good addition
>
> >
> > - bundle = several libraries
> > this will require http://jira.codehaus.org/browse/MNG-2316 to be
> > implement first to list all the dependencies provided by the bundle
> >
>
> Do you have a timeline for MNG-2316?
unfortunately no, it will depend who's willing to help and how 2.1 goes
>
> >
> > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > Interesting - btw, does it handle top-level dependencies with 'provided' scope
> > > as required by FELIX-262 (ie. to avoid the new artifact having transitive deps)
> > >
> > > On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > > I commented in 255 about this, it'd be easy to add a parameter to
> > > > FELIX-199 bundleall goal to specify how deep to process the tree, you
> > > > could set it to 1 to bundle only the direct dependencies
> > > >
> > > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > > > Hi Alin,
> > > > >
> > > > > Thanks for the comments - I'm not completely adverse to the idea of handling
> > > > > the transitive dependency issue inside the plugin, just questioning the benefit
> > > > > given there's (imho) a workable solution.
> > > > >
> > > > > I'm also worried that changing the way the bundle pulls in artifacts might break
> > > > > other users. I believe this issue is only for the 'wrapping jar' case
> > > > > - is that right?
> > > > >
> > > > > Anyway, this is just my own opinion - looking forward to hearing more views :)
> > > > >
> > > > > Cheers, Stuart
> > > > >
> > > > > On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > > > > > Nice summary Stuart,
> > > > > >
> > > > > > I also posted some comments on FELIX-262 and FELIX-255.
> > > > > >
> > > > > > Alin Dreghiciu
> > > > > >
> > > > > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > > > > >
> > > > > > > Hi folks,
> > > > > > >
> > > > > > > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > > > > > > written up a
> > > > > > > short one-line status for each of them (inc. # of votes, whether a patch
> > > > > > > exists)
> > > > > > > along with a suggested course of action in another table. (see attached
> > > > > > > file)
> > > > > > >
> > > > > > > The suggested actions are all MHO, so apologies if I've misrepresented any
> > > > > > > of the issues, or the patches. Please post a follow-up message pointing
> > > > > > > out
> > > > > > > any mistakes, updates or alternative suggestions.
> > > > > > >
> > > > > > > Basically I recommend looking at FELIX-199 first, as it also solves
> > > > > > > several
> > > > > > > other issues. The one thorny area is over maven dependencies: whether to
> > > > > > > get the user to handle this outside in the pom with other plugins, or to
> > > > > > > add
> > > > > > > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> > > > > > >
> > > > > > > --
> > > > > > > Cheers, Stuart
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers, Stuart
> > > > >
> > > >
> > > >
> > > > --
> > > > I could give you my word as a Spaniard.
> > > > No good. I've known too many Spaniards.
> > > > -- The Princess Bride
> > > >
> > >
> > >
> > > --
> > > Cheers, Stuart
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
>
>
> --
> Cheers, Stuart
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> haven't tried, but should use them
>
> i don't see the scope as the solution, is a workaround, it's not
> designed to do that
Yep, I'd like to avoid mis-using the maven dependency system if pos.
BTW, what do you think about using the maven-dependency-plugin as
another way to wrap library artifacts? (for the non-recursive use-case)
>
> there are two cases here:
>
> - bundle = original library + OSGi manifest
> I think this is the best solution, if you do it from the original
> library pom, you just need the bundle:manifest goal, if you do it from
> outside somehow you should deploy the dependencies section from the
> pom in the original library instead of the current one.
Would this be in a separate 'wrap' goal - personally, I prefer plugins which
have many, simple goals that you can combine as necessary, rather than
one swiss-army-knife goal with lots of options.
>
> - bundle = several libraries
> this will require http://jira.codehaus.org/browse/MNG-2316 to be
> implement first to list all the dependencies provided by the bundle
>
Do you have a timeline for MNG-2316?
>
> On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > Interesting - btw, does it handle top-level dependencies with 'provided' scope
> > as required by FELIX-262 (ie. to avoid the new artifact having transitive deps)
> >
> > On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> > > I commented in 255 about this, it'd be easy to add a parameter to
> > > FELIX-199 bundleall goal to specify how deep to process the tree, you
> > > could set it to 1 to bundle only the direct dependencies
> > >
> > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > > Hi Alin,
> > > >
> > > > Thanks for the comments - I'm not completely adverse to the idea of handling
> > > > the transitive dependency issue inside the plugin, just questioning the benefit
> > > > given there's (imho) a workable solution.
> > > >
> > > > I'm also worried that changing the way the bundle pulls in artifacts might break
> > > > other users. I believe this issue is only for the 'wrapping jar' case
> > > > - is that right?
> > > >
> > > > Anyway, this is just my own opinion - looking forward to hearing more views :)
> > > >
> > > > Cheers, Stuart
> > > >
> > > > On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > > > > Nice summary Stuart,
> > > > >
> > > > > I also posted some comments on FELIX-262 and FELIX-255.
> > > > >
> > > > > Alin Dreghiciu
> > > > >
> > > > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > > > >
> > > > > > Hi folks,
> > > > > >
> > > > > > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > > > > > written up a
> > > > > > short one-line status for each of them (inc. # of votes, whether a patch
> > > > > > exists)
> > > > > > along with a suggested course of action in another table. (see attached
> > > > > > file)
> > > > > >
> > > > > > The suggested actions are all MHO, so apologies if I've misrepresented any
> > > > > > of the issues, or the patches. Please post a follow-up message pointing
> > > > > > out
> > > > > > any mistakes, updates or alternative suggestions.
> > > > > >
> > > > > > Basically I recommend looking at FELIX-199 first, as it also solves
> > > > > > several
> > > > > > other issues. The one thorny area is over maven dependencies: whether to
> > > > > > get the user to handle this outside in the pom with other plugins, or to
> > > > > > add
> > > > > > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> > > > > >
> > > > > > --
> > > > > > Cheers, Stuart
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > > -- The Princess Bride
> > >
> >
> >
> > --
> > Cheers, Stuart
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Carlos Sanchez <ca...@apache.org>.
haven't tried, but should use them
i don't see the scope as the solution, is a workaround, it's not
designed to do that
there are two cases here:
- bundle = original library + OSGi manifest
I think this is the best solution, if you do it from the original
library pom, you just need the bundle:manifest goal, if you do it from
outside somehow you should deploy the dependencies section from the
pom in the original library instead of the current one.
- bundle = several libraries
this will require http://jira.codehaus.org/browse/MNG-2316 to be
implement first to list all the dependencies provided by the bundle
On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> Interesting - btw, does it handle top-level dependencies with 'provided' scope
> as required by FELIX-262 (ie. to avoid the new artifact having transitive deps)
>
> On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> > I commented in 255 about this, it'd be easy to add a parameter to
> > FELIX-199 bundleall goal to specify how deep to process the tree, you
> > could set it to 1 to bundle only the direct dependencies
> >
> > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > Hi Alin,
> > >
> > > Thanks for the comments - I'm not completely adverse to the idea of handling
> > > the transitive dependency issue inside the plugin, just questioning the benefit
> > > given there's (imho) a workable solution.
> > >
> > > I'm also worried that changing the way the bundle pulls in artifacts might break
> > > other users. I believe this issue is only for the 'wrapping jar' case
> > > - is that right?
> > >
> > > Anyway, this is just my own opinion - looking forward to hearing more views :)
> > >
> > > Cheers, Stuart
> > >
> > > On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > > > Nice summary Stuart,
> > > >
> > > > I also posted some comments on FELIX-262 and FELIX-255.
> > > >
> > > > Alin Dreghiciu
> > > >
> > > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > > > > written up a
> > > > > short one-line status for each of them (inc. # of votes, whether a patch
> > > > > exists)
> > > > > along with a suggested course of action in another table. (see attached
> > > > > file)
> > > > >
> > > > > The suggested actions are all MHO, so apologies if I've misrepresented any
> > > > > of the issues, or the patches. Please post a follow-up message pointing
> > > > > out
> > > > > any mistakes, updates or alternative suggestions.
> > > > >
> > > > > Basically I recommend looking at FELIX-199 first, as it also solves
> > > > > several
> > > > > other issues. The one thorny area is over maven dependencies: whether to
> > > > > get the user to handle this outside in the pom with other plugins, or to
> > > > > add
> > > > > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> > > > >
> > > > > --
> > > > > Cheers, Stuart
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Cheers, Stuart
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
>
>
> --
> Cheers, Stuart
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
Interesting - btw, does it handle top-level dependencies with 'provided' scope
as required by FELIX-262 (ie. to avoid the new artifact having transitive deps)
On 26/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> I commented in 255 about this, it'd be easy to add a parameter to
> FELIX-199 bundleall goal to specify how deep to process the tree, you
> could set it to 1 to bundle only the direct dependencies
>
> On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > Hi Alin,
> >
> > Thanks for the comments - I'm not completely adverse to the idea of handling
> > the transitive dependency issue inside the plugin, just questioning the benefit
> > given there's (imho) a workable solution.
> >
> > I'm also worried that changing the way the bundle pulls in artifacts might break
> > other users. I believe this issue is only for the 'wrapping jar' case
> > - is that right?
> >
> > Anyway, this is just my own opinion - looking forward to hearing more views :)
> >
> > Cheers, Stuart
> >
> > On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > > Nice summary Stuart,
> > >
> > > I also posted some comments on FELIX-262 and FELIX-255.
> > >
> > > Alin Dreghiciu
> > >
> > > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > > > written up a
> > > > short one-line status for each of them (inc. # of votes, whether a patch
> > > > exists)
> > > > along with a suggested course of action in another table. (see attached
> > > > file)
> > > >
> > > > The suggested actions are all MHO, so apologies if I've misrepresented any
> > > > of the issues, or the patches. Please post a follow-up message pointing
> > > > out
> > > > any mistakes, updates or alternative suggestions.
> > > >
> > > > Basically I recommend looking at FELIX-199 first, as it also solves
> > > > several
> > > > other issues. The one thorny area is over maven dependencies: whether to
> > > > get the user to handle this outside in the pom with other plugins, or to
> > > > add
> > > > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> > > >
> > > > --
> > > > Cheers, Stuart
> > > >
> > > >
> > >
> >
> >
> > --
> > Cheers, Stuart
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Carlos Sanchez <ca...@apache.org>.
I commented in 255 about this, it'd be easy to add a parameter to
FELIX-199 bundleall goal to specify how deep to process the tree, you
could set it to 1 to bundle only the direct dependencies
On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> Hi Alin,
>
> Thanks for the comments - I'm not completely adverse to the idea of handling
> the transitive dependency issue inside the plugin, just questioning the benefit
> given there's (imho) a workable solution.
>
> I'm also worried that changing the way the bundle pulls in artifacts might break
> other users. I believe this issue is only for the 'wrapping jar' case
> - is that right?
>
> Anyway, this is just my own opinion - looking forward to hearing more views :)
>
> Cheers, Stuart
>
> On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> > Nice summary Stuart,
> >
> > I also posted some comments on FELIX-262 and FELIX-255.
> >
> > Alin Dreghiciu
> >
> > On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> > >
> > > Hi folks,
> > >
> > > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > > written up a
> > > short one-line status for each of them (inc. # of votes, whether a patch
> > > exists)
> > > along with a suggested course of action in another table. (see attached
> > > file)
> > >
> > > The suggested actions are all MHO, so apologies if I've misrepresented any
> > > of the issues, or the patches. Please post a follow-up message pointing
> > > out
> > > any mistakes, updates or alternative suggestions.
> > >
> > > Basically I recommend looking at FELIX-199 first, as it also solves
> > > several
> > > other issues. The one thorny area is over maven dependencies: whether to
> > > get the user to handle this outside in the pom with other plugins, or to
> > > add
> > > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> > >
> > > --
> > > Cheers, Stuart
> > >
> > >
> >
>
>
> --
> Cheers, Stuart
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
Hi Alin,
Thanks for the comments - I'm not completely adverse to the idea of handling
the transitive dependency issue inside the plugin, just questioning the benefit
given there's (imho) a workable solution.
I'm also worried that changing the way the bundle pulls in artifacts might break
other users. I believe this issue is only for the 'wrapping jar' case
- is that right?
Anyway, this is just my own opinion - looking forward to hearing more views :)
Cheers, Stuart
On 26/03/07, Alin Dreghiciu <ad...@gmail.com> wrote:
> Nice summary Stuart,
>
> I also posted some comments on FELIX-262 and FELIX-255.
>
> Alin Dreghiciu
>
> On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
> >
> > Hi folks,
> >
> > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > written up a
> > short one-line status for each of them (inc. # of votes, whether a patch
> > exists)
> > along with a suggested course of action in another table. (see attached
> > file)
> >
> > The suggested actions are all MHO, so apologies if I've misrepresented any
> > of the issues, or the patches. Please post a follow-up message pointing
> > out
> > any mistakes, updates or alternative suggestions.
> >
> > Basically I recommend looking at FELIX-199 first, as it also solves
> > several
> > other issues. The one thorny area is over maven dependencies: whether to
> > get the user to handle this outside in the pom with other plugins, or to
> > add
> > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> >
> > --
> > Cheers, Stuart
> >
> >
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Alin Dreghiciu <ad...@gmail.com>.
Nice summary Stuart,
I also posted some comments on FELIX-262 and FELIX-255.
Alin Dreghiciu
On 3/25/07, Stuart McCulloch <st...@jayway.net> wrote:
>
> Hi folks,
>
> Currently there are 8 open issues for the maven-bundle-plugin. I've
> written up a
> short one-line status for each of them (inc. # of votes, whether a patch
> exists)
> along with a suggested course of action in another table. (see attached
> file)
>
> The suggested actions are all MHO, so apologies if I've misrepresented any
> of the issues, or the patches. Please post a follow-up message pointing
> out
> any mistakes, updates or alternative suggestions.
>
> Basically I recommend looking at FELIX-199 first, as it also solves
> several
> other issues. The one thorny area is over maven dependencies: whether to
> get the user to handle this outside in the pom with other plugins, or to
> add
> options to the bundle plugin for the sake of convenience (FELIX-255/262).
>
> --
> Cheers, Stuart
>
>
Re: Executive summary of maven-bundle-plugin issues
Posted by Alin Dreghiciu <ad...@gmail.com>.
I already voted for the 199, but for the record I'm doing it again here.
Alin.
On 3/27/07, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Stuart,
>
> Thanks for your summary.
>
> Regarding the suggestion to start with FELIX-199, I think I am in
> agreement there...and it seems only fair since it is the oldest. :-)
>
> Looking that the patch, it appears that most of its major changes are
> orthogonal to the existing bundle functionality. Thus, I don't see much
> of an issue in applying the patch. I don't know if we need to bother
> with a vote on accepting the patch or not...in truth, I don't know the
> proper process for this. I am included to just see if anyone responds to
> this thread in a day or so to object and if not, then just apply the
> patch for FELIX-199.
>
> As a test, I wasn't able to apply the latest unified patch that you
> attached to the JIRA issue, however, Were you able to apply it to the
> trunk?
>
> I also agree that FELIX-218 is reasonably trivial, so that could be
> applied easily too. I assume that only the last patch is relevant. Since
> this one is so trivial, I could probably go ahead and apply and close it
> before we do FELIX-199, then perhaps you could create a new unified
> patch for 199?
>
> -> richard
>
> Stuart McCulloch wrote:
> > Hi folks,
> >
> > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > written up a
> > short one-line status for each of them (inc. # of votes, whether a
> > patch exists)
> > along with a suggested course of action in another table. (see
> > attached file)
> >
> > The suggested actions are all MHO, so apologies if I've misrepresented
> > any
> > of the issues, or the patches. Please post a follow-up message
> > pointing out
> > any mistakes, updates or alternative suggestions.
> >
> > Basically I recommend looking at FELIX-199 first, as it also solves
> > several
> > other issues. The one thorny area is over maven dependencies: whether to
> > get the user to handle this outside in the pom with other plugins, or
> > to add
> > options to the bundle plugin for the sake of convenience
> (FELIX-255/262).
> >
>
Re: Executive summary of maven-bundle-plugin issues
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/27/07, Felix Meschberger <Fe...@day.com> wrote:
> Hi all,
>
>
> > > As a test, I wasn't able to apply the latest unified patch that you
> > > attached to the JIRA issue, however, Were you able to apply it to the trunk?
> > >
> >
> > Ah, I just did a simple unified diff between trunk and Carlos' branch
> > so it may be I missed something in the process. Will take a look at
> > it tomorrow (I'm UTC+8) and come up with a clean (tested) patch.
>
> Could this be the CR-LF vs. LF issue again ? I usual do a dos2unix on
> patch files before submission, which seems to help.
make sure you set svn:eol-style to native in all text files
I use this script and then revert binary files for old files. I have
this svn configuration
http://maven.apache.org/developers/svn-eol-style.txt
for f in `find . -type f | grep -v .svn` ; do
prop=`svn propget svn:mime-type $f`
prop=`svn propget svn:eol-style $f`
if [ -z "$prop" ]
then
echo $prop $f
svn propset svn:eol-style native $f
fi
prop=`svn propget svn:keywords $f`
if [ -z "$prop" ]
then
echo $prop $f
svn propset svn:keywords "\"Author Date Id Revision\"" $f
fi
done
>
> Regards
> Felix
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Executive summary of maven-bundle-plugin issues
Posted by Felix Meschberger <Fe...@day.com>.
Hi all,
> > As a test, I wasn't able to apply the latest unified patch that you
> > attached to the JIRA issue, however, Were you able to apply it to the trunk?
> >
>
> Ah, I just did a simple unified diff between trunk and Carlos' branch
> so it may be I missed something in the process. Will take a look at
> it tomorrow (I'm UTC+8) and come up with a clean (tested) patch.
Could this be the CR-LF vs. LF issue again ? I usual do a dos2unix on
patch files before submission, which seems to help.
Regards
Felix
Re: Executive summary of maven-bundle-plugin issues
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> On 28/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
>> I also agree that FELIX-218 is reasonably trivial, so that could be
>> applied easily too. I assume that only the last patch is relevant. Since
>> this one is so trivial, I could probably go ahead and apply and close it
>> before we do FELIX-199, then perhaps you could create a new unified
>> patch for 199?
>
> Yes, it's just the last patch that's needed, to map the '_' prefix to
> '-'.
Ok, one down...I applied FELIX-218 and used it to fix an issue in
main.jar where the config.properties file was being included by mistake...
-> richard
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
Hi Richard,
On 28/03/07, Richard S. Hall <he...@ungoverned.org> wrote:
> Stuart,
>
> Thanks for your summary.
>
> Regarding the suggestion to start with FELIX-199, I think I am in
> agreement there...and it seems only fair since it is the oldest. :-)
>
> Looking that the patch, it appears that most of its major changes are
> orthogonal to the existing bundle functionality. Thus, I don't see much
> of an issue in applying the patch. I don't know if we need to bother
> with a vote on accepting the patch or not...in truth, I don't know the
> proper process for this. I am included to just see if anyone responds to
> this thread in a day or so to object and if not, then just apply the
> patch for FELIX-199.
>
Sounds fair to me.
> As a test, I wasn't able to apply the latest unified patch that you
> attached to the JIRA issue, however, Were you able to apply it to the trunk?
>
Ah, I just did a simple unified diff between trunk and Carlos' branch
so it may be I missed something in the process. Will take a look at
it tomorrow (I'm UTC+8) and come up with a clean (tested) patch.
> I also agree that FELIX-218 is reasonably trivial, so that could be
> applied easily too. I assume that only the last patch is relevant. Since
> this one is so trivial, I could probably go ahead and apply and close it
> before we do FELIX-199, then perhaps you could create a new unified
> patch for 199?
Yes, it's just the last patch that's needed, to map the '_' prefix to '-'.
I'll review, test and upload the definitive FELIX-199 patch tomorrow.
Cheers, Stuart
>
> -> richard
>
> Stuart McCulloch wrote:
> > Hi folks,
> >
> > Currently there are 8 open issues for the maven-bundle-plugin. I've
> > written up a
> > short one-line status for each of them (inc. # of votes, whether a
> > patch exists)
> > along with a suggested course of action in another table. (see
> > attached file)
> >
> > The suggested actions are all MHO, so apologies if I've misrepresented
> > any
> > of the issues, or the patches. Please post a follow-up message
> > pointing out
> > any mistakes, updates or alternative suggestions.
> >
> > Basically I recommend looking at FELIX-199 first, as it also solves
> > several
> > other issues. The one thorny area is over maven dependencies: whether to
> > get the user to handle this outside in the pom with other plugins, or
> > to add
> > options to the bundle plugin for the sake of convenience (FELIX-255/262).
> >
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
FYI, with maven 2.0.5 the current felix build fails trying to find the
maven-bundle-plugin ... as a workaround I can pre-install it using:
mvn -N install
cd tools/maven2/maven-bundle-plugin/
mvn install
cd ../..
ant
I've opened FELIX-263 to track this build break.
On 28/03/07, Stuart McCulloch <st...@jayway.net> wrote:
> On 28/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> > On 3/27/07, Richard S. Hall <he...@ungoverned.org> wrote:
> > > As a test, I wasn't able to apply the latest unified patch that you
> > > attached to the JIRA issue, however, Were you able to apply it to the trunk?
> >
> > you don't even need a patch, just use svn merge as both are in Apache svn repo
> >
>
> True, although we don't want all the changes (such as the groupId change)
> and imho it's worthwhile having a patchfile that people can review offline.
>
> BTW, I'm having trouble building felix using maven 2.0.5 and an empty local repo
>
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
>
>
> --
> Cheers, Stuart
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Stuart McCulloch <st...@jayway.net>.
On 28/03/07, Carlos Sanchez <ca...@apache.org> wrote:
> On 3/27/07, Richard S. Hall <he...@ungoverned.org> wrote:
> > As a test, I wasn't able to apply the latest unified patch that you
> > attached to the JIRA issue, however, Were you able to apply it to the trunk?
>
> you don't even need a patch, just use svn merge as both are in Apache svn repo
>
True, although we don't want all the changes (such as the groupId change)
and imho it's worthwhile having a patchfile that people can review offline.
BTW, I'm having trouble building felix using maven 2.0.5 and an empty local repo
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
Cheers, Stuart
Re: Executive summary of maven-bundle-plugin issues
Posted by Carlos Sanchez <ca...@apache.org>.
On 3/27/07, Richard S. Hall <he...@ungoverned.org> wrote:
> As a test, I wasn't able to apply the latest unified patch that you
> attached to the JIRA issue, however, Were you able to apply it to the trunk?
you don't even need a patch, just use svn merge as both are in Apache svn repo
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Executive summary of maven-bundle-plugin issues
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart,
Thanks for your summary.
Regarding the suggestion to start with FELIX-199, I think I am in
agreement there...and it seems only fair since it is the oldest. :-)
Looking that the patch, it appears that most of its major changes are
orthogonal to the existing bundle functionality. Thus, I don't see much
of an issue in applying the patch. I don't know if we need to bother
with a vote on accepting the patch or not...in truth, I don't know the
proper process for this. I am included to just see if anyone responds to
this thread in a day or so to object and if not, then just apply the
patch for FELIX-199.
As a test, I wasn't able to apply the latest unified patch that you
attached to the JIRA issue, however, Were you able to apply it to the trunk?
I also agree that FELIX-218 is reasonably trivial, so that could be
applied easily too. I assume that only the last patch is relevant. Since
this one is so trivial, I could probably go ahead and apply and close it
before we do FELIX-199, then perhaps you could create a new unified
patch for 199?
-> richard
Stuart McCulloch wrote:
> Hi folks,
>
> Currently there are 8 open issues for the maven-bundle-plugin. I've
> written up a
> short one-line status for each of them (inc. # of votes, whether a
> patch exists)
> along with a suggested course of action in another table. (see
> attached file)
>
> The suggested actions are all MHO, so apologies if I've misrepresented
> any
> of the issues, or the patches. Please post a follow-up message
> pointing out
> any mistakes, updates or alternative suggestions.
>
> Basically I recommend looking at FELIX-199 first, as it also solves
> several
> other issues. The one thorny area is over maven dependencies: whether to
> get the user to handle this outside in the pom with other plugins, or
> to add
> options to the bundle plugin for the sake of convenience (FELIX-255/262).
>