<repository /> on quickstarts pom.xml
by Rafael Benevides
Hi all,
On a look for a continuous improvement on developer user experience and
also because we have been constantly asked to support issues related to
the setup of https://access.redhat.com/maven-repository to make the
quickstarts work, we want to include the <repository /> definition on
quickstarts pom.xml
Actually the Archetypes already have the <repository /> on the pom.xml
file of the generated project.
The idea here is to have the <repository /> with the
https://maven.repository.redhat.com/techpreview/all/ defined on every
quickstarts's pom.xml file with a comment on top of it saying that this
approach is not recommended but we included it so users can test the
quickstarts without further setup and that it's recommended to use
settings.xml.
It will bring the following advantages:
- It will make ease to contributors and users
- Simplify the build.
- Simplify the Archetype synch process / No need to inject the repo
since it will come from the Quickstarts
- We can add a pre-defined comment above the pom.xml repository
definition to explain that we don't recommend that.
- We can also add this "comment" to QSTools to check/fix it.
As a roadmap for it:
- We need to document that at the
https://github.com/jboss-developer/jboss-developer-shared-resources
- We need to update the contributing guides
- We need to update QSTools to do this update on all quickstarts for us.
Max, Is there any restrictions on JBDS side ?
Anyone else have any objections/comments on this $subject ?
Thanks
--
*Rafael Benevides | Senior Software Engineer*
JBoss Developer
M: +55-61-9269-6576
Red Hat
Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com <http://www.redhat.com/>
LinkedIn <http://www.linkedin.com/company/3258288> Youtube
<https://www.youtube.com/redhatlatam>
10 years, 3 months
Fwd: Re: Maven Configuration - preferred method
by Sande Gilda
This was the email discussing the cons....
-------- Original Message --------
Subject: Re: Maven Configuration - preferred method
Date: Thu, 26 Apr 2012 18:50:57 +0200
From: Max Rydahl Andersen <max.andersen(a)redhat.com>
To: Sande Gilda <sgilda(a)redhat.com>
CC: Burr Sutter <bsutter(a)redhat.com>, Pete Muir <pmuir(a)redhat.com>,
Paul Gier <pgier(a)redhat.com>, jboss-developer-usability-internal(a)redhat.com
> I have inherited some Maven configuration documentation and am trying to verify a statement that was made in a topic on how to configure the project POM file to use the JBoss EAP Maven Repository.
>
> It basically says:
> "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.
This recommendation is broken standing on its own.
Read: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-p...
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"
> Here are my questions:
> • Is the really the preferred and recommended configuration? This would only work if the repository is stored on a shared server. If the repository is installed on the local file system, this wouldn't work.
Yes, exactly.
> • For distributed development, it seems like it limits what a developer can do to optimize the build process.
Yup.
plus 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.
> What should we be recommending here? Maven settings or project POM? Or does it just depend? Should we be recommending anything?
10 years, 3 months
Fwd: Re: [Wolf] Revisting embedding repositories in POMs for developer materials
by 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(a)redhat.com>
To: Alan Santos <asantos(a)redhat.com>
CC: jboss-developer-experience-list(a)redhat.com, Gert Vanthienen
<gvanthie(a)redhat.com>, "Enterprise Maven Repo \(Project Wolf\)"
<enterprise-maven-list(a)redhat.com>, Max(a)redhat.com, Max Rydahl Andersen
<max.andersen(a)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(a)redhat.com> wrote:
>
> On Nov 25, 2013, at 6:21 AM, Karel Piwko <kpiwko(a)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?sof...
>
> 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(a)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-y...
>>>>
>>>> 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(a)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
>>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
10 years, 3 months
Re: [jbossdeveloper] GitHub Usage
by Paul Robinson
All,
This isn't going to work, as only those with push access can set the labels :-(
I'll continue to use the labels for my own organisation, until we can come up with something that works for all contributors.
Paul.
On 1 Aug 2014, at 13:13, Paul Robinson <paul.robinson(a)redhat.com> wrote:
> All,
>
> We've recently created some labels on GitHub PRs. The idea is to make it easier to see, at-a-glance what the PR is waiting upon. Although Github will allow multiple labels to be present at once, our workflow forbids it.
>
> The workflow is quite simple:
>
> On Hold
> This is for WiP PRs and things that can't be merged until some external factor has been addressed. For example, https://github.com/jboss-developer/www.jboss.org/pull/336 requires a DCP outage, so we need to wait for an appropriate time. this typically replaces the "DO NOT MERGE THIS YET" text that people have been adding.
>
> Ready for Review
> This label means that a reviewer should take a look. Mark your PRs as this when they are ready for review or when you have completed addressing the reviewer's comments.
>
> Address Comments
> This means that a review round is complete and there are comments that need addressing.
>
> Ready to Merge:
> This indicates that a reviewer is happy for the PR to be merged. This step is skipped if the reviewer merges immediately.
>
> Awaiting retest
> This just indicates that a retest has been triggered. Once the test completes, it would most likely be switched to "Ready for Review". I added this label for my own convenience, it's not necessarily something you have to use.
>
> Pete and I only set this up yesterday, so it's likely to evolve over time. Lets see how we get on with it.
>
> Paul.
>
> --
> Paul Robinson
> JBoss Developer Team Lead (www.jboss.org)
>
> JBoss, a Division of Red Hat
> Registered in England and Wales under Company Registration No. 03798903
> Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Paul Hickey (Ireland)
>
Paul.
--
Paul Robinson
JBoss Developer Team Lead (www.jboss.org)
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Paul Hickey (Ireland)
10 years, 4 months
Re: [jbossdeveloper] Do we need to tag the quickstarts?
by Rafael Benevides
Ref to the branches, I also think that we should do a cleanup removing
- 6.2.x-develop
- 6.3.x-develop
- jdf-2.1.9.Final
branches (keeping the tags)
Btw,
There's also a kitchensink-angularjs and wildfly branches that were not
updated since last year.
Anyone has any objections on removing theses branches ?
Em 8/14/14, 16:04, Sande Gilda escreveu:
> Rafael, that sounds great to me.
>
> Paul, does this work for you?
>
> On 08/14/2014 02:26 PM, Rafael Benevides wrote:
>> I think we should tag the 6.3 quickstarts, then keep the same 6.3.x
>> for EAP 6.3.1 and rename the 6.3.x-develop to 6.4.x-develop
>>
>> 6.3.x-develop -> rename to 6.4.x-develop
>> 6.3.x -> keep it to EAP 6.3.1
>>
>> That's what I think about it.
>>
>>
>> Em 8/14/14, 14:33, Sande Gilda escreveu:
>>> Now that JBoss EAP 6.3 is GA, do we need to tag the quickstarts and
>>> create new branches for EAP 6.3.1 and EAP 6.4? It's so seldom we do
>>> this that I forget!
>>>
>>
>
10 years, 4 months
Re: [jbossdeveloper] GitHub Usage
by Pete Muir
Adding the jbossdeveloper list. (Wes, Dan, please sign up at lists.jboss.org)
On 1 Aug 2014, at 13:13, Paul Robinson <paul.robinson(a)redhat.com> wrote:
> All,
>
> We've recently created some labels on GitHub PRs. The idea is to make it easier to see, at-a-glance what the PR is waiting upon. Although Github will allow multiple labels to be present at once, our workflow forbids it.
>
> The workflow is quite simple:
>
> On Hold
> This is for WiP PRs and things that can't be merged until some external factor has been addressed. For example, https://github.com/jboss-developer/www.jboss.org/pull/336 requires a DCP outage, so we need to wait for an appropriate time. this typically replaces the "DO NOT MERGE THIS YET" text that people have been adding.
>
> Ready for Review
> This label means that a reviewer should take a look. Mark your PRs as this when they are ready for review or when you have completed addressing the reviewer's comments.
>
> Address Comments
> This means that a review round is complete and there are comments that need addressing.
>
> Ready to Merge:
> This indicates that a reviewer is happy for the PR to be merged. This step is skipped if the reviewer merges immediately.
>
> Awaiting retest
> This just indicates that a retest has been triggered. Once the test completes, it would most likely be switched to "Ready for Review". I added this label for my own convenience, it's not necessarily something you have to use.
>
> Pete and I only set this up yesterday, so it's likely to evolve over time. Lets see how we get on with it.
>
> Paul.
>
> --
> Paul Robinson
> JBoss Developer Team Lead (www.jboss.org)
>
> JBoss, a Division of Red Hat
> Registered in England and Wales under Company Registration No. 03798903
> Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Paul Hickey (Ireland)
>
10 years, 4 months
