Re: artifact versioning WAS: >>> Can you override remote repositories

[Brett Porter <bp...@f2network.com.au>]

I think I've seen it with other JARs, but I'll wait until I see a 
concrete example before sending it back to the list.

By the other discussions going on, it sounds like the 
SNAPSHOT/dev/release problems are being thought through and resolved well.

My 2 cents...

Personally, I'd be happy with automatically timestamped builds instead 
of SNAPSHOT for build repeatability. The concept of latest can be 
replaced by depending on a POM that checks out/updates to CVS HEAD (or a 
branch) and builds another project via reactor, which I believe is 
already planned?

It'd also be nice to have a dependency on a jelly script that you could 
write to hook into a legacy/other build mechanism like Ant or otherwise. 
But that probably works as is with a project that has just a project.xml 
and maven.xml in its base directory to activate the other mechanism.

I like the idea of repository metadata as a supplement, but not a 
dependency. I don't the repo directory screwed up because the metadata 
is broken, and adding a JAR should be no more complicated than putting 
it in the directory. Any metadata can probably be encapsulated in a POM 
anyway.

Cheers,
Brett

Ben Walding wrote:
> It "should" only be downloading from both in the case of SNAPSHOT 
> artifacts.  Normal artifacts should not differ between repositories.
> 
> Frankly, the concept that "the developer rereleased a jar with the same, 
> but different contents" disturbs me.  It's just bad form.
> 
> The exception to this seems to be -dev jars at the moment, but I'm not 
> convinced that is a good idea either.
> 
> Brett Porter wrote:
> 
>> Interestingly, if you do (2), maven seems to download from both of 
>> these in order - can the developers enlighten me if there a reason for 
>> this?
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

-- 
Web Developer
f2 network ~ everything essential
02 8596 4437


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: artifact versioning WAS: >>> Can you override remote repositories

[Rafal Krzewski <Ra...@caltha.pl>]

Brett Porter wrote:
> Personally, I'd be happy with automatically timestamped builds instead
> of SNAPSHOT for build repeatability. The concept of latest can be
> replaced by depending on a POM that checks out/updates to CVS HEAD (or a
> branch) and builds another project via reactor, which I believe is
> already planned?

I don't know of any high level support for "build me version x of this
project" functionality being present of planned that would make use of
branches or versions elements of POM. AFAIK those are used solely for
documentation generation.

> It'd also be nice to have a dependency on a jelly script that you could
> write to hook into a legacy/other build mechanism like Ant or otherwise.
> But that probably works as is with a project that has just a project.xml
> and maven.xml in its base directory to activate the other mechanism.

I don't quite understand what you mean by 'dependency on a jelly
script'. Plugging in legacy build mechnisms using Ant is easy as things
stand today.

> I like the idea of repository metadata as a supplement, but not a
> dependency. I don't the repo directory screwed up because the metadata
> is broken, and adding a JAR should be no more complicated than putting
> it in the directory. Any metadata can probably be encapsulated in a POM
> anyway.

You meant 'as a requirement'? (Re)generating metadata information from
the files existing in the repository can be done with a simple shell
script, so I don't think this is a major problem. As for deployment,
when you deploy with maven, modifying the metadata file would done
automatically, when not - it's easy enough to do by hand if we use
date.time timestamps.

As for encaplulating metadata in POM - you don't really want to have
the information about each and every deployed SNAPSHOT jar in your POM.
Available versions (1.0, 1.1...) is a feature of the project, but
available snapshots (1.1-20020520.092911, 1.1-200205020105450, ...) is
a feature of the repository.

R.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org