Hi,
Does anybody know whether maven scr plugin is compatible with java 10?
I am trying to build an equinox osgi based software platform with java 10
and i am unable to get the scr plugin to generate the OSGI-INF folder
structure (which contains serviceComponents.xml) in target folder. As a
>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
>>
>>
>>
>>
>>
>>
>>
>> Regards,
>> Jens
>>
>>
>> Gesendet: Dienstag, 22. März 2016 um 07:45 Uhr
>&g
ct.build.outputDirectory}/OSGI-INF
> false
>
>
>
>
>
>
>
> Regards,
> Jens
>
>
> Gesendet: Dienstag, 22. März 2016 um 07:45 Uhr
> Von: "Carsten Ziegeler&qu
false
Regards,
Jens
Gesendet: Dienstag, 22. März 2016 um 07:45 Uhr
Von: "Carsten Ziegeler"
An: users@felix.apache.org
Betreff: Re: maven-scr-plugin and DS 1.3 annotations not working
The maven-scr-plugin does not support the DS 1.
The maven-scr-plugin does not support the DS 1.3 annotations.
Using the maven-bundle-plugin 3.0.1 is all you need. I think you need to
add this configuration to the bundle plugin:
<_dsannotati
Hi,
I am using maven-scr-plugin:1.21.0,
org.osgi.service.component.annotations:1.3.0,
org.apache.felix.scr.ds-annotations:1.2.8 and
org.apache.felix.scr.annotations:1.9.12 and maven-bundle-plugin:3.0.1.
This is my annotated class with makes use of the prototype scope:
@Component(immediate
Hi,
I woukd like to know whether maven-scr-plugin currently supports the
*properties* property of org
.osgi
.service
.component
.annotations
.Component in order to use/refer to a properties file inside the bundle.
I tried to set a component but I'm not seeing any result in the generate
Hi,
Has anyone tried integrating the maven-scr-plugin with a Tycho build?
I'm currently maintaining the SCR descriptor files by hand and it's a
pain.
The main issue that I face is that I would need to get the scr
annotations jar into a p2 repository to convince the toolchain (
E
FYI,
the problem was fixed and will be available in next release.
https://issues.apache.org/jira/browse/FELIX-4159
On 03/07/13 12:58, Jad Naous wrote:
looks like you're defining three properties called "foo" in your @Component
parameters. Try change "foo" to foo1, foo2, foo3.
On Wed, Jul 3,
Hi,
That was intentional since the OSGi compendium spec (112.14
org.osgi.service.component.annotations) defines that:
Each property string is specified as "key=value". The type of the
property value can be specified in the key as key:type=value. The type
must be one of the property types sup
looks like you're defining three properties called "foo" in your @Component
parameters. Try change "foo" to foo1, foo2, foo3.
On Wed, Jul 3, 2013 at 7:05 AM, Cristiano Gavião wrote:
> Hi,
>
> I'm trying to declare a DS component with a property with multiple values:
>
> @Component(name = "My co
Hi,
I'm trying to declare a DS component with a property with multiple values:
@Component(name = "My commands",
property={"foo:Integer=1","foo:Integer=2","foo:Integer=3"})
And I'm getting the following error:
Duplicate definition for property foo in class MyCommandsComponent
(org.apache.fel
e methods
>>> because of the class being final. Could you try not declaring the class
>>> final ? If that works, I would assume the plugin should properly complain
>>> and fail the build due to missing methods.
>>>
>>> Regards
>>> Felix
&
the plugin not generating the methods
>> because of the class being final. Could you try not declaring the class
>> final ? If that works, I would assume the plugin should properly complain
>> and fail the build due to missing methods.
>>
>> Regards
>>
ould assume the plugin should properly complain and fail
> the build due to missing methods.
>
> Regards
> Felix
>
> Am 24.02.2013 um 15:23 schrieb László Hordós:
>
>> Hi,
>>
>> I just updated to maven-scr-plugin:1.10.0 and
>> org.apache.fe
declaring the class final ?
If that works, I would assume the plugin should properly complain and fail the
build due to missing methods.
Regards
Felix
Am 24.02.2013 um 15:23 schrieb László Hordós:
> Hi,
>
> I just updated to maven-scr-plugin:1.10.0 and
> org.apache.felix.scr.annotations
Hi,
I just updated to maven-scr-plugin:1.10.0 and
org.apache.felix.scr.annotations:1.8.0 and I have this component:
@Component(name = "org.example.component", immediate = true, policy =
ConfigurationPolicy.IGNORE)
public final class ContextRegistrator {
@Reference
H
Great! Thanks a lot!
Best regards,
Patrick
From:
Carsten Ziegeler
To:
users@felix.apache.org,
Date:
15.02.2013 11:26
Subject:
Re: Release plans for maven-scr-plugin 1.10.0?
Hi,
I started the vote this week, so 1.10.0 will be available on Monday :)
Regards
Carsten
2013/2/15 Patrick
Hi,
I started the vote this week, so 1.10.0 will be available on Monday :)
Regards
Carsten
2013/2/15 Patrick Schlebusch :
> Hi,
>
> are there any plans for the 1.10.0 release of the maven-scr-plugin in the
> near future? According to the roadmap in Jira [1], all issues are
> res
Hi,
are there any plans for the 1.10.0 release of the maven-scr-plugin in the
near future? According to the roadmap in Jira [1], all issues are
resolved, so I was wondering whether that might happen soon.
Alternatively, is there a way to obtain a snapshot version of the plugin
from a public
2012 at 4:31 PM, Justin Edelson
> wrote:
>
>> Hi Miles,
>> I don't think the maven-scr-plugin works with any language other than Java
>> right now. There's an effort on to rewrite the core of the scr-plugin in
>> such a way that it operates
best practises for maintain bundle dependencies
On Mon, Jul 23, 2012 at 4:31 PM, Justin Edelson wrote:
> Hi Miles,
> I don't think the maven-scr-plugin works with any language other than Java
> right now. There's an effort on to rewrite the core of the scr-plugin in
> such a w
Hi Miles,
I don't think the maven-scr-plugin works with any language other than Java
right now. There's an effort on to rewrite the core of the scr-plugin in
such a way that it operates at the bytecode rather than the source code
level. See https://issues.apache.org/jira/browse/FELI
Hi all,
I’ve recently been brought onto a new project to migrate some legacy code.
We’ve had some good success with Groovy assuming the OSGI manifests are
written manually but when I try and use a more modern annotation driven
approach the scr-plugin doesn’t appear to pick up the reference.
H
Future of the Maven SCR Plugin
From: Carsten Ziegeler
To: d...@felix.apache.org
Date: Tue 29 Nov 2011 01:47:29 AM CST
> 2011/11/28 Reto Bachmann-Gmür :
>> Well, the old annotations could also be improved so that FELIX-2892
>> and the (probably duplicate) FELIX-3187 could be resolved
2011/12/15 Mark Derricutt :
> Will raise one shortly - we'll also need to get ASM 4.0 in maven central as
> well which is the version that supports 1.7 (apparently?).
Ah I thought this would work with the current asm by just setting the
flags...ok, yes in that case we need the new asm as well in t
Will raise one shortly - we'll also need to get ASM 4.0 in maven central as
well which is the version that supports 1.7 (apparently?).
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Wed, Dec 14, 2011 at 9:41 PM, Carsten Ziegeler wrote:
> So I gue
So I guess we should add those flags to the plugin. Could you please
create a jira issue for that?
Thanks
Carsten
2011/12/9 Mark Derricutt :
> Interesting, when I enable those two flags seem to work, altho now I seem
> to be getting ClassNotFoundExceptions on classes from in maven
> dependencies.
Interesting, when I enable those two flags seem to work, altho now I seem
to be getting ClassNotFoundExceptions on classes from in maven
dependencies. The mojo has "@requiresDependencyResolution compile" and yet
it doesn't seem to find compile time dependency classes.
Might have to chase this up
Hi,
I had the same issues with iPOJO:
https://plus.google.com/u/0/116267359728910593612/posts/hfMFf3mWKTP
Regards,
Clement
On 07.12.2011, at 04:50, Mark Derricutt wrote:
> No I didn't - I'll give that a go and report back.
>
> Cheers,
> Mark
>
>
> --
> "Great artists are extremely selfish a
No I didn't - I'll give that a go and report back.
Cheers,
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On Wed, Dec 7, 2011 at 2:51 PM, Stuart McCulloch wrote:
> Did you try passing ClassWriter.COMPUTE_MAXS or ClassWriter.COMPUTE_FRAMES
>
On 6 Dec 2011, at 22:36, Mark Derricutt wrote:
> Is anyone currently using tghe maven-scr-plugin under JDK 1.7 compiling
> with a -target- language level of JDK 1.7?
>
> Whilst the plugin runs fine, it appears that any automatically generated
> bind/unbind methods created by the
Is anyone currently using tghe maven-scr-plugin under JDK 1.7 compiling
with a -target- language level of JDK 1.7?
Whilst the plugin runs fine, it appears that any automatically generated
bind/unbind methods created by the plugin generate bad bytecode for JDK 1.7.
It appears that the version of
il Bartlett wrote:
> Do you have other Java versions installed on the same machine, and is
> it possible that Maven has picked up one of the other ones?
>
> Also, did you compile the Maven SCR plugin locally? It would be
> surprising to me if the binaries for the plugin are being sh
machine, and is
it possible that Maven has picked up one of the other ones?
Also, did you compile the Maven SCR plugin locally? It would be
surprising to me if the binaries for the plugin are being shipped with
class version 51.0, implying they can only run on Java 7.
Regards,
Neil
On Mon, Nov 21
Has anyone got maven-scr-plugin working under OpenJDK 1.7 at all?
[ERROR] Failed to execute goal org.apache.felix:maven-scr-plugin:1.7.4:scr
(generate-scr-scrdescriptor) on project smx3.entity: Execution
generate-scr-scrdescriptor of goal
org.apache.felix:maven-scr-plugin:1.7.4:scr failed: An API
The Apache Felix team is pleased to announce the release
Apache Felix Maven SCR Plugin 1.6.0
Apache Felix SCR Ant Task 1.0.0
Apache Felix SCR Generator 1.0.0
Apache Felix SCR Annotations 1.4.0
The Apache Felix Maven SCR Plugin is a Maven 2 plugin to generate OSGi
Declarative Services and
Maven SCR Plugin) please and maybe attach a simple example?
Regards
Carsten
Stephen Flynn wrote
>
> Apologies if this is posted in the wrong place or this issue has already
> been raised and I have missed it.
>
> We use SCR annotations (1.2.0) and the SCR Maven Plug-in (1.4.2) to
&g
Apologies if this is posted in the wrong place or this issue has already been
raised and I have missed it.
We use SCR annotations (1.2.0) and the SCR Maven Plug-in (1.4.2) to generate DS
1.1 component descriptors. All works well except for one issue - we cannot find
a way to control the orde
Justin Edelson wrote:
[...]
So the best thing to do is to only specify plugin versions in the parent,
using either the plugins or pluginManagement elements.
Justin
Hi Justin,
it worked!
Thanks for your support.
Guido
-
T
On Mon, Dec 28, 2009 at 12:59 PM, Guido Spadotto wrote:
> Hi Justin,
> thanks for your hint.
>
> So, if I specify the versions I require the whole project to use in the
> "pluginManagement" section of my
> parent pom P, will that be enough to avoid this
> "first-version-found-is-always-used" polic
Justin Edelson wrote:
One thing to look at is to confirm that you are *only* specifying the plugin
versions for both maven-scr-plugin and maven-bundle-plugin in the parent
POM. Maven has a bug/feature wherein it will only use one version of a given
plugin in a multi-module build, even if
One thing to look at is to confirm that you are *only* specifying the plugin
versions for both maven-scr-plugin and maven-bundle-plugin in the parent
POM. Maven has a bug/feature wherein it will only use one version of a given
plugin in a multi-module build, even if different versions are
Hi all,
I'm facing a very strange behaviour that *might* be related to SCR
(I'm not sure, so Carsten - if you're reading this - please forgive me).
The project I'm working on is divided into several Maven modules.
The modules I maintain use the maven-scr-plugin (v1.4
Guido Spadotto wrote:
> Hi Carsten, after you mentioned the difference, I realized that it's
> exactly as you wrote above.
>
> One description is about java annotations and the other one for javadocs.
>
> My fault, I have to connect fingers with brain *before* posting.
>
Hehe, no problem :) I th
Carsten Ziegeler wrote:
Hi,
[...]
In http://felix.apache.org/site/apache-felix-maven-scr-plugin.html there
are *two* paragraphs that explain how to deal with multivalue properties, and I
can't understand which is the correct one.
Hmm, can you point me to the two paragraphs? Or is one
Hi,
Guido Spadotto wrote:
> Hi all,
> I'm a bit puzzled by this (hopefully simple to solve) issue.
>
> I'm writing an EventHandler implementation using SCR annotations.
> How do I specify multi-value property for the topics to listen to?
> I've this at the moment, is it correct?
>/**
> *
Hi all,
I'm a bit puzzled by this (hopefully simple to solve) issue.
I'm writing an EventHandler implementation using SCR annotations.
How do I specify multi-value property for the topics to listen to?
I've this at the moment, is it correct?
/**
* The OSGi Event Topics to listen to
*
I know Spring and the new JSR330 (Dependency Injection For Java) specs
support it, using a notation similar to what I mentioned in the first
post. I suspect what they're doing is scanning classes for the
annotations they want, and if they find any unknown annotations,
recurse into checking the ann
al Message-
From: Mark Derricutt [mailto:m...@talios.com]
Sent: 16 December 2009 00:51
To: users@felix.apache.org
Subject: maven-scr-plugin annotations
'lo all,
I'm really loving using the JDK annotations for @Component and
@Service etc. in my code base, really makes using SCR much
'lo all,
I'm really loving using the JDK annotations for @Component and
@Service etc. in my code base, really makes using SCR much nicer,
however I was wondering if the plugin supports chained annotations at
all? What I'd love to do is:
@Component(immediate = true)
@Service
@Retention(RetentionP
Hi,
you can use the @Services annotation which allows you to embed several
@Service annotations.
Regards
Carsten
Daniel Bimschas wrote:
> Hi there!
>
> I just found an unsupported use case that I'm "stuck" with. Consider a
> class A that implements the interfaces B, C and EventHandler. For B an
Hi there!
I just found an unsupported use case that I'm "stuck" with. Consider a
class A that implements the interfaces B, C and EventHandler. For B
and C class A wants to be registered as service declaratively.
Therefore I use the scr annotations. For interface EventHandler I want
to reg
On 28.07.2009, at 10:59, Carsten Ziegeler wrote:
Clement Escoffier wrote
Hi,
iPOJO uses ASM to handle annotations. In iPOJO, this choice made
perfect
sense as the manipulation is itself built with ASM. This allows to
introspect all the annotations present in the bytecode of classes.
Howev
Clement Escoffier wrote
>
> Hi,
>
> iPOJO uses ASM to handle annotations. In iPOJO, this choice made perfect
> sense as the manipulation is itself built with ASM. This allows to
> introspect all the annotations present in the bytecode of classes.
> However, it will require that you compile your c
On 28.07.2009, at 10:08, Carsten Ziegeler wrote:
Reto Bachmann-Gmür wrote:
Carsten Ziegeler said the following on 07/27/2009 02:41 PM:
Reto Bachmann-Gmür wrote:
Hello
I was hoping that with support for annotations the scr plugin
would work
with scala code as well. But in my mixed java/sc
Reto Bachmann-Gmür wrote:
> Carsten Ziegeler said the following on 07/27/2009 02:41 PM:
>> Reto Bachmann-Gmür wrote:
>>
>>> Hello
>>>
>>> I was hoping that with support for annotations the scr plugin would work
>>> with scala code as well. But in my mixed java/scala project it seems to
>>> only
Carsten Ziegeler said the following on 07/27/2009 02:41 PM:
> Reto Bachmann-Gmür wrote:
>
>> Hello
>>
>> I was hoping that with support for annotations the scr plugin would work
>> with scala code as well. But in my mixed java/scala project it seems to
>> only look at the annotations in the java
Reto Bachmann-Gmür wrote:
> Hello
>
> I was hoping that with support for annotations the scr plugin would work
> with scala code as well. But in my mixed java/scala project it seems to
> only look at the annotations in the java sources.
>
> @Component
> public class Service {
>
> @Property(v
Hello
I was hoping that with support for annotations the scr plugin would work
with scala code as well. But in my mixed java/scala project it seems to
only look at the annotations in the java sources.
@Component
public class Service {
@Property(value = "default value")
static final Strin
plugin is 1.0.8
Carsten
>
> [1]:
> http://repo2.maven.org/maven2/org/apache/felix/maven-scr-plugin/maven-metadata.xml
>
> [2]: http://repo2.maven.org/maven2/org/apache/felix/maven-scr-plugin/
>
> Thanks.
--
Carsten Ziegeler
cziege...@apache.org
--
Hi All,
the URL in [1] says that the latest version of the SCR plugin is 1.2.8,
but there's no such version in [2].
Is this correct?
[1]:
http://repo2.maven.org/maven2/org/apache/felix/maven-scr-plugin/maven-metadata.xml
[2]: http://repo2.maven.org/maven2/org/apache/felix/maven-scr-p
>
>
> only if the parent of "org.trialox:org.trialox.triaxrs:bundle" that
> contains it as a module is built, not if I go in the subdirectory and
> compile the individual project.
>
> We are using maven-scr-plugin 1.0.10.
>
> Any ideas on what could cause this
; that
contains it as a module is built, not if I go in the subdirectory and
compile the individual project.
We are using maven-scr-plugin 1.0.10.
Any ideas on what could cause this error?
Cheers,
Reto
-
To unsubscribe, e-mail:
Mark Derricutt wrote:
> Using 1.0.8 works fine, I never saw a 1.0.9 in my repository so I
> guess things went straight to 1.0.10.
Thanks for the info. Yes, we never released a 1.0.9 as it had some problems.
So it seems updating qdox from 1.0.8 to 1.0.10 fixed parsing problems
for some people while
@Pattern(message = "{domainName.invalid}", regex =
"^([A-Za-z0-9]([-A-Za-z0-9]*[A-Za-z0-9])*\\.)+[A-Za-z]{2,}$")
It doesn't seem to like the \\ in the regex.
On Wed, Mar 18, 2009 at 8:13 PM, Carsten Ziegeler wrote:
> Mark Derricutt wrote:
>> I noticed the other day
Mark Derricutt wrote:
> I noticed the other day 1.0.10 of the maven-scr-plugin was released,
> since using this plugin we're seeing illegal escape character problems
> when compiling our bundles.
>
Hi,
we're using this version without any problems. Does it work for you with
I noticed the other day 1.0.10 of the maven-scr-plugin was released,
since using this plugin we're seeing illegal escape character problems
when compiling our bundles.
[ERROR] FATAL ERROR
[INFO]
[INFO] Illegal e
Hi,
this is a known issue of the QDox parser the plugin issues.
http://felix.apache.org/site/apache-felix-scr-plugin-faq.html
Now, did you use the latest release of the scr plugin, 1.0.10? I think
the issue in QDox is fixed there.
Regards
Carsten
Reto Bachmann-Gmür wrote:
> with the following c
with the following class:
public class Test {
public enum Type {
SCHEME,
USER_INFO
}
public Test() {
}
}
I get exeptions like the following:
com.thoughtworks.qdox.parser.ParseException: syntax error @[8,14] in
file:/home/rbn/projects/default/org.trialox.jax
see below :-)
> >> Of course you can still opt to ignore any call to the bind and unbind
> >> method and instead use the ComponentContext to lookup the reference on
> >> demand. But, I agree, that this definitely clutters the class and adds
> >> some overhead without any real need.
> >
> > Jup t
Hi Thijs,
Thijs Metsch schrieb:
> Hi,
>
>> Of course you can still opt to ignore any call to the bind and unbind
>> method and instead use the ComponentContext to lookup the reference on
>> demand. But, I agree, that this definitely clutters the class and adds
>> some overhead without any real ne
Hi,
> Of course you can still opt to ignore any call to the bind and unbind
> method and instead use the ComponentContext to lookup the reference on
> demand. But, I agree, that this definitely clutters the class and adds
> some overhead without any real need.
Jup the overhead is my concern :-)
Hi Thijs,
Thijs Metsch schrieb:
> Hi,
>
> If I wanted to use a lookup strategy to access my service; does
> maven-scr-plugin support this? And how?
Well, the scr plugin currently requires bind and unbind methods. Thus
the pure lookup strategy without using bind and unbind me
Hi,
If I wanted to use a lookup strategy to access my service; does
maven-scr-plugin support this? And how?
It all works using a event strategy to access my service :-) So that is
not the question :-)
Cheers,
-Thijs
--
Thijs MetschTel: +49 (0)941 3075-122 (x60122
provided - in this case maven does not include the transitive
dependencies in the classpath. As the scr plugin scans the class files
it requires all dependent classes in the class path.
HTH
Carsten
Heibel, Niklas wrote:
> Hi all,
>
> I'm totally confused! When I remove the maven-scr-
Felix Meschberger wrote:
> Hi Carsten,
>
> Shouldn't this be placed as a FAQ/Known Issues entry on the scr plugin
> documentation page ?
>
Done.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
gt; public interface MyTest {
>>
>> /** more error codes may be added */
>> enum Result {
>> OK, UNKNOWN, ERROR, DENIED
>> }
>>
>> /** @return the result */
>> public void getResult()
Hi Carsten,
...
> this is a known problem of the used qdox version to scan the source
> code. There is a workaround - I'm not 100% sure, but I think just
> putting a ";" after the closing bracket should do the trick.
Thanks! It works!
Best regards,
Niklas
--
x error) for source code files that use enum's
> like this:
>
> public interface MyTest {
>
> /** more error codes may be added */
> enum Result {
> OK, UNKNOWN, ERROR, DENIED
> }
>
> /** @return the result */
> public void ge
Error is during maven-scr-plugin is working:
[INFO] [scr:scr {execution: generate-scr-scrdescriptor}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] syntax
Hi all,
I'm totally confused! When I remove the maven-scr-plugin from my master pom.xml
maven finished successful.
Then I add this to the master pom.xml:
org.apache.felix
maven-scr-plugin
1.0.8
generate-scr-scrdescr
Ingo Feulner wrote:
> Hi Carsten,
>
> when do you think there will be a new release of the plugin and the
> metatype implementation?
> Anything I can help here?
>
Hi Ingo,
we're planning to have a release by next week. Testing and reporting
problems (or even having no problems) is always a great
Hi Carsten,
when do you think there will be a new release of the plugin and the
metatype implementation?
Anything I can help here?
Best regards, Ingo.
Am 25.08.2008 um 14:03 schrieb Carsten Ziegeler:
Ingo Feulner wrote:
Ok, thanks for the information, so I'll wait for the new release of
Ingo Feulner wrote:
> Ok, thanks for the information, so I'll wait for the new release of the
> two components.
>
> For the scr-plugin: Looking at the generated metatype.xml, which also
> uses the "metatype" namespace in all tags,
> is it possible there will be the same problems as with the
> serv
Ok, thanks for the information, so I'll wait for the new release of
the two components.
For the scr-plugin: Looking at the generated metatype.xml, which also
uses the "metatype" namespace in all tags,
is it possible there will be the same problems as with the
serviceComponents.xml?
I haven
Ingo Feulner wrote:
> Hi Carsten,
>
> I've just tried it and this problem is fixed now, thanks for the quick fix!
> But there's now another problem with the new format of the
> serviceComponent.xml - it does not work anymore when running inside the
> felix container
Hi Ingo,
yes this is a known
iner (it's working inside eclipse now ...). Output of
maven-scr-plugin is:
Well, of course I wanted to write "equinox"...
- Ingo.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
...). Output of
maven-scr-plugin is:
===
http://www.osgi.org/xmlns/scr/v1.0.0";>
name="net.oc.cardservices.terminal.CardTerminalRegistry">
class="net.oc.cardservices.terminal.CardTerminalRegistry"/>
interface=&
t; there still seems to be a problem with maven-scr-plugin, if the project
> POM references a paren POM:
> It works with 1.0.5, but does not work with 1.0.6, 1.0.7 and the
> trunk... here's the debug output:
> It tries to reference a manifest, but there's no in a POM project..
Hi,
there still seems to be a problem with maven-scr-plugin, if the
project POM references a paren POM:
It works with 1.0.5, but does not work with 1.0.6, 1.0.7 and the
trunk... here's the debug output:
It tries to reference a manifest, but there's no in a POM project...
Any i
Hi Carsten,
> No problem - and sorry for forgetting to commit the second part of the
> patch :(
> I just committed it, can you please recheck?
Sorry for the delay! I had to fix an other Problem :D
Now I recheck and build the plugin from current trunk r688080
Your Patch works fine, THANKS for al
Heibel, Niklas wrote:
>
> and apply it to my m2_repo with "mvn clean install", then I changes the
> version in my pom-file to "1.0.8-SNAPSHOT". After that the generated
> xml-file is still corrupt for equinox.ds.
>
> In my "local" patch I remove the PREFIX from all _QNAME constants.
>
> PREFEX i
Hi Carsten,
> it seems that the schema is the specification for the xml document
> (apart from the ordering of elements), so the inner elements should
have
> no namespace.
>
> I've created a bug for this and will
> https://issues.apache.org/jira/browse/FELIX-695
>
> and applied a fix to latest t
he inner tags (see attached file). Only
>> the component tag has the namespace. This file works fine.
>>
>> When I check the generated xml-file from the maven-scr-plugin with the
>> schema-xsd-file the test failed.
>>
>> I hope there is no mistake in my advise
>
> When I check the generated xml-file from the maven-scr-plugin with the
> schema-xsd-file the test failed.
>
> I hope there is no mistake in my advisement :)
>
Hi Niklas,
actually, I don't know :) In my opinion, the schema is broken :) but it
seems that equinox is
This File is running with equinox.ds.
I remove the namespace only in the inner tags (see attached file). Only
the component tag has the namespace. This file works fine.
When I check the generated xml-file from the maven-scr-plugin with the
schema-xsd-file the test failed.
I hope there is no mistake in
Heibel, Niklas wrote:
> You are right. The "components"-Tag is needed for a valid xml file when you
> have more then one components. That's my mistake, but the namespace is still
> a problem with equinox.ds
>
> When I remove the "scr:" from all Tags, my services are up und running,
> otherwise
#x27;s my mistake, but the namespace is still a
problem with equinox.ds
When I remove the "scr:" from all Tags, my services are up und running,
otherwise the services don't start.
The attachment files:
<>
Generated by maven-scr-plugin. Services not started.
<>
Remove th
1 - 100 of 115 matches
Mail list logo
