Why is distributionManagement inside the pom?

[Benson Margulies <bi...@gmail.com>]

I'd like to submit the concept that distributionManagement has
something in common with repositories. Here's the common event that
leads me to think about this:

1. Find a useful open source component.
2. Discover that it has a missing feature or a bug(let) that gets in
the way of what I want to do.
3. Submit to owner, meanwhile ...
4. Want to make release into my own infrastructure of fork while
waiting a long time for owner to absorb and release.

Step 4 has always felt to me like much too much work. If it's entirely
my infrastructure, I need to diddle with scm, distributionManagement,
url, and version. If I am actually making a public fork, then I've got
the groupId (and perhaps the package) to deal with. This case,
however, is outside of the scope of this message.

I've mulled over a maven-fork-plugin that would pom-edit for this
purpose, but I've also wondered about the subject line of this
message: should _all_ the information that concerns 'extrinsic'
infrastructure be factored in some way that makes all this trivial?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Why is distributionManagement inside the pom?

[Stephen Connolly <st...@gmail.com>]

mvn release:prepare release:perform -DpushChanges=false -DlocalCheckout=true

Will do what you want if working on a GIT repo

On Monday, 22 December 2014, Benson Margulies <bi...@gmail.com> wrote:

> What I always do is create a fork repo to maintain my fix and to
> release from. So Stephen's idea isn't ideal for me; I'd rather do pom
> surgery to change scm so I can use the release plugin.
>
>
> On Mon, Dec 22, 2014 at 9:34 AM, jieryn <jieryn@gmail.com <javascript:;>>
> wrote:
> > On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly
> > <stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >>
> >> mvn versions:set -DnewVersion=1.1-mycompany-01 && mvn clean javadoc:jar
> >> source:jar deploy -DaltDeploymentUrl=my-Id::default::my-url && mvn
> >> versions:revert
> >>
> >> Ok so it's a long command line, but really not that much work at the
> end of
> >> they day. I did it 4 times last month
> >
> > Which is why I keep it handy via a small bash function in my
> > environment. It's very easy grease for one-off type fixes to keep the
> > gears moving across large projects requiring many external plugins and
> > dependencies. We even have a dedicated Archiva repository for those
> > locally fixed third party hotfix deployments, so we can keep track and
> > manage them sanely.
> >
> > I think the only thing we are missing for this pattern is a
> > differential tracker for really slow (to release) upstream projects,
> > where our local fix has not been released, but other fixes are landing
> > there. It's too much work to do manually, maybe Jenkins has a hotfix
> > plugin where you can drop in a patch and have it keep track of
> > upstream and also manage the application of your local patch... hrm.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: Why is distributionManagement inside the pom?

[Benson Margulies <bi...@gmail.com>]

What I always do is create a fork repo to maintain my fix and to
release from. So Stephen's idea isn't ideal for me; I'd rather do pom
surgery to change scm so I can use the release plugin.


On Mon, Dec 22, 2014 at 9:34 AM, jieryn <ji...@gmail.com> wrote:
> On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>>
>> mvn versions:set -DnewVersion=1.1-mycompany-01 && mvn clean javadoc:jar
>> source:jar deploy -DaltDeploymentUrl=my-Id::default::my-url && mvn
>> versions:revert
>>
>> Ok so it's a long command line, but really not that much work at the end of
>> they day. I did it 4 times last month
>
> Which is why I keep it handy via a small bash function in my
> environment. It's very easy grease for one-off type fixes to keep the
> gears moving across large projects requiring many external plugins and
> dependencies. We even have a dedicated Archiva repository for those
> locally fixed third party hotfix deployments, so we can keep track and
> manage them sanely.
>
> I think the only thing we are missing for this pattern is a
> differential tracker for really slow (to release) upstream projects,
> where our local fix has not been released, but other fixes are landing
> there. It's too much work to do manually, maybe Jenkins has a hotfix
> plugin where you can drop in a patch and have it keep track of
> upstream and also manage the application of your local patch... hrm.
>
> ---------------------------------------------------------------------
> 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: Why is distributionManagement inside the pom?

[jieryn <ji...@gmail.com>]

On Sun, Dec 21, 2014 at 7:59 PM, Stephen Connolly
<st...@gmail.com> wrote:
>
> mvn versions:set -DnewVersion=1.1-mycompany-01 && mvn clean javadoc:jar
> source:jar deploy -DaltDeploymentUrl=my-Id::default::my-url && mvn
> versions:revert
>
> Ok so it's a long command line, but really not that much work at the end of
> they day. I did it 4 times last month

Which is why I keep it handy via a small bash function in my
environment. It's very easy grease for one-off type fixes to keep the
gears moving across large projects requiring many external plugins and
dependencies. We even have a dedicated Archiva repository for those
locally fixed third party hotfix deployments, so we can keep track and
manage them sanely.

I think the only thing we are missing for this pattern is a
differential tracker for really slow (to release) upstream projects,
where our local fix has not been released, but other fixes are landing
there. It's too much work to do manually, maybe Jenkins has a hotfix
plugin where you can drop in a patch and have it keep track of
upstream and also manage the application of your local patch... hrm.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Why is distributionManagement inside the pom?

[Stephen Connolly <st...@gmail.com>]

On Sunday, December 21, 2014, Benson Margulies <bi...@gmail.com>
wrote:

> I'd like to submit the concept that distributionManagement has
> something in common with repositories. Here's the common event that
> leads me to think about this:
>
> 1. Find a useful open source component.
> 2. Discover that it has a missing feature or a bug(let) that gets in
> the way of what I want to do.
> 3. Submit to owner, meanwhile ...
> 4. Want to make release into my own infrastructure of fork while
> waiting a long time for owner to absorb and release.


> Step 4 has always felt to me like much too much work.


mvn versions:set -DnewVersion=1.1-mycompany-01 && mvn clean javadoc:har
source:jar deploy -DaltDeploymentUrl=my-Id::default::my-url && mvn
versions:revert

Ok so it's a long command line, but really not that much work at the end of
they day.

I did it 4 times last month

 If it's entirely
> my infrastructure, I need to diddle with scm, distributionManagement,
> url, and version. If I am actually making a public fork, then I've got
> the groupId (and perhaps the package) to deal with. This case,
> however, is outside of the scope of this message.
>
> I've mulled over a maven-fork-plugin that would pom-edit for this
> purpose, but I've also wondered about the subject line of this
> message: should _all_ the information that concerns 'extrinsic'
> infrastructure be factored in some way that makes all this trivial?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: Why is distributionManagement inside the pom?

[Benson Margulies <bi...@gmail.com>]

On Sun, Dec 21, 2014 at 3:30 PM, Mirko Friedenhagen
<mf...@gmail.com> wrote:
> Hello Benson,
>
> we work around the distributionManagement issue for our in-house
> projects by defining a property which is picked up from Maven
> settings.xml in our department parent pom.

Maybe my plugin idea that automates 'fork' pom edits is really the answer here.


>
> My question here: if you do not define distributionManagement (via a
> property) in a pom, all users of Maven would have to fiddle around
> with their settings to deploy anything.
>
>
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies <bi...@gmail.com> wrote:
>> I'd like to submit the concept that distributionManagement has
>> something in common with repositories. Here's the common event that
>> leads me to think about this:
>>
>> 1. Find a useful open source component.
>> 2. Discover that it has a missing feature or a bug(let) that gets in
>> the way of what I want to do.
>> 3. Submit to owner, meanwhile ...
>> 4. Want to make release into my own infrastructure of fork while
>> waiting a long time for owner to absorb and release.
>>
>> Step 4 has always felt to me like much too much work. If it's entirely
>> my infrastructure, I need to diddle with scm, distributionManagement,
>> url, and version. If I am actually making a public fork, then I've got
>> the groupId (and perhaps the package) to deal with. This case,
>> however, is outside of the scope of this message.
>>
>> I've mulled over a maven-fork-plugin that would pom-edit for this
>> purpose, but I've also wondered about the subject line of this
>> message: should _all_ the information that concerns 'extrinsic'
>> infrastructure be factored in some way that makes all this trivial?
>>
>> ---------------------------------------------------------------------
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Why is distributionManagement inside the pom?

[Bernd Eckenfels <ec...@zusammenkunft.net>]

Am Sun, 21 Dec 2014 21:30:49 +0100
schrieb Mirko Friedenhagen <mf...@gmail.com>:

> My question here: if you do not define distributionManagement (via a
> property) in a pom, all users of Maven would have to fiddle around
> with their settings to deploy anything.

I think you have to do that in some way anyway, as you need to define
servers and logins. I guess it only works for ssh without special
setup.

But you are correct some form for distributing those settings would be
a good addition. Something like an environment mechanism which could
also cover staging/localtest/snapshot/release differences would be cool.

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Why is distributionManagement inside the pom?

[Hervé BOUTEMY <he...@free.fr>]

Le dimanche 21 décembre 2014 21:30:49 Mirko Friedenhagen a écrit :
> Hello Benson,
> 
> we work around the distributionManagement issue for our in-house
> projects by defining a property which is picked up from Maven
> settings.xml in our department parent pom.
I suppose this works well for repository or snapshotRepository, ie what's 
absolutely necessary

But for site, there is a strong issue
http://jira.codehaus.org/browse/MSITE-604
and fixing it isn't trivial...
do you use such property with site too?

> 
> My question here: if you do not define distributionManagement (via a
> property) in a pom, all users of Maven would have to fiddle around
> with their settings to deploy anything.
> 
> 
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
> 
> On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies <bi...@gmail.com> 
wrote:
> > I'd like to submit the concept that distributionManagement has
> > something in common with repositories. Here's the common event that
> > leads me to think about this:
> > 
> > 1. Find a useful open source component.
> > 2. Discover that it has a missing feature or a bug(let) that gets in
> > the way of what I want to do.
> > 3. Submit to owner, meanwhile ...
> > 4. Want to make release into my own infrastructure of fork while
> > waiting a long time for owner to absorb and release.
> > 
> > Step 4 has always felt to me like much too much work. If it's entirely
> > my infrastructure, I need to diddle with scm, distributionManagement,
> > url, and version. If I am actually making a public fork, then I've got
> > the groupId (and perhaps the package) to deal with. This case,
> > however, is outside of the scope of this message.
> > 
> > I've mulled over a maven-fork-plugin that would pom-edit for this
> > purpose, but I've also wondered about the subject line of this
> > message: should _all_ the information that concerns 'extrinsic'
> > infrastructure be factored in some way that makes all this trivial?
> > 
> > ---------------------------------------------------------------------
> > 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Why is distributionManagement inside the pom?

[Mirko Friedenhagen <mf...@gmail.com>]

Hello Benson,

we work around the distributionManagement issue for our in-house
projects by defining a property which is picked up from Maven
settings.xml in our department parent pom.

My question here: if you do not define distributionManagement (via a
property) in a pom, all users of Maven would have to fiddle around
with their settings to deploy anything.


Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sun, Dec 21, 2014 at 6:30 PM, Benson Margulies <bi...@gmail.com> wrote:
> I'd like to submit the concept that distributionManagement has
> something in common with repositories. Here's the common event that
> leads me to think about this:
>
> 1. Find a useful open source component.
> 2. Discover that it has a missing feature or a bug(let) that gets in
> the way of what I want to do.
> 3. Submit to owner, meanwhile ...
> 4. Want to make release into my own infrastructure of fork while
> waiting a long time for owner to absorb and release.
>
> Step 4 has always felt to me like much too much work. If it's entirely
> my infrastructure, I need to diddle with scm, distributionManagement,
> url, and version. If I am actually making a public fork, then I've got
> the groupId (and perhaps the package) to deal with. This case,
> however, is outside of the scope of this message.
>
> I've mulled over a maven-fork-plugin that would pom-edit for this
> purpose, but I've also wondered about the subject line of this
> message: should _all_ the information that concerns 'extrinsic'
> infrastructure be factored in some way that makes all this trivial?
>
> ---------------------------------------------------------------------
> 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