You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Rajwinder Makkar <ra...@gmail.com> on 2012/02/29 05:51:56 UTC

Deploy and settings.xml

Hi,
I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment.

I have this scenario which probably is pretty common in any dev environment
but just want to take inputs on the approach.

My current understanding :

- Only way that maven deploy phase uses to put artifacts in remote repo is
by reading "distributionManagement" tag in the pom.xml. There is no way to
configure the repo for deployment in settings.xml ( under ../conf as well
as user home dir)

Scenerio is :

If i have 100 development teams then :

- either every one need to have distributionManagement tag in 100 pom.xml
- We can has one super pom with the entries and all 100 dev team will
inherit this super pom.

Will appreciate if i can get some help around this on if my assumption are
correct or not , secondly what is the best way to handle this scenarios.

Thanks in advance
-Raj

Re: Deploy and settings.xml

Posted by Frederic Simon <fr...@jfrog.org>.
Yes, using CI Server job configuration can actually completely remove the
need for "distributionManagement" declaration.
The problem becomes a Jenkins job configuration management which I find
easier has a global CM tool.
Playing with pom files in VCS for handling data that are solely related to
the CI environment can be very tricky to handle (especially after
branching, tagging).

My 2cts on this,
Good luck,
Fred.

On Wed, Feb 29, 2012 at 4:55 PM, Stephen Wenner <st...@joann.com>wrote:

> If you have Artifactory 2.4.2 Pro, then I would suggest using some type of
> CI tool that has good integration with Artifactory.  I use Jenkins
> Enterprise.  With the provided plugins the integration between Jenkins and
> Artifactory is seamless and very easy to set up for a large number of
> builds.  There should be documentation at  http://wiki.jfrog.org  that
> lists proper integration points with various CI tools.
>
> Best of luck.
>
> Steve
>
> On Wed, Feb 29, 2012 at 8:46 AM, Ron Wheeler <
> rwheeler@artifact-software.com
> > wrote:
>
> > My interpretation of the theory is that each project has its own
> > deployment need so that putting the distribution management at the
> > settings.xml level would be problematic.
> > On the other hand all projects probably share the same sources for
> > libraries so putting the repo config in settings makes sense.
> >
> > My feeling is that the "right" way to handle distribution is in the
> > project's parent pom (not at the corporate level).
> > That way each project can have its own deployment specification but the
> > individual programmer does not have to worry about it.
> > The parent for the project is set up once by the core team and the rest
> of
> > the developers don't have any changes to make at all.
> >
> > Ron
> >
> >
> > On 28/02/2012 11:51 PM, Rajwinder Makkar wrote:
> >
> >> Hi,
> >> I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment.
> >>
> >> I have this scenario which probably is pretty common in any dev
> >> environment
> >> but just want to take inputs on the approach.
> >>
> >> My current understanding :
> >>
> >> - Only way that maven deploy phase uses to put artifacts in remote repo
> is
> >> by reading "distributionManagement" tag in the pom.xml. There is no way
> to
> >> configure the repo for deployment in settings.xml ( under ../conf as
> well
> >> as user home dir)
> >>
> >> Scenerio is :
> >>
> >> If i have 100 development teams then :
> >>
> >> - either every one need to have distributionManagement tag in 100
> pom.xml
> >> - We can has one super pom with the entries and all 100 dev team will
> >> inherit this super pom.
> >>
> >> Will appreciate if i can get some help around this on if my assumption
> are
> >> correct or not , secondly what is the best way to handle this scenarios.
> >>
> >> Thanks in advance
> >> -Raj
> >>
> >>
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> --
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> confidential and privileged information intended only for the addressee.
> If you are not the intended recipient, please be advised that you have
> received this material in error and that any forwarding, copying, printing,
> distribution, use or disclosure of the material is strictly prohibited.
> If you have received this material in error, please (i) do not read it,
> (ii) reply to the sender that you received the message in error, and
> (iii) erase or destroy the material. Emails are not secure and can be
> intercepted, amended, lost or destroyed, or contain viruses. You are deemed
> to have accepted these risks if you communicate with us by email. Thank
> you.
>



-- 
JFrog Ltd
http://www.jfrog.org/

Re: Deploy and settings.xml

Posted by Stephen Wenner <st...@joann.com>.
If you have Artifactory 2.4.2 Pro, then I would suggest using some type of
CI tool that has good integration with Artifactory.  I use Jenkins
Enterprise.  With the provided plugins the integration between Jenkins and
Artifactory is seamless and very easy to set up for a large number of
builds.  There should be documentation at  http://wiki.jfrog.org  that
lists proper integration points with various CI tools.

Best of luck.

Steve

On Wed, Feb 29, 2012 at 8:46 AM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> My interpretation of the theory is that each project has its own
> deployment need so that putting the distribution management at the
> settings.xml level would be problematic.
> On the other hand all projects probably share the same sources for
> libraries so putting the repo config in settings makes sense.
>
> My feeling is that the "right" way to handle distribution is in the
> project's parent pom (not at the corporate level).
> That way each project can have its own deployment specification but the
> individual programmer does not have to worry about it.
> The parent for the project is set up once by the core team and the rest of
> the developers don't have any changes to make at all.
>
> Ron
>
>
> On 28/02/2012 11:51 PM, Rajwinder Makkar wrote:
>
>> Hi,
>> I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment.
>>
>> I have this scenario which probably is pretty common in any dev
>> environment
>> but just want to take inputs on the approach.
>>
>> My current understanding :
>>
>> - Only way that maven deploy phase uses to put artifacts in remote repo is
>> by reading "distributionManagement" tag in the pom.xml. There is no way to
>> configure the repo for deployment in settings.xml ( under ../conf as well
>> as user home dir)
>>
>> Scenerio is :
>>
>> If i have 100 development teams then :
>>
>> - either every one need to have distributionManagement tag in 100 pom.xml
>> - We can has one super pom with the entries and all 100 dev team will
>> inherit this super pom.
>>
>> Will appreciate if i can get some help around this on if my assumption are
>> correct or not , secondly what is the best way to handle this scenarios.
>>
>> Thanks in advance
>> -Raj
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

-- 
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

Re: Deploy and settings.xml

Posted by Manfred Moser <ma...@mosabuam.com>.
On 12-02-29 07:34 AM, Wayne Fay wrote:
>> If i tweak the scenario little bit and lets assume that all the development
>> teams need to go in same repository. Even then my understaing till now is
>> that "settings.xml" can not host distribution management  tag , it can only
>> be present in pom.
> Ron already told you what to do:
>>> The parent for the project is set up once by the core team and the rest of
>>> the developers don't have any changes to make at all.
> Make a single top-level corporate parent project that holds the
> distributionManagement information. Require all teams to use this
> top-level project as their project's parent pom.

And when you do that you can enforce other company wide things like 
plugin versions..

manfred

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


Re: Deploy and settings.xml

Posted by Wayne Fay <wa...@gmail.com>.
> If i tweak the scenario little bit and lets assume that all the development
> teams need to go in same repository. Even then my understaing till now is
> that "settings.xml" can not host distribution management  tag , it can only
> be present in pom.

Ron already told you what to do:
>> The parent for the project is set up once by the core team and the rest of
>> the developers don't have any changes to make at all.

Make a single top-level corporate parent project that holds the
distributionManagement information. Require all teams to use this
top-level project as their project's parent pom.

Wayne

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


Re: Deploy and settings.xml

Posted by Rajwinder Makkar <ra...@gmail.com>.
Ron thank's you for your response ,

If i tweak the scenario little bit and lets assume that all the development
teams need to go in same repository. Even then my understaing till now is
that "settings.xml" can not host distribution management  tag , it can only
be present in pom.

Any thoughts ?

-Raj

On Wed, Feb 29, 2012 at 5:46 AM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> My interpretation of the theory is that each project has its own
> deployment need so that putting the distribution management at the
> settings.xml level would be problematic.
> On the other hand all projects probably share the same sources for
> libraries so putting the repo config in settings makes sense.
>
> My feeling is that the "right" way to handle distribution is in the
> project's parent pom (not at the corporate level).
> That way each project can have its own deployment specification but the
> individual programmer does not have to worry about it.
> The parent for the project is set up once by the core team and the rest of
> the developers don't have any changes to make at all.
>
> Ron
>
>
>
> On 28/02/2012 11:51 PM, Rajwinder Makkar wrote:
>
>> Hi,
>> I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment.
>>
>> I have this scenario which probably is pretty common in any dev
>> environment
>> but just want to take inputs on the approach.
>>
>> My current understanding :
>>
>> - Only way that maven deploy phase uses to put artifacts in remote repo is
>> by reading "distributionManagement" tag in the pom.xml. There is no way to
>> configure the repo for deployment in settings.xml ( under ../conf as well
>> as user home dir)
>>
>> Scenerio is :
>>
>> If i have 100 development teams then :
>>
>> - either every one need to have distributionManagement tag in 100 pom.xml
>> - We can has one super pom with the entries and all 100 dev team will
>> inherit this super pom.
>>
>> Will appreciate if i can get some help around this on if my assumption are
>> correct or not , secondly what is the best way to handle this scenarios.
>>
>> Thanks in advance
>> -Raj
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Re: Deploy and settings.xml

Posted by Ron Wheeler <rw...@artifact-software.com>.
My interpretation of the theory is that each project has its own 
deployment need so that putting the distribution management at the 
settings.xml level would be problematic.
On the other hand all projects probably share the same sources for 
libraries so putting the repo config in settings makes sense.

My feeling is that the "right" way to handle distribution is in the 
project's parent pom (not at the corporate level).
That way each project can have its own deployment specification but the 
individual programmer does not have to worry about it.
The parent for the project is set up once by the core team and the rest 
of the developers don't have any changes to make at all.

Ron


On 28/02/2012 11:51 PM, Rajwinder Makkar wrote:
> Hi,
> I have just setup Artifactory 2.4.2 and Maven 3.0 in our environment.
>
> I have this scenario which probably is pretty common in any dev environment
> but just want to take inputs on the approach.
>
> My current understanding :
>
> - Only way that maven deploy phase uses to put artifacts in remote repo is
> by reading "distributionManagement" tag in the pom.xml. There is no way to
> configure the repo for deployment in settings.xml ( under ../conf as well
> as user home dir)
>
> Scenerio is :
>
> If i have 100 development teams then :
>
> - either every one need to have distributionManagement tag in 100 pom.xml
> - We can has one super pom with the entries and all 100 dev team will
> inherit this super pom.
>
> Will appreciate if i can get some help around this on if my assumption are
> correct or not , secondly what is the best way to handle this scenarios.
>
> Thanks in advance
> -Raj
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102