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 
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
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
