plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <>
Subject Re: Hardening our build ... what I learnt
Date Sun, 20 Jan 2019 15:32:51 GMT
After fetching and pulling into my develop branch I was able to `mvn clean
package` both with and without network with no errors.  Nice job.

On January 19, 2019 at 13:17:11, Christofer Dutz (

Ok ... so I guess I finally identified the problem Justin was having and
fixed it (hopefully)

It turned out that Justin wasn't doing a "mvn package" or "mvn verify" or
"mvn install" ... but a "mvn compile".
When doing this, Maven doesn't execute the package phase and Maven passes a
directory in as dependency (Which is usually ok)
However the karaf plugin isn't expecting this. So if tries to read the
directory as if it was a jar (Zip File) and of course this fails.

I managed to shift the feature.xml generation to the package phase ... as
we don't have any code to compile, tests to run and stuff to package, this
is a valid workaround.
However I should report this to the karaf team as this is definitely a bug
... the plugin should be able to handle this.

Either it should be able to handle directories and keep the generation in
the generate-resources phase, or they should move is to a phase for which
is known that jar exists.

Guess this was the last build-problem I know of ...

And as it turns out to be an avoidable problem by simply running "mvn
package" instead of "mvn compile" I don't think we need the hastle of
rebasing the release branch.
But that's up to you Julian.


´╗┐Am 19.01.19, 11:52 schrieb "Christofer Dutz" <>:

Hi Julian,

I think I'd wait for Justin to respond to my last suggestions ... this is
the last issue I have on my radar.

After we've addressed everything maybe it would be good to re-base even if
these potential problems were always in there and we never really had any
problem reports during the last releases. SO I guess it's up to you as
Release Manager to decide ;-)

Otto's problem could be solved by being online (We should change that
I really like this option to define custom annotations for Junit5 and have
some of the tests simply skipped if a prerequisite is not met. So I'd
probably define a "@RequiresBeingOnline" and if that's not true it will
skip that particular test.
This way we can generally continue to test this functionality, without the
problem of not being able to build offline. And I would probably add a
"@RequiresNonCaptureAllDns" annotation for the other problems reported
(This would just resolve two non-existent domain names and if both succeed
and are equal, we've detected a "capture-all-dns" setup)


Am 19.01.19, 11:38 schrieb "Julian Feinauer" <>:

Hey Chris,

thanks for the analysis, I'm totally of with Karaf, I'm not even able
understand the problem it solves : /
But to your point, I agree with your proposition to leave it out of the
release if it's not "stable" and perhaps Sebastian can jump in when he has
some time as he started the work on this, I think.

Regarding all the recent fixes and changes in develop I'm unsure if I am
able to follow anything.
Do you think it would be better to rebase the rel branch to current develop
as all that was happening in develop since then where build fixes?


Am 19.01.19, 11:19 schrieb "Christofer Dutz" <>:

Ok so that helped ... a little ... thing is I was expecting it to occur
when WRITING the features.xml file ... seems it occurs when reading it
inside a jar ...

Investigating even more, I noticed that the build of the Karaf modules
don't seem to produce any jar files, just sources.jar, which is quite
pointless for a project without a line of code.
As far as I understood it, these modules should take the driver modules and
re-package them with OSGI descriptors so they can be used in an OSGI
context. For that they would have to contain something ...

I would suggest to comment out the Karaf module in the release branch and
we concentrate on building something useful instead of just being happy the
build works ;-)

I've just checked out the Karaf project as a total and will now try to find
out how to fix the bundle generation (Another option would be to add the
descriptor generation to the drivers themselves (Would prefer that)
No need to re-package stuff as the additional metadata will not interfere
with the normal JAR functionality.


Am 19.01.19, 01:49 schrieb "Justin Mclean" <>:


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message