Re: [jbossdeveloper] <repository /> on quickstarts pom.xml
by Pete Muir
On 16 Sep 2014, at 00:27, Max Rydahl Andersen <max.andersen(a)redhat.com> wrote:
> On 9 Sep 2014, at 16:07, Rafael Benevides wrote:
>
>> We also need to check that with JBDS, because it's odd that stacks only
>> uses "redhat-techpreview-all-repository" as additional repository.
>
> because it was the only thing we needed originally.
>
>> Max/Fred,
>>
>> Is there any issues having
>> https://maven.repository.redhat.com/earlyaccess/all/ as declared inside
>> quickstarts pom.xml ?
>
> sorry - but I need to grok when earlyaccess/all is even needed before answering that ? :)
>
> My default position would be that if you need earlyaccess you are expected to be able to understand why you need it.
>
> But i'm not sure if that is true anymore - hence wanting to ask why/when earlyaccess is ever needed ?
> is it for running quickstarts targeting a beta version of EAP ? (meaning no snapshots, but actual all releases in it?)
Right, it’s where we put beta and alpha releases.
>
> If yes, why doesn't /all get split up in /supported and /earlyaccess and /all will serve the combined result ?
Propose this on the wolf list?
>
> Meaning we remove the need to have two different repos always handed around but allow those who want the separation to just use /supported if need be.
>
> i.e. do what maven normally does (use version numbers to separate things) and stop having it be a complex setup for the default case ?
>
> /max
>
>>
>> Em 9/9/14, 9:27, Pete Muir escreveu:
>>> On 9 Sep 2014, at 13:06, Marek Novotny <mnovotny(a)redhat.com> wrote:
>>>
>>>> On 9.9.2014 13:56, Pete Muir wrote:
>>>>> On 9 Sep 2014, at 12:54, Marek Novotny <mnovotny(a)redhat.com> wrote:
>>>>>
>>>>>> On 9.9.2014 13:00, Pete Muir wrote:
>>>>>>> On 9 Sep 2014, at 11:35, Marek Novotny <mnovotny(a)redhat.com> wrote:
>>>>>>>
>>>>>>>> On 8.9.2014 18:48, Pete Muir wrote:
>>>>>>>>>>>>>>> QSTools ticket: https://issues.jboss.org/browse/JDF-762
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But after placing http://maven.repository.redhat.com/techpreview/all/ at the Quickstarts, I realized that we won't solve the user experience issues without adding - https://maven.repository.redhat.com// and
>>>>>>>>>>>>>>> - http://jboss-developer.github.io/temp-maven-repo/ also
>>>>>>>>>>>>>>> for the -develop branch.
>>>>>>>>>>>>> I’m not sure we need to worry about people using the -develop branch. This is for contributors only, and they can read the instructions normally.
>>>>>>>>>>> So I assume that we need to inject http://maven.repository.redhat.com/techpreview/all/ in pom.xml and make them to add the others in settings.xml
>>>>>>>>> Well, we may want to add earlyaccess too. WDYT?
>>>>>>>>>
>>>>>>>> Why we should have it there for end users? earlyaccess repository is
>>>>>>>> just exceptional resource for public Betas, isn't it? Isn't that
>>>>>>>> confusing to have it there even for traditional GA releases?
>>>>>>> OTOH this is not really the way Maven works. In Maven you tend to mix up all releases, and use version numbers to control what gets pulled in.
>>>>>> Even I agree with your statement, do we have a clean description there
>>>>>> what could end users understand why we have a bunch or repositories
>>>>>> there instead of one? We declared today that you can use our product
>>>>>> maven repository (online techpreview/all or offline zipped repository)
>>>>>> plus Central and then in Quickstarts we use "another" repository.
>>>>>>
>>>>>> I agree that injected repository will help to an end user, but wouldn't
>>>>>> it be simple just as one repository?
>>>>>>
>>>>>> you can easily manage versions in BOM imports etc. but for the learning
>>>>>> purpose it can be confusing. WDYT?
>>>>> Hmm. People are used to adding a second repo for snapshots, which is kinda similar.
>>>>>
>>>> What are our target group of developers for quicksktarts? Newbies or
>>>> experienced devs?
>>>>
>>>> I may see it more like short and simple bootstrap for newbies, but your
>>>> view is probably different.
>>> Agreed on newbies. Hence why we don’t want to make people add/remove repos, but have a sensible default configured for them.
>>>
>>>>
>>>> --
>>>> Marek Novotny
>>>> --
>>>> WFK and Seam Product Lead
>>>>
>>>> Red Hat Czech s.r.o.
>>>> Purkynova 99
>>>> 612 45 Brno
>>>
>>> _______________________________________________
>>> jbossdeveloper mailing list
>>> jbossdeveloper(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper
>>
>> _______________________________________________
>> jbossdeveloper mailing list
>> jbossdeveloper(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbossdeveloper
>
>
> /max
> http://about.me/maxandersen
11 years, 8 months
Don't do a "rake update"
by Paul Robinson
All,
There's a problem with aweplug/master ATM. Doing a "rake update" on the www.jboss.org code will pull in the latest master and fail to build.
If you see this error, you'll know you've got this problem:
> An error occurred: undefined local variable or method `site' for Aweplug::Helpers::Resources::Resource:Class
For now you can revert the Gemfile.lock change:
git checkout Gemfile.lock
I'll report bak when it's fixed or if we have a better workaround in place.
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)
11 years, 10 months
Common issues building www.jboss.org project
by Paul Robinson
All,
I've added a common issues area to the Readme file: https://github.com/jboss-developer/www.jboss.org/blob/master/README.md. The idea is to document common issues and solutions. You should consult this area when you have an issue, and also consider contributing to it when you find a solution.
I'm not totally sure this is the right place for this type of content, but it will do for now.
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)
11 years, 10 months
Google Books API
by Paul Robinson
Pete, Jason,
I've temporarily enabled authentication on the Google Books API. We are getting zero builds through at the moment. I'm hoping this will at least get us a new quota that we can use today. I want to get the new FeedHenry banner out and also a preview of the Mobile product pages for review.
FYI: We are using my branch of AwePlug ATM, as a temporary solution.
Pete, you mentioned that the quota is lower for authenticated users? Are you sure about this, I struggled to find any docs to support this. Even if it is, enabling authentication should buy us a few requests to be getting on with.
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)
11 years, 10 months
<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>
11 years, 11 months
Re: [jbossdeveloper] EAP 6.2 Archetypes
by Rafael Benevides
I'll check why those archetypes were not synchronized with Maven Central...
Em 12/17/13, 11:37, Rafael Benevides escreveu:
> Archetypes released at:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/archet...
>
> Now I'll wait to it be available on Maven Central so I can merge
> stacks.yaml
>
>
> Thanks
>
> Em 17/12/13 05:29, Martin Malina escreveu:
>>
>> On 16. 12. 2013, at 15:12, Rafael Benevides <benevides(a)redhat.com
>> <mailto:benevides@redhat.com>> wrote:
>>
>>>
>>> Thanks Fred and Martin!
>>
>> You’re welcome.
>>
>>> Ok, so can I assume that I have green flag to promote staged
>>> Archetypes and merge the PR as soon as we have it on Maven Central?
>>
>> Yes, I believe so.
>>
>> -Martin
>>
>>>
>>>
>>> Em 16/12/13 11:54, Fred Bricon escreveu:
>>>> As I explained on IRC, this is actually a regression
>>>> (https://issues.jboss.org/browse/JBIDE-16292) caused by the way we
>>>> now handle a given project type backed by archetypes with different
>>>> GAV (only V changed before)
>>>>
>>>> Shouldn't be a problem if EAP 6.2 maintained API compatibility with 6.1
>>>>
>>>>
>>>> Le lundi 16 décembre 2013 12:39:40, Rafael Benevides a écrit :
>>>>> Hi Martin,
>>>>>
>>>>> That's a kind weird because in stacks file 6.1.1 points to older 7.1.3
>>>>> Archetypes:
>>>>> https://github.com/rafabene/jdf-stack/blob/eap62Archetypes/stacks.yaml#L2...
>>>>>
>>>>>
>>>>> ,6.2.0 points to the new archetypes:
>>>>> https://github.com/rafabene/jdf-stack/blob/eap62Archetypes/stacks.yaml#L2...
>>>>>
>>>>>
>>>>> and we don't have wildfly in stacks.yaml.
>>>>>
>>>>> Isn't this runtime/archetypes relationship being managed by jbds
>>>>> instead ?
>>>>>
>>>>> Em 16/12/13 09:24, Martin Malina escreveu:
>>>>>> Hi Rafael,
>>>>>>
>>>>>> I verified that when using stacks.yaml from your PR EAP 6.1.1 and 6.2
>>>>>> both use the new java ee web archetype version 6.2.0 and JBoss AS
>>>>>> 7.1.1 and Wildfly and anything else uses the older 7.1.3. I was able
>>>>>> to build & deploy & view the archetype without any problems.
>>>>>>
>>>>>> Just to make sure: Is it intentional that EAP 6.1.1 also uses this
>>>>>> new archetype?
>>>>>>
>>>>>> Asa far as I can see this update is only to this one archetype,
>>>>>> correct? Other archetypes remain unchanged.
>>>>>>
>>>>>> Thanks,
>>>>>> Martin
>>>>>>
>>>>>> On 13. 12. 2013, at 15:40, Rafael Benevides <benevides(a)redhat.com
>>>>>> <mailto:benevides@redhat.com>
>>>>>> <mailto:benevides@redhat.com>> wrote:
>>>>>>
>>>>>>> Done!
>>>>>>>
>>>>>>> https://github.com/jboss-jdf/jdf-stack/pull/31
>>>>>>>
>>>>>>>
>>>>>>> Em 13/12/13 12:16, Martin Malina escreveu:
>>>>>>>> What I will need is an altered stacks.yaml to point to the new
>>>>>>>> archetype that I want to verify, right?
>>>>>>>> And then I can start JBDS with
>>>>>>>> -Dorg.jboss.tools.stacks.url_stacks=…
>>>>>>>> If I can achieve that, that would be perfect.
>>>>>>>>
>>>>>>>> -Martin
>>>>>>>>
>>>>>>>> On 13. 12. 2013, at 15:03, Rafael Benevides <benevides(a)redhat.com
>>>>>>>> <mailto:benevides@redhat.com>> wrote:
>>>>>>>>
>>>>>>>>> More or less.
>>>>>>>>>
>>>>>>>>> This test that I made are automated by JUnit, so it's part of the
>>>>>>>>> build.
>>>>>>>>>
>>>>>>>>> There's also mention on how to test on the contributing.md (step 8
>>>>>>>>> and 9) :
>>>>>>>>> https://github.com/jboss-developer/jboss-eap-archetypes/blob/master/CONTR...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Em 13/12/13 11:57, Pete Muir escreveu:
>>>>>>>>>> I think Martin could do with steps to configure the staging repo,
>>>>>>>>>> and then to alter JBoss Central to use the archetype.
>>>>>>>>>>
>>>>>>>>>> Is this documented somewhere?
>>>>>>>>>>
>>>>>>>>>> On 13 Dec 2013, at 13:53, Rafael Benevides <benevides(a)redhat.com
>>>>>>>>>> <mailto:benevides@redhat.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Well,
>>>>>>>>>>>
>>>>>>>>>>> My tests consists in creating a project and build/deploy the
>>>>>>>>>>> created project using the CLI.
>>>>>>>>>>> I'm not sure if it's sufficient for an Archerype.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Em 13/12/13 11:51, Martin Malina escreveu:
>>>>>>>>>>>> Yes, I can test it, but only on Monday.
>>>>>>>>>>>> Also, I will need Rafael to provide steps to test this. Can you
>>>>>>>>>>>> do that, Rafael?
>>>>>>>>>>>>
>>>>>>>>>>>> -Martin
>>>>>>>>>>>>
>>>>>>>>>>>> On 13. 12. 2013, at 14:39, Pete Muir <pmuir(a)redhat.com
>>>>>>>>>>>> <mailto:pmuir@redhat.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Martin, are you able to test this out?
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 13 Dec 2013, at 13:18, Rafael Benevides
>>>>>>>>>>>>> <benevides(a)redhat.com <mailto:benevides@redhat.com>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi guys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I did:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1 - Prepared EAP 6.2 Archetypes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Synch:
>>>>>>>>>>>>>> https://github.com/jboss-developer/jboss-eap-archetypes/commit/d532e54d6c...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tag:
>>>>>>>>>>>>>> https://github.com/jboss-developer/jboss-eap-archetypes/releases/tag/6.2....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2- Release EAP 6.2 Archetype in a staged repo:
>>>>>>>>>>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I need to know if will we let QE team work on this
>>>>>>>>>>>>>> release or if should I promote this Archetypes based on the
>>>>>>>>>>>>>> tests I made. I'm asking that because I consider it isn't a
>>>>>>>>>>>>>> community release anymore so I think QE production tests
>>>>>>>>>>>>>> should handle it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Em 09/12/13 17:43, Rafael Benevides escreveu:
>>>>>>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry for the wide audience but since EAP 6.2 was released
>>>>>>>>>>>>>>>>> last week, the archetypes (
>>>>>>>>>>>>>>>>> https://github.com/jboss-developer/jboss-eap-archetypes )
>>>>>>>>>>>>>>>>> was not even mentioned.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Since Archetypes are part of the stacks, I'd like to know
>>>>>>>>>>>>>>>>> who in productization team should handle the archetypes?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WFK 2.4 Archetypes was released to Maven Central after a
>>>>>>>>>>>>>>>>> period in a nexus staged repository being tested by WFK QE
>>>>>>>>>>>>>>>>> team. Can I assume that we will have the same approach for
>>>>>>>>>>>>>>>>> EAP 6.2 Archetypes? If so, there are some steps missing
>>>>>>>>>>>>>>>>> that it's needed and the time is flying.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1 - Prepare the EAP 6.2 Archetypes based on a EAP 6.2
>>>>>>>>>>>>>>>>> Quickstarts tag
>>>>>>>>>>>>>>>>> 2 - Release EAP 6.2 Archetype in a staged repo
>>>>>>>>>>>>>>>>> 3 - QE test/fix cycle on the Archetypes
>>>>>>>>>>>>>>>>> 4 - Promote the stage repo
>>>>>>>>>>>>>>>>> 5 - Ask to Sonatype to include this new archetype groupId
>>>>>>>>>>>>>>>>> (org.jboss.archetype.eap) to be synched with Maven Central
>>>>>>>>>>>>>>>>> 6 - Update stacks.yaml
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So the purpose of this email is bring EAP Archetypes under
>>>>>>>>>>>>>>>>> discussion (at least for this release) since Pete is
>>>>>>>>>>>>>>>>> preparing a plan that should work for next releases.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Rafael Benevides | Senior Software Engineer
>>>>>>>>>>>>>>>>> JBoss Developer
>>>>>>>>>>>>>>>>> M: +55-61-9269-6576
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <Mail Attachment.jpeg>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Better technology. Faster innovation. Powered by community
>>>>>>>>>>>>>>>>> collaboration.
>>>>>>>>>>>>>>>>> See how it works at www.redhat.com
>>>>>>>>>>>>>>>>> <http://www.redhat.com/>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> <Mail Attachment.png> <Mail Attachment.png>
>>>>>>>>>>>> --
>>>>>>>>>>>> Martin Malina
>>>>>>>>>>>> JBoss QA Engineer
>>>>>>>>>>>> Red Hat Czech s.r.o.
>>>>>>>>>>>> Purkynova 99
>>>>>>>>>>>> 612 45 Brno, Czech Republic
>>>>>>>>>>>>
>>>>>>>>>>>> Tel.: +420 532 294 265
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Martin Malina
>>>>>>>> JBoss QA Engineer
>>>>>>>> Red Hat Czech s.r.o.
>>>>>>>> Purkynova 99
>>>>>>>> 612 45 Brno, Czech Republic
>>>>>>>>
>>>>>>>> Tel.: +420 532 294 265
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Malina
>>>>>> JBoss QA Engineer
>>>>>> Red Hat Czech s.r.o.
>>>>>> Purkynova 99
>>>>>> 612 45 Brno, Czech Republic
>>>>>>
>>>>>> Tel.: +420 532 294 265
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> --
>> Martin Malina
>> JBoss QA Engineer
>> Red Hat Czech s.r.o.
>> Purkynova 99
>> 612 45 Brno, Czech Republic
>>
>> Tel.: +420 532 294 265
>>
>>
>>
>>
>
11 years, 11 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?
11 years, 11 months
Two site updates
by Pete Muir
1) We now have a password vault, which provides you with all the keys you need to build the site. If you want adding to it, please take a look at the readme, or ping me on IRC.
2) We switched to a new cache format. If you get some file incompatible error whilst building, just do a rake clean[all]
11 years, 11 months
