[jitsi-dev] [libjitsi] Maven resolve issue with jitsi-universe (#55)


#1

I assumed the Maven build was ready for prime-time, however I see this error when I attempt to build master.

[ERROR]   The project org.jitsi:libjitsi:1.0-SNAPSHOT (/home/mondain/workspace/github/libjitsi/pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM: Could not find artifact org.jitsi:jitsi-universe:pom:1.0-SNAPSHOT in maven2-repository.dev.java.net (http://download.java.net/maven/2) and 'parent.relativePath' points at wrong local POM @ line 7, column 11 -> [Help 2]
···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55


#2

The Maven support is under active development at this time.

The issue is known and I was going to write to the dev mailing list in search of suggestions. We're using a Maven repository of our own (jitsi-maven-repository hosted on GitHub) so it has to be explicitly made known to Maven. One approach is ~/.m2/settings.xml but that seemed complex to me at the time. But then it's good practice to have it in the POM as well and I've added it to jitsi-universe because pretty much every project of ours with Maven support extends it. Unfortunately, that's kind of a "catch 22" in a sense. For the time being, it's necessary to checkout jitsi-universe as well before building any of the projects such as libjitsi which extend it.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124200352


#3

While I understand wanting your own maven repo, I would like to share that most devs won't want to edit their settings.xml in general. As an alternative, I suggest using a "well known" repository instead such as central / sonatype. This guide is really easy to use and I had most of the Red5 projects up there in no time: http://central.sonatype.org/pages/ossrh-guide.html

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124221093


#4

Hey @mondain

We actually have no preference at all to create a repo of our own. Quite on the contrary: we'd rather not. From what I understand Maven Central does not allow project relations and Sonatype requires 100% javadoc (which would love for us to have but, in spite of our best efforts: we don't ... I really wish we did).

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124255095


#5

Ahm, I don't really know about the parent project stuff - I brought that up. Did someone actually do some research if parents are really disallowed? Even if it is so: have a look at https://github.com/opentelecoms-org/lumicall. Embedding jitsi-universe as a git module at a specific revision would solve that problem (and at the same time make a project bound to a specific version of jitsi-universe, which is a good thing). If we cannot use Sonatype in the end, the parent-pom can then still refer to an additional, private repository.

The Javadoc thing is different I think: every artifact needs to have a Javadoc-jar, but that doesn't meen every single method needs to have a full documentation.

Besides, the snapshot uploads to Sonatype don't even need to adhere to that. They're for trial-and-error. And we have org.jitsi at Sonatype. So that's available for experiments.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124261285


#6

We dont have 100% javadoc in all the Red5 projects, but we did fix all the maven javadoc errors. One of our projects "plugins" has a maven parent pom, so from that I have to say they are allowed or it would be rejected. Here's the listing http://mvnrepository.com/artifact/org.red5 and there "plugins" is a parent of "tomcatplugin". It's tricky at first like most things maven, but once its set up and working its really nice to work with.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124288341


#7

About the 100% Javadoc issue, it’s something that I’ve experienced while publishing otr4j on maven central and shared with the team effectively misleading them. Sorry for the FUD. From what you say, there’s probably a way to relax this requirement which would be tremendously useful.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124294963


#8

So, can anyone think of any reason not to go on sonatype? @lyubomir ?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124444114


#9

At least for snapshots, no. Doing actual releases is another story (all dependencies must be available in Central, GPG signatures, no -SNAPSHOT).

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124453227


#10

I cannot think of any reason not to go on sonatype. Today I'll be working on Maven assemblies (for the purposes of preparing distributables) for jitsi-videobridge and jicofo so the earliest I could possibly start looking into sonatype is next week.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124514579


#11

@lyubomir I don't know what you plan to use for the assembly, but I will say that the maven assembly plugin is really easy to use and if you wanted examples, I can point you to the ones I configured for our project.

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <descriptors>
            <descriptor>src/main/assembly/server.xml</descriptor>
        </descriptors>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <!-- this is used for inheritance merges -->
            <phase>package</phase>
            <!-- bind to the packaging phase -->
            <goals>
                <goal>single</goal>
             </goals>
        </execution>
    </executions>
</plugin>            
···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124521699


#12

FWIW:
- [OSSRH Guide](http://central.sonatype.org/pages/ossrh-guide.html) (skip the new project part, we already have that)
- [Central Component Requirements](http://central.sonatype.org/pages/requirements.html)

The requirements seem to have been loosened since I last read this. For Javadoc it even says that you can upload fake jars with a readme for non-java language projects.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-124584064


#13

Thank you very much, all!

Commit 5b9e2971086019adf1670874070ef1b4f51aeccb should fix this issue by making the jitsi-maven-repository known.

On the subject of sonatype and Maven Central, we are fine with jitsi-maven-repository at this time given that we have just added the support for Maven, we have snapshots only right now and no extensive testing to the newly-added support for Maven has been given by the Jitsi community developers. We will work on publishing our artifacts on sonatype and/or Maven Central later. If anyone feels like they need it now, we'll readily accept contributions.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-125324062


#14

Closed #55.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#event-470544115


#15

I'm going to close this since maven works fine with the jitsi repo entries in the poms.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/issues/55#issuecomment-158442318