[jbossdeveloper] Fwd: Re: [Wolf] Revisting embedding repositories in POMs for developer materials

[Sande Gilda]

This was Pete's email.


-------- Original Message --------
Subject: 	Re: [Wolf] Revisting embedding repositories in POMs for 
developer materials
Date: 	Mon, 25 Nov 2013 14:40:34 +0000
From: 	Pete Muir <pmuir at redhat.com>
To: 	Alan Santos <asantos at redhat.com>
CC: 	jboss-developer-experience-list at redhat.com, Gert Vanthienen 
<gvanthie at redhat.com>, "Enterprise Maven Repo \(Project Wolf\)" 
<enterprise-maven-list at redhat.com>, Max at redhat.com, Max Rydahl Andersen 
<max.andersen at redhat.com>



Right. The issue is that people will often just not read instructions, miss a step, misunderstand or otherwise screw up. It’s always better, especially with the thing that we present as the place to start, that it just works. Put another way, how many people do you think will try out the quickstarts, having unzipped EAP (or another product), see that dependencies can’t be found, and just give up? Are we sure we can just shrug our shoulders and give up on this group?

One idea I have is that we could build a maven plugin, that sits in Maven central. This could be configured in a quickstart, example etc. and check to see if maven.repository.redhat.com is defined. If it isn’t it could tell the user they need to configure it, and offer (interactively) to add it for them. If you’ve used JBDS, this should be familiar, as it is what JBDS does :-) This would bring that same experience to the quickstart when used from plain Maven, or in another IDE.

This plugin could either be generic (you need to configure in the quickstart/example that it needs to fail if it’s missing the redhat repo), or it could be hardcoded to maven.repository.redhat.com, or it could be a combo of the both - a generic version that we repackage to avoid the configuration in pom.xml

This would allow us to continue showing the best practice, but help users understand why it doesn’t work ootb.

WDYT?

On 25 Nov 2013, at 13:47, Alan Santos <asantos at redhat.com> wrote:

>
> On Nov 25, 2013, at 6:21 AM, Karel Piwko <kpiwko at redhat.com> wrote:
>
>> The original pain was about zip repositories, which would have different
>> location on every machine. Now, if we want to point user to
>> maven.repository.redhat.com in our quickstarts/demos, why don't we simply ship
>> settings.xml as well?
>>
>
>
> https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=25563&product=soaplatform&version=6.0.0+Beta&downloadType=distributions
>
> We do.
>
> afaict most users want/expect to use the hosted repo.  The ones who are interested in a big .zip are typically interested because they *cant* use the hosted repo.   The maven .zips
>
> To Catherines original email - for GA the FSW installer will offer to update a users settings.xml to point at the hosted repository.   Does JBDS not honor settings.xml? I don’t recall having to set anything explicitly in the editor once maven proper was correctly configured.
>
>
>
>
>
>> Karel
>>
>> On Sun, 24 Nov 2013 12:59:18 +0100
>> Max Rydahl Andersen <manderse at redhat.com> wrote:
>>
>>> If we do this we should:
>>>
>>> a) use the exact same id/url for referenced repositories (this ensures
>>> mirror settings in settings.xml would just need to be setup once) b) we
>>> should add comments in the pom.xml saying it is recommended for real projects
>>> (i.e. not examples) to remove the repository url from the pom.xml (my
>>> comments below goes in more detail) c) check if i'm right about #a and that
>>> local pom.xml repositories doesn't simply override settings.xml repository
>>> definitions making it even harder to use ;/ Note, users trying the archetypes
>>> need to add the reference to settings.xml anyway.
>>>
>>> btw. if the repository is *not* defined in settings.xml tools can't check if
>>> things are setup correctly...thats why a and c are important to get
>>> tested/verified.
>>>
>>> /max
>>>
>>> On Fri, Nov 22, 2013 at 01:51:29PM -0500, Sande Gilda wrote:
>>>> When I took over the Maven documentation for EAP 6.0 Development
>>>> Guide, I remember this came up. The original writer had written:
>>>>
>>>> "Red Hat recommends configuring the Maven repository in your project's
>>>> pom.xml file so the configuration applies regardless of where the project
>>>> is built." This is as opposed to using the Maven settings."
>>>>
>>>> Max responded:
>>>>
>>>> This recommendation is broken standing on its own.
>>>>
>>>> Read:http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>>>>
>>>> We don't even do this for our own products and with good reasons.
>>>>
>>>> I know some projects do still do this but it has to be done very
>>>> carefully.
>>>>
>>>> All the arguments is in the blog from Sonatype.
>>>>
>>>> Thus in my opinion we should say something like:
>>>>
>>>> "Red Hat recommends configuration the Maven repository in your
>>>> settings.xml and only place the repositories in your pom.xml if you
>>>> understand the consequence of doing so, see <linktosontaypeblog>" "For a
>>>> team the simplest way is to host the maven repository on a shared webserver
>>>> or use a repository manager such as Nexus or Artifactory and use these
>>>> settings in their ~/.m2/settings.xml"
>>>>
>>>> These were additional comments by Max:
>>>>
>>>> * It limits what a developer can do to optimize the build process .
>>>> * If the customer is putting this into a pom that is referred to by
>>>> other projects he can actually "inject" this repository into other
>>>> users/customers builds which expect their builds to use nothing but
>>>> their hosted repository.
>>>>
>>>>
>>>> I can forward the email if you like.
>>>>
>>>> On 11/22/2013 12:07 PM, Pete Muir wrote:
>>>>> With JBDS it’s not too bad, as it fixes your settings.xml for you. I agree
>>>>> with Max here, there is no way to magically do the fix.
>>>>>
>>>>> The only way I’m aware off, to make this transparent, is to embed the
>>>>> repository definition into the POM. However this is generally regarded as
>>>>> an anti-pattern in Maven...
>>>>>
>>>>>
>>>>> On 22 Nov 2013, at 16:57, Catherine Robson <crobson at redhat.com> wrote:
>>>>>
>>>>>> Thanks for sending this Pete, this was on my list of things to follow up
>>>>>> on after seeing the FSW experience.
>>>>>>
>>>>>> Is there any way to bundle these dependencies in with the tooling the
>>>>>> users download, and would this solve the problem for all products?
>>>>>>
>>>>>> The experience now:
>>>>>> - download JBDS
>>>>>> - get specific tooling for product
>>>>>> - go fix maven w/ a new settings.xml file
>>>>>> - use quickstarts and projects
>>>>>>
>>>>>> Would like to see it back to:
>>>>>> - download JBDS
>>>>>> - get specific tooling for product (has maven stuff build into it to 'just
>>>>>> work'?)
>>>>>> - use quickstarts and examples
>>>>>>
>>>>>> Feel free to point out if I'm missing something.  Maven is still a crazy
>>>>>> black box to me - so I definitely might not understand all the
>>>>>> implications!
>>>>>>
>>>>>> - Catherine
>>>>>>
>>>>>> Pete Muir wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As we move our resources to target product, where the dependencies of the
>>>>>>> projects are not in Maven Central (nor can be, for legal reasons), we hit
>>>>>>> a usability problem if we require users to set up their settings.xml
>>>>>>> correctly first. This is not a good “getting started” experience.
>>>>>>>
>>>>>>> Therefore, I would like to reopen the question of whether we should
>>>>>>> consider putting maven.repository.redhat.com into our quickstart, example
>>>>>>> and demo POMs as a standard practice.
>>>>>>>
>>>>>>> I would also like to see if any clever people have other ideas about how
>>>>>>> to address this as well :-)
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossdeveloper/attachments/20140827/b9fb5a51/attachment-0001.html