|
wojciech.kapcia@tigase.net opened 1 decade ago
|
|
Linux developer said:
|
|
|
note: mimic older packages, e.g.: https://projects.tigase.org/attachments/download/139/tigase-issue #5.1.0-beta3-b2775.src.tar.gz https://projects.tigase.org/attachments/download/18/tigase-utils-3.2.0-b623.src.tar.gz https://projects.tigase.org/attachments/download/19/tigase-xmltools-3.3.1-b484.src.tar.gz |
|
I wonder if we could make it a single package with src from the server, xmltools and utills. Generally the thing with xmltools and utils is that they can be potentially used by other projects. Especially the XML parser. Maybe it is even already used by JaXMPP. This is why they were separated from the Tigase repository. However, from the Tigase server point of view these are essential part of the source code, therefore all the Tigase server scripts could/should treat them as the part of the main repo. I wonder if there is something like SVN external which could be used in Git so we could make these 2 projects a part of the Tigase server repo for the binary and src packages generation. I think this would simply things a lot. |
|
|
We are already inlining classes from utils and xmltools in binary tigase-server build so I think it shouldn't be a problem to do the same for the sources (and maybe javadoc as well). While it's possible to have submodules in git (and git tree as well) I would be reluctant to use it - it's a bit different than svn external. No to mention that if we want to have utils and xmltools available to other projects as maven artifacts they would still need to be semi-separated from server itself thus we would actually be in the same situation that we are right now. A possible solution (to have those two packages within one repository, but available as separate artifacts) would be merging the repositories and turning them as maven submodules of the server, but we still would need the whole inlining of the sources/classes. A benefit of that approach would be simpler versioning and dependency management of xmltools-utils-server. |
|
|
I do not have much knowledge about Git so I leave it to you to decide on what would be the best way. Inlining them for source packages the same way as we do for binaries is OK and seems like a relatively quick thing to do. Merging repos and submodule them seems more complex and time consuming so we could go for a quick fix now and do the other thing later if you feel like it makes more sense. |
|
|
To match #1657: Generate RPM and DEB packages |
|
|
What is a progress on this? If nothing has been done, please move it to next version. |
|
|
Please investigate possible solutions. |
|
|
Eric, what is progress of this? |
|
I did not get to this yet. I was working on related issue https://projects.tigase.org/issues/1657 , and monitoring project. |
|
|
I was making progress working on a yum package. I was using yum because there is a tool which converts them to debian packages. Something more important came up and I never got back to this. |
| Type |
Task
|
| Priority |
Normal
|
| Assignee | |
| RedmineID |
1675
|
| Version |
Candidate for next major release
|
| Spent time |
480h
|
We need, in addition to regular binary packages, generate distribution packages with sources and deploy it to public repository.
A possible solution (preferable) would be to take advantage of maven to generate such package, deploy it to maven repository (artifact-sources.jar, please look at http://maven.tigase.org/tigase/tigase-server/5.2.0-beta2/) and put a regular archive (artifact.src.tar.gz) next to the nightly build.
While we are at it we could also generate javadocs in a similar manner (deploy to maven repo) on a nightly basis.
(note: look into ant src-dist task)
Bartosz: could you provide more details about how the package should look like, what should contain and what would be preferable location to put it? After gathering the information please put summary here and reassign task to me.