You are viewing a plain text version of this content. The canonical link for it is here.
Posted to m2-dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2004/09/22 07:00:32 UTC
setting jar:install on its head
I've been mulling a conversation I had awhile back with Trygve for the
past several days, and I'm wondering if it's time for a big change in
maven-2.
At the time, I had made a change to plexus and simply bumped the version
from 0.16 to 0.17, and published. Most of you can no doubt spot the
problem with what I just said...I didn't know that this change was
release-worthy, I only wanted to distinguish it from plexus-0.16.
To be more explicit, Trygve rightly pointed out to me that the version
in the POM should ALWAYS be a -SNAPSHOT unless/until we're ready for a
release. So, it got me thinking:
Why do we do things like:
m2 jar:install-snapshot
?
Wouldn't it make more sense to make the default state of any build to
produce a -SNAPSHOT artifact, and then provide goals like
"jar:install-release"? Then, we could code a general-case release
procedure into a maven plugin, and perform {site updates, email
announcements, artifact upload, distro production, etc.} into a single
operation:
m2 install-release
or somesuch...
Anyway, in the spirit of "making the right thing easy, and all the wrong
things hard" shouldn't we emphasize that most builds should in fact
produce a snapshot?
Something to chew on.
-j
Re: setting jar:install on its head
Posted by Brett Porter <br...@apache.org>.
John,
I agree. But last time I suggested this, I got shot down :) I think I was taking
a more extreme tack which diluted the issue, or proposing something rather
hair-brained as I tend to do, when a simpler solution exists.
I'll dig up the thread and summarise: I don't remember if we came to a
conclusion or if the thread just died off.
Cheers,
Brett
Quoting John Casey <jd...@commonjava.org>:
> I've been mulling a conversation I had awhile back with Trygve for the
> past several days, and I'm wondering if it's time for a big change in
> maven-2.
>
> At the time, I had made a change to plexus and simply bumped the version
> from 0.16 to 0.17, and published. Most of you can no doubt spot the
> problem with what I just said...I didn't know that this change was
> release-worthy, I only wanted to distinguish it from plexus-0.16.
>
> To be more explicit, Trygve rightly pointed out to me that the version
> in the POM should ALWAYS be a -SNAPSHOT unless/until we're ready for a
> release. So, it got me thinking:
>
> Why do we do things like:
>
> m2 jar:install-snapshot
>
> ?
>
> Wouldn't it make more sense to make the default state of any build to
> produce a -SNAPSHOT artifact, and then provide goals like
> "jar:install-release"? Then, we could code a general-case release
> procedure into a maven plugin, and perform {site updates, email
> announcements, artifact upload, distro production, etc.} into a single
> operation:
>
> m2 install-release
>
> or somesuch...
>
> Anyway, in the spirit of "making the right thing easy, and all the wrong
> things hard" shouldn't we emphasize that most builds should in fact
> produce a snapshot?
>
> Something to chew on.
>
> -j
>
Re: setting jar:install on its head
Posted by Brett Porter <br...@apache.org>.
Trygve Laugstøl wrote:
>On Wed, Sep 22, 2004 at 08:22:35PM +1000, Brett Porter wrote:
>
>
>>I think this is a good idea. This is essentially what I built for m1
>>with scm:prepare-release, and can be managed just as easily with a GUI tool.
>>We can also use this goal to do timestamped releases (change 2 to set to
>>timestamp, change 6 to set back to old version, and skip commit steps 4, 7).
>>There is no concept of snapshot right now, so this is the right time to
>>change it. I'd be more than happy to backport this to m1 to get people
>>used to it as well.
>>
>>
>
>Yeah, I forgot to say that you already had this stuff in m1, didn't mean
>to steal your idea. I'd really like to make maven a bigger part of all
>aspects of the development cycle including better support for cutting
>releases like this.
>
>
>
Haha... yes, well I'll leave that to my lawyers... I've just got a
patent on releasing software packages and am going to make a killing :)
I certainly think this is in Maven's realm.
Cheers,
Brett
Re: setting jar:install on its head
Posted by Brett Porter <br...@apache.org>.
The problem is that the user, being used to using these goals, forgets to check
the state of the POM, and accidentally builds a modified JAR as the previous
release. Even worse when they deploy it.
These sorts of accidents are easy to do . I think John can vouch for this in
regards to plexus-0.17 :)
I agree with both you and John - it needs to be simple, especially for regular
development, but releases should be more tightly controlled. trygvis step-wise
points covers this, as long as you have some sort of version control, follow its
best practices and are happy to commit the POM twice every release.
Cheers,
Brett
Quoting Michal Maczka <mm...@interia.pl>:
> John Casey wrote:
>
> > [...]
> >
> > I guess I'm just trying to say that goals should assume their
> > manipulating snapshotted data (producing snapshot artifacts, etc.)
> > unless we explicitly specify otherwise. I think we all agree that's
> > how development should take place, and it would be easy enough in
> > maven to encourage this best practice.
>
> I think that the rule should be even simpler then that: goals should
> assume nothing - just look at the state which is kept in POM.
>
> I even think that m2 install goal should be able to run reactor (e.g.
> when project type is set to "multiproject") and reactor really should be
> built-in into core and visible for the plugins and plugins should be
> able to work in two modes: normal and multiproroject.
> So when I type "m2 site" for project of type multiproject something else
> happen then "m2 site" for normal project.
> This will really make things simple for users which will have to
> memorize 4-5 goals and never care about the situational context
> in which given goal works.
>
>
> michal
>
> ----------------------------------------------------------------------
> Startuj z INTERIA.PL... >>> http://link.interia.pl/f1834
>
>
Re: setting jar:install on its head
Posted by Michal Maczka <mm...@interia.pl>.
John Casey wrote:
> [...]
>
> I guess I'm just trying to say that goals should assume their
> manipulating snapshotted data (producing snapshot artifacts, etc.)
> unless we explicitly specify otherwise. I think we all agree that's
> how development should take place, and it would be easy enough in
> maven to encourage this best practice.
I think that the rule should be even simpler then that: goals should
assume nothing - just look at the state which is kept in POM.
I even think that m2 install goal should be able to run reactor (e.g.
when project type is set to "multiproject") and reactor really should be
built-in into core and visible for the plugins and plugins should be
able to work in two modes: normal and multiproroject.
So when I type "m2 site" for project of type multiproject something else
happen then "m2 site" for normal project.
This will really make things simple for users which will have to
memorize 4-5 goals and never care about the situational context
in which given goal works.
michal
----------------------------------------------------------------------
Startuj z INTERIA.PL... >>> http://link.interia.pl/f1834
Re: setting jar:install on its head
Posted by John Casey <jd...@commonjava.org>.
Trygve Laugst�l wrote:
> On Wed, Sep 22, 2004 at 08:22:35PM +1000, Brett Porter wrote:
>
>>I think this is a good idea. This is essentially what I built for m1
>>with scm:prepare-release, and can be managed just as easily with a GUI tool.
>>We can also use this goal to do timestamped releases (change 2 to set to
>>timestamp, change 6 to set back to old version, and skip commit steps 4, 7).
>>There is no concept of snapshot right now, so this is the right time to
>>change it. I'd be more than happy to backport this to m1 to get people
>>used to it as well.
>
>
> Yeah, I forgot to say that you already had this stuff in m1, didn't mean
> to steal your idea. I'd really like to make maven a bigger part of all
> aspects of the development cycle including better support for cutting
> releases like this.
>
I guess what I'm really getting at is that I'd like to see the
operations like:
jar:jar
jar:install
...
produce a timestamped, or serial-numbered artifact - a snapshot. These
are the most commonly used goals, and represent the day-to-day usage of
maven. I'd like to see the production of a NON-snapshot (no serial
number, no timestamp) version ONLY when I go out of my way to do it:
jar:install-release
jar:deploy-release
...
Basically, compare this to the old way of "normally" doing:
jar:jar
jar:install
jar:deploy
which produces a release version (unless the POM specifies -SNAPSHOT, in
which case you get a non-timestamped "snapshot" that is basically
useless). You then had to go to extra effort to produce a "real" snapshot:
jar:snapshot
jar:install-snapshot
jar:deploy-snapshot
I guess I'm just trying to say that goals should assume their
manipulating snapshotted data (producing snapshot artifacts, etc.)
unless we explicitly specify otherwise. I think we all agree that's how
development should take place, and it would be easy enough in maven to
encourage this best practice.
I didn't mean to muddy the waters with a scm:release conversation. ;)
-john
Re: setting jar:install on its head
Posted by Trygve Laugstøl <tr...@student.matnat.uio.no>.
On Wed, Sep 22, 2004 at 08:22:35PM +1000, Brett Porter wrote:
> I think this is a good idea. This is essentially what I built for m1
> with scm:prepare-release, and can be managed just as easily with a GUI tool.
> We can also use this goal to do timestamped releases (change 2 to set to
> timestamp, change 6 to set back to old version, and skip commit steps 4, 7).
> There is no concept of snapshot right now, so this is the right time to
> change it. I'd be more than happy to backport this to m1 to get people
> used to it as well.
Yeah, I forgot to say that you already had this stuff in m1, didn't mean
to steal your idea. I'd really like to make maven a bigger part of all
aspects of the development cycle including better support for cutting
releases like this.
--
Trygve
>
> - Brett
>
> Trygve Laugstøl wrote:
>
> >On Wed, Sep 22, 2004 at 01:00:32AM -0400, John Casey wrote:
> >
> >
> >>I've been mulling a conversation I had awhile back with Trygve for the
> >>past several days, and I'm wondering if it's time for a big change in
> >>maven-2.
> >>
> >>At the time, I had made a change to plexus and simply bumped the version
> >>from 0.16 to 0.17, and published. Most of you can no doubt spot the
> >>problem with what I just said...I didn't know that this change was
> >>release-worthy, I only wanted to distinguish it from plexus-0.16.
> >>
> >>To be more explicit, Trygve rightly pointed out to me that the version
> >>in the POM should ALWAYS be a -SNAPSHOT unless/until we're ready for a
> >>release. So, it got me thinking:
> >>
> >>
> >
> >A argument pro having -SNAPSHOT in the <version> is that then all
> >information about the artifact is in the pom. Remember that the pom will
> >be much more visible in maven 2 as it will always accompany the artifact.
> >
> >For stuff like Continuum (and all other automated processes) it's really
> >useful to have a single place to look for metadata.
> >
> >One alternative to "jar:install-snapshot" is to have "release:release"
> >which will
> >
> >1: Do a clean co
> >2: Change the pom (remove -SNAPSHOT)
> >3: Build the artifact
> >4: Commit the new pom (without -SNAPSHOT)
> >5: Make a tag in the scm
> >6: Change the pom (bump the version, add -SNAPSHOT again)
> >7: Commit the new pom (with -SNAPSHOT)
> >8: Deploy the artifact
> >
> >We can even get fancy here and to this over a set of artifacts.
> >
> >--
> >Trygve
> >
> >
> >
> >>Why do we do things like:
> >>
> >>m2 jar:install-snapshot
> >>
> >>?
> >>
> >>Wouldn't it make more sense to make the default state of any build to
> >>produce a -SNAPSHOT artifact, and then provide goals like
> >>"jar:install-release"? Then, we could code a general-case release
> >>procedure into a maven plugin, and perform {site updates, email
> >>announcements, artifact upload, distro production, etc.} into a single
> >>operation:
> >>
> >>m2 install-release
> >>
> >>or somesuch...
> >>
> >>Anyway, in the spirit of "making the right thing easy, and all the wrong
> >>things hard" shouldn't we emphasize that most builds should in fact
> >>produce a snapshot?
> >>
> >>Something to chew on.
> >>
> >>-j
> >>
> >>
> >
> >
> >
> >>begin:vcard
> >>fn:John Casey
> >>n:Casey;John
> >>email;internet:jdcasey@commonjava.org
> >>x-mozilla-html:FALSE
> >>version:2.1
> >>end:vcard
> >>
> >>
> >>
> >
> >
> >
>
>
Re: setting jar:install on its head
Posted by Brett Porter <br...@apache.org>.
I think this is a good idea. This is essentially what I built for m1
with scm:prepare-release, and can be managed just as easily with a GUI tool.
We can also use this goal to do timestamped releases (change 2 to set to
timestamp, change 6 to set back to old version, and skip commit steps 4, 7).
There is no concept of snapshot right now, so this is the right time to
change it. I'd be more than happy to backport this to m1 to get people
used to it as well.
- Brett
Trygve Laugstøl wrote:
>On Wed, Sep 22, 2004 at 01:00:32AM -0400, John Casey wrote:
>
>
>>I've been mulling a conversation I had awhile back with Trygve for the
>>past several days, and I'm wondering if it's time for a big change in
>>maven-2.
>>
>>At the time, I had made a change to plexus and simply bumped the version
>>from 0.16 to 0.17, and published. Most of you can no doubt spot the
>>problem with what I just said...I didn't know that this change was
>>release-worthy, I only wanted to distinguish it from plexus-0.16.
>>
>>To be more explicit, Trygve rightly pointed out to me that the version
>>in the POM should ALWAYS be a -SNAPSHOT unless/until we're ready for a
>>release. So, it got me thinking:
>>
>>
>
>A argument pro having -SNAPSHOT in the <version> is that then all
>information about the artifact is in the pom. Remember that the pom will
>be much more visible in maven 2 as it will always accompany the artifact.
>
>For stuff like Continuum (and all other automated processes) it's really
>useful to have a single place to look for metadata.
>
>One alternative to "jar:install-snapshot" is to have "release:release"
>which will
>
> 1: Do a clean co
> 2: Change the pom (remove -SNAPSHOT)
> 3: Build the artifact
> 4: Commit the new pom (without -SNAPSHOT)
> 5: Make a tag in the scm
> 6: Change the pom (bump the version, add -SNAPSHOT again)
> 7: Commit the new pom (with -SNAPSHOT)
> 8: Deploy the artifact
>
>We can even get fancy here and to this over a set of artifacts.
>
>--
>Trygve
>
>
>
>>Why do we do things like:
>>
>>m2 jar:install-snapshot
>>
>>?
>>
>>Wouldn't it make more sense to make the default state of any build to
>>produce a -SNAPSHOT artifact, and then provide goals like
>>"jar:install-release"? Then, we could code a general-case release
>>procedure into a maven plugin, and perform {site updates, email
>>announcements, artifact upload, distro production, etc.} into a single
>>operation:
>>
>>m2 install-release
>>
>>or somesuch...
>>
>>Anyway, in the spirit of "making the right thing easy, and all the wrong
>>things hard" shouldn't we emphasize that most builds should in fact
>>produce a snapshot?
>>
>>Something to chew on.
>>
>>-j
>>
>>
>
>
>
>>begin:vcard
>>fn:John Casey
>>n:Casey;John
>>email;internet:jdcasey@commonjava.org
>>x-mozilla-html:FALSE
>>version:2.1
>>end:vcard
>>
>>
>>
>
>
>
Re: setting jar:install on its head
Posted by Trygve Laugstøl <tr...@student.matnat.uio.no>.
On Wed, Sep 22, 2004 at 01:00:32AM -0400, John Casey wrote:
> I've been mulling a conversation I had awhile back with Trygve for the
> past several days, and I'm wondering if it's time for a big change in
> maven-2.
>
> At the time, I had made a change to plexus and simply bumped the version
> from 0.16 to 0.17, and published. Most of you can no doubt spot the
> problem with what I just said...I didn't know that this change was
> release-worthy, I only wanted to distinguish it from plexus-0.16.
>
> To be more explicit, Trygve rightly pointed out to me that the version
> in the POM should ALWAYS be a -SNAPSHOT unless/until we're ready for a
> release. So, it got me thinking:
A argument pro having -SNAPSHOT in the <version> is that then all
information about the artifact is in the pom. Remember that the pom will
be much more visible in maven 2 as it will always accompany the artifact.
For stuff like Continuum (and all other automated processes) it's really
useful to have a single place to look for metadata.
One alternative to "jar:install-snapshot" is to have "release:release"
which will
1: Do a clean co
2: Change the pom (remove -SNAPSHOT)
3: Build the artifact
4: Commit the new pom (without -SNAPSHOT)
5: Make a tag in the scm
6: Change the pom (bump the version, add -SNAPSHOT again)
7: Commit the new pom (with -SNAPSHOT)
8: Deploy the artifact
We can even get fancy here and to this over a set of artifacts.
--
Trygve
>
> Why do we do things like:
>
> m2 jar:install-snapshot
>
> ?
>
> Wouldn't it make more sense to make the default state of any build to
> produce a -SNAPSHOT artifact, and then provide goals like
> "jar:install-release"? Then, we could code a general-case release
> procedure into a maven plugin, and perform {site updates, email
> announcements, artifact upload, distro production, etc.} into a single
> operation:
>
> m2 install-release
>
> or somesuch...
>
> Anyway, in the spirit of "making the right thing easy, and all the wrong
> things hard" shouldn't we emphasize that most builds should in fact
> produce a snapshot?
>
> Something to chew on.
>
> -j
> begin:vcard
> fn:John Casey
> n:Casey;John
> email;internet:jdcasey@commonjava.org
> x-mozilla-html:FALSE
> version:2.1
> end:vcard
>