search

freme-project / e-Internationalization

Apache License 2.0
0 stars 0 forks source link

Re-arrange codes according to FREME standards #1

Closed jnehring closed 9 years ago

jnehring commented 9 years ago

@borriellom can you please update the pom.xml file? Right now all libraries are loaded from a local repository but they should be referenced via an external repository, e.g. Maven central repository. Or is there a particular reason why you chose this setup?

I opened a new branch "code-cleanup", please do your work in this branch.

borriellom commented 9 years ago

Libraries are stored in a local repository because okapi jars are not available on the Maven Central Repository. I'll ask Yves if they are stored in some public repository. Regarding the jericho-html jar I couldn't find the 3.4 version used in Okapi. Any suggestion is very welcome.

jnehring commented 9 years ago

Did you try this repository?: http://repository-okapi.forge.cloudbees.com/release/ I found it here: https://bitbucket.org/okapiframework/okapi

The Jericho HTML parser homepage seems to be down so I could not check. Seems the latest version on maven central is 3.3. Maybe including the Okapi dependency resolves the jericho dependency issue?

fsasaki commented 9 years ago

https://bitbucket.org/okapiframework/okapi is the current one - at least it was the correct one a few weeks ago (Yves pointed me to that).

ysavourel commented 9 years ago

One of the companies working on Okapi actually paid for additional work on Jericho, and that's the version we use: 3.4-dev. And we pull it from:

<repository>
   <id>swt-repo</id>
   <url>https://raw.githubusercontent.com/maven-eclipse/swt-repo/master/</url>
</repository>

FYI: the latest Okapi release is m27 back from January (master branch)

A lot of work is being done for m28 in the dev branch, soon to be released (although I don't think much of it would affect directly the NIF step).

borriellom commented 9 years ago

Many thanks to all of you for your suggestions.

Okapi dependencies are available here http://repository-okapi.forge.cloudbees.com/release/, as suggested by Jan.

Unfortunately the link https://raw.githubusercontent.com/maven-eclipse/swt-repo/master/ for jericho library doesn't work and including the okapi dependencies doesn't solve the issue. Maybe that repository can be accessed only after an authentication step.

Committed changes for external Okapi repository in the "code-cleanup" branch.

ysavourel commented 9 years ago

For the Jericho dependency the JAR is here: https://bitbucket.org/okapiframework/maven-repo/src/master/net/htmlparser/jericho/jericho-html/3.4-dev/

And the following repository declaration should work (it's the one we use in the Okapi build):

<repository>
  <id>okapi</id>
  <name>okapi-repository</name>
  <url>https://bitbucket.org/okapiframework/maven-repo/raw/master/</url>
</repository>
borriellom commented 9 years ago

Thank you Yves, that works. pom.xml changed and committed.

jnehring commented 9 years ago

I updated pom.xml and package names of e-Internationalization. I created some classes:

So please add your codes to EInternationalizationAPI. You might also want to add a headers to each source code file to mention yourself and vistatec.

borriellom commented 9 years ago

@jnehring I thought that MIME type info wasn't necessary but I was wrong. Indeed I've just found out that the MIME type is retrieved by the file extension, and we don't know the name of the file when dealing with InputStream objects. So the EInternationalizationAPI should accept an InputStream and a MIME type String. Let me know if I can change the method signature or if you prefer to do it yourself. Just to let you know, the MIME type for XLIFF files is "application/x-xliff+xml"

fsasaki commented 9 years ago

Hi Marta, sorry to be picky, I think the mine type is application/xliff+xml not critical here. Am 28.07.2015 17:11 schrieb "borriellom" notifications@github.com:

@jnehring https://github.com/jnehring I thought that MIME type info wasn't necessary but I was wrong. Indeed I've just found out that the MIME type is retrieved by the file extension, and we don't know the name of the file when dealing with InputStream objects. So the EInternationalizationAPI should accept an InputStream and a MIME type String. Let me know if I can change the method signature or if you prefer to do it yourself. Just to let you know, the MIME type for XLIFF files is "application/x-xliff+xml"

— Reply to this email directly or view it on GitHub https://github.com/freme-project/e-Internationalization/issues/1#issuecomment-125643772 .

jnehring commented 9 years ago

Wikipedia says the mime type is application/xliff+xml for XLIFF 2.0 and later and application/x-xliff+xml before 2.0. Btw which XLIFF version can we process with e-Internationalization?

You can change the signature. Maybe you can also add the supported mime types as "public static final String" or as an enum to the API class? Just to make it more clear which values to submit here.

fsasaki commented 9 years ago

@ysavourel and @borriellom may correct me, but I think we can process any input document which is supported by Okapi. Currently this is XLIFF 1.2. So application/x-xliff+xml should be the right mime type for now.

borriellom commented 9 years ago

Yes, I think we can deal only with XLIFF 1.2 at the moment. I'll add public static constants to the class as suggested by Jan.