half here, half in felix-dev
I have made some improvements to Felix bundle plugin for manifest
generation that you can see here
https://issues.apache.org/jira/browse/FELIX-199
once that it's applied and hopefully released we'll give a try with
our own maven artifacts
On 3/28/07, Nathan Beyer <
On 3/28/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
I'm working with the Felix guys to go through all these issues. As
usual Maven would provide a default manifest that you could override
with configuration in your pom.
Where is this conversation happening? I'd like to hear more about the det
I'm working with the Felix guys to go through all these issues. As
usual Maven would provide a default manifest that you could override
with configuration in your pom.
On 3/28/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> We're just trying t
On 3/28/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
We're just trying to help out the OSGi folks so that they aren't
repackaging everything which is what they are doing. It's basically
doing the minimum work so that JARs produced will function with OSGi
containers. If it has no impact on normal
as soon as https://issues.apache.org/jira/browse/FELIX-199 gets
applied anybody can add the "manifest" goal and get the OSGi manifest
in the jar.
On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
2007/3/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> > It would be great if that could be available in
2007/3/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> It would be great if that could be available in 2.0.x version of
> Maven. We are too far from 2.1 version.
you will always have the option to add a plugin to your pom that will
generate the OSGi manifest (the maven-bundle-plugin from Apache
Felix).
On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populates manifest information.
It would be great if that could be av
On 28 Mar 07, at 9:27 AM 28 Mar 07, Kaloyan Enimanev wrote:
On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populat
On 28 Mar 07, at 9:15 AM 28 Mar 07, Damien Lecan wrote:
> How this will be done ?
At first by putting an innocuous plugin in the lifecycle, or in 2.1
with extensions in Plexus it will be an extension to the JAR plugin
that populates manifest information.
It would be great if that could be ava
Hi Milos
I was just expressing an opinion :)
I'm not part of the Maven team.
best regards,
Kaloyan
On 3/28/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
if I understood correctly, OSGI bundles should have a special
packaging like ear/wars do and define it's lifecycle to include the
OSGI stuff i
if I understood correctly, OSGI bundles should have a special
packaging like ear/wars do and define it's lifecycle to include the
OSGI stuff in the resulting binary
Milos
On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
> > Ok I understand, but you didn't answer my (not clear) question : if
> Ok I understand, but you didn't answer my (not clear) question : if
> OSGi packaging is fast enough, will OSGi manifest entries be
> transparently added to every maven-build jars ?
>
> Or will it be an OSGi developer option, that will never be known and
> used by other common people ?
IMHO this
On 3/28/07, Damien Lecan <[EMAIL PROTECTED]> wrote:
> > How this will be done ?
> At first by putting an innocuous plugin in the lifecycle, or in 2.1
> with extensions in Plexus it will be an extension to the JAR plugin
> that populates manifest information.
It would be great if that could be av
> How this will be done ?
At first by putting an innocuous plugin in the lifecycle, or in 2.1
with extensions in Plexus it will be an extension to the JAR plugin
that populates manifest information.
It would be great if that could be available in 2.0.x version of
Maven. We are too far from 2.1 v
On 28 Mar 07, at 4:02 AM 28 Mar 07, Damien Lecan wrote:
Hello,
[...]
it is entirely non-invasive then I
think it would be fine to add to the default lifecycle.
How this will be done ?
At first by putting an innocuous plugin in the lifecycle, or in 2.1
with extensions in Plexus it will
Hello,
[...]
it is entirely non-invasive then I
think it would be fine to add to the default lifecycle.
How this will be done ?
Does "bundle" packaging will become official, or will it supercede
default jar packaging ?
Will it be active by default ?
Thank you for this great job !
Damien Lec
On Monday 19 March 2007 16:12, Carlos Sanchez wrote:
> afaik they passed the vote to graduate
Oh yea. Forgot about that and google still brings up their incubator
page as the first hit (which still says it's undergoing incubation).
Guess they need to upgrade the incubator sites to let people
afaik they passed the vote to graduate
On 3/19/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
One more thing to take into consideration:
Felix is in incubation. Thus, as of right now, the plugin cannot go to
central. Feel free to complain about that on
[EMAIL PROTECTED]:-)
Dan
On Mo
One more thing to take into consideration:
Felix is in incubation. Thus, as of right now, the plugin cannot go to
central. Feel free to complain about that on
[EMAIL PROTECTED]:-)
Dan
On Monday 19 March 2007 16:03, Carlos Sanchez wrote:
> I'm still waiting for a big patch to be a
I'm still waiting for a big patch to be applied
https://issues.apache.org/jira/browse/FELIX-199
And they need to make a release also.
I'll take a look at the performance
On 3/19/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
This is mostly directed at Carlos,
Just following up on the discussion
This is mostly directed at Carlos,
Just following up on the discussion we have at EclipseCon. Have you
check the performance of the Felix plugin? If it doesn't add any
significant overhead to people building their JARs due to the
analysis performed by BND, and it is entirely non-invasive th
21 matches
Mail list logo
