views:

495

answers:

4

I'm creating Maven 2 archetypes for our project (Weld). I would like to be able to control which files are placed into the generated project based on the value of a property that is defined during archetype:generate. For instance, I foresee the following prompt:

Define value for groupId: : com.example
Define value for artifactId: : myproject
Define value for package:  com.example: :
Define value for includeGradleSupport: : y

Based on the value of includeGradleSupport, I want to include (or not include) the build.gradle file in the generated project. If the user does not want Gradle support, I don't want to clutter up the generated project with unnecessary files.

Another example is that I might need to provide a Jetty web fragment (to activate a listener perhaps) if the user wants Jetty support.

It's all about customization of the project based on what the developer intends to use. While I could create a whole other archetype, sometimes the changes are so slight that it would be easier to include/exclude a file.

Is there a way to control this behavior using the archetype-metadata.xml descriptor?

A: 

I can have a look into what coding it would take to enable this in the archetype plugin.

I think the primary vehicle to do this today would be to conditionally produce two different archetype artifacts during the original build. The archetype user would then explicitly use yourarchetype-withthing or yourarchetype-withoutthing.

I know this isn't perfectly what you are after and I agree that what you are asking for is a sensible use case.

Matthew McCullough
Hmm, creating multiple artifacts from the same project would go against the philosophy of Maven (one project => one artifact).I really think this would be a useful thing. I can use velocity inside of a file to change the content, but what I cannot do is include or exclude whole files, which is really an extension of that same idea.I look forward to your prototype ;)
Dan Allen
A: 

While I could create a whole other archetype, sometimes the changes are so slight that it would be easier to include/exclude a file.

This sentence made me think...

It seems like you have a default project structure.
Let's suppose it is big, has many files. Of course, you don't want to duplicate the logic and the files in a different archetype.

Now sometimes, a project has an additional behavior (related to Gradle).
This sound a typical use-case for another archetype that does not start from nothing, but that comes after the first one. I've seen several examples of such archetypes on the web. The developper triggers this archetype only if the project needs Graddle. :-)

So I suggest : create your Graddle archetype, that adds only the files relevant to Graddle.

KLE
Are you saying that we should have what is termed a "partial" archetype that layers over an existing project (presumably created by the base archetype)? That still sounds like too much work for the end developer. They don't want to run two archetype:generate commands, they want to run one. If, on the other hand, you are suggesting that we create a second archetype that merges in the addition files into a base archetype, to me that breaks the convention in Maven where one project produces one artifact. Perhaps if the archetype can pull in shared files then that would be another possibility.
Dan Allen
@Dan I was suggesting the partial archetype solution :-). I believe the conceptual complexity is the same for the end developper, because he has to know the two notions in all cases. In the implementation, you can assure that he doesn't have to do more typing ;-). Also, it should be easy to wrap the calls to the two by a single command if needed, shouldn't it?
KLE
+1  A: 

I personally would move the parts that can be removed/added on user request and put the into different maven profiles so u can build different part using different profiles

Mite Mitreski
Yes, that is certainly a valid approach. But in our case, we want to minimize the complexity of the generated project for reasons of usability. When the developer chooses the servlet configuration, for instance, we want that build to only accommodate that single scenario.
Dan Allen
A: 

I worked on a project for a while that used profiles for this type of behavior and that went badly and our builds and poms were extremely complicated. We came to the conclusion in the end that the best thing to do is to set up a new project structure where our main application code was jarred up and then the different deployment configurations were entirely different builds that had a dependency on the main project. This creates a lot of builds and projects but they are all simple and easy to maintain and have a single artifact.