You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/07/02 09:55:15 UTC
Current ArchetypeNG trunk issues
Hi,
Pumping this out to the list, since I don't have time to flood JIRA,
and some may be answerable beforehand or get taken care of before the
import. I'll take responsibility for collating this and any
responses, retesting against the final imported code, and getting
into JIRA (Which will need to first be reviewed for validity against
the new codebase anyway).
Here are the issues I've encountered so far:
- [ ] doesn't build OOTB because of missing dependency on rt.jar. I
don't understand the need for this (it worked after removing
it), but if it is required on some platform it should be done
like in it0063 (I think that's the one - with the system
dependency).
- [ ] doesn't build on versions of Maven < 2.0.7. Needs a
prerequisite in the parent POM.
- [ ] craps out on first use due to missing ~/.m2/archetype.xml
(see [1]).
- [ ] tried creating ~/.m2/archetype.xml with no content, and then
with <archetype/>, and neither worked. All error messages
were different, but both unhelpful. For those playing along
at home, it's <archetype-registry />. See [2] and [3] for
exceptions.
- [ ] I ran... "mvn archetypeng:create -DartifactId=foo
-DgroupId=bar" and got prompted with:
Choose group:
Choose a number: :
(so, two problems here - it's still prompting by default,
and there's no error handling on whatever should be
determining the choices here)
- [ ] I progressively added settings to the command line and it
kept prompting - so it's not using any defaults for version,
package, archetype*Id.
- [ ] create-from-project seems to look in ~/m2/archetype.xml
(note the missing '.')
Some stuff/outstanding questions from before that needs to be
rechecked (most already had been answered, just still on the todo
list - see <FB...@apache.org>):
- [ ] Design
- [ ] Carlos pointed out ARCHETYPE-38 wasn't in there, which
was on archetype trunk
(<1a...@mail.gmail.com>).
We need to review whether anything else has
happened on trunk that is not in here due to the rewrite
- [ ] currently the archetype descriptor is required, however I
believe that sensible defaults could be derived making it
unnecessary
- [ ] The archetype descriptor seems like it's plugin
configuration as well as the descriptor for inclusion -
this seems to be a bad overlap
- [ ] I need to review this some more for my own
understanding
- [ ] I was led to believe create-from-project required an
archetype descriptor to work - I would have thought
the information could be gathered and any remaining
configuration became plugin configuration so the full
descriptor is generated instead of hand crafted.
- [ ] I still need to look more closely at create-from-project
- it doesn't produce the acftual bundle when run so
there's no way to take the generate sources and produce a
JAR to release. It makes it a once off activity.
- [ ] We need some documentation on how to use partial
archetypes
- [ ] Code
- [ ] Should the interactive part of create-from-project that
generates the properties file be a separate goal from the
one that produces an archetype?
- [ ] not all the archetype bundles have been converted to the
new format (and are omitted from the parent pom modules
list)
- [ ] we previously agreed to remove the model from
archetype-common and just use normal code - it's not
read/write anywhere
- [ ] Don't necessarily agree with the module structure - we
should completely split out the actual archetypes, and
make -core the top level
- [ ] Not sure of the need for a clean goal
- [ ] archetype.properties should be in target,
automatically cleaned up, or not used at all (not
sure why it is needed yet - seems to be inter-mojo
configuration which can be achieved in other ways -
see below)
- [ ] I think it'd be better to compose the execution stages of
various calls to components rather than orchestrating
mojos in the lifecycle - 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 think the interactivity should be externalised rather
than conditional via the true/false flag on some methods
- [ ] having the available languages hardcoded into Constants
is a problem
- [ ] 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
- [ ] PathUtils seems like it could be replaced with something
from commons-io
- [ ] ListScanner is another duplication of code from
plexus-utils - is there no way to reuse that?
- [ ] various other exception / javadoc / code style stuff as
Raphaël pointed out
Thanks for pushing this along... happy to plough through some of this
once the code lands.
- Brett
[1]
Caused by: java.io.FileNotFoundException: /Users/brett/.m2/
archetype.xml (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileReader.<init>(FileReader.java:55)
at
org.codehaus.mojo.archetypeng.DefaultArchetypeRegistryManager.readArchet
ypeRegistry(DefaultArchetypeRegistryManager.java:98)
[2]
Caused by: java.io.EOFException: input contained no data
at org.codehaus.plexus.util.xml.pull.MXParser.fillBuf
(MXParser.java:2979)
at org.codehaus.plexus.util.xml.pull.MXParser.more
(MXParser.java:3022)
at org.codehaus.plexus.util.xml.pull.MXParser.parseProlog
(MXParser.java:1407)
at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl
(MXParser.java:1392)
at org.codehaus.plexus.util.xml.pull.MXParser.next
(MXParser.java:1090)
at
org.codehaus.mojo.archetypeng.registry.io.xpp3.ArchetypeRegistryXpp3Read
er.read(ArchetypeRegistryXpp3Reader.java:748)
at
org.codehaus.mojo.archetypeng.registry.io.xpp3.ArchetypeRegistryXpp3Read
er.read(ArchetypeRegistryXpp3Reader.java:762)
at
org.codehaus.mojo.archetypeng.DefaultArchetypeRegistryManager.readArchet
ypeRegistry(DefaultArchetypeRegistryManager.java:102)
[3]
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException:
Unrecognised tag: 'archetype' (position: START_TAG seen <archetype /
>... @1:13)
at
org.codehaus.mojo.archetypeng.registry.io.xpp3.ArchetypeRegistryXpp3Read
er.parseArchetypeRegistry(ArchetypeRegistryXpp3Reader.java:418)
at
org.codehaus.mojo.archetypeng.registry.io.xpp3.ArchetypeRegistryXpp3Read
er.read(ArchetypeRegistryXpp3Reader.java:751)
at
org.codehaus.mojo.archetypeng.registry.io.xpp3.ArchetypeRegistryXpp3Read
er.read(ArchetypeRegistryXpp3Reader.java:762)
at
org.codehaus.mojo.archetypeng.DefaultArchetypeRegistryManager.readArchet
ypeRegistry(DefaultArchetypeRegistryManager.java:102)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org