I agree with Brett, Gilles, Daniel.
Gilles, thanks for that reference, I think we should all learn from that!
On Wed, Sep 30, 2009 at 7:49 AM, Daniel Kulp wrote:
>
> I agree with Brett. Strongly recommend, but not require.
>
> Dan
>
>
> On Wed September 30 2009 12:57:34 am Brett Porter wrote:
I agree with Brett.Strongly recommend, but not require.
Dan
On Wed September 30 2009 12:57:34 am Brett Porter wrote:
> I think any rule needs to be enforced on the server side as much as in
> the repository plugin too.
>
> For mine, I think strongly recommending SCM is a good idea, but we
There is no requirements for open sources project to offer access to a
repository : http://www.opensource.org/docs/osd
So recommending it is good, but make it mandatory would be excessive.
Gilles Scokart
I think any rule needs to be enforced on the server side as much as in
the repository plugin too.
For mine, I think strongly recommending SCM is a good idea, but we do
allow artifacts that are redistributable and not open source and so it
should not be required. If you were to get fancy you
You can turn a quality of something to be a requirement only if that
something can be verified at any given time. How about ?
Would you accept this? Not bbecause you want to verify that you can
connect to the server? What if the server is down because of
maintenance? Or it is behind a firewall? Acc
I will also add that since the primary use case of this plugin is to
produce bundles for central, that if this turns out to be a complete
mess, we can decide to change or reduce the requirement. I do however
think we should try and see how it works out. If the number of
exceptions becomes unmanagea
If we don't require it then people simply won't populate it even when
it could be done.
There will always be a manual way to get artifacts through a process
into central if they don't meet the requirements that would have to be
judged on a case by case basis. I think that a significant majority o
On 2009-09-29, at 2:14 PM, Jesse McConnell wrote:
there are certainly benefits to having it in place, I wonder about the
scm metadata suffering from bit rot over time as project juggle around
stuff in their scm's though..
kind of throws a monkey wrench into the materialization process for
proj
I agree with Jörg.
is just another "required" information, which helps nothing but
it may lead to corruption.
OSS projects should be allowed to protect their version control server
with a firewall.
Many -s of different artifacts, with the same ip address of
192.168... would be ugly and confusing.
John Casey wrote:
> Hi,
>
> I've been having a conversation with Jason and some others lately about
> the repository plugin, and the fact that it doesn't require the SCM
> section of the POM. POMs with this section missing disable the project
> materialization features that some of the more recen
I think having it even if over time it rots, is better than having
nothing to start with. Bottom line is that we will want this in
central and will look to automate enforcement, so the bundle plugin
should line up with that process to simplify life for everyone.
On Tue, Sep 29, 2009 at 2:14 PM, Je
there are certainly benefits to having it in place, I wonder about the
scm metadata suffering from bit rot over time as project juggle around
stuff in their scm's though..
kind of throws a monkey wrench into the materialization process for
projects or dependencies
jesse
--
jesse mcconnell
jesse.
On 2009-09-29, at 1:56 PM, John Casey wrote:
Hi,
I've been having a conversation with Jason and some others lately
about the repository plugin, and the fact that it doesn't require
the SCM section of the POM. POMs with this section missing disable
the project materialization features tha
Hi,
I've been having a conversation with Jason and some others lately about
the repository plugin, and the fact that it doesn't require the SCM
section of the POM. POMs with this section missing disable the project
materialization features that some of the more recent Maven tooling
(m2eclipse
14 matches
Mail list logo
