If you don't like the term metasoftware, why would you like the metadata?
Data has software dependencies (or data dependencies) just like software.
Data is software. More about this:
http://www.dans.knaw.nl/nl/over_dans/factsheets/mixed_future_proof/
If it looks like a duck...
2009/10/8 Tamás Cse
t;
>> metametadata is therefore data about metadata
>>
>> the jar is your artifact : data
>> the pom is data about the artifact : metadata
>> the metadata.xml is data about the pom files : metametadata
>>
>> Sent from my [rhymes with tryPod] ;-)
>>
>&g
cognition is thinking about thinking
>
> metametadata is therefore data about metadata
>
> the jar is your artifact : data
> the pom is data about the artifact : metadata
> the metadata.xml is data about the pom files : metametadata
>
> Sent from my [rhymes with tryPod] ;-)
>
&
orrect is the metametadata... and
> thankfully that can be reconstructed from the pom files
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 6 Oct 2009, at 18:30, Albert Kurucz wrote:
>
>> Brian,
>>
>>> This is why in suggestion 1) I said lets get som
Brian,
This is a Stalemate!
I go to sleep() until that code arrives to you.
If I had the time, I promise I would code it for you.
On Tue, Oct 6, 2009 at 12:30 PM, Albert Kurucz wrote:
> Brian,
>
>> This is why in suggestion 1) I said lets get some code to validate the
>> arti
If the meta data is
erroneous, the artifact can’t be uploaded.
"
On Tue, Oct 6, 2009 at 12:19 PM, Brian Fox wrote:
> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz wrote:
>> Tamas, I cannot predict when, but once it will be done in a "machine
>> way" or a mathematical
y by
> license URL? Etc...
>
> Many of these are pretty hard to determine in "machine way"
>
> ~t~
>
> On Tue, Oct 6, 2009 at 2:26 AM, Brian Fox wrote:
>
>> On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz
>> wrote:
>> > Brian,
>> >
>
h it.
On Mon, Oct 5, 2009 at 7:28 PM, Brian Fox wrote:
> On Mon, Oct 5, 2009 at 4:36 PM, Albert Kurucz wrote:
>> Brian,
>>
>> If you start maintaining a list of violators I have zero motivation to
>> contribute to your list, because this kind of list is useless for me.
at 2:16 PM, Albert Kurucz wrote:
> Brian,
>
>> Ok then, I assert they are all fine. Now you can provide a list and
>> refute me ;-).
> In this case (if they were all fine) here is your list:
> http://repo2.maven.org/maven2/.index/
> (But unfortunately they are not all
;>
>>> 4) Assuming we have identified a significant number of the problems
>>> from work done in #2, we would then need concrete proposals for how to
>>> fix this without breaking people's builds. Proposals can be posted on
>>> the MAVENUSER wiki spac
stic and we'd be glad to accept help in the areas
> above. I think further theorizing at this point is going to get
> diminishing returns, and I personally think attempting to fork an
> entire repository is not going to help the users as much as even
> items #1,2,3 above.
>
>
My vote is on Option2:
http://xircles.codehaus.org/projects/pinin
On Thu, Oct 1, 2009 at 2:43 PM, Albert Kurucz wrote:
> Isn't that funny:
> http://ask.metafilter.com/68789/Why-do-rotten-onions-smell-good
>
>
> On Thu, Oct 1, 2009 at 2:13 PM, Albert Kurucz wrote:
>>
Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
If somebody can create a Maven repo crawler as a hobby project, then
somebody will.
The first Cert List will probably be just the result of some simple
tests, not much.
But many will follow. We will have to protect somehow our bandwid
Isn't that funny:
http://ask.metafilter.com/68789/Why-do-rotten-onions-smell-good
On Thu, Oct 1, 2009 at 2:13 PM, Albert Kurucz wrote:
> I would like to see some votes:
>
> 1. Big Rotten Onion
> 2. Starting Over After Writing New Policies
>
> On Thu, Oct 1, 2009 at 2:04 P
I would like to see some votes:
1. Big Rotten Onion
2. Starting Over After Writing New Policies
On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz wrote:
> You know where Option1 will drive us?
> When the added metadata which hides current corruption will become
> corrupt, we need anot
You know where Option1 will drive us?
When the added metadata which hides current corruption will become
corrupt, we need another layer.
At the end, it will look like a big onion. :)
Where will Option2 will get us?
The new repo will get corrupted again.
Unless the policy of repo-ing something will
current repo for all new
>>>>>>> artifacts.
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Moving over to dev...
>>>>&g
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:
> 1) defined rules for what an "acceptable" artifact is
> 2) gating central with those rules
Any time when I referred to
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
as a requirement, I always had a bad feeling.
Why? Requirement is what you can verify against, but this m
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 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.
21 matches
Mail list logo
