Julian, I would suggest to use maven cli "-s" with settings to your
staging repository. Do not inject that into quickstarts, repositories
are injected ONLY for public end users. We are advanced users so we
should use CLI with a specified settings.xml.
We should not publish any product artefact into
http://jboss-developer.github.io/temp-maven-repo/
I would consider that repository only for upstream BOMs publicly available.
On 27.11.2014 13:15, Rafael Benevides wrote:
On 11/27/14 10:04, Julian Coleman wrote:
> Hi,
>
>> I think that the staging repo is the answer here for testing purposes.
> I think that this makes sense too. However, I'm not sure how we will test
> the final version, as that will need a reference to the public repository
> and be tested before the public repository contains the artifacts.
We use a different process that we have the final versions released
previously having the "-build-x" suffix at the version and place those
versions at
http://jboss-developer.github.io/temp-maven-repo/ repo
(which is our "staging" repo until we have a nexus server setup). But I
know that this process is particular and couldn't fit for every project.
Do you see any restrictions to test the final version using the internal
repo and having that repo defined in settings.xml ?
>> I think so, otherwise we won't achieve our objectives to have buildable
>> sources at github.
> Will it matter if we reference an internal repository in the sources?
> (It won't be possible to build them trivially from outside the Red Hat
> network.)
In that case, that's why we used
http://jboss-developer.github.io/temp-maven-repo/ as a staging maven repo.
> Thanks,
>
> J
>
_______________________________________________
jbossdeveloper mailing list
jbossdeveloper(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossdeveloper
--
Marek Novotny
--
WFK and Seam Product Lead
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno