[jitsi-dev] Maven, versions, and parent poms


#1

Dear developers,

Maven necessitates the use of versions for our projects, libraries,
dependencies, Maven plugins used to compile, package, deploy our
projects. I'd like to seek your opinions on how we should approach the
versioning.

1. Obviously, we could look at each of our projects separately and
specify versions in particular and configurations in general in its
pom.xml file. The problems that I see with this approach is that (1)
we have to repeat versions and configurations and (2) we will most
likely end up with different versions for one and the same dependency
across the various projects and configurations in different projects.

2. We define parent Maven projects which are merely pom.xml files with
versions and configurations common to all our projects. For example,
we could have a parent pom.xml that lists all the versions of all the
libraries that we have as dependencies across all our projects and
then we'd pretty much have to edit in just one place when we want to
upgrade all our projects to a new version of a specific library. We
could specify the versions of the Maven plugins in a single place.
Similarly, we could specify in the common parent pom.xml that we
default to the non-Maven directory layout and describe our common
directory layout.

What do you think? Do you have ideas about any other approaches?

Best regards,
Lyubo Marinov


#2

Hi Lyubo

Thank you for your work on this!

Maven necessitates the use of versions for our projects, libraries,
dependencies, Maven plugins used to compile, package, deploy our
projects. I'd like to seek your opinions on how we should approach the
versioning.

1. Obviously, we could look at each of our projects separately and
specify versions in particular and configurations in general in its
pom.xml file. The problems that I see with this approach is that (1)
we have to repeat versions and configurations and (2) we will most
likely end up with different versions for one and the same dependency
across the various projects and configurations in different projects.

2. We define parent Maven projects which are merely pom.xml files with
versions and configurations common to all our projects. For example,
we could have a parent pom.xml that lists all the versions of all the
libraries that we have as dependencies across all our projects and
then we'd pretty much have to edit in just one place when we want to
upgrade all our projects to a new version of a specific library. We
could specify the versions of the Maven plugins in a single place.
Similarly, we could specify in the common parent pom.xml that we
default to the non-Maven directory layout and describe our common
directory layout.

What do you think? Do you have ideas about any other approaches?

I'm generally in favor of (2), however:
a) I'm slightly concerned that Maven Central does not allow pom relationships. IIRC this would be a problem with the redistribution of a library when the dependencies are declared somewhere outside of the project's main metadata. I realize that Maven Central is not our main objective, but we should keep it in mind (and there are probably solutions out there as well, e.g. merging the parent poms before uploading to OSSRH).
b) An update of a dependency's version could necessitate code changes. Who's going to be responsible for those follow-up changes in other projects depending on the same library? Say I update smack in Jitsi to 4.x, who's adapting the Videobridge - I don't even have the Videobridge set up as a project. Obviously dependencies could be overridden, but that also needs to be done.
c) I'm strongly against specifying the override of the default directory layout in a shared definition. It would encourage to use the Ant-layout for new projects as well. But a newly started project should use the Maven layout (and other projects potentially migrated over time).
d) It would obviously be a great place to define artifact repositories such as the OSSRH, the plugin versions, build profiles, etc.

Sorry if this isn't a real answer, but hopefully some usable input.

Cheers,
Ingo


#3

Dear Ingo,

I'm generally in favor of (2), however:

Thank you very much for expressing your opinion!

a) I'm slightly concerned that Maven Central does not allow pom relationships. IIRC this would be a problem with the redistribution of a library when the dependencies are declared somewhere outside of the project's main metadata. I realize that Maven Central is not our main objective, but we should keep it in mind (and there are probably solutions out there as well, e.g. merging the parent poms before uploading to OSSRH).

Priceless!

I'll sleep on that and I may come back to you about it. Of course,
anyone else is welcome to share their opinion without waiting for me.

b) An update of a dependency's version could necessitate code changes. Who's going to be responsible for those follow-up changes in other projects depending on the same library? Say I update smack in Jitsi to 4.x, who's adapting the Videobridge - I don't even have the Videobridge set up as a project. Obviously dependencies could be overridden, but that also needs to be done.

I see what you mean.

But I believe we as a community would be interested in working with
one and the same version of a library across all our projects and then
describe exclusive cases (i.e. override) per project. If you happen to
upgrade Smack for Jitsi and that turns out to require source code
changes in Videobridge, then... well, we'll see the compile-time error
during the development phase and decide whether we prefer to change
the source code or override the version. I personally prefer that. Of
course, it would be great to hear what the other developers think.

c) I'm strongly against specifying the override of the default directory layout in a shared definition. It would encourage to use the Ant-layout for new projects as well. But a newly started project should use the Maven layout (and other projects potentially migrated over time).

I'm with you here.

Sorry if this isn't a real answer, but hopefully some usable input.

Thank you very much! I appreciate your help!

Best regards,
Lyubo Marinov

···

2015-07-06 14:40 GMT-05:00 Ingo Bauersachs <ingo@jitsi.org>:


#4

Hi all,

Hi Lyubo

Thank you for your work on this!

Maven necessitates the use of versions for our projects, libraries,
dependencies, Maven plugins used to compile, package, deploy our
projects. I'd like to seek your opinions on how we should approach the
versioning.

1. Obviously, we could look at each of our projects separately and
specify versions in particular and configurations in general in its
pom.xml file. The problems that I see with this approach is that (1)
we have to repeat versions and configurations and (2) we will most
likely end up with different versions for one and the same dependency
across the various projects and configurations in different projects.

I don't think we're going to be happy with this one, as we have quite a
number of plugins that we could separate out into child projects.

2. We define parent Maven projects which are merely pom.xml files with
versions and configurations common to all our projects. For example,
we could have a parent pom.xml that lists all the versions of all the
libraries that we have as dependencies across all our projects and
then we'd pretty much have to edit in just one place when we want to
upgrade all our projects to a new version of a specific library. We
could specify the versions of the Maven plugins in a single place.
Similarly, we could specify in the common parent pom.xml that we
default to the non-Maven directory layout and describe our common
directory layout.

What do you think? Do you have ideas about any other approaches?

I'm in favor of this one.

I think Maven 3 has all the mechanics for this. There is a tag
"dependencyManagement" IIRC that is there specifically to add (possible)
dependencies with default versions and scopes. One could override per
"child" plugin or leave out the tags in order to adopt the default.
See
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management

I'm generally in favor of (2), however:
a) I'm slightly concerned that Maven Central does not allow pom relationships. IIRC this would be a problem with the redistribution of a library when the dependencies are declared somewhere outside of the project's main metadata. I realize that Maven Central is not our main objective, but we should keep it in mind (and there are probably solutions out there as well, e.g. merging the parent poms before uploading to OSSRH).

I'm not aware of restrictions in Maven Central. For a, I'm not sure if
pom relationships are really an issue. I think we're quite far if we
simply define all dependencies of each project. Maven does the rest
w.r.t. downloading necessary dependencies. We should take care to not
set conflicting dependencies within the various maven projects ourselves
(unless absolutely necessary) but that's a given and is significantly
simplified with dependencyManagement section of the parent pom.

b) An update of a dependency's version could necessitate code changes. Who's going to be responsible for those follow-up changes in other projects depending on the same library? Say I update smack in Jitsi to 4.x, who's adapting the Videobridge - I don't even have the Videobridge set up as a project. Obviously dependencies could be overridden, but that also needs to be done.

If it builds then it's okay? We should still worry about major version
changes, I guess. Hmm... in that respect, should we treat Videobridge
and the other non-Jitsi-desktop-clients as separate maven projects?
Maybe something like:

jitsi-master-project
>
+ Jitsi desktop client
    + Jitsi UI
    + XMPP protocol
    + OTR plugin
    + libjitsi
+ Jitsi Videobridge
+ Jitsi Meet
+ ...

I may not have a complete picture here, but I think libjitsi is the
biggest common denominator between the projects(?) that also has quite a
number of dependencies, I'm guessing. (I haven't checked.)
That might be the one project where you can break other stuff if you
upgrade dependency-versions.

CI will help here, but when you're working on version upgrades, it's way
easier to be able to build everything.

c) I'm strongly against specifying the override of the default directory layout in a shared definition. It would encourage to use the Ant-layout for new projects as well. But a newly started project should use the Maven layout (and other projects potentially migrated over time).

If we are going to separate out all the plugins into their respective
maven (sub)projects, then we might as well do everything at once, do it
good and be done with it.

d) It would obviously be a great place to define artifact repositories such as the OSSRH, the plugin versions, build profiles, etc.

OSSRH?

Danny

···

On 06-07-15 21:40, Ingo Bauersachs wrote:

Sorry if this isn't a real answer, but hopefully some usable input.

Cheers,
Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

I'm generally in favor of (2), however:
a) I'm slightly concerned that Maven Central does not allow pom
relationships. IIRC this would be a problem with the redistribution of a
library when the dependencies are declared somewhere outside of the project's
main metadata. I realize that Maven Central is not our main objective, but we
should keep it in mind (and there are probably solutions out there as well,
e.g. merging the parent poms before uploading to OSSRH).

I'm not aware of restrictions in Maven Central. For a, I'm not sure if
pom relationships are really an issue.

I might be totally mistaken with this one and haven't actually looked it up or tried. I simply have some memory that it wasn't allowed.

I think we're quite far if we
simply define all dependencies of each project. Maven does the rest
w.r.t. downloading necessary dependencies. We should take care to not
set conflicting dependencies within the various maven projects ourselves
(unless absolutely necessary) but that's a given and is significantly
simplified with dependencyManagement section of the parent pom.

b) An update of a dependency's version could necessitate code changes.
Who's going to be responsible for those follow-up changes in other projects
depending on the same library? Say I update smack in Jitsi to 4.x, who's
adapting the Videobridge - I don't even have the Videobridge set up as a
project. Obviously dependencies could be overridden, but that also needs to
be done.

If it builds then it's okay? We should still worry about major version
changes, I guess.

Well, who knows? A lot of the projects don't have (enough) unit tests...

Hmm... in that respect, should we treat Videobridge
and the other non-Jitsi-desktop-clients as separate maven projects?

Ahm, yeah, I guess that's set? Doesn't make much sense otherwise.

Maybe something like:

jitsi-master-project

This would be the parent definition.

>
+ Jitsi desktop client

One desktop-jitsi with a whole lot of modules.

    + Jitsi UI
    + OTR plugin

    + XMPP protocol

The XMPP and SIP protocols should be promoted to standalone projects as they are used in multiple projects. Which in turn pulls all implemented service interfaces out as well...

    + libjitsi

Libjitsi is (already) a separate project.

+ Jitsi Videobridge
+ Jitsi Meet
+ ...
I may not have a complete picture here, but I think libjitsi is the
biggest common denominator between the projects(?) that also has quite a
number of dependencies, I'm guessing. (I haven't checked.)

Yes.

That might be the one project where you can break other stuff if you
upgrade dependency-versions.

I'm actually more concerned about e.g. breaking Jigasi or Jicofo by updating jain-sip or smack respectively.

CI will help here, but when you're working on version upgrades, it's way
easier to be able to build everything.

Well, it'll be easier for all of us to at least set up the projects and build them. But unless we get unit tests for all the projects (which is simply not possible at this point) this will always be a trial and error.

c) I'm strongly against specifying the override of the default directory
layout in a shared definition. It would encourage to use the Ant-layout for
new projects as well. But a newly started project should use the Maven layout
(and other projects potentially migrated over time).

If we are going to separate out all the plugins into their respective
maven (sub)projects, then we might as well do everything at once, do it
good and be done with it.

That's a big "if" here... Are we actually going to migrate the desktop-jitsi more or less NOW? I might not have the whole picture either, but I thought we're starting with the smaller projects and see how it goes. Then, once all the other projects are ready and when we're all a little more experienced with Maven, we'd split up desktop-jitsi into separate projects and modules.

d) It would obviously be a great place to define artifact repositories such
as the OSSRH, the plugin versions, build profiles, etc.

OSSRH?

Open Source Software Repository Hosting

https://oss.sonatype.org
http://central.sonatype.org/pages/ossrh-guide.html

Danny

Ingo

Ingo


#6

I'm generally in favor of (2), however:
a) I'm slightly concerned that Maven Central does not allow pom
relationships. IIRC this would be a problem with the redistribution of a
library when the dependencies are declared somewhere outside of the project's
main metadata. I realize that Maven Central is not our main objective, but we
should keep it in mind (and there are probably solutions out there as well,
e.g. merging the parent poms before uploading to OSSRH).

I'm not aware of restrictions in Maven Central. For a, I'm not sure if
pom relationships are really an issue.

I might be totally mistaken with this one and haven't actually looked it up or tried. I simply have some memory that it wasn't allowed.

Okay, sure. I suspect you might be referring to a specific situation.
But then again, I'm not that familiar Maven repositories. I do know how
to set up a basic maven project though with some extra plugins etc. So I
can help there.

I think we're quite far if we
simply define all dependencies of each project. Maven does the rest
w.r.t. downloading necessary dependencies. We should take care to not
set conflicting dependencies within the various maven projects ourselves
(unless absolutely necessary) but that's a given and is significantly
simplified with dependencyManagement section of the parent pom.

b) An update of a dependency's version could necessitate code changes.
Who's going to be responsible for those follow-up changes in other projects
depending on the same library? Say I update smack in Jitsi to 4.x, who's
adapting the Videobridge - I don't even have the Videobridge set up as a
project. Obviously dependencies could be overridden, but that also needs to
be done.

If it builds then it's okay? We should still worry about major version
changes, I guess.

Well, who knows? A lot of the projects don't have (enough) unit tests...

Sure, unit tests help improve reliability and confidence. The first test
is seeing that it builds. Everything after that is extra. I know it's
not a lot to start with, but it's better than nothing.

Hmm... in that respect, should we treat Videobridge
and the other non-Jitsi-desktop-clients as separate maven projects?

Ahm, yeah, I guess that's set? Doesn't make much sense otherwise.

Uhmm..., well that's my bad for trying to respond when I was actually
already kind of tired. Makes for bad replies. What I meant to say was to
have multiple layers:
- first: all former-bluejimp software
- second: specific components of a single project, i.e. the plugins +
core parts etc. I'm not a fan of making too many layers/levels. So maybe
only a single level for all of these. (I kind of tried to sketch that
below too. That was probably a bit clearer.)

Maybe something like:

jitsi-master-project

This would be the parent definition.

Indeed. This would contain the dependency management entries with the
preferred version. Overriding is still possible in poms for projects. We
may not even want to define a unit testing library here, since we may
use several if we want to migrate from junit3 to junit4 and I don't even
know about other projects. But we could define some "default dependencies".

Also, this parent definition would not actually provide any
buildable/deliverable component. Just the definition as overall parent.

>
+ Jitsi desktop client

One desktop-jitsi with a whole lot of modules.

Yes, so desktop-jitsi which would *probably* (haven't thought this true
very much) not be a component in itself. Just a(nother) parent
containing all the jitsi components.

    + Jitsi UI
    + OTR plugin

Basically all jitsi core components and plugins.

    + XMPP protocol

The XMPP and SIP protocols should be promoted to standalone projects as they are used in multiple projects. Which in turn pulls all implemented service interfaces out as well...

I was talking about the Jitsi protocol plugins, not the actually
protocol library implementation (say Smack, irc-api, etc.) The actual
library is an external dependency. Maybe a fork (if we have local
modifications) or even a reference to an existing external library
already available in maven.

    + libjitsi

Libjitsi is (already) a separate project.

True, my bad. This one would only be listed as dependency reference in
jitsi. Probably in just a few child components, not even the parent pom,
as many components don't directly rely on libjitsi IIRC.

+ Jitsi Videobridge
+ Jitsi Meet
+ ...
I may not have a complete picture here, but I think libjitsi is the
biggest common denominator between the projects(?) that also has quite a
number of dependencies, I'm guessing. (I haven't checked.)

Yes.

That might be the one project where you can break other stuff if you
upgrade dependency-versions.

I'm actually more concerned about e.g. breaking Jigasi or Jicofo by updating jain-sip or smack respectively.

We can still refer explicitly to a version. So we can avoid breaking
others if we update smack for Jitsi. I would stick to a single line of
history though. Still I understand that if you don't detect breaking
something, it is quite possible that we do not detect it. Maybe we
should upgrade each project individually, until all are on a newer
version and then upgrade the parent pom? This is more related to the
process then technical difficulties though.

CI will help here, but when you're working on version upgrades, it's way
easier to be able to build everything.

Well, it'll be easier for all of us to at least set up the projects and build them. But unless we get unit tests for all the projects (which is simply not possible at this point) this will always be a trial and error.

True, there's room for improvement :stuck_out_tongue:

c) I'm strongly against specifying the override of the default directory
layout in a shared definition. It would encourage to use the Ant-layout for
new projects as well. But a newly started project should use the Maven layout
(and other projects potentially migrated over time).

If we are going to separate out all the plugins into their respective
maven (sub)projects, then we might as well do everything at once, do it
good and be done with it.

That's a big "if" here... Are we actually going to migrate the desktop-jitsi more or less NOW? I might not have the whole picture either, but I thought we're starting with the smaller projects and see how it goes. Then, once all the other projects are ready and when we're all a little more experienced with Maven, we'd split up desktop-jitsi into separate projects and modules.

Well, I would prefer doing Jitsi as a whole at once. It's not a good
idea to start with Jitsi though. There are quite a number of modules. I
did not mean to express a moment in time, just to say that it's probably
more of a hassle to have 2 or 3 intermediate steps before arriving at:
1. fully migrate to using maven (I know there exists an ant-plugin for
maven, but I haven't used it)
2. adopting the full maven project layout
3. and creating separate subprojects for core components and plugins.

d) It would obviously be a great place to define artifact repositories such
as the OSSRH, the plugin versions, build profiles, etc.

OSSRH?

Open Source Software Repository Hosting

https://oss.sonatype.org
http://central.sonatype.org/pages/ossrh-guide.html

O sure, I didn't know they had a fancy abbreviation for that, though :stuck_out_tongue:

Again quite late, I hope this response still clears it up a bit.
Danny

···

On 07-07-15 00:03, Ingo Bauersachs wrote:

Danny

Ingo

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev