On 3/23/07, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
On 23/03/07, Alin Dreghiciu <[EMAIL PROTECTED]> wrote:
> Just checked out and if I use:
>
>
> !META-INF.*,
> *
>
>
> I will get what I want: META-INF/spring not exported but in
On 23/03/07, Alin Dreghiciu <[EMAIL PROTECTED]> wrote:
Just checked out and if I use:
!META-INF.*,
*
I will get what I want: META-INF/spring not exported but included in the
bundle due to, I suppose, Include-resource.
It is anyhow
Just checked out and if I use:
!META-INF.*,
*
I will get what I want: META-INF/spring not exported but included in the
bundle due to, I suppose, Include-resource.
It is anyhow annoying that I will have exclude via the export-package
dir
On 3/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Alin Dreghiciu wrote:
> Hi,
>
> Does anyone recalls why the following code was added to the
> maven-bundle-plugin?
>
> if (new File(baseDir, "src/main/resources").exists()) {
> header(properties, Analyzer.INCLUDE_RESOURCE,
"src/main/re
Hi,
On 3/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
although the conditional was added later because someone
experienced an issue.
This was me :-) The reason for the problems is, that if the
src/main/resources folder would not exist but would be added to the
BND properties, BND would fa
Alin Dreghiciu wrote:
Hi,
Does anyone recalls why the following code was added to the
maven-bundle-plugin?
if (new File(baseDir, "src/main/resources").exists()) {
header(properties, Analyzer.INCLUDE_RESOURCE, "src/main/resources/");
}
In my view has two problems:
1. is useless since by
I just need one: the one I'm using as direct dependency. If you take a look
at FELIX-225 you will know what I mean.
And I want to do it automatically not to pick one by hand.
Alin Dreghiciu
On 3/15/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
the manifest goal will allow you to generate a bun
the manifest goal will allow you to generate a bundle from the same project
the bundleall will go through all transitive dependencies and bundle
one by one if they are not already OSGi bundles. So if they are you'll
get just the one you want
On 3/14/07, Alin Dreghiciu <[EMAIL PROTECTED]> wrote:
I do not find the direct relation but I do find your improvements very
useful especially the manifest goal.
Could you detail more. Seems to me, if I get it rght that the bundleall will
create a bundle for all dependencies.
I just wish to allow me to just wrap the direct dependency and nothing else
iche Nachricht-
Von: Stuart McCulloch [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 09. März 2007 09:17
An: felix-dev@incubator.apache.org
Betreff: Re: maven-bundle-plugin, wrapping and excludeTransitive
Hi Michael,
If the original jar has dependencies with 'compile' scope then they're
BTW, one way to exclude transitive dependencies at the moment is:
1A) specify wrapped jars as dependencies with 'runtime' scope and
use the maven-dependency-plugin to copy them into a directory
called 'lib' ... the dependency plugin has an excludeTransitive
option to not copy the e
Hi Michael,
If the original jar has dependencies with 'compile' scope then they're added to
the build classpath and packaged in the final bundle. This may or may not be
what you want - some jars have dependencies that form a collective module
and would never appear separately, so you'd like those
Hi Michael,
Transitive dependencies are a great thing and huge plus for Maven 2 over
Maven 1. On the other hand, if not judiciosly configured, transitive
dependencies may quickly evolve to a huge pile of libraries being packed
when using packing plugins like the maven-bundle-plugin (as well as th
Actually I have almost get it to work, the manifest just seems not to
be right yet.
Latest code of my branch of the bundle plugin is at
http://svn.apache.org/repos/asf/maven/sandbox/plugins/maven-bundle-plugin/
if you want to give it a try.
On 2/12/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
From what Peter says, it doesn't sound like this is easily possible:
This is not possible ... The bnd file == the manifest. You can't have the
definition in two places. So or you use the PDE where the manifest describes
your classpath (together with Eclipse magic), and then no bnd. Or you us
Richard S. Hall wrote:
Carlos Sanchez wrote:
On 1/26/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
One thing we could possibly do is to allow both:
groupId=org.mortbay.jetty;artifactId=jetty,*;scope=runtime
or
In the spirit of not trying to make more work for you, I woul
Alex Karasulu wrote:
I agree with Alan here. Maven can get ugly with you if you start to
stray from it's conventions. It might be worth considering his approach.
It seems that we just have to figure out exactly what its conventions are...
However, I am more aligned with Chris, get it working
I agree with Alan here. Maven can get ugly with you if you start to
stray from it's conventions. It might be worth considering his approach.
Alex
Richard S. Hall wrote:
Carlos Sanchez wrote:
On 1/26/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
One thing we could possibly do is to allow
I suspect that those of us who like the simple OSGi style directives have
spent a lot of time hand crafting OSGi manifest headers and don't want to
switch gears inside this little block of instructions for BND. Those who
want to see XML probably don't care much for this specific syntax (yet). I
Carlos Sanchez wrote:
On 1/26/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
One thing we could possibly do is to allow both:
groupId=org.mortbay.jetty;artifactId=jetty,*;scope=runtime
or
In the spirit of not trying to make more work for you, I would be
happy to contribute th
On 1/26/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
One thing we could possibly do is to allow both:
groupId=org.mortbay.jetty;artifactId=jetty,*;scope=runtime
or
In the spirit of not trying to make more work for you, I would be
happy to contribute the latter.
A maven co
Plexus makes using XML in the POM crazy simple. It does all the work
for you so avoiding XML does not save you a lot of time. Just
pointing this out to those who have never made a maven plugin; it's
pretty easy to do.
Regards,
Alan
On Jan 27, 2007, at 3:04 PM, Chris Custine wrote:
I ca
I can see merits to both approaches, but at the moment I think retaining the
OSGi manifest directive style makes the most sense. I can see the XML
syntax being an enhancement at some point as the tools evolve, but I just
can't see worrying about it too much right now.
Frankly, I think tooling fo
On Jan 27, 2007, at 1:47 AM, Alex Karasulu wrote:
Richard S. Hall wrote:
Alan D. Cabrera wrote:
In the spirit of not trying to make more work for you, I would be
happy to contribute the latter.
Something to consider...thanks.
What does this mean?
It means that we will consider the solutio
Richard S. Hall wrote:
Alan D. Cabrera wrote:
In the spirit of not trying to make more work for you, I would be
happy to contribute the latter.
Something to consider...thanks.
What does this mean?
Alex
Alan D. Cabrera wrote:
On Jan 26, 2007, at 1:21 PM, Richard S. Hall wrote:
Alan D. Cabrera wrote:
On Jan 26, 2007, at 12:16 PM, Richard S. Hall wrote:
Red
Blue
Red
Red
Blue
Red
Perhaps we have others with viewpoints on this?
One thing we could possibly do is to allow both:
On Jan 26, 2007, at 1:21 PM, Richard S. Hall wrote:
Alan D. Cabrera wrote:
On Jan 26, 2007, at 12:16 PM, Richard S. Hall wrote:
Red
Blue
Red
Red
Blue
Red
Perhaps we have others with viewpoints on this?
One thing we could possibly do is to allow both:
groupId=org.mortbay.j
Alan D. Cabrera wrote:
On Jan 26, 2007, at 12:16 PM, Richard S. Hall wrote:
I agree that this is a reasonable argument, but this is only relevant
if we assume that at some point in time someone else might want to
parse the BND commands, which seems like an unlikely possibility.
I'm not so s
Hi,
I would like to second Richard in keeping the syntax. In contrast to many
other maven plugins out there in plugin land, this one is a very simple
frontend to a third party tool. The parameters inside the
element are simply copied over to the parameter map for BND.
I think it is valid to sta
On Jan 26, 2007, at 12:16 PM, Richard S. Hall wrote:
Alan D. Cabrera wrote:
On Jan 26, 2007, at 5:30 AM, Richard S. Hall wrote:
This would allow people to easily achieve the same behavior as
the old plugin by simply doing:
*;scope=compile,*;scope=runtimedependency>
Thus, this instru
Alan D. Cabrera wrote:
On Jan 26, 2007, at 5:30 AM, Richard S. Hall wrote:
This would allow people to easily achieve the same behavior as the
old plugin by simply doing:
*;scope=compile,*;scope=runtime
Thus, this instruction would automatically embed any maven
dependencies that were o
On Jan 26, 2007, at 5:30 AM, Richard S. Hall wrote:
This would allow people to easily achieve the same behavior as
the old plugin by simply doing:
*;scope=compile,*;scope=runtimedependency>
Thus, this instruction would automatically embed any maven
dependencies that were of scope "com
One other issue that I think we need to follow up on, how should the
plugin handle transitive dependencies of the bundle's dependencies?
I see three options:
1. Ignore them and require the bundle developer to list them as
explicit dependencies if they want to embed them.
2. Embed all t
Alan D. Cabrera wrote:
On Jan 25, 2007, at 12:35 PM, Richard S. Hall wrote:
Hello,
Back in early December we had a discussion with Emil Eifrém, Aaron
Siri, et al about how the new bundle plugin should deal with
embedding (as opposed to inlining) dependent JAR files. Peter and I
have finall
Peter Kriens wrote:
RSH> No, it won't. Classes on the bundle class path will be considered part
RSH> of the content of the bundle and BND will not generate imports for
RSH> packages that are part of the content of the bundle.
Unless you export them of course ...
If you export them, BND won
On Jan 25, 2007, at 12:35 PM, Richard S. Hall wrote:
Hello,
Back in early December we had a discussion with Emil Eifrém, Aaron
Siri, et al about how the new bundle plugin should deal with
embedding (as opposed to inlining) dependent JAR files. Peter and I
have finally had some time to di
On 1/25/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
On Jan 25, 2007, at 4:27 PM, Emil Eifrém wrote:
> Hey, thanks guys for coming back to this issue. The proposal is a good
> step forward. One question tho. If I use a class that is provided by a
> jar file on Bundle-Classpath... won't the plug
On Jan 25, 2007, at 4:27 PM, Emil Eifrém wrote:
On 1/25/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
This instruction would be used to match the specified Maven
dependencies
for embedding. Any matching dependency would have its JAR file
embedded
onto the resulting bundle JAR file and it wo
On 1/25/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
This instruction would be used to match the specified Maven dependencies
for embedding. Any matching dependency would have its JAR file embedded
onto the resulting bundle JAR file and it would be appended to the
Bundle-ClassPath header after
On Tue, January 2, 2007 8:20 pm, Richard S. Hall wrote:
> Generally speaking, the plugin will only include into your bundle JAR
> file the packages you list in or . All
> other packages will be imported. So, if you list packages from Eclipse
> inside of these declarations, then you are telling th
Graham Leggett wrote:
I am having some conceptual problems with the maven-bundle-plugin and the
way dependencies are handled.
I have successfully managed to use the maven-bundle-plugin to produce an
OSGI bundle from an Eclipse RCP application that we use. The nett result
is a single bundle that'
41 matches
Mail list logo
