search

oasp / oasp4j

The Open Application Standard Platform for Java
Apache License 2.0
60 stars 303 forks source link

Archetype 3.0.0 removed DB resources configuration #686

Open maybeec opened 5 years ago

maybeec commented 5 years ago

Given a project wanting to implement e.g. against an oracle DB, someone would choose oracle as the database type during archetype generation.

Now having the demand of letting developers to develop with h2 as long as possible, while providing the ability to switch to an oracle instance as well you would like to have the database-configuration for both. In oasp4j 2.4.x you got multiple confgurations generated, which https://github.com/oasp/oasp4j/wiki/guide-configuration#database-configuration or https://github.com/oasp-forge/oasp4j-wiki/wiki/guide-configuration#database-configuration is referring to. Anyhow, this is not valid anymore, so the documentation should be adapted showing how to achieve multiple datasources (replaceable or even in parallel).

Sidemark: All DB scripts are generated by the archetype no matter which database type is specified. This does not fit to the opt-in approach for the database configuration, which has again to be done completely on your own.

Probosal: Keep configurable datasource based on a spring profile to give an idea of how to add additional database easily. Always keep h2 DB scripts and configuration if the choice is any other database like oracle,mysql,...

hohwille commented 5 years ago

@maybeec thanks for pointing this out. I was not aware of that part in the documentation and I still believe that is was wrong from the start to propagate this approach at all. I therefore just updated that section in the forge wiki. To be honest 99% of our projects decide for one (productive) database and then do not switch that anymore. However, software products that are soled to multiple customers often have this demand. In such case, people can just look at my-thai-star and copy the solution from there.

Sidemark: All DB scripts are generated by the archetype no matter which database type is specified. This does not fit to the opt-in approach for the database configuration, which has again to be done completely on your own.

I fully agree with this one. However, maven-archetype sucks really hard. Not only is maintaining an archetype with velocity code that is not language-agnostic a kind of pain. Also the ways to include and exclude content are very limited and hackish. I already spent hours up to days in order to solve this issue easily but could not find a solution so I finally gave up. If someone has an idea how to solve this, I am more than happy to go for it.

Probosal: Keep configurable datasource based on a spring profile to give an idea of how to add additional database easily. Always keep h2 DB scripts and configuration if the choice is any other database like oracle,mysql,...

As I said, I vote against it. I think this is leading projects in the wrong direction.

maybeec commented 5 years ago

Ok, if that has been decided some time ago, I do not want to start the discussion again. Anyhow, in my project we are maintaining both configurations for h2 and oracle in order to fasten development and circumvent connectivity issues respectively have a backup for offline work. I think this is very valuable and I would be happy to get this for free from oasp/devon.

hohwille commented 5 years ago

Fine. We are using h2 for tests anyhow so that already implies to maintain the SQLs also for that. The only difference then is...

Sorry, to say so: I rather think you are doing something that is not most common for 80% of the projects. Even further, I think we are all clear that h2 is not an option for productive usage.

Therefore my suggestion would be:

Still if anyone has a solution how we can make the archetype generate

I would be very pleased, because this is IMHO the 80% layout. It would also already be fine if we could just get rid of the other DB type folders that have not been chosen. This would be even closer then to your desired setup @maybeec and also this setup has the advantage to offer a solution to have "shared" SQLs that are independent of DB type (such as simple inserts of masta-data as demonstrated in archetype by V0004__Add_blob_data.sql)