maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphaël Piéroni" <raphaelpier...@gmail.com>
Subject Re: Archetype review
Date Wed, 23 May 2007 11:55:56 GMT
Hi

2007/5/23, Brett Porter <brett@apache.org>:
>
>
> On 22/05/2007, at 5:36 AM, Raphaël Piéroni wrote:
>
> >
> > It don't prompt when maven is called with -B
>
> I understand - but this is not the previous behaviour.


Could that point  should be marked as a non mandatory backward
incompatibility ?
Because i dunno how to forbid prompting behaviour unless the usage of this
option.

>
> > * 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.


Sory i meant which are the steps for me to reproduce?


> * 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.)

The descriptor is first searched there, maybe the Exception should not be
visible.


> * 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.


Do you mean some use case like this?
an archetype project without the descriptor
where the descriptor is generated before package phase.
But only when the descriptor is absent.


> * 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?


The descriptor which reside in the archetype's artifact is used
for generating a project from that archetype.

The descriptor is created by the create-from-project goal
(or by hand)

During the time the archetype is created from a project (or by hand)
and the time it is uploaded as a jar, the descriptor is only a resource.

I hope this answer your question (if not, maybe i don't have understood the
question)



>
> > * 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?

This is an interrsting usecase. i think we could poll the potential users
with both proposition and see what is better (or provide both and use a
goal property to distinguish). But i don't have any preference.


> * 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!

Netbeans settings can't be shared, the formatting for xml is poor enough
just the tab vs space and space size of indent.


>
> > * 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.

Thanks, the headers, should have been (at least in java code) taken care by
jalopy


> - 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?


i don't have use case for the prompting mojos as standalone.
But i have for the non prompting : to be called in a wizard-like mode
and embedded in an IDE.

I currently have some tough about this on paper.

>
> >
> > * 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


OK

> * 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?


Will  re-think at the code to code it better (not before next week)

> * 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.


yep

> * 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?


Nope move the list in the "registry"
the file at ~/.m2/archetype.xml is what i call the registry.
It currently holds the list of archetype groups, the list of repositories
wher to find archetypes,
the list of languages and the list of filtered extensions.

> * 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 ;)


So just take the code, i will not do anything untill tomorrow.
Then i will use svn switch...


I'll send a separate mail since I've already promised it...


Seen

Regards

Raphaël

- Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message