Hi, So the long answer
2007/5/21, Brett Porter <[EMAIL PROTECTED]>:
This is mostly for Raphaël, but also anyone else interested in Archetype dev. So, as I understand it: - maven-archetype-1.0.x branch is no longer needed (this was for the alpha series releases before the re-arrangement / refactoring that only got half done last year). I've removed it. - trunk has had a number of changes made, though none very recent - archetypeng was forked from trunk and changed drastically. It includes all the things that were done on trunk (Raphaël - can you confirm? Do you know what rev# it was forked from?)
So i did not forked, but rewrited. Some history : I must admit have inspired myself on using the artifactDownloader and use of component in plexus and a bit of modello. I first made some paper work during new year holydays. And started to code thereafter. I needed a SCM and used my own. When i was happy enough with the code, i sent to Jason who told me it was better on a public SCM. I had access to mojo, So it ended there. Since, i made some refactor to improve the descriptor. Else can be known reading the svn logs. :-) So, I've started reviewing archetypeng as a replacement for trunk so
that we have one place to move forward from. It's looking pretty good, but there are a few issues.
Thanks. Here are my comments / questions on archetypeng (in my typical stream
of conciousness, kitchen sink style): *) Backwards compat issues / bugs * archetype:create now prompts for input - this could cause problems for other users that relied on it using default values.
It don't prompt when maven is called with -B * archetype:create comes up empty on archetypes for o.a.m.archetypes.
I guess this is a lack of current metadata?
That is the correct guess. The metadata are the same as plugin metadata for plugin groups. * after selecting values I get "Confirm archetype
selection:org.apache.maven.archetypes/null".
Can i have the full trace please? * I don't think we should prompt for confirmation I will try * "Define value for version:" probably needs more explanation It is define value for 'property name', But i am agree to improve any prompt. Does anyone have ideas? * Package should still default to group ID IMO Fine i have some issue to propose some default values to the 4 required properties common to each archetypes: groupId, artifactId, version and package * Running a second time retains the values selected the first time,
which is inconsistent
This is because the 3 mojos used in the project generation communicate using the file archetype.properties. So i think i should just add the use of archetypeng:clean mojo just at the end of the lifecycle * Leaving package empty causes it to fail with " The archetype
generation must be configured here"
Yep, package and all the required properties are mandatory. But this is a bug because the process should keep asking for the package * Trying to generate from the webapp archetype gave: "Failed to
generate project from the old archetype"
Can i have a complete log please? *) Concepts
* We'll need to change references to org.codehaus.mojo in both poms, code and doco, as well as references to NG
Fine * Is the archetype descriptor required to do anything, or is it
optional?
The META-INF/maven/archetype.xml is mandatory * The archetype descriptor seems like it's plugin configuration as
well as the descriptor for inclusion - this seems to be a bad overlap
The descriptor defines what to be found in the archetype-resources directory. It is used during the project generation to find which files are velocity templates and which are copied only, which are in packaged directories and which not, which are the submodules in a project. It also contains all the additional required properties (additional to the common ones) with their default values. * I'm confused by the create-from-project goal: it seems to just
create sources and properties, but doesn't actually produce the archetype? How is it meant to go from that to the final bundle?
It creates a maven project in target/generated-sources that project is the archetype which can be inserted in a scm. To have that archetype in a repository, one should 'cd' to target directory then call mvn install or mvn deply phases. * When I run create-from-project a second time, I get a string out of
bounds exception
A complete log please * Should the interactive part of create-from-project that generates
the properties file be a separate goal from the one that produces an archetype?
I really don't know what is better; but currently, the 5 main components (selection, configuration of create, create, configuration of create from project and create from project) are mapped to the 5 main mojos. And there are 2 lifecycle mojos to bind the 5 main mojos in creation or create from project. * Are there any examples of partial archetypes? Only in the tests *) Code
* Should the archetype descriptor example be in the documentation instead of the model directory?
Yep, I had the example ther for adding the features one by one. Now i made the descriptor complete, i am agree. * We should come up with a better way to extend the settings file for
use by plugins (general comment - using archetype.xml for now seems right)
Agree, this is for what i needed the ~/.m2/archetype.xml * not all the archetypes seem to be included in the bundles pom? Yep, only the one that i can create a descriptor for (using new descriptor ). This sentence is valid for some time ago when i had the other descriptor proposition. I will have to refactor the included to the new descriptor proposition, then add each unbundled one by one. i just kept them for not forgetting to do it. * what is the purpose of archetype-common? The code in there seems
inconsistent in style - capitalised tag names and complicated statements that could be extracted from the code segments. The XSD is generated, but no reader/writer.
It is mainly a util project with common code called from archetype creation and project generation. I am agree it smells and is in constant refactoring... If any one has ideas to stabilise it, they are welcome. The modello in -common only serve to generate java code. I will check the pom and remove the xsd if defined. * Don't necessarily agree with the module structure - we should
completely split out the actual archetypes, and make -core the top level
Any better ideas than mine are welcomed. * Just a minor thing - the formatting (particularly the number of
spaces in xml) is inconsistent which will make it hard to incorporate
Examples wher i have to correct. A definition of what is consistent for me not to reprocude unsconsistency in the future? (i use netbeans formatter for xml and jalopy (paid) for java) * The licenses throughout are inconsistent (probably a pre-existing
problem, Carlos recently corrected some on trunk)
Please show me the light i will follow * Not sure of the need for a clean goal (since I think
archetype.properties should be written somewhere else, if at all)
If somewhere else, where is better? If not at all, how to cummunicate between the mojos? * I think it'd be better to compose the execution stages of various
calls to components rather than orchestrating mojos in the lifecycle
The answer of my above question it seems. - I don't see the usefulness of the mojos independent of the
lifecycles they are declared in so it's unnecessary complexity (unless I'm missing something?). Looks particularly weird on create and create-from-project empty mojo
I don't understand what you are complaining for (= find an issue - please correct my poor english) here. Maybe the answer is to have create and create-from-project call the components successively, as you stated. * Nitpicks: Exception handling, no need to set java defaults on mojo
parameters that already have default-value
Can you please explain with an example. * Needs lots of Javadoc Yep... * I think the interactivity should be externalised rather than
conditional via the true/false flag on some methods
* The APIs seem very verbose - lots of parameters and exceptions. eg.
what would the caller think an XmlPullParserException mean from ArchetypeGenerator.generateArchetype?
I am not very good at exception definition. By lazyness, i just propagated the exception to the mojo. * PathUtils seems like it could be replaced with something from
commons-io
I will be happy to use shared code that fullfill my needs instead recreating the wheel * ListScanner is another duplication of code from plexus-utils - is
there no way to reuse that?
It scans in a java.util.List of String. I first searched for a shared component but did not find any that had the required feature, so i duplicated (but am not happy with) * Is the languages hard-coded in Constants a problem? Yep, there are many languages that could benefit from a maven build not only java :) and we can't maintain a list in code. The languages are the name of the directories which follow a directory-per-package tree like java, c, groovy, and more, i don't know about. * It might be nice to separate the maven-artifact related pieces from
archetype-core: ie, so you could use the archetype api just by providing a jar file reference with no repository interaction
I am sure not to understand exaclty what you mean. * The Exception classes should be suffixed with Exception Ok, will do. This is as far as I got here... didn't read through the code itself.
*) Documentation
First the doco is outdated for the old proposition, and need update. * In the 'handcrafting' archetype doco, it mentions that you must use
the type 'maven-plugin'. Is that correct? I thought it was maven- archetype?
It is currently maven-plugin. But using maven-archetype is planed. I just have to dig how to do it and have group metadata uploaded also. * In handcrafting, it says a pom is always necessary. Is that only
for complete archetypes?
IIRC, it is also for partial archetype. the pom included in the archetype-resources is merged in that case instead of only a velocity template. I have conceptual issues with the generated pom beeing a velocity template. I can't figure exactly what it is but for me it is not the correct assumption. * In handcrafting, there is nothing about arbitrary source groups -
is it possible to create these?
Not sure to understand. Thanks again for the efforts to get this critical piece of
infrastructure finished.
I am happy to create some piece of soft that is usefull to others. Before your email, i had a list of issues in my todo list on archetypes. Now i will have a Huge list :) Regards, Raphaël Cheers,
Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
