Thanks for the explanation Jarek. It makes much more sense to me now.
Then as far as reusing the same code is concerned there is four choices:
- have a common converter bundle used by the application
BundleConverter as well as the webbundle handler
- make the webbundle handler reuse the BundleConverter
- make the BundleConverter reuse the webbundle handler
- have everything in a single bundle.
My personal preference would be the third choice, keeping a minimum of
separation without unnecessary bundle. Also, I think the
BundleConverter interface is the more general one. However, that
choice would mean the webbundle handler bundle would have imports from
application API. I assume that would not be a problem in Genorimo,
right?
What do people think?
Valentin
On 12 Jan 2010, at 16:05, Jarek Gawor wrote:
The converter and extender are related but separate parts. In Geronimo
I think we will have a Geronimo-specific extender but we would like to
use the converter from Aries. So we want to see the converter code
(along with the url handler) to be moved to trunk even though there is
no extender in Aries right now.
Jarek
On Tue, Jan 12, 2010 at 10:55 AM, Alasdair Nottingham
<[email protected]> wrote:
The WAR to WAB url handler is pretty useless in the absence of a web
application extender which can serve the content. That is why, in my
view, it has remained in contrib, not because of lack of interest.
Until we have a view on how/where we get a web application extender
from I do not think there is a need to create the WAR to WAB url
handler. At that time I would expect to want to ensure that the code
is reused between the BundleConverter and the WAR to WAB converter.
Alasdair
2010/1/12 Valentin Mahrwald <[email protected]>:
Hi Lin,
as it stands I have not moved the webbundle url handler part of
the code.
Rather I have moved the existing code to hook into the
BundleConverter API
that is defined in application manifest. So using the current bundle
(application-converters) you would not get the webbundle url
handler and you
would need to have at least the application API bundle as well.
The main reason for this setup is that there is an immediate use
case for
the code through the BundleConverter API but I was not sure on the
other
hand if anyone is actually interested in the webbundle url handler
on its
own (seeing how long the code has lingered in /contrib ;).
Regards,
Valentin
On 12 Jan 2010, at 14:30, Lin Sun wrote:
I prefer to keep them separately too. It is possible that people
may
just want to consume the webbundle url handler without the app
management API.
Lin
On Mon, Jan 11, 2010 at 4:46 PM, Alasdair Nottingham <[email protected]
>
wrote:
I'm very tempted to suggest putting it out separately so people
can
choose not to consume it reasonably easily. Also I think it is
likely
that as we progress we may want to use it in more places and
having it
slightly to one size should make that simpler.
Just my 2 cents worth.
Alasdair
2010/1/11 Valentin Mahrwald <[email protected]>:
My current working set has a new converters project under
application
primed
with the WarToWab conversions, but I suppose it could equally
go into
the
existing management project. Any thoughts?
Regards,
Valentin
On 11 Jan 2010, at 21:04, Jarek Gawor wrote:
Valentin,
Ok, great! Looking forward to your updates. Will the converter
be in a
separate module?
Jarek
On Mon, Jan 11, 2010 at 3:50 PM, Valentin Mahrwald
<[email protected]> wrote:
Hi Jarek,
I have started just yesterday moving it to the new
BundleConverter API
but I
haven't come round to raise a JIRA for it yet :) I am quite
happy to
continue with the task.
My idea was to take the code out of the context of the RFC 66
context
it
was
originally contributed since the RFC 66 bits weren't much
more than
the
conversion logic anyway.
Valentin
On 11 Jan 2010, at 20:38, Jarek Gawor wrote:
Hi,
Is anyone planning to migrate the WAR to WAB converter
donated by IBM
to trunk any time soon? If not, and if there are no
objections I can
work on moving that code to trunk.
Jarek
--
Alasdair Nottingham
[email protected]
--
Alasdair Nottingham
[email protected]
