Eclipse Git Push, refs/heads/master & refs/remotes/origin/master ?

Push Ref Specifications





Reference URL:
Is “refs/heads/master” same as “refs/remotes/origin/master” in Git?
https://stackoverflow.com/questions/7541040/is-refs-heads-master-same-as-refs-remotes-origin-master-in-git

They are two different symbolic names that can point to different things. refs/heads/master is a branch in your working copy named master. Frequently that is a tracking branch of refs/remotes/origin/master because origin is the default name for the remote created by git clone and its primary branch is usually also named master.

You can see the difference between them with git rev-list refs/heads/master..refs/remotes/origin/master which will be empty if they are the same and will otherwise list the commits between them.

Found this configuration in eclipse:

Not sure what the different of:
refs/heads/master - refs/remotes/origin/master
vs
+refs/heads/*:refs/remotes/origin/*

is * = wildcard?




https://stackoverflow.com/a/7546794/676104

The key difference to understand is that the branches under refs/heads/ are branches that, when you have one checked out, you can advance by creating new commits. Those under refs/remotes/, however, are so-called "remote-tracking branches" - these refs just point to the commit that a remote repository was at the last time you did a git fetch <name-of-remote>, or a successful git push to the corresponding branch in that remote repository. (I wrote a blog post that talks about this difference at some length here.)

https://longair.net/blog/2009/04/16/git-fetch-and-merge/

GIT: FETCH AND MERGE, DON’T PULL

2009-04-16 MARK 129 COMMENTS

datasource c3p0 vs org.apache.commons.dbcp.BasicDataSource

https://stackoverflow.com/questions/520585/connection-pooling-options-with-jdbc-dbcp-vs-c3p0

DBCP is out of date and not production grade. Some time back we conducted an in-house analysis of the two, creating a test fixture which generated load and concurrency against the two to assess their suitability under real life conditions.

DBCP consistently generated exceptions into our test application and struggled to reach levels of performance which C3P0 was more than capable of handling without any exceptions.

C3P0 also robustly handled DB disconnects and transparent reconnects on resume whereas DBCP never recovered connections if the link was taken out from beneath it. Worse still DBCP was returning Connection objects to the application for which the underlying transport had broken.

Since then we have used C3P0 in 4 major heavy-load consumer web apps and have never looked back.

UPDATE: It turns out that after many years of sitting on a shelf, the Apache Commons folk have taken DBCP out of dormancy and it is now, once again, an actively developed project. Thus my original post may be out of date.

That being said, I haven't yet experienced this new upgraded library's performance, nor heard of it being de-facto in any recent app framework, yet.

Hibernate ORM 5.3.11.Final = current stable release

As of 2019-Sep-03_pm021556
Hibernate ORM 5.3.11.Final  = current stable release


Hibernate ORM 5.3.11.Final User Guide.html

https://docs.jboss.org/hibernate/stable/core/userguide/html_single/Hibernate_User_Guide.html#_system_requirements

System Requirements

Hibernate 5.2 and later versions require at least Java 1.8 and JDBC 4.2.

Hibernate 5.1 and older versions require at least Java 1.6 and JDBC 4.0.

Relevant:
https://spring.io/blog/2018/09/21/spring-framework-5-1-goes-ga

Spring Framework 5.1 requires JDK 8 or higher and specifically supports JDK 11 as the next long-term support release. It comes with initial refinements for GraalVM compatibility and deeply integrates with the recently released Reactor Californium and Hibernate ORM 5.3.

JSTL compilation error

Can not find the tag library descriptor for "http://www.springframework.org/tags"

Cannot confirm was is been solved by pom.xml as I cannot reproduce anymore.

remove the scope and do Maven Update Project.




<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
<scope>runtime</scope>
</dependency>

<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
<scope>runtime</scope>
</dependency>

to



<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>

<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
</dependency>

Google pinyin input windows 10 download

Resource URL:
https://forum.lowyat.net/topic/4620075/all


Found this link still reachable on: 2019-Sep-02_pm010812
http://dl.google.com/pinyin/v2/GooglePinyinInstaller.exe

No PersistenceProvider - Caused by: java.lang.IllegalArgumentException: No PersistenceProvider specified in EntityManagerFactory configuration, and chosen PersistenceUnitInfo does not specify a provider class name either

Change the emf bean configuration and add a new bean called jpaVendorAdapter:

<bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" id="emf">
  <property name="packagesToScan" value="com.medsoft.stadto.entity" />
  <property name="dataSource" ref="dataSource" />
  <property name="jpaVendorAdapter" ref="jpaVendorAdapter"/>
  <property name="persistenceUnitName" value="stadto"/>
  <property name="jpaProperties">
    <props>
      <prop key="hibernate.show_sql">true</prop>
      <prop key="hibernate.hbm2ddl.auto">create</prop>
    </props>
  </property>
</bean>

<bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
  <property name="showSql" value="true"/>
  <property name="generateDdl" value="true"/>
  <property name="databasePlatform" value="org.hibernate.dialect.PostgreSQLDialect"/>
</bean>

Also make sure you have a persistence.xml in the META-INF directory:

<?xml version="1.0"?>
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
  http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
  version="2.1">
  <persistence-unit name="stadto">
    //No need to specify the provider as we already have specified JPA vendor in applicationContext.xml
  </persistence-unit>
</persistence>

To remove persistence.xml, refer to: https://billson.blogspot.com/2019/08/caused-by-javalangillegalstateexception.html

Caused by: java.lang.IllegalStateException: No persistence units parsed from {classpath*:META-INF/persistence.xml}

Reference URL: https://www.baeldung.com/the-persistence-layer-with-spring-and-jpa

5. Going Full XML-less

Usually, JPA defines a persistence unit through the META-INF/persistence.xml file. Starting with Spring 3.1, the persistence.xml is no longer necessary. The LocalContainerEntityManagerFactoryBean now supports a ‘packagesToScan' property where the packages to scan for @Entity classes can be specified.

This file was the last piece of XML we need to remove. We can now set up JPA fully with no XML.

We would usually specify JPA properties in the persistence.xml file. Alternatively, we can add the properties directly to the entity manager factory bean:

factoryBean.setJpaProperties(this.additionalProperties());

As a side-note, if Hibernate would be the persistence provider, then this would be the way to specify Hibernate specific properties.

add this into your servlet context.xml

<property name="packagesToScan" value="com.howtodoinjava.entity" />

Migrate Spring Security From 3 to 4, deprecated: org.springframework.security.core.authority.GrantedAuthorityImpl

Found URL: https://docs.spring.io/spring-security/site/migrate/current/3-to-4/html5/migrate-3-to-4-xml.html#m3to4-deprecations-core-gai

4.5.10. GrantedAuthorityImpl

GrantedAuthorityImpl was removed in favor of SimpleGrantedAuthority or implementing your own. For example:

new GrantedAuthorityImpl(role);

should be replaced with

new SimpleGrantedAuthority(role);

maven deploy with eclipse

Add below to your settings.xml for global or user_settings.xml for personalized user id for access control.

<server>
<id>snapshots</id>
<username>user_one</username>
<password>password1</password>
</server>
<server>
<id>releases</id>
<username>user_two</username>
<password>password2</password>
</server>

Add below to your project/pom.xml

<distributionManagement>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots Repository</name>
<url>http://company-private-repo.com/apache-archiva-2.2.4/repository/snapshots</url>
</snapshotRepository>
<repository>
<id>releases</id>
<name>Releases Repository</name>
<url>http://company-private-repo.com/apache-archiva-2.2.4/repository/releases/</url>
</repository>
</distributionManagement>

Eclipse Run As: Maven build, goal as deploy.


Reference: 
https://maven.apache.org/repository-management.html

Alternative:

https://stackoverflow.com/a/2230464

Info below from stackoverflow:

I want the jar to be in a 3rdparty lib in source control, and link to it by relative path from the pom.xml file.

If you really want this (understand, if you can't use a corporate repository), then my advice would be to use a "file repository" local to the project and to not use a system scoped dependency. The system scoped should be avoided, such dependencies don't work well in many situation (e.g. in assembly), they cause more troubles than benefits.

So, instead, declare a repository local to the project:

<repositories>
  <repository>
    <id>my-local-repo</id>
    <url>file://${project.basedir}/my-repo</url>
  </repository>
</repositories>

Install your third party lib in there using install:install-file with the localRepositoryPath parameter:

Update: It appears that install:install-file ignores the localRepositoryPath when using the version 2.2 of the plugin. However, it works with version 2.3 and later of the plugin. So use the fully qualified name of the plugin to specify the version:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
                         -Dfile=<path-to-file> -DgroupId=<myGroup> \ 
                         -DartifactId=<myArtifactId> -Dversion=<myVersion> \
                         -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>

maven-install-plugin documentation

Finally, declare it like any other dependency (but without the system scope):

<dependency>
  <groupId>your.group.id</groupId>
  <artifactId>3rdparty</artifactId>
  <version>X.Y.Z</version>
</dependency>

This is IMHO a better solution than using a system scope as your dependency will be treated like a good citizen (e.g. it will be included in an assembly and so on).

Now, I have to mention that the "right way" to deal with this situation in a corporate environment (maybe not the case here) would be to use a corporate repository.