Using 3.0 in real project

[Pavel Tavoda]

Hello,

I started (after some patches) using 3.0 in production project. For one project I created special project with Xtend overrides. However I don't like to have special project with one file where I have my overrides.

For another project I did another arrangement. I put overrides into src/main/resources/generator/SpecialCases.xtend like:

=========================

package generator

import org.sculptor.generator.util.CamelCaseConverter

import org.sculptor.generator.chain.ChainOverride

import org.sculptor.generator.template.jpa.JPATmpl

import org.sculptor.generator.template.service.ServiceTmpl

import sculptormetamodel.Application

import sculptormetamodel.Service

@ChainOverride

class JPATmplOverride extends JPATmpl {

override String persistenceUnitAnnotatedClasses(Application it, String unitName) {

next.persistenceUnitAnnotatedClasses(it, unitName) + '''

<!-- smartclient classes -->

<class>sk.f4s.albiq.process.domain.AlbiqProcess</class>

<class>sk.f4s.albiq.process.domain.AlbiqTask</class>

'''

}

}

@ChainOverride

class ServiceTmplOverride extends ServiceTmpl {

override String springServiceAnnotation(Service service) {

"@org.springframework.security.access.annotation.Secured(\"ROLE_"+CamelCaseConverter::camelCaseToUnderscore(service.name).toUpperCase()+"\")\n"

+ next.springServiceAnnotation(service)

}

}

=========================

Than I used attached pom-generator.xml for compiling it inside same project like 'mvn -f pom-generator.xml clean install' and I have to run it always when I change generator. And than used it in standard pom.xml as dependency in sculptor-maven-plugin. Everything works.

What do you think, can we use same also for library-example as sample for overriding or you think we have to make separate project for xtend overrides?

Torsten it's possible to merge standard pom with pom-generator.xml via profiles into one and active both for default build?

Which features we are missing? My list include:

1) Get rid of workflow engine (MWE) #53

2) Solve problem with dispatch method overrides #45

Regards

Pavel

[Torsten Juergeleit]

Than I used attached pom-generator.xml for compiling it inside same project like 'mvn -f pom-generator.xml clean install' and I have to run it always when I change generator. And than used it in standard pom.xml as dependency in sculptor-maven-plugin. Everything works.

From my experience you're asking for trouble, e.g.

• A Maven project is responsible for creating a single artifact (jar, war, ear). Creating multiple artifacts is not intended for a single Maven project. Ok, sometime it's necessary, e.g. ejb client jar.
• With this approach building the whole project from scratch (no artifacts from a previous build are available in the local Maven repository) is not possible. One has to build the project with the template override stuff manually first.
• This approach infringes the principle of "separation of concerns". Here build-related artifacts (classes with template override implementation) are mixed with the business-related artifacts (classes with business logic).
• The build process (Maven poms) are becoming complex by trying to do stuff Maven is not intended for.

In a real world project we're using the following Maven projects only for the Sculptor2 stuff:

• sculptor-runtime: pom project with bom (bill of material) for dependencies needed during runtime
• sculptor-test: pom project bom for dependencies needed during test
  
• sculptor-generator: jar project with bom for generator-related dependencies and jar with global sculptor-generator.properties and SpecialCases.*

What do you think, can we use same also for library-example as sample for overriding or you think we have to make separate project for xtend overrides?

As I wrote previously, I would use a separate project for the template override stuff.

 

Torsten it's possible to merge standard pom with pom-generator.xml via profiles into one and active both for default build?

No, putting the template override stuff into the same Maven project you'll end up creating separate artifacts with the same maven coordinates (groupId, artifactId, version). To build the "real" artifacts (which needs the template override stuff) needs a dependencies on itself. The Maven reactor does not allow this.

 

Which features we are missing? My list include:
1) Get rid of workflow engine (MWE) #53

Yes, but this isn't a deal breaker. The MWE2 stuff is only used internally by the generator and it's not exposed.

/Torsten

[Pavel Tavoda]

Thanks for your enlightenment. I start to understand it when I was trying to merge POMs ;-).

I dislike that I have to create separate project in Eclipse which holds ONE useful file (SpecialCases.xtend), that's crazy (for me).

I will stick with this and create separate library project for template overrides where we can make some demo cases.

Torsten it's possible to merge standard pom with pom-generator.xml via profiles into one and active both for default build?

No, putting the template override stuff into the same Maven project you'll end up creating separate artifacts with the same maven coordinates (groupId, artifactId, version). To build the "real" artifacts (which needs the template override stuff) needs a dependencies on itself. The Maven reactor does not allow this.

Can I create property in profile and use it as artifactId? This way we can have different artifactId for different profiles?

Anyways I guess it will be hard to build in one shot because of multiple results. I never give up ;-).

Pavel

[Torsten Juergeleit]

Can I create property in profile and use it as artifactId? This way we can have different artifactId for different profiles?

Nope. The reasoning behind this can be found in the section "Which areas of a POM can be customized by each type of profile? Why?" of http://maven.apache.org/guides/introduction/introduction-to-profiles.html

/Torsten

[Torsten Juergeleit]

I started (after some patches) using 3.0 in production project.

How are you going with your real world project using version 3.0?
Is version 3.0 ready for prime time?

/Torsten

On Friday, 23 August 2013 14:43:59 UTC+2, Pavel Tavoda wrote:

[Pavel Tavoda]

Now fighting with SQL generation and sometimes NPE (from wrong, but real life models, you know 'developers'). But except this SQL I was able to run it and integrate very well bellow our Smartclient GUI. I will commit today my changes for PostgreSQL/Oracle than we have to do same with MySQLTmpl.

Pavel

[Pavel Tavoda]

Hello,

now we are using 3.0 in 4 real life projects. However we use very specific settings now:

jpa.provider=hibernate3

jpa.version=1.0

db.product=postgresql #oracle

For me everything work fine, can somebody test also on some real life projects with different settings?

Pavel

[Ron Smith]

I've been using it on a real project for months with the following settings, and it's working great:

nosql.provider=mongoDb

datetime.library=joda

cartridges=builder,mongodb

[Torsten Juergeleit]

Is anyone using Hibernate 4 and JPA2 with MySQL?

jpa.provider=hibernate

db.product=mysql

I'm asking because for running the example used in the Maven Archetype Tutorial in JBoss AS 7.2 (shipping with Hibernate 4) with MySQL I had to tweak the MySQL DDL template to support the table hibernate_sequence used by Hibernates "SequenceStyleGenerator".

/Torsten