Conversation
edalex-ian
left a comment
edalex-ian
left a comment
There was a problem hiding this comment.
A few questions mainly. Additionally:
- What is all the new
update/stuff? - There's a few JARs added in the
updatefolder which look like outputs - do we need to keep them in the repo?
Will also still need to run up locally to test the instructions.
| <description url="http://www.example.com/description"> | ||
| [Enter Feature Description here.] | ||
| </description> | ||
|
|
||
| <copyright url="http://www.example.com/copyright"> | ||
| [Enter Copyright Description here.] | ||
| </copyright> | ||
|
|
||
| <license url="http://www.example.com/license"> | ||
| [Enter License Description here.] | ||
| </license> |
There was a problem hiding this comment.
We should fill all these in.
The update is an update website, so that users could go into their BIRT install and add an update server and point it to this GitHub repository. I couldn't get it working anyway, so I will remove it. |
|
Note that this PR contains a number .jar binaries, however they are merely placeholders for Javadoc (since none is being generated) or non-existent source for the BIRT framework. |
| *.asc | ||
| birt.zip No newline at end of file |
There was a problem hiding this comment.
Should bin.jar also be included in this list?
There was a problem hiding this comment.
The bin.jar in the birt-framework directory is in the repo as a placeholder, since upload to OSSRH required a binary jar file as the main jar. It wouldn't accept just a classifier=zip artefact on it's own :(
There was a problem hiding this comment.
😕 Maven and Gradle upload artifacts to OSSRH independent of source control (artifacts usually aren't checked in).
Does Eclipse' upload process work different?
There was a problem hiding this comment.
If you create a normal Gradle project in Eclipse then it would create normal jars etc, and you can get your dependencies via Maven etc...
The problem is that these jars are actually OSGI plugins, and the dependencies are fetched via "P2" (you can't hope the retrieve them from Maven), therefore I had serious trouble in getting a Gradle script to build the Eclipse plugins and automatically push them to Maven. (Hence the manual process). It might be possible, using a number of Gradle plugins that I tried and failed with, but I had already spent way too long trying to get those to work. (See the aborted feature/build-process branch)
3 participants
Updated plugin projects and instructions on how to build.
I have applied to OSSRH (Maven central) to register com.github.openequella as a group ID, so might be worth renaming our Eclipse plugins to match as well.
I applied to OSSRH so that we can store the produced plugins into Maven Central so that the openEQUELLA server can download these during the build process and use them for it's own report generation. Currently the server is using the old plugins, which isn't causing problems at the moment, but could do in future.