On Sun, Dec 21, 2014 at 3:30 PM, Mirko Friedenhagen
<[email protected]> 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 <[email protected]> 
> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to