On 12-Feb-08, at 1:19 PM, Milos Kleint wrote:
On Feb 12, 2008 9:53 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 12-Feb-08, at 11:39 AM, Milos Kleint wrote:
anyway,
I fixed both my and Daniels problem here:
http://svn.apache.org/viewvc?view=rev&revision=627055
Great. Hardly tragic. Probably took you less time to patch it then
write the email.
It is actually serious. It's playing with the goodwill. And most users
vote with their feet, just a few bother to report or complain. That's
a lesson we learned the hard way with NetBeans in the early days..
I fully realize this, but this case it worked out quite well where
Raphael, Brian, and myself put in over 100 hours and got the new
system working. A bit of checking on your part and a patch and we're
back to full compatibility. So it's entirely complementary. Auto
update must be destroyed: users will not get nailed by these things if
new things don't magically get pulled down.
I also didn't figure that embedding Archetype in netbeans you would
just run the command line stuff. We tried to make it easier to embed.
I don't want to include and depend on yet another pile of alpha
software. I don't have anything against the archetype components
specifically, but depending on them directly requires me to sychronize
my release cycle with the libraries. That's something I don't want to
do with the archetype stuff. Additionally, having a loose coupling
allows me to let people choose what version to use (sort of) in case
of specific troubles..
Again, auto update would prevent user unhappiness. You just wouldn't
have gotten the new version, but if you control the command line
invocation then you could actually go back to the 1.x version to
provide the same capability for now. I will put up archetype for
another vote as soon as I fix the generated archetype projects from
spitting out the wrong versions in their POMs (this is for create-from-
project).
Again, another argument for not auto-updating under any circumstance
and leave this to the user. Moving across major versions will happen
and we just shouldn't upgrade unless the user asks for it. I'm not
saying we shouldn't keep the behavior in the archetype plugin, if
desired, but this would prevent incompatibilities from whacking users
in the face.
I agree here. Automatic updates are the sort of evil that will hit
almost everyone. It seems that people feel cheated then and get
frustrated at Maven. Not sure why, but it seems common. A "no suprises
and ess magic" kind of strategy should help.
If that patch is in, I'll add a fix for the incorrect version
information being generated and stage another release.
Cool. Thanks.
Milos
Milos
On Feb 12, 2008 7:52 PM, Milos Kleint <[EMAIL PROTECTED]> wrote:
On Feb 12, 2008 6:45 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 12-Feb-08, at 8:16 AM, Milos Kleint wrote:
Jason,
this is not about mimicking old behaviour. The new code is plain
wrong
for this case.
Mimicking the behavior means making it work like the previous
version.
It would also have been nice if both you and Dan actually looked
at
this before it was released. I don't think it's that much work to
change it, but appeared from almost all people talking about
Archetype
absolutely hated the old mechanism. Writing scripts to work around
it,
begging for another method to select.
Well, I've been testing archetypeng for some time, I even applied
patches. The batch mode actually works because I fixed it as far
as I
remember. I've tested the staged version in netbeans integration
with
my 2 custom archetypes that work with 2.0-alpha-1 only. In the
netbeans integration I use the batch mode exclusively, because I
don't
want *any* user interaction to happen when the archetype plugin
runs.
I need the UI to populate all fields before starting archetype.
That's
why I didn't catch this issue. I only did when I released my 2
archetypes and was updating documentation, describing how to create
from archetype on command-line.
When you define the archetype's groupId, artifactId and version
on
command line, the plugin should not offer you a list to pick
from.
That's especially tragic when the archetype you want is not in
the
list. Period.
I would consider that a bug, sure, I don't think I would
categorize
that as tragic.
We advertise the archetype plugin in the docs as *the* easy way to
setup a maven project. All documentation is now wrong. (in a sense
that what is described to happen is not happening). What message
does
it send?
If all archetype properties are defined, it should just create
the
project, if some are missing ask for missing values.
Catalogues should help, not be in the way.
Well, I'm sure glad you helped so much while we were developing
the
new version.
Both you and Dan had every opportunity to look at the code along
the
way, look at the staged release and voice your concerns.
see my reply above..
Nothing is irreparable. But generally it would be better if you're
going to voice a concern try and do it before the release. By all
accounts I could see no one I could see actually like the old
cumbersome way. Evidenced by the proliferation of tools that
cropped
up to present lists to people.
The only workaround I figured out, is to run maven in batch mode
and
declare archetype ids and all properties on command line.
Strangely
enough the central repository needs to be declared on command
line as
well. I'm for calling this a bug too.
Nothing tragic, it can be fixed. We can create a new goal (like
archetype:generate which is more accurate or archetype:create-
from-
list) for the behavior that we created, and have the "create" goal
mimic the old behavior. How's that sound? I think people who like
the
old way are in the minority but not that hard to fix.
well. Why introduce additional complexity? IMHO it's more than
sufficient to keep one goal, but when the user declares the
archetype
id on the command line, don't show a list but use the information
provided by the user.
Milos
Milos
On Feb 12, 2008 4:30 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
We can create a new goal name, whatever it be, and mimic the old
behavior.
The archetypes don't need to reside in central. I've been taking
the
list off the Wiki and turning it into the internal catalog. We
can
keep the list itself in that case for the command line. For the
Eclipse use case we can read the internal catalog, or the Nexus
index
source which does require the Archetypes to be in central. And
what's
the problem with that in your case if you're syncing to central.
At any rate, we can fix that goal and mimic the new behavior.
Might
be
good to try and raise these things when we've asked repeatedly
for
people to try it. Most people seem to hate that notation below
so I
asked Raphael to make the batch mode non-default and provide the
list.
On 12-Feb-08, at 7:02 AM, Daniel Kulp wrote:
The new archetype plugin seems to have broken the normal
instructions on
how to create new projects. It doesn't seem to work.
For example, according to:
http://cwiki.apache.org/confluence/display/CAMEL/Creating+a+new+Spring+based+Camel+Route
I should just need to run:
mvn archetype:create \
-DarchetypeGroupId=org.apache.camel \
-DarchetypeArtifactId=camel-router \
-DarchetypeVersion=1.1.0 \
-DgroupId=myGroupId \
-DartifactId=myArtifactId
That worked last week. Now I get a big list of archetypes to
select
from and the camel stuff isn't there.
So, how the heck is this now supposed to work? If projects
have
archetypes in central, how are users supposed to use them? I
really
think we need to get a new version out that allows the previous
instructions to work. This really breaks a BUNCH of projects
instructions for creating samples/projects.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more
it
will
elude you, but if you turn your attention to other things, it
will
come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A language that doesn't affect the way you think about programming
is
not worth knowing.
-— Alan Perlis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
