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

ECR-1526 Prepare for maven release #298

Merged
merged 5 commits into from
Jun 15, 2018
Merged

ECR-1526 Prepare for maven release #298

merged 5 commits into from
Jun 15, 2018

Conversation

MakarovS
Copy link
Contributor

@MakarovS MakarovS commented Jun 14, 2018

Overview

Prepare for maven release.


See: https://jira.bf.local/browse/ECR-1526

Definition of Done

@MakarovS MakarovS requested a review from dmitry-timofeev June 14, 2018 22:00
@@ -7,7 +7,7 @@
<parent>
<artifactId>exonum-java-binding-parent</artifactId>
<groupId>com.exonum.binding</groupId>
<version>1.0-SNAPSHOT</version>
<version>0.1.0</version>
Copy link
Contributor

Choose a reason for hiding this comment

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

I just wondering shouldn't we keep sync with core version?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think not at this point.

Copy link
Contributor

@dmitry-timofeev dmitry-timofeev left a comment

Choose a reason for hiding this comment

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

I am not sure I understand how it works — what is the command line to deploy the signed modules, with the Javadocs and sources?

<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
Copy link
Contributor

Choose a reason for hiding this comment

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

Does such configuration excludes the module correctly (I remember you asked about this)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should. Tbh I'm not sure how to check it before our first deploy

pom.xml Outdated
</licenses>

<organization>
<name>Exonum.com</name>
Copy link
Contributor

Choose a reason for hiding this comment

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

Just Exonum?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What else? Bitfury?

Copy link
Contributor

Choose a reason for hiding this comment

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

No, I meant Exonum without the domain name for our website.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, sure. I didn't know we have 'Exonum' organization.

pom.xml Outdated
<goals>
<goal>deploy</goal>
</goals>
</execution>
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it deploy to sonatype staging with no additional configuration?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should be enough for basic deploy

@MakarovS
Copy link
Contributor Author

I am not sure I understand how it works — what is the command line to deploy the signed modules, with the Javadocs and sources?

mvn clean deploy should do the job.

@dmitry-timofeev
Copy link
Contributor

  1. Does it work with no enabled 'deploy' plugin in each module to be deployed (pluginManagement does not enable the plugin)? Or is it enabled by default?
  2. Does it correctly handle javadocs and sources being generated at 'deploy' phase?
  3. Can we test it?

@MakarovS
Copy link
Contributor Author

Does it work with no enabled 'deploy' plugin in each module to be deployed (pluginManagement does not enable the plugin)? Or is it enabled by default?

Thanks, I moved these plugins to <plugins>

Does it correctly handle javadocs and sources being generated at 'deploy' phase?

I tested those at other phases - works well. Hopefully that won't change during deploy phase.

Can we test it?

Well, we would be able to see what we are about to publish to Central after we deploy to our staging repo. I'm afraid there are not many more possibilities to test it.

Copy link
Contributor

@dmitry-timofeev dmitry-timofeev left a comment

Choose a reason for hiding this comment

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

Looks good, will see how it goes.

@dmitry-timofeev dmitry-timofeev merged commit 7727875 into master Jun 15, 2018
@dmitry-timofeev dmitry-timofeev deleted the ECR-1526 branch June 15, 2018 16:11
vitvakatu pushed a commit that referenced this pull request Jun 19, 2018
* Add third party licenses for direct Rust dependencies [ECR-1502]. (#277)

* Update the project dependencies [ECR-1521, ECR-1518]:

- Add versions plugin
- Update the plugins that we use, specify the versions
  in the pluginManagement.
- Update the versions of dependencies.
- Disable Powermock tests until the library is updated.
- Verify the project builds on 10, run tests with openjdk-10 on the CI server.
- Check for updates on the CI server.

* Use the default Java compiler instead of error-prone:

Error-prone does not support Java 10 yet. A setup to activate
it conditionally would be too verbose (a profile activation
in each sub-module, because it does not work for
<build><pluginManagement>...).

See google/error-prone#860

* Do not install RocksDb — prevents SIGILL on older systems.

On some systems with older CPUs our build produces an executable
with an illegal instruction for those processors.

The problem needs further investigation, but if we do not use
the system version of RocksDb, it goes away. As I remember
(have no stack at the moment), the illegal instruction appears
somewhere in RocksDb initialization.

See: ECR-1558

* Upgrade to Exonum 0.8 [ECR-1620]

* Improve the documentation of a test. (#284)

* Change Java serialization to protobuf and use owner’s public key as wallet id [ECR-1493, ECR-1494]

  - Change Java Serialization of transactions and wallets to protobuf.
  - Wallet String name is changed to the  wallet owner’s public key.
  - Fix a bug in send money transaction when a transaction with the sender 
  equal to the receiver resulted in doubling the balance of that wallet.

PR: #272

* Messages payload length fix [ECR-1624]:

'payload length' field in the message header used to be equal to 
'body' length in bytes, while it should be equal to the size 
of the whole message (header + body + signature).

Also, improve the tests and exception messages.

PR: #285

* Fix the service API path: (#288)

The service API path must start with a slash 
to be correctly mounted.

* Fix the transaction location URL [ECR-1648] (#293).

The base path of explorer was changed in Exonum 0.7 
from ""/api/system/v1" to "/api/explorer/v1/".

* Add Javadoc plugin [ECR-1510] (#290):

Javadoc generation does not happen during normal builds 
and must be triggered manually. JARs with the Javadoc 
for all modules can be generated with 

$ mvn javadoc:jar

* Fix build on Travis CI [ECR-1658] (#292):

* Build the dependencies instead of using installed in the system
 to prevent illegal instructions appearing in our artefacts (the actual cause
 is still unknown).
* Disable caching of rust/target for it takes at least 2.5G, 
which is too much for Travis to archive and upload.

* Add an Exonum App [ECR-869, ECR-867] (#238):

Implemented JavaServiceRuntime abstraction around JVM 
to configure and run Java services. 

JavaServiceRuntime is a ServiceFactory, allowing to configure
Java services in the same way as any other Exonum service.

Also includes EJB App - a Rust application to configure and run
an Exonum node with a specific Java service.

* Add LICENSE and license headers in every source file [ECR-1499] (#295):

Also added a script generating a text file with third-party licenses 
of Rust dependencies:

./generate_licenses.sh

* Prepare the build configuration for a release [ECR-1526] (#298):

Add required plugins to prepare artefacts for a publication 
to the repository.

* Update native-proxies branch to Exonum 0.8.1 [ECR-1157] (#299).

* Fix NodeProxy so that it can create a View

* Remove 'provided' scope of the system dependencies of a service: (#301)

Until we ship an app that includes these dependencies,
they must be available on the classpath of the service (the only
configuration option that we will have at 0.1 release).

* Remove unused imports.

* Use the Java home that Maven reports in the scripts setting LD_LIBRARY_PATH

* Fix the Exception class that we use in tests:

The mocked methods can not throw checked exceptions.

* Skip all tests until the bug with loading shared libraries is fixed.

* Add a tutorial describing how to launch a node with a Java service (#300)

* Fix the application name and the script to start the crypto demo.

* Update the project documents [ECR-486, ECR-1515, ECR-1516] (#296):

Add a contribution guide, clean up the readme, add a roadmap.

* Fix the formatting.

* Fix anchors in the contribution guide.

* Change travis-ci.com to travis-ci.org (#305)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants