Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/eclipse build #6

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Feature/eclipse build #6

wants to merge 14 commits into from

Conversation

abidingotter
Copy link

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.

Copy link
Member

@edalex-ian edalex-ian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few questions mainly. Additionally:

  • What is all the new update/ stuff?
  • There's a few JARs added in the update folder 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.

Comment on lines +8 to +18
<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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should fill all these in.

@abidingotter
Copy link
Author

A few questions mainly. Additionally:

What is all the new update/ stuff?
There's a few JARs added in the update folder 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.

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.

@abidingotter
Copy link
Author

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.

Comment on lines +1 to +2
*.asc
birt.zip
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should bin.jar also be included in this list?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😕 Maven and Gradle upload artifacts to OSSRH independent of source control (artifacts usually aren't checked in).
Does Eclipse' upload process work different?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants