maven - customized dojo profile.

[peter cooke]

I am looking for best best practices. this is such a fundamental issue I cannot see why I don't find more postings on this.


we have a number of apps where I work all with dojo (all same version) BUT they all have a custom profiles, and those files have been traditionally checked into the app, and have found out that someone has been hand modifying the generated files. We of course don't want the developers modify generated code. at least modify the the authoritative source.

I have found a solution to rebuild dojo every time the web app builds. Since those dojo artifacts don't change much. it takes way to long for no benefit.

on the command line. I can build the custom profiled dojo, zip it up, and tell mvn to install a zip of the dojo into com.mycompany.web.dojo:app:dojoversion then have my app depend on that dojo version. works but not elegant. At some point I did get maven to call the dojo build.bat script.


Ideally the pom would build out all the versions of dojo, and then install them into the repository. mvn install:install-file or mvn deploy:deploy-file. Then in the target web app declare the dependancie and unpack the dojo stuff in the maven repository.



Leaning maven
My questions are:
1) what are the best practices for storing generated 3rd party non-java files and storing them in a maven repository? assemblies/war/jar/zip files??

2) since my pom seems to want to generate a jar or war one way or the other. Assuming I jar up all the dojo stuff. what plugin would I use to extract? Why didn't they include zip as a package type?




I have to be missing somehting.... any lessons learned???

[Tim Holloway]

Red Hat has similar issues for their Linux software packages. In their case, they wrote their own system: the RedHat Package Manager.

One of the first things that the RPM builder does is unzip/tar the master (official) source archive of the application being packaged and apply the patch utility to the unpacked source in order to customize the build process for the Red Hat environment. Something similar could be done with Maven, although you'd probably have to make your own mojo.

If you're looking for different "flavors" of dojo, you should give them distinct artefact IDs and not just rely on version numbers. Save the version numbers for successive generations within each flavor. Ideally, keep the customization to a minumum. Dojo is a pretty nasty piece of work and assuming a typical modern-day IT shop, the only people who understand the mods will end up getting laid off within 2-3 years.

[Peter Johnson]

1) You have to come up with your own best practices for groupId and artifactId of thrid-party artifacts. That is what we did. The biggest issue was avoiding potential conflicts with existing groupIds, so we uses common prefix for all third-party groupIds (e.g., thirdparty.foo.bar.xxx) Also, we installed a Nexus server, it comes preconfigured with a thirdparty repository and we placed all third-party artifacts in there.

2) Package files such as zip and tar.gz are best created using the Assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/). You can usually just invoke the assembly:single goal from the command line (i.e., mvn assembly:single) and have it create the zip for you. In this case the zip is not the result of the build (the result is a JAR or WAR or something) but is instead a separate packaging of your application. We actually created our own plugin that recognized a zip (and other ) packaging types so that we could create POMs for those artifacts and treat them as results of a build.