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 <[EMAIL PROTECTED]> 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
