Hi all, So, what's our current approach towards hardcoding maven repositories in the pom.xml files? Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds:

On 19 May 2011, at 09:52, Galder Zamarreño wrote: > Hi all, > > So, what's our current approach towards hardcoding maven repositories in the pom.xml files? > > Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: > > <repository> > <id>jboss</id> > <url>http://repository.jboss.org/maven2</url> > </repository> > > First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. > > Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. Now in some cases I've seen third-party repos exposed in certain modules' poms. This needs to be assessed on a case-by-case basis, but is generally discouraged. For example, infinispan-spring declares a repo which contains some Spring 3.1 milestone artefacts, and cachestore-cloud points to a repo with JClouds milestones/snapshots. -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On Thu, May 19, 2011 at 12:18, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. Don't know about that, but if you want something in Maven Central, it cannot depend on external repos. You can refer to external artifacts, but it's up to the user to add them to their own settings.xml / repo.

I also assume that at some point we might want to have our artifacts synched with central, I doubt they will accept poms pointing to other repositories, that was not the case before but it might have changed.

2011/5/19 Pete Muir <pmuir(a)redhat.com&gt;: > The one argument for putting the (new) repo in the pom is that does make getting started contributing easier, and buildable on a clean system with no changes. > > Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. Still I've been consulting in some big companies where there are rules about it: projects having poms defining a repository can not be used. Makes it too hard to create a controlled build environment.

I also assume that at some point we might want to have our artifacts synched with central, I doubt they will accept poms pointing to other repositories, that was not the case before but it might have changed.

I'd avoid that. people using our artifacts learned how to configure their settings already, or wouldn't be able to build infinispan core anyway.

> > On 19 May 2011, at 10:58, Manik Surtani wrote: > >> >> On 19 May 2011, at 09:52, Galder Zamarreño wrote: >> >>> Hi all, >>> >>> So, what's our current approach towards hardcoding maven repositories in the pom.xml files? >>> >>> Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: >>> >>> <repository> >>> <id>jboss</id> >>> <url>http://repository.jboss.org/maven2</url> >>> </repository> >>> >>> First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. >>> >>> Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users >> >> I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. >> >> Now in some cases I've seen third-party repos exposed in certain modules' poms. This needs to be assessed on a case-by-case basis, but is generally discouraged. For example, infinispan-spring declares a repo which contains some Spring 3.1 milestone artefacts, and cachestore-cloud points to a repo with JClouds milestones/snapshots. >> >> >> -- >> Manik Surtani >> manik(a)jboss.org >> twitter.com/maniksurtani >> >> Lead, Infinispan >> http://www.infinispan.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

So this got quite urgent right now: http://repository.jboss.org/maven2 is now returning "not authorized", we all knew it was deprecated since long time, but now it's gone and this is affecting my build and blocking my work. Even if I fix it locally, it's still troublesome as people depending on these poms will download it, get it in their cache, and then spend hours to figure out what's wrong, because right now Maven3 is not even being explicit on what is broken (I had to use -X and read the full log to figure this out). My current workaround is to define mirrors in my own settings.xml. Seems to me a good reason to remove all these references, or at least fix the links; I'm voting to remove them, but have no strong feeling about it as Pete's objections are interesting as well; just that I don't think we risk loosing good contributors or users, we might loose someone which doesn't have a clue on how Maven works, but if they're good and interested they'll find the wiki or ask for help; most people I know don't need to add this as if you use artifactory or nexus the jboss.org repository is already proxies by default, and others might have the URL setup already because they used JBoss community projects too. Either way, we should take a decision urgently. https://issues.jboss.org/browse/ISPN-1142 Cheers, Sanne 2011/5/19 Pete Muir <pmuir(a)redhat.com&gt;: > > On 19 May 2011, at 11:40, Sanne Grinovero wrote: > >> 2011/5/19 Pete Muir <pmuir(a)redhat.com&gt;: >>> The one argument for putting the (new) repo in the pom is that does make getting started contributing easier, and buildable on a clean system with no changes. >>> >>> Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. >> >> Still I've been consulting in some big companies where there are rules >> about it: projects having poms defining a repository can not be used. >> Makes it too hard to create a controlled build environment. > > Yes, and note that i'm certainly not advocating putting any old repo in a pom. As Tristan says, we should require that everything is in the jboss repo. I'm simply proposing putting the jboss repo in the POM as it is our "canonical" repo. > >> I also assume that at some point we might want to have our artifacts >> synched with central, I doubt they will accept poms pointing to other >> repositories, that was not the case before but it might have changed. > > Agreed, but see my other email, having them in settings.xml is just as bad/worse at this point. > >> >> I'd avoid that. people using our artifacts learned how to configure >> their settings already, or wouldn't be able to build infinispan core >> anyway. > > I would hope we are planning to attract some new users ;-) > >> >>> >>> On 19 May 2011, at 10:58, Manik Surtani wrote: >>> >>>> >>>> On 19 May 2011, at 09:52, Galder Zamarreño wrote: >>>> >>>>> Hi all, >>>>> >>>>> So, what's our current approach towards hardcoding maven repositories in the pom.xml files? >>>>> >>>>> Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: >>>>> >>>>> <repository> >>>>> <id>jboss</id> >>>>> <url>http://repository.jboss.org/maven2</url> >>>>> </repository> >>>>> >>>>> First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. >>>>> >>>>> Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users >>>> >>>> I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. >>>> >>>> Now in some cases I've seen third-party repos exposed in certain modules' poms. This needs to be assessed on a case-by-case basis, but is generally discouraged. For example, infinispan-spring declares a repo which contains some Spring 3.1 milestone artefacts, and cachestore-cloud points to a repo with JClouds milestones/snapshots. >>>> >>>> >>>> -- >>>> Manik Surtani >>>> manik(a)jboss.org >>>> twitter.com/maniksurtani >>>> >>>> Lead, Infinispan >>>> http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

What was the fix around this?  To remove the hard-coded repo in the poms?

On 31 May 2011, at 09:46, Galder Zamarreño wrote: > I'm fine with it. I think Adrian added it but clearly, all jars should be available in the Nexus maven profile. > > This has been fixed and integrated and build looks fine. > > On May 26, 2011, at 4:12 PM, Sanne Grinovero wrote: > >> So this got quite urgent right now: >> >> http://repository.jboss.org/maven2 >> >> is now returning "not authorized", we all knew it was deprecated since >> long time, but now it's gone and this is affecting my build and >> blocking my work. >> >> Even if I fix it locally, it's still troublesome as people depending >> on these poms will download it, get it in their cache, and then spend >> hours to figure out what's wrong, because right now Maven3 is not even >> being explicit on what is broken (I had to use -X and read the full >> log to figure this out). >> >> My current workaround is to define mirrors in my own settings.xml. >> >> Seems to me a good reason to remove all these references, or at least >> fix the links; >> I'm voting to remove them, but have no strong feeling about it as >> Pete's objections are interesting as well; just that I don't think we >> risk loosing good contributors or users, we might loose someone which >> doesn't have a clue on how Maven works, but if they're good and >> interested they'll find the wiki or ask for help; most people I know >> don't need to add this as if you use artifactory or nexus the >> jboss.org repository is already proxies by default, and others might >> have the URL setup already because they used JBoss community projects >> too. >> >> Either way, we should take a decision urgently. >> >> https://issues.jboss.org/browse/ISPN-1142 >> >> Cheers, >> Sanne >> >> 2011/5/19 Pete Muir <pmuir(a)redhat.com&gt;: >>> >>> On 19 May 2011, at 11:40, Sanne Grinovero wrote: >>> >>>> 2011/5/19 Pete Muir <pmuir(a)redhat.com&gt;: >>>>> The one argument for putting the (new) repo in the pom is that does make getting started contributing easier, and buildable on a clean system with no changes. >>>>> >>>>> Maven guys used to recommend not putting repos in poms, but they changed that a while back and now don't discourage it. >>>> >>>> Still I've been consulting in some big companies where there are rules >>>> about it: projects having poms defining a repository can not be used. >>>> Makes it too hard to create a controlled build environment. >>> >>> Yes, and note that i'm certainly not advocating putting any old repo in a pom. As Tristan says, we should require that everything is in the jboss repo. I'm simply proposing putting the jboss repo in the POM as it is our "canonical" repo. >>> >>>> I also assume that at some point we might want to have our artifacts >>>> synched with central, I doubt they will accept poms pointing to other >>>> repositories, that was not the case before but it might have changed. >>> >>> Agreed, but see my other email, having them in settings.xml is just as bad/worse at this point. >>> >>>> >>>> I'd avoid that. people using our artifacts learned how to configure >>>> their settings already, or wouldn't be able to build infinispan core >>>> anyway. >>> >>> I would hope we are planning to attract some new users ;-) >>> >>>> >>>>> >>>>> On 19 May 2011, at 10:58, Manik Surtani wrote: >>>>> >>>>>> >>>>>> On 19 May 2011, at 09:52, Galder Zamarreño wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> So, what's our current approach towards hardcoding maven repositories in the pom.xml files? >>>>>>> >>>>>>> Should we allow JBoss repos to be defined master/parent/pom.xml? This was added by Adrian C when he upgraded JClouds: >>>>>>> >>>>>>>    <repository> >>>>>>>       <id>jboss</id> >>>>>>>       <url>http://repository.jboss.org/maven2</url> >>>>>>>    </repository> >>>>>>> >>>>>>> First of all, this is a deprecated repo and not sure it should even be amongst the configured repositories. >>>>>>> >>>>>>> Secondly, the idea so far has been that users configure the JBoss Maven repo in their settings.xml - http://community.jboss.org/wiki/MavenGettingStarted-Users >>>>>> >>>>>> I think we should still stick to putting it in settings.xml since even as a bootstrap for project X to reach infinispan jars, you'd need the JBoss repo either in project X's pom or in settings.xml. >>>>>> >>>>>> Now in some cases I've seen third-party repos exposed in certain modules' poms.  This needs to be assessed on a case-by-case basis, but is generally discouraged.  For example, infinispan-spring declares a repo which contains some Spring 3.1 milestone artefacts,  and cachestore-cloud points to a repo with JClouds milestones/snapshots. >>>>>> >>>>>> >>>>>> -- >>>>>> Manik Surtani >>>>>> manik(a)jboss.org >>>>>> twitter.com/maniksurtani >>>>>> >>>>>> Lead, Infinispan >>>>>> http://www.infinispan.org >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 8 Jun 2011, at 13:50, Sanne Grinovero wrote: > On Wed, Jun 8, 2011 at 12:59 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: >> >> What was the fix around this?  To remove the hard-coded repo in the poms? > > No, I removed the old deprecated repository.jboss.org/maven2 as this > was offline and pretty urgent, and re-adapted the build to be able to > build without it (needed to add/reconfigure other repository > definitions, especially for the scala compiler). This may be old news, but if something is missing from the "new" (ish ;-) r.j.o, but available in another repo, you can email Paul Gier and ask for that repo to be added to the r.j.o consolidated repo.

On 8 Jun 2011, at 13:54, Sanne Grinovero wrote: > On Wed, Jun 8, 2011 at 1:52 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> >> This may be old news, but if something is missing from the "new" (ish ;-) r.j.o, but available in another repo, you can email Paul Gier and ask for that repo to be added to the r.j.o consolidated repo. > > Se we could collect all needed dependencies and add them to jboss.org, > so that nothing else is needed? Yes, I believe so. This should be the correct approach.