You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/06/17 17:52:38 UTC
Practice of releasing small changes before incorporation into a build
If you're working on a fix that requires a specific fix and is not
something that is in ongoing, high-flux development then can people
release first and then incorporate.
Two example of late are plexus-utils in trunk, and the Maven parent POM.
Snapshots are for intra-project, high-flux development. Having them
as external dependencies is not good. We either have to change
repository settings around which sucks, or things are very well
tested. For the Maven parent POM I can't use it in the branch because
it's not released, and it causes a CCE in the remote-resources plugin
(Kulp, you may want to look at that, it's a CCE between and
ArtifactRepository and org.apache.maven.model.Repository).
I don't think there's any problem with pushing out tons of micro
releases and just makes things far more stable (and releasable).
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Brett Porter <br...@apache.org>.
On 18/06/2007, at 11:48 AM, Daniel Kulp wrote:
> On Sunday 17 June 2007 19:24, Brett Porter wrote:
>> I was going to take care of that very shortly, but wanted to make
>> sure it was at least correct first. Using v5 was not - the gpg plugin
>> that was included did not work with the assemblies (as you can see
>> from your staging repository: http://people.apache.org/~jvanzyl/
>> maven-2.0.7-staging-repository/org/apache/maven/maven/2.0.7/ - the
>> signatures are all missing -src).
>
> I believe this is fixed in the latest SNAPSHOT of GPG. I just
> haven't
> had the time to clean up remaining issues and get it released. :-(
No, it's fixed in the alpha-3 release - it worked just great for me
which is why I wanted to update to it across the board.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 17 June 2007 19:24, Brett Porter wrote:
> I was going to take care of that very shortly, but wanted to make
> sure it was at least correct first. Using v5 was not - the gpg plugin
> that was included did not work with the assemblies (as you can see
> from your staging repository: http://people.apache.org/~jvanzyl/
> maven-2.0.7-staging-repository/org/apache/maven/maven/2.0.7/ - the
> signatures are all missing -src).
I believe this is fixed in the latest SNAPSHOT of GPG. I just haven't
had the time to clean up remaining issues and get it released. :-(
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)
Posted by Brett Porter <br...@apache.org>.
Yeah, I hadn't made it to my second cup of coffee so I didn't
remember we had the @aggregator tag for this purpose, so using
assembly:attached *should* work for this purpose. But I don't think
it properly draws in the modules so it's purely an assembly plugin
feature.
- Brett
On 18/06/2007, at 11:51 AM, Wendy Smoak wrote:
> On 6/17/07, Brett Porter <br...@apache.org> wrote:
>
>> I remember pushing for assemblies at the root in the past, but later
>> agreeing it wasn't best practice because of the lifecycle
>> inconsistency (the root project must be first in the reactor to
>> install the pom, but must be last in the reactor if it is producing
>> an assembly that aggregates built content).
>
> I've never been successful with an assembly at the root because I've
> always had to jump through hoops to get the right dependencies and
> versions into the -bin assembly.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)
Posted by Wendy Smoak <ws...@gmail.com>.
On 6/17/07, Brett Porter <br...@apache.org> wrote:
> I remember pushing for assemblies at the root in the past, but later
> agreeing it wasn't best practice because of the lifecycle
> inconsistency (the root project must be first in the reactor to
> install the pom, but must be last in the reactor if it is producing
> an assembly that aggregates built content).
I've never been successful with an assembly at the root because I've
always had to jump through hoops to get the right dependencies and
versions into the -bin assembly.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: assembly best practices (was: Practice of releasing small changes before incorporation into a build)
Posted by Brett Porter <br...@apache.org>.
On 18/06/2007, at 11:33 AM, Jason van Zyl wrote:
>
> I think we also have to deal with the asymmetry in that we make the
> source assembly from the root, and then do weird wiggling. In Maven
> I think we should have the assemblies at the top-level but this
> leads other problems with the assembly plugin. Allowing the
> assembly plugin to attach with a different artifactId is what is
> done in the shade plugin and I think it's a valid use but in this
> case I think it's a work around. Or we simply call the module that
> contains the assembly be named what the assembly is to be named.
> Still pondering.
I remember pushing for assemblies at the root in the past, but later
agreeing it wasn't best practice because of the lifecycle
inconsistency (the root project must be first in the reactor to
install the pom, but must be last in the reactor if it is producing
an assembly that aggregates built content).
I very much like using the root as an aggregation point (it's the
only sensible way to make a source assembly, and it would certainly
be better to have the binary assembly in the same place).
So it seems like:
- current best practice is to aggregate using dependencies under a
module
- suggested best practice is to aggregate at root, and so this must
be added to the architectural goals
A possible way to achieve this is to execute the lifecycle *both*
before and after modules in a project that has them, binding
differently each time and be able to configure which (default to
before as is the case now, but add a flag to bind new plugins after-
modules). This needs a lot more thought, just throwing it out there
for starters.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Jun 07, at 5:59 PM 17 Jun 07, Brett Porter wrote:
>
> On 18/06/2007, at 10:28 AM, Jason van Zyl wrote:
>
>>
>> It won't work on the assemblies anyway because that's not the name
>> we use for distribution so the signatures would not be correct.
>> They have to be taken as they are built with the final name and
>> those are signed. Something I need to bring up as a best practice
>> discussion. They way we do things currently we cannot do a release
>> from end to end. The assembly we make are "maven-core" or "maven-
>> embedder" when they are deployed to the repository. The module
>> making the assembly must be named "maven" if we want it to work.
>> Or we need to be able to make the assembly from the top-level
>> directory like we do for the source assembly.
>
> The name isn't baked into the signature, so as long as you rename
> them both, it should be fine.
>
> That said, I'm happy to open the other point up for discussion
> anyway. The best practice there might be to allow the assembly
> plugin to produce something with a different artifactId to attach
> (ie, build in maven-core, assign to the same place as the source
> bundle).
>
I think we also have to deal with the asymmetry in that we make the
source assembly from the root, and then do weird wiggling. In Maven I
think we should have the assemblies at the top-level but this leads
other problems with the assembly plugin. Allowing the assembly plugin
to attach with a different artifactId is what is done in the shade
plugin and I think it's a valid use but in this case I think it's a
work around. Or we simply call the module that contains the assembly
be named what the assembly is to be named. Still pondering.
>>
>> There is something wrong with the remote resources plugin as
>> specified in the parent POM. It passes in
>> org.apache.maven.model.Repository to the artifact resolution
>> mechanism when it expects an ArtifactRepository which leads to a
>> CCE. So it's not ready to go out yet.
>
> Ok, I misunderstood - I thought the rem. res. plugin freaked out
> because of the snapshot parent, not because of the new version.
> I'll downgrade it to the previous one.
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Brett Porter <br...@apache.org>.
On 18/06/2007, at 10:28 AM, Jason van Zyl wrote:
>
> It won't work on the assemblies anyway because that's not the name
> we use for distribution so the signatures would not be correct.
> They have to be taken as they are built with the final name and
> those are signed. Something I need to bring up as a best practice
> discussion. They way we do things currently we cannot do a release
> from end to end. The assembly we make are "maven-core" or "maven-
> embedder" when they are deployed to the repository. The module
> making the assembly must be named "maven" if we want it to work. Or
> we need to be able to make the assembly from the top-level
> directory like we do for the source assembly.
The name isn't baked into the signature, so as long as you rename
them both, it should be fine.
That said, I'm happy to open the other point up for discussion
anyway. The best practice there might be to allow the assembly plugin
to produce something with a different artifactId to attach (ie, build
in maven-core, assign to the same place as the source bundle).
>
> There is something wrong with the remote resources plugin as
> specified in the parent POM. It passes in
> org.apache.maven.model.Repository to the artifact resolution
> mechanism when it expects an ArtifactRepository which leads to a
> CCE. So it's not ready to go out yet.
Ok, I misunderstood - I thought the rem. res. plugin freaked out
because of the snapshot parent, not because of the new version. I'll
downgrade it to the previous one.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 18 June 2007 12:41, Brett Porter wrote:
> On 19/06/2007, at 2:35 AM, Daniel Kulp wrote:
> > 1) The project name is officially "Apache Maven", not "Maven". The
> > downloads and such should reflect that. (as should the READMEs,
> > the web
> > site, etc....)
>
> Yes, I agree with that. Sorry, I thought you were suggesting it for
> all artifact IDs, which would be a bit much.
Oh. God no. Definitely a bit much. :-) There are a few people
that think every jar and pom and everything needs to
be "apache-foo.jar", but to me, that just makes classpath length issues
even more of an issue for no real benifit. Apache is in the groupId
already.
However, in CXF, we name the artifact that builds the distribution (we
don't do this from the top level pom due to some of the same issues
Wendy talked about) "apache-cxf" so the files the assembly creates
are "apache-cxf-${versions}.tar.gz" and they get properly GPG signed as
such. Basically, upon deploy, the org/apache/cxf/apache-cxf/VERSION
directory can just about be copied as is to the distribution download
area. No need to resign anything, rename anything, etc... For the
most part, I'm completely lazy. If I can have maven do the work for
me, great. :-)
> I'm in favour of changing the distribution filename in future
> releases (but don't see it as required for this one).
Agreed.
Dan
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Brett Porter <br...@apache.org>.
On 19/06/2007, at 2:35 AM, Daniel Kulp wrote:
> On Sunday 17 June 2007 21:51, Brett Porter wrote:
>> On 18/06/2007, at 11:46 AM, Daniel Kulp wrote:
>>> Technically, if you follow all the latest legal discussions and
>>> stuff, the name of the tgz/zip should be "apache-maven-2.0.7" which
>>> would allow
>>> to use an artifactId of apache-maven. We just changed over to
>>> that format for CXF. That way the signatures are all OK as is.
>>> (The directory it extracts to should also be apache-maven)
>>
>> Do you have a pointer to the specific message-id or policy document
>> for this? I thought I followed that discussion and it was not seen as
>> a requirement.
>>
>> I can't see why it would be legally required.
>
> There are two "reasons" that come up with these discussions:
>
> 1) The project name is officially "Apache Maven", not "Maven". The
> downloads and such should reflect that. (as should the READMEs,
> the web
> site, etc....)
Yes, I agree with that. Sorry, I thought you were suggesting it for
all artifact IDs, which would be a bit much.
I'm in favour of changing the distribution filename in future
releases (but don't see it as required for this one).
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 17 June 2007 21:51, Brett Porter wrote:
> On 18/06/2007, at 11:46 AM, Daniel Kulp wrote:
> > Technically, if you follow all the latest legal discussions and
> > stuff, the name of the tgz/zip should be "apache-maven-2.0.7" which
> > would allow
> > to use an artifactId of apache-maven. We just changed over to
> > that format for CXF. That way the signatures are all OK as is.
> > (The directory it extracts to should also be apache-maven)
>
> Do you have a pointer to the specific message-id or policy document
> for this? I thought I followed that discussion and it was not seen as
> a requirement.
>
> I can't see why it would be legally required.
There are two "reasons" that come up with these discussions:
1) The project name is officially "Apache Maven", not "Maven". The
downloads and such should reflect that. (as should the READMEs, the web
site, etc....)
2) Trademark protection - by using "apache-maven-###.tar.gz" or whatever,
you know you are getting the real Apache version. If some other
company releases a version of Maven that is
named "apache-maven-###.tar.gz" and we don't like it (example: they add
some stuff into it that we consider a hack or makes it incompatible), we
can go after them for trademark infringement/dilution. With it being
Apache licensed, the company can release their version with their
changes, but they cannot call it "Apache Maven", only we can.
I'm not sure if anyone made it official policy, but whenever anyone in
the incubator tries to do a release without following that, the
incubator folks complain about it. I personally didn't care one way or
another so for CXF we just kind of decided to avoid the whole thing and
follow the recommendation.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Carlos Sanchez <ca...@apache.org>.
On 6/17/07, Brett Porter <br...@apache.org> wrote:
>
> On 18/06/2007, at 11:46 AM, Daniel Kulp wrote:
>
> > Technically, if you follow all the latest legal discussions and stuff,
> > the name of the tgz/zip should be "apache-maven-2.0.7" which would
> > allow
> > to use an artifactId of apache-maven. We just changed over to that
> > format for CXF. That way the signatures are all OK as is. (The
> > directory it extracts to should also be apache-maven)
>
> Do you have a pointer to the specific message-id or policy document
> for this? I thought I followed that discussion and it was not seen as
> a requirement.
>
> I can't see why it would be legally required.
I remember that discussion but not if there was a decision. However i
remember that using groupId+artifactId would be ok for legal so the
word apache is in the assembly
>
> >
> > That's a new one. A bunch of use have been using the RR plugin
> > without
> > that error. That said, I think the maven parent is still locking
> > down
> > to a relatively old version which had a bunch of other issues with
> > NPE's
> > and such when there are SNAPSHOTS. Have you tried with one of the
> > newer versions of RR?
>
> You're right, it's pinned to alpha-2 but 5 is out.
>
> Jason - how do I reproduce the error if I want to check it?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
Posted by Jason van Zyl <ja...@maven.org>.
On 18 Jun 07, at 11:19 PM 18 Jun 07, Brett Porter wrote:
> I wasn't able to reproduce the problem. I think I'll just update
> the parent to alpha-5, check again, then call the release tomorrow.
>
When you update I'll try again as well.
> - Brett
>
> On 19/06/2007, at 11:39 AM, Jason van Zyl wrote:
>
>>
>> On 18 Jun 07, at 5:57 PM 18 Jun 07, Brett Porter wrote:
>>
>>> Jason,
>>>
>>> How did you experience this problem with the RR plugin so I can
>>> verify it is fixed in a later version?
>>>
>>
>> Try building the embedder module in trunk. That's where it failed
>> for me.
>>
>>> - Brett
>>>
>>> On 18/06/2007, at 11:51 AM, Brett Porter wrote:
>>>
>>>>
>>>> You're right, it's pinned to alpha-2 but 5 is out.
>>>>
>>>> Jason - how do I reproduce the error if I want to check it?
>>>>
>>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
Posted by Brett Porter <br...@apache.org>.
I wasn't able to reproduce the problem. I think I'll just update the
parent to alpha-5, check again, then call the release tomorrow.
- Brett
On 19/06/2007, at 11:39 AM, Jason van Zyl wrote:
>
> On 18 Jun 07, at 5:57 PM 18 Jun 07, Brett Porter wrote:
>
>> Jason,
>>
>> How did you experience this problem with the RR plugin so I can
>> verify it is fixed in a later version?
>>
>
> Try building the embedder module in trunk. That's where it failed
> for me.
>
>> - Brett
>>
>> On 18/06/2007, at 11:51 AM, Brett Porter wrote:
>>
>>>
>>> You're right, it's pinned to alpha-2 but 5 is out.
>>>
>>> Jason - how do I reproduce the error if I want to check it?
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
Posted by Jason van Zyl <ja...@maven.org>.
On 18 Jun 07, at 5:57 PM 18 Jun 07, Brett Porter wrote:
> Jason,
>
> How did you experience this problem with the RR plugin so I can
> verify it is fixed in a later version?
>
Try building the embedder module in trunk. That's where it failed for
me.
> - Brett
>
> On 18/06/2007, at 11:51 AM, Brett Porter wrote:
>
>>
>> You're right, it's pinned to alpha-2 but 5 is out.
>>
>> Jason - how do I reproduce the error if I want to check it?
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: remote resource problem (was: Practice of releasing small changes before incorporation into a build)
Posted by Brett Porter <br...@apache.org>.
Jason,
How did you experience this problem with the RR plugin so I can
verify it is fixed in a later version?
- Brett
On 18/06/2007, at 11:51 AM, Brett Porter wrote:
>
> You're right, it's pinned to alpha-2 but 5 is out.
>
> Jason - how do I reproduce the error if I want to check it?
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Brett Porter <br...@apache.org>.
On 18/06/2007, at 11:46 AM, Daniel Kulp wrote:
> Technically, if you follow all the latest legal discussions and stuff,
> the name of the tgz/zip should be "apache-maven-2.0.7" which would
> allow
> to use an artifactId of apache-maven. We just changed over to that
> format for CXF. That way the signatures are all OK as is. (The
> directory it extracts to should also be apache-maven)
Do you have a pointer to the specific message-id or policy document
for this? I thought I followed that discussion and it was not seen as
a requirement.
I can't see why it would be legally required.
>
> That's a new one. A bunch of use have been using the RR plugin
> without
> that error. That said, I think the maven parent is still locking
> down
> to a relatively old version which had a bunch of other issues with
> NPE's
> and such when there are SNAPSHOTS. Have you tried with one of the
> newer versions of RR?
You're right, it's pinned to alpha-2 but 5 is out.
Jason - how do I reproduce the error if I want to check it?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Daniel Kulp <dk...@apache.org>.
On Sunday 17 June 2007 20:28, Jason van Zyl wrote:
> It won't work on the assemblies anyway because that's not the name we
> use for distribution so the signatures would not be correct. They
> have to be taken as they are built with the final name and those are
> signed. Something I need to bring up as a best practice discussion.
> They way we do things currently we cannot do a release from end to
> end. The assembly we make are "maven-core" or "maven-embedder" when
> they are deployed to the repository. The module making the assembly
> must be named "maven" if we want it to work. Or we need to be able to
> make the assembly from the top-level directory like we do for the
> source assembly.
Technically, if you follow all the latest legal discussions and stuff,
the name of the tgz/zip should be "apache-maven-2.0.7" which would allow
to use an artifactId of apache-maven. We just changed over to that
format for CXF. That way the signatures are all OK as is. (The
directory it extracts to should also be apache-maven)
> > As I understood it, you weren't going to do anything from the
> > branch again. If I'd known that, I'd have suggested you stage and
> > release the parent too.
> >
> > I'll call a vote on it today.
>
> There is something wrong with the remote resources plugin as
> specified in the parent POM. It passes in
> org.apache.maven.model.Repository to the artifact resolution
> mechanism when it expects an ArtifactRepository which leads to a CCE.
> So it's not ready to go out yet.
That's a new one. A bunch of use have been using the RR plugin without
that error. That said, I think the maven parent is still locking down
to a relatively old version which had a bunch of other issues with NPE's
and such when there are SNAPSHOTS. Have you tried with one of the
newer versions of RR?
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Jason van Zyl <ja...@maven.org>.
On 17 Jun 07, at 4:24 PM 17 Jun 07, Brett Porter wrote:
>
> On 18/06/2007, at 1:52 AM, Jason van Zyl wrote:
>
>> If you're working on a fix that requires a specific fix and is not
>> something that is in ongoing, high-flux development then can
>> people release first and then incorporate.
>>
>> Two example of late are plexus-utils in trunk, and the Maven
>> parent POM.
>>
>> Snapshots are for intra-project, high-flux development. Having
>> them as external dependencies is not good. We either have to
>> change repository settings around which sucks, or things are very
>> well tested. For the Maven parent POM I can't use it in the branch
>> because it's not released, and it causes a CCE in the remote-
>> resources plugin (Kulp, you may want to look at that, it's a CCE
>> between and ArtifactRepository and
>> org.apache.maven.model.Repository).
>>
>> I don't think there's any problem with pushing out tons of micro
>> releases and just makes things far more stable (and releasable).
>
> I was going to take care of that very shortly, but wanted to make
> sure it was at least correct first. Using v5 was not - the gpg
> plugin that was included did not work with the assemblies (as you
> can see from your staging repository: http://people.apache.org/
> ~jvanzyl/maven-2.0.7-staging-repository/org/apache/maven/maven/
> 2.0.7/ - the signatures are all missing -src).
>
It won't work on the assemblies anyway because that's not the name we
use for distribution so the signatures would not be correct. They
have to be taken as they are built with the final name and those are
signed. Something I need to bring up as a best practice discussion.
They way we do things currently we cannot do a release from end to
end. The assembly we make are "maven-core" or "maven-embedder" when
they are deployed to the repository. The module making the assembly
must be named "maven" if we want it to work. Or we need to be able to
make the assembly from the top-level directory like we do for the
source assembly.
> As I understood it, you weren't going to do anything from the
> branch again. If I'd known that, I'd have suggested you stage and
> release the parent too.
>
> I'll call a vote on it today.
>
There is something wrong with the remote resources plugin as
specified in the parent POM. It passes in
org.apache.maven.model.Repository to the artifact resolution
mechanism when it expects an ArtifactRepository which leads to a CCE.
So it's not ready to go out yet.
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Practice of releasing small changes before incorporation into a build
Posted by Brett Porter <br...@apache.org>.
On 18/06/2007, at 1:52 AM, Jason van Zyl wrote:
> If you're working on a fix that requires a specific fix and is not
> something that is in ongoing, high-flux development then can people
> release first and then incorporate.
>
> Two example of late are plexus-utils in trunk, and the Maven parent
> POM.
>
> Snapshots are for intra-project, high-flux development. Having them
> as external dependencies is not good. We either have to change
> repository settings around which sucks, or things are very well
> tested. For the Maven parent POM I can't use it in the branch
> because it's not released, and it causes a CCE in the remote-
> resources plugin (Kulp, you may want to look at that, it's a CCE
> between and ArtifactRepository and org.apache.maven.model.Repository).
>
> I don't think there's any problem with pushing out tons of micro
> releases and just makes things far more stable (and releasable).
I was going to take care of that very shortly, but wanted to make
sure it was at least correct first. Using v5 was not - the gpg plugin
that was included did not work with the assemblies (as you can see
from your staging repository: http://people.apache.org/~jvanzyl/
maven-2.0.7-staging-repository/org/apache/maven/maven/2.0.7/ - the
signatures are all missing -src).
As I understood it, you weren't going to do anything from the branch
again. If I'd known that, I'd have suggested you stage and release
the parent too.
I'll call a vote on it today.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org