On 22/05/2007, at 5:36 AM, Raphaël Piéroni wrote:
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. :-)
Yep, understood. It just makes it very difficult to think about how
we reintegrate it into trunk if there have been changes there :
( Unfortunately, we didn't have enough tests before to run against
the new one to verify compatibility.
It don't prompt when maven is called with -B
I understand - but this is not the previous behaviour.
* 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.
Ok - it should fail in this instance then (if interactive). You
should probably be able to enter your own one too rather than
selecting from a list.
* after selecting values I get "Confirm archetype
selection:org.apache.maven.archetypes/null".
Can i have the full trace please?
It wasn't a trace - that was the output on the line after selection.
* Trying to generate from the webapp archetype gave: "Failed to
generate project from the old archetype"
Can i have a complete log please?
oddly, I just tried again and it worked... I did:
mvn archetypeng:create -DartifactId=webapp -DgroupId=test -
DarchetypeArtifactId=maven-archetype-webapp -
DarchetypeGroupId=org.apache.maven.archetypes
(though I did get an IOException in the middle:
IOExceptionjava.io.IOException: The META-INF/maven/archetype.xml
descriptor cannot be found.)
* Is the archetype descriptor required to do anything, or is it
optional?
The META-INF/maven/archetype.xml is mandatory
Aren't there conventions that can be followed that would mean the
archetype descriptor can be generated with sensible defaults? I think
that would be a good way to go.
* 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.
Understood, I'm just not comfortable with it being used as both
'compile time' and 'run time' information. ie, I don't think it
should be used by create-from-project at all - only from within a
published archetype in :create. Am I misunderstanding how it is used?
* 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.
It's an interesting problem. I'm not sure if that's how I'd use it,
or something more like:
mvn archetype:create-from-project -DartifactId=my-archetype -
DgroupId=com.mycompany -Dproject=../my-sample-project
ie, generate to my-archetype directory (much like archetype:create
would), and point to where the source project is instead of running
on the current one. What do you think?
* When I run create-from-project a second time, I get a string out of
bounds exception
A complete log please
My bad, I should have recorded what I was doing. Can't reproduce again.
* 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 two things we don't have styles for :)
The things that come to mind are 4 space indenting in XML, and the
new lines inside brackets in the code.
Probably easiest to look at some existing Maven code and try
reformatting it, then adjusting your settings until the reformat
keeps it as it was :) If you could share the netbeans settings for
that, that'd be great!
* The licenses throughout are inconsistent (probably a pre-existing
problem, Carlos recently corrected some on trunk)
Please show me the light i will follow
We can take care of that if bringing it over, I just noticed there
were different headers.
- 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.
Yes, that's what I was getting at - the use of mojos for some of the
tasks if they won't ever be executed as standalone goals is something
I don't think is needed.
Do you have use cases where the mojos for selection, etc would be
called on their own?
* Nitpicks: Exception handling, no need to set java defaults on mojo
parameters that already have default-value
Can you please explain with an example.
catch (Exception), throw new Exception, throws Exception (or anything
that deals with Exception and not a derivative).
/** @parameter default-value="..." */
private String something = "..."; // the = "..." is redundant
* I think the interactivity should be externalised rather than
conditional via the true/false flag on some methods
What do you think of this one?
* 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.
Np, just something to review on the whole then.
* 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.
So what is the answer here? To move the list to the descriptor?
* 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.
Basically, refactor until the archetype core has no dependency on
maven-artifact (or downloader) :)
That seems like an appropriate separation of concerns to me, that's
all - we can review later.
First the doco is outdated for the old proposition, and need update.
Yep, I saw your other note on that after I wrote this (oops)
* In handcrafting, there is nothing about arbitrary source groups -
is it possible to create these?
Not sure to understand.
I think this is what I referred to with the non-constant languages
above.
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 :)
Well, I think the best thing is to get the code all in one place, and
get that list alongside it (or into jira), so that anyone interested
(as there have been a few) can help out. I wouldn't mind doing a
little coding rather than talking ;)
I'll send a separate mail since I've already promised it...
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
