You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Orjan Austvold <au...@colibria.com> on 2006/05/19 23:08:48 UTC
time-constrained repository instability
During the last 8-10 months we have experienced several updates in
already released artifacts in the maven repository at Ibiblio. Many of
these has been caused by reports to Maven evangelism.
For us this has been extremely problematic since the time of download of
dependencies causes developers to have different POMs in their local
repository. For us this has caused our projects to produce different
builds dependent on which developer made the build and at which time the
build was made.
Personally I strongly believe in once an artifact has been released --
with or without errors in the artifacts POM -- it should be left in the
state it's in. If a change is required due to a malformed POM, a missing
groupId, non-existing parent, missing dependency, wrong scope of a
dependency or the alike, it should be left in the state it is in. If an
update is required a new version should be released.
Due to the instability of released artifacts at Ibiblio we are now
considering setting up our own repository (not a mirror and not a
maven-proxy repository) to gain complete control over changes in
released POMs. Of course this is not the intention of Maven 2.
Please comment.
Thanks,
Ørjan Austvold
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Brad Davis <bd...@saintandreas.org>.
I have to agree that public repositories should essentially be
write-once media. As Maven grows in popularity, the repositories are
going to need to be stable and artifact deployment will need to become
an atomic operation.
Brad
Orjan Austvold wrote:
> During the last 8-10 months we have experienced several updates in
> already released artifacts in the maven repository at Ibiblio. Many of
> these has been caused by reports to Maven evangelism.
>
> For us this has been extremely problematic since the time of download
> of dependencies causes developers to have different POMs in their
> local repository. For us this has caused our projects to produce
> different builds dependent on which developer made the build and at
> which time the build was made.
>
> Personally I strongly believe in once an artifact has been released --
> with or without errors in the artifacts POM -- it should be left in
> the state it's in. If a change is required due to a malformed POM, a
> missing groupId, non-existing parent, missing dependency, wrong scope
> of a dependency or the alike, it should be left in the state it is in.
> If an update is required a new version should be released.
>
> Due to the instability of released artifacts at Ibiblio we are now
> considering setting up our own repository (not a mirror and not a
> maven-proxy repository) to gain complete control over changes in
> released POMs. Of course this is not the intention of Maven 2.
>
> Please comment.
>
>
>
> Thanks,
> Ørjan Austvold
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: some questions
Posted by Stefan Hübner <st...@googlemail.com>.
Hi Thorsten,
2006/5/20, Thorsten Düvelmeyer <Th...@online.de>:
> Hello,
>
> i'm quiet new with maven and have these questions:
> In the maven2 book a read: "To set up Jetty, download the Jetty 5.1.10
> server bundle from the book's Web site and copy it to the repository
> directory". Does anyone have a link for me? I didn't found it yet?
go to http://jetty.mortbay.org/jetty/index.html. you should find what
you're looking for.
>
> Where i can find the Repository Manager?
That one isn't ready yet. Its development seems to be lacking progress...
>
> How i can put all needed files into the shared repository? Just copy it
> from the local repo? Can I bring up a shared repository with a normal
> web server (IIS)?
What exactly do you mean by "shared" repository? If you're going to
establish a company wide repository, see the description at
http://maven.apache.org/guides/introduction/introduction-to-repositories.html
(chapter "Internal Repositories").
Once set up, you can deploy 3rd-party-files by invoking "mvn
deploy:deploy-file". see description of deploy plugin for further
details on usage.
>
> What is the easiest way to make a developer maven installation make
> working
> with the new shared repo instead of repo1.maven.org? What is to do for
> eclipse?
>
have a look at http://maven.apache.org/guides/index.html (chapter
"development guides").
> And my last one:
> I have a Serena Version Manager as SCM plattform. Can i work with
> continuum and version manager? I don't found a plugin ;-(
> What I tried is a file as scm connection, but than I only get a
> "No file changed" and in the output window "Error:" with no exception
>
sorry Thorsten, no clue on that one.
cheers,
Stefan
some questions
Posted by Thorsten Düvelmeyer <Th...@online.de>.
Hello,
i'm quiet new with maven and have these questions:
In the maven2 book a read: "To set up Jetty, download the Jetty 5.1.10
server bundle from the book's Web site and copy it to the repository
directory". Does anyone have a link for me? I didn't found it yet?
Where i can find the Repository Manager?
How i can put all needed files into the shared repository? Just copy it
from the local repo? Can I bring up a shared repository with a normal
web server (IIS)?
What is the easiest way to make a developer maven installation make
working
with the new shared repo instead of repo1.maven.org? What is to do for
eclipse?
And my last one:
I have a Serena Version Manager as SCM plattform. Can i work with
continuum and version manager? I don't found a plugin ;-(
What I tried is a file as scm connection, but than I only get a
"No file changed" and in the output window "Error:" with no exception
Thanks!
Thorsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Orjan Austvold <au...@colibria.com>.
Dennis Lundberg wrote:
> For projects that use Maven for building and releasing your idea is
> good. But for projects that does not have a POM of their own this
> doesn't work. Most of the issues in MEV are for projects without POMs.
> The POMs that get uploaded to these issues are often not made by the
> people *responsible* for the project but by people *using* the
> project. Because of this errors do occur in these POMs more often than
> one would like.
>
>
I am in total appreciation of the effort that volunteers do for making
non-mavenized project available on Ibiblio. Anyhow this does not change
my opinion that published POMs should not be changed. If a change in a
POM is required then a new version of the artifact should be published.
Ørjan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Orjan Austvold <au...@colibria.com>.
Brett Porter wrote:
> So I'm seeing two different solutions here that seem to address things
> a bit differently.
>
> 1) hashing to double check whether something has changed
>
> This has actually been suggested in the context of the JAR - so
> perhaps the hash to use is that of the dependency artifact and it's
> pom combined. It can be written in as an element at release time, and
> used to either warn or fail a build if it is no longer consistent.
>
I would very much like for a build to succeed consistently after it has
been created. Allowing for something to change depending on the time of
download of dependencies does not seem like an attractive solution.
> 2) revision the POMs to allow them to change.
>
> It hasn't been nailed down but the last time I thought about this, it
> would be along the lines of a new element in the <dependency>
> declaration (<revision/>). If absent, you'd get the latest revision
> (so you would pick up changes along the way if they occurred). At
> release the release plugin (or yourself) could lock in the <revision>
> element to ensure that reproducibility occurs.
>
This could work if the <revision> element on released artifacts locked
down the revision version on every dependency at the time of release.
> While this would facilitate making changes, they should still be
> heavily discouraged. While I'd like to just lock it down, the fact
> that very popular POMs (spring, hibernate) have needed significant and
> sometimes frequent fixes has made this impossible.
>
> However, other improvements should come hand in hand to make it less
> of an issue:
> - repository manager improvements to better validate incoming POMs
Unfortunately the quality of Maven is heavily dependent on the quality
of the repository. A validation of incoming POMs (beyond syntactial
validation?) is welcomed.
>
> - dependency management improvements to cover the use cases why they
> are changed
> - changes to static vs dynamic metadata (this is another use case for
> the revisions above - eg, when you move your SVN but want to build an
> old release where the POM points to the old location - if that
> metadata is migrated then the revisions might not be necessary)
>
Good idea. Revisions should probably only change upon dependency changes.
> What do others think of this?
>
> Cheers,
> Brett
>
> On 19/05/06, Daniel Kulp <da...@kulp.com> wrote:
>>
>> The hash thing ONLY works for a limited set of changes to a
>> pom.xml. For
>> example, in the past there have been changes that affect dependencies
>> like changing scopes from runtime to provided or similar. I've also
>> seen changes to poms that change groupIds of dependencies (that were
>> also
>> moved in the repository).
>>
>> Many of those changes would (and did) cause build breakages even if the
>> md5 hash thing was done. Until they REALLY do limit the changes to
>> those that are COMPLETELY safe, we're all at risk. Then the question
>> DOES arise: how WOULD they make changes like dependency changes, etc..?
>>
>> Dan
>>
>>
>> On Friday 19 May 2006 18:56, Wayne Fay wrote:
>> > -Or- like I said in my previous email (and unless I'm mistaken, what I
>> > believe the Maven team is planning on implementing), they should add
>> > hashing of the pom itself and check that file in addition to the
>> > binary jar when looking for and downloading updates.
>> >
>> > This is also a reasonable fix to the solution, imo. Especially
>> > considering the "difficulty" related to matching poms with a certain
>> > version tag to binaries with another version tag (ie 1.4.2-rc1 and
>> > -rc2 vs 1.4.2, etc).
>> >
>> > Wayne
>> >
>> > On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
>> > > Daniel Kulp wrote:
>> > > > Right. But if an error is detected in a pom, why does the pom
>> have
>> > > > to be updated. For example, if there is a:
>> > > >
>> > > > foo/1.0/foo-1.0.pom
>> > > >
>> > > > why can't we do something like Gentoo Linux and leave that alone
>> > > > and then add a:
>> > > > foo/1.0-R2/foo-1.0-R2.pom
>> > > >
>> > > > It's stilll "foo 1.0 as release by the foo developers", but its
>> the
>> > > > R2 "update" as far as the maven repository is concerned. If the
>> > > > foo developers produce a 1.0.1, fine. We create a:
>> > > > foo/1.0.1/foo-1.0.1.pom
>> > > >
>> > > > Thus, existing apps and such that depend on the broken behavior
>> are
>> > > > OK and others can migrate to the "correct" poms as needed.
>> > > >
>> > > > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a
>> > > > release, correct or broken, should stay that way.
>> > >
>> > > Right on, Daniel! Introduction of non-maven artifacts could adopt
>> the
>> > > scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized
>> released
>> > > in which versions numbers could document a change made by "Maven"
>> > > number X. Every change in a fixed release of the artifact (POM or
>> > > whatever) would increase the X.
>> > >
>> > > A release to the repository has to be write-once. If this is not
>> > > true, then Maven has to come with a footnote telling everybody to
>> > > delete their local repository if a build goes astray.
>> > >
>> > >
>> > > Ørjan
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>>
>> --
>> J. Daniel Kulp
>> dan@kulp.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Brett Porter <br...@gmail.com>.
So I'm seeing two different solutions here that seem to address things
a bit differently.
1) hashing to double check whether something has changed
This has actually been suggested in the context of the JAR - so
perhaps the hash to use is that of the dependency artifact and it's
pom combined. It can be written in as an element at release time, and
used to either warn or fail a build if it is no longer consistent.
2) revision the POMs to allow them to change.
It hasn't been nailed down but the last time I thought about this, it
would be along the lines of a new element in the <dependency>
declaration (<revision/>). If absent, you'd get the latest revision
(so you would pick up changes along the way if they occurred). At
release the release plugin (or yourself) could lock in the <revision>
element to ensure that reproducibility occurs.
While this would facilitate making changes, they should still be
heavily discouraged. While I'd like to just lock it down, the fact
that very popular POMs (spring, hibernate) have needed significant and
sometimes frequent fixes has made this impossible.
However, other improvements should come hand in hand to make it less
of an issue:
- repository manager improvements to better validate incoming POMs
- dependency management improvements to cover the use cases why they are changed
- changes to static vs dynamic metadata (this is another use case for
the revisions above - eg, when you move your SVN but want to build an
old release where the POM points to the old location - if that
metadata is migrated then the revisions might not be necessary)
What do others think of this?
Cheers,
Brett
On 19/05/06, Daniel Kulp <da...@kulp.com> wrote:
>
> The hash thing ONLY works for a limited set of changes to a pom.xml. For
> example, in the past there have been changes that affect dependencies
> like changing scopes from runtime to provided or similar. I've also
> seen changes to poms that change groupIds of dependencies (that were also
> moved in the repository).
>
> Many of those changes would (and did) cause build breakages even if the
> md5 hash thing was done. Until they REALLY do limit the changes to
> those that are COMPLETELY safe, we're all at risk. Then the question
> DOES arise: how WOULD they make changes like dependency changes, etc..?
>
> Dan
>
>
> On Friday 19 May 2006 18:56, Wayne Fay wrote:
> > -Or- like I said in my previous email (and unless I'm mistaken, what I
> > believe the Maven team is planning on implementing), they should add
> > hashing of the pom itself and check that file in addition to the
> > binary jar when looking for and downloading updates.
> >
> > This is also a reasonable fix to the solution, imo. Especially
> > considering the "difficulty" related to matching poms with a certain
> > version tag to binaries with another version tag (ie 1.4.2-rc1 and
> > -rc2 vs 1.4.2, etc).
> >
> > Wayne
> >
> > On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
> > > Daniel Kulp wrote:
> > > > Right. But if an error is detected in a pom, why does the pom have
> > > > to be updated. For example, if there is a:
> > > >
> > > > foo/1.0/foo-1.0.pom
> > > >
> > > > why can't we do something like Gentoo Linux and leave that alone
> > > > and then add a:
> > > > foo/1.0-R2/foo-1.0-R2.pom
> > > >
> > > > It's stilll "foo 1.0 as release by the foo developers", but its the
> > > > R2 "update" as far as the maven repository is concerned. If the
> > > > foo developers produce a 1.0.1, fine. We create a:
> > > > foo/1.0.1/foo-1.0.1.pom
> > > >
> > > > Thus, existing apps and such that depend on the broken behavior are
> > > > OK and others can migrate to the "correct" poms as needed.
> > > >
> > > > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a
> > > > release, correct or broken, should stay that way.
> > >
> > > Right on, Daniel! Introduction of non-maven artifacts could adopt the
> > > scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released
> > > in which versions numbers could document a change made by "Maven"
> > > number X. Every change in a fixed release of the artifact (POM or
> > > whatever) would increase the X.
> > >
> > > A release to the repository has to be write-once. If this is not
> > > true, then Maven has to come with a footnote telling everybody to
> > > delete their local repository if a build goes astray.
> > >
> > >
> > > Ørjan
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> --
> J. Daniel Kulp
> dan@kulp.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Daniel Kulp <da...@kulp.com>.
The hash thing ONLY works for a limited set of changes to a pom.xml. For
example, in the past there have been changes that affect dependencies
like changing scopes from runtime to provided or similar. I've also
seen changes to poms that change groupIds of dependencies (that were also
moved in the repository).
Many of those changes would (and did) cause build breakages even if the
md5 hash thing was done. Until they REALLY do limit the changes to
those that are COMPLETELY safe, we're all at risk. Then the question
DOES arise: how WOULD they make changes like dependency changes, etc..?
Dan
On Friday 19 May 2006 18:56, Wayne Fay wrote:
> -Or- like I said in my previous email (and unless I'm mistaken, what I
> believe the Maven team is planning on implementing), they should add
> hashing of the pom itself and check that file in addition to the
> binary jar when looking for and downloading updates.
>
> This is also a reasonable fix to the solution, imo. Especially
> considering the "difficulty" related to matching poms with a certain
> version tag to binaries with another version tag (ie 1.4.2-rc1 and
> -rc2 vs 1.4.2, etc).
>
> Wayne
>
> On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
> > Daniel Kulp wrote:
> > > Right. But if an error is detected in a pom, why does the pom have
> > > to be updated. For example, if there is a:
> > >
> > > foo/1.0/foo-1.0.pom
> > >
> > > why can't we do something like Gentoo Linux and leave that alone
> > > and then add a:
> > > foo/1.0-R2/foo-1.0-R2.pom
> > >
> > > It's stilll "foo 1.0 as release by the foo developers", but its the
> > > R2 "update" as far as the maven repository is concerned. If the
> > > foo developers produce a 1.0.1, fine. We create a:
> > > foo/1.0.1/foo-1.0.1.pom
> > >
> > > Thus, existing apps and such that depend on the broken behavior are
> > > OK and others can migrate to the "correct" poms as needed.
> > >
> > > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a
> > > release, correct or broken, should stay that way.
> >
> > Right on, Daniel! Introduction of non-maven artifacts could adopt the
> > scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released
> > in which versions numbers could document a change made by "Maven"
> > number X. Every change in a fixed release of the artifact (POM or
> > whatever) would increase the X.
> >
> > A release to the repository has to be write-once. If this is not
> > true, then Maven has to come with a footnote telling everybody to
> > delete their local repository if a build goes astray.
> >
> >
> > Ørjan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
J. Daniel Kulp
dan@kulp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Max Cooper <ma...@maxcooper.com>.
I do think this is an important issue.
I like the hash idea. A positive side effect of using hashes is that
they can help recover from a bad file transfer. I see hashes for POMs
already. This discussion makes me think they are not used.
One potential downside of incrementing the version number in these cases
is that it could result in a cascade of updates. Consider a
multi-project that produces 5 jars. 4 of the jars depend on the 5th jar.
If the 5th jar got deployed poorly, the operation to fix it should
include updating the version of all 5 jars so that the other 4 point to
the "fixed" 5th jar.
-Max
Wayne Fay wrote:
> -Or- like I said in my previous email (and unless I'm mistaken, what I
> believe the Maven team is planning on implementing), they should add
> hashing of the pom itself and check that file in addition to the
> binary jar when looking for and downloading updates.
>
> This is also a reasonable fix to the solution, imo. Especially
> considering the "difficulty" related to matching poms with a certain
> version tag to binaries with another version tag (ie 1.4.2-rc1 and
> -rc2 vs 1.4.2, etc).
>
> Wayne
>
> On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
>
>> Daniel Kulp wrote:
>> > Right. But if an error is detected in a pom, why does the pom have
>> to be
>> > updated. For example, if there is a:
>> >
>> > foo/1.0/foo-1.0.pom
>> >
>> > why can't we do something like Gentoo Linux and leave that alone and
>> then
>> > add a:
>> > foo/1.0-R2/foo-1.0-R2.pom
>> >
>> > It's stilll "foo 1.0 as release by the foo developers", but its the R2
>> > "update" as far as the maven repository is concerned. If the foo
>> > developers produce a 1.0.1, fine. We create a:
>> > foo/1.0.1/foo-1.0.1.pom
>> >
>> > Thus, existing apps and such that depend on the broken behavior are
>> OK and
>> > others can migrate to the "correct" poms as needed.
>> >
>> > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
>> > correct or broken, should stay that way.
>> >
>> >
>>
>>
>> Right on, Daniel! Introduction of non-maven artifacts could adopt the
>> scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released in
>> which versions numbers could document a change made by "Maven" number X.
>> Every change in a fixed release of the artifact (POM or whatever) would
>> increase the X.
>>
>> A release to the repository has to be write-once. If this is not true,
>> then Maven has to come with a footnote telling everybody to delete their
>> local repository if a build goes astray.
>>
>>
>> Ørjan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Carlos Sanchez <ca...@apache.org>.
Some light into this:
Now POMs are not modified NEVER except the following cases:
- sintactically incorrect pom (eg. wrong xml): the pom couldn't work
before, so changing it should be a problem except for that people that
dowloaded it being wrong, that need to delete it, anyway it was broken
- adding info that doesn't affect the build (eg. license, scm, description,...)
- the pom didn't exist before. If you depend on a jar without pom
you'll get warnings. You should provide a pom for upload as somebody
else may upload it later and break your build.
On 5/19/06, Wayne Fay <wa...@gmail.com> wrote:
> -Or- like I said in my previous email (and unless I'm mistaken, what I
> believe the Maven team is planning on implementing), they should add
> hashing of the pom itself and check that file in addition to the
> binary jar when looking for and downloading updates.
>
> This is also a reasonable fix to the solution, imo. Especially
> considering the "difficulty" related to matching poms with a certain
> version tag to binaries with another version tag (ie 1.4.2-rc1 and
> -rc2 vs 1.4.2, etc).
>
> Wayne
>
> On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
> > Daniel Kulp wrote:
> > > Right. But if an error is detected in a pom, why does the pom have to be
> > > updated. For example, if there is a:
> > >
> > > foo/1.0/foo-1.0.pom
> > >
> > > why can't we do something like Gentoo Linux and leave that alone and then
> > > add a:
> > > foo/1.0-R2/foo-1.0-R2.pom
> > >
> > > It's stilll "foo 1.0 as release by the foo developers", but its the R2
> > > "update" as far as the maven repository is concerned. If the foo
> > > developers produce a 1.0.1, fine. We create a:
> > > foo/1.0.1/foo-1.0.1.pom
> > >
> > > Thus, existing apps and such that depend on the broken behavior are OK and
> > > others can migrate to the "correct" poms as needed.
> > >
> > > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
> > > correct or broken, should stay that way.
> > >
> > >
> >
> >
> > Right on, Daniel! Introduction of non-maven artifacts could adopt the
> > scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released in
> > which versions numbers could document a change made by "Maven" number X.
> > Every change in a fixed release of the artifact (POM or whatever) would
> > increase the X.
> >
> > A release to the repository has to be write-once. If this is not true,
> > then Maven has to come with a footnote telling everybody to delete their
> > local repository if a build goes astray.
> >
> >
> > Ørjan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Wayne Fay <wa...@gmail.com>.
-Or- like I said in my previous email (and unless I'm mistaken, what I
believe the Maven team is planning on implementing), they should add
hashing of the pom itself and check that file in addition to the
binary jar when looking for and downloading updates.
This is also a reasonable fix to the solution, imo. Especially
considering the "difficulty" related to matching poms with a certain
version tag to binaries with another version tag (ie 1.4.2-rc1 and
-rc2 vs 1.4.2, etc).
Wayne
On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
> Daniel Kulp wrote:
> > Right. But if an error is detected in a pom, why does the pom have to be
> > updated. For example, if there is a:
> >
> > foo/1.0/foo-1.0.pom
> >
> > why can't we do something like Gentoo Linux and leave that alone and then
> > add a:
> > foo/1.0-R2/foo-1.0-R2.pom
> >
> > It's stilll "foo 1.0 as release by the foo developers", but its the R2
> > "update" as far as the maven repository is concerned. If the foo
> > developers produce a 1.0.1, fine. We create a:
> > foo/1.0.1/foo-1.0.1.pom
> >
> > Thus, existing apps and such that depend on the broken behavior are OK and
> > others can migrate to the "correct" poms as needed.
> >
> > Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
> > correct or broken, should stay that way.
> >
> >
>
>
> Right on, Daniel! Introduction of non-maven artifacts could adopt the
> scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released in
> which versions numbers could document a change made by "Maven" number X.
> Every change in a fixed release of the artifact (POM or whatever) would
> increase the X.
>
> A release to the repository has to be write-once. If this is not true,
> then Maven has to come with a footnote telling everybody to delete their
> local repository if a build goes astray.
>
>
> Ørjan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Orjan Austvold <au...@colibria.com>.
Daniel Kulp wrote:
> Right. But if an error is detected in a pom, why does the pom have to be
> updated. For example, if there is a:
>
> foo/1.0/foo-1.0.pom
>
> why can't we do something like Gentoo Linux and leave that alone and then
> add a:
> foo/1.0-R2/foo-1.0-R2.pom
>
> It's stilll "foo 1.0 as release by the foo developers", but its the R2
> "update" as far as the maven repository is concerned. If the foo
> developers produce a 1.0.1, fine. We create a:
> foo/1.0.1/foo-1.0.1.pom
>
> Thus, existing apps and such that depend on the broken behavior are OK and
> others can migrate to the "correct" poms as needed.
>
> Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
> correct or broken, should stay that way.
>
>
Right on, Daniel! Introduction of non-maven artifacts could adopt the
scheme from Gentoo (or Debian (Ubuntu)) to provide mavenized released in
which versions numbers could document a change made by "Maven" number X.
Every change in a fixed release of the artifact (POM or whatever) would
increase the X.
A release to the repository has to be write-once. If this is not true,
then Maven has to come with a footnote telling everybody to delete their
local repository if a build goes astray.
Ørjan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Brett Porter <br...@gmail.com>.
This is pretty much the solution we last discussed for inclusion in Maven 2.1.
- Brett
On 19/05/06, Daniel Kulp <da...@iona.com> wrote:
> On Friday 19 May 2006 17:23, Dennis Lundberg wrote:
> > > Personally I strongly believe in once an artifact has been released
> > > -- with or without errors in the artifacts POM -- it should be left
> > > in the state it's in. If a change is required due to a malformed POM,
> > > a missing groupId, non-existing parent, missing dependency, wrong
> > > scope of a dependency or the alike, it should be left in the state it
> > > is in. If an update is required a new version should be released.
> >
> > For projects that use Maven for building and releasing your idea is
> > good. But for projects that does not have a POM of their own this
> > doesn't work. Most of the issues in MEV are for projects without POMs.
> > The POMs that get uploaded to these issues are often not made by the
> > people *responsible* for the project but by people *using* the project.
> > Because of this errors do occur in these POMs more often than one would
> > like.
>
> Right. But if an error is detected in a pom, why does the pom have to be
> updated. For example, if there is a:
>
> foo/1.0/foo-1.0.pom
>
> why can't we do something like Gentoo Linux and leave that alone and then
> add a:
> foo/1.0-R2/foo-1.0-R2.pom
>
> It's stilll "foo 1.0 as release by the foo developers", but its the R2
> "update" as far as the maven repository is concerned. If the foo
> developers produce a 1.0.1, fine. We create a:
> foo/1.0.1/foo-1.0.1.pom
>
> Thus, existing apps and such that depend on the broken behavior are OK and
> others can migrate to the "correct" poms as needed.
>
> Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
> correct or broken, should stay that way.
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Daniel Kulp <da...@iona.com>.
On Friday 19 May 2006 17:23, Dennis Lundberg wrote:
> > Personally I strongly believe in once an artifact has been released
> > -- with or without errors in the artifacts POM -- it should be left
> > in the state it's in. If a change is required due to a malformed POM,
> > a missing groupId, non-existing parent, missing dependency, wrong
> > scope of a dependency or the alike, it should be left in the state it
> > is in. If an update is required a new version should be released.
>
> For projects that use Maven for building and releasing your idea is
> good. But for projects that does not have a POM of their own this
> doesn't work. Most of the issues in MEV are for projects without POMs.
> The POMs that get uploaded to these issues are often not made by the
> people *responsible* for the project but by people *using* the project.
> Because of this errors do occur in these POMs more often than one would
> like.
Right. But if an error is detected in a pom, why does the pom have to be
updated. For example, if there is a:
foo/1.0/foo-1.0.pom
why can't we do something like Gentoo Linux and leave that alone and then
add a:
foo/1.0-R2/foo-1.0-R2.pom
It's stilll "foo 1.0 as release by the foo developers", but its the R2
"update" as far as the maven repository is concerned. If the foo
developers produce a 1.0.1, fine. We create a:
foo/1.0.1/foo-1.0.1.pom
Thus, existing apps and such that depend on the broken behavior are OK and
others can migrate to the "correct" poms as needed.
Anyway, I COMPLETELY agree that stuff put up on ibiblio as a release,
correct or broken, should stay that way.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Dennis Lundberg <de...@apache.org>.
Orjan Austvold wrote:
> During the last 8-10 months we have experienced several updates in
> already released artifacts in the maven repository at Ibiblio. Many of
> these has been caused by reports to Maven evangelism.
>
> For us this has been extremely problematic since the time of download of
> dependencies causes developers to have different POMs in their local
> repository. For us this has caused our projects to produce different
> builds dependent on which developer made the build and at which time the
> build was made.
>
> Personally I strongly believe in once an artifact has been released --
> with or without errors in the artifacts POM -- it should be left in the
> state it's in. If a change is required due to a malformed POM, a missing
> groupId, non-existing parent, missing dependency, wrong scope of a
> dependency or the alike, it should be left in the state it is in. If an
> update is required a new version should be released.
For projects that use Maven for building and releasing your idea is
good. But for projects that does not have a POM of their own this
doesn't work. Most of the issues in MEV are for projects without POMs.
The POMs that get uploaded to these issues are often not made by the
people *responsible* for the project but by people *using* the project.
Because of this errors do occur in these POMs more often than one would
like.
> Due to the instability of released artifacts at Ibiblio we are now
> considering setting up our own repository (not a mirror and not a
> maven-proxy repository) to gain complete control over changes in
> released POMs. Of course this is not the intention of Maven 2.
If you have strict requirements on reproducible builds this is sounds
like a good plan. If you don't have that many dependencies it should not
require so much work.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: JavaNCSS Plugin for Maven2.0
Posted by Wayne Fay <wa...@gmail.com>.
Snapshots are not deployed to ibiblio.
You need to add the proper repository to your pom. I'm not positive
where this plugin "lives" but I'm sure this is discussed in the Maven
User email archive somewhere if you just search.
Wayne
On 5/19/06, sambit kumar dikshit <sa...@apple.com> wrote:
> Hi,
>
> I'm trying to use JavaNCSS plugin for Maven 2.0. Im facing some
> problem while trying to run the mvn site:site command.
>
> I have added the following lines in my pom.xml
>
>
>
> <repositories>
> <repository>
> <id>Ibiblio.org</id>
> <url>http://www.ibiblio.org/maven2/</url>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> <releases>
> <enabled>false</enabled>
> </releases>
> </repository>
> </repositories>
>
> <plugin>
> <groupId>maven-plugins</groupId>
> <artifactId>maven-javancss-plugin</artifactId>
>
> </plugin>
>
> Can anyone help me out on this.
>
> Regards
> -Sambit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
JavaNCSS Plugin for Maven2.0
Posted by sambit kumar dikshit <sa...@apple.com>.
Hi,
I'm trying to use JavaNCSS plugin for Maven 2.0. Im facing some
problem while trying to run the mvn site:site command.
I have added the following lines in my pom.xml
<repositories>
<repository>
<id>Ibiblio.org</id>
<url>http://www.ibiblio.org/maven2/</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<plugin>
<groupId>maven-plugins</groupId>
<artifactId>maven-javancss-plugin</artifactId>
</plugin>
Can anyone help me out on this.
Regards
-Sambit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Orjan Austvold <au...@colibria.com>.
Wayne Fay wrote:
> In the meantime, this problem can easily be solved by "blowing away"
> your local m2 repo periodically and allowing artifacts to be
> re-downloaded from scratch. Not an ideal solution, but it is
> effective, and relatively simply to accomplish.
>
This would work fine by me as I am an Maven-addict, but I cannot force
developers in my organization to do same.
> The trouble with requiring a bump in the version number to reflect a
> change in the pom should be obvious -- for 99% of the artifacts in the
> Maven repo, the Maven team has no control over the project itself,
> they are merely publishing the pom and Maven bundles for our use.
> Thus, the Maven project cannot simply bump a project from 1.2.5 to
> 1.2.6 simply because a bad pom exists in the repo.
>
That's true. But someone is doing the fix of the POM for the project. My
point is that the version number of the fix of the POM should reflect
that the POM is different from what was released initially. Version
1.2.5 of something could then be released as 1.2-5-be-aware-im-fixed-1.
Ørjan
> Wayne
>
> On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
>> During the last 8-10 months we have experienced several updates in
>> already released artifacts in the maven repository at Ibiblio. Many of
>> these has been caused by reports to Maven evangelism.
>>
>> For us this has been extremely problematic since the time of download of
>> dependencies causes developers to have different POMs in their local
>> repository. For us this has caused our projects to produce different
>> builds dependent on which developer made the build and at which time the
>> build was made.
>>
>> Personally I strongly believe in once an artifact has been released --
>> with or without errors in the artifacts POM -- it should be left in the
>> state it's in. If a change is required due to a malformed POM, a missing
>> groupId, non-existing parent, missing dependency, wrong scope of a
>> dependency or the alike, it should be left in the state it is in. If an
>> update is required a new version should be released.
>>
>> Due to the instability of released artifacts at Ibiblio we are now
>> considering setting up our own repository (not a mirror and not a
>> maven-proxy repository) to gain complete control over changes in
>> released POMs. Of course this is not the intention of Maven 2.
>>
>> Please comment.
>>
>>
>>
>> Thanks,
>> Ørjan Austvold
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: time-constrained repository instability
Posted by Wayne Fay <wa...@gmail.com>.
I believe this is also a valid complaint/problem, and I know this is
something the Maven dev team is working on for future Maven versions,
perhaps even 2.1, by including md5 for the poms themselves and
checking for changes to both the poms and the jars. So I think
everyone agrees with you in principle.
In the meantime, this problem can easily be solved by "blowing away"
your local m2 repo periodically and allowing artifacts to be
re-downloaded from scratch. Not an ideal solution, but it is
effective, and relatively simply to accomplish.
The trouble with requiring a bump in the version number to reflect a
change in the pom should be obvious -- for 99% of the artifacts in the
Maven repo, the Maven team has no control over the project itself,
they are merely publishing the pom and Maven bundles for our use.
Thus, the Maven project cannot simply bump a project from 1.2.5 to
1.2.6 simply because a bad pom exists in the repo.
Wayne
On 5/19/06, Orjan Austvold <au...@colibria.com> wrote:
> During the last 8-10 months we have experienced several updates in
> already released artifacts in the maven repository at Ibiblio. Many of
> these has been caused by reports to Maven evangelism.
>
> For us this has been extremely problematic since the time of download of
> dependencies causes developers to have different POMs in their local
> repository. For us this has caused our projects to produce different
> builds dependent on which developer made the build and at which time the
> build was made.
>
> Personally I strongly believe in once an artifact has been released --
> with or without errors in the artifacts POM -- it should be left in the
> state it's in. If a change is required due to a malformed POM, a missing
> groupId, non-existing parent, missing dependency, wrong scope of a
> dependency or the alike, it should be left in the state it is in. If an
> update is required a new version should be released.
>
> Due to the instability of released artifacts at Ibiblio we are now
> considering setting up our own repository (not a mirror and not a
> maven-proxy repository) to gain complete control over changes in
> released POMs. Of course this is not the intention of Maven 2.
>
> Please comment.
>
>
>
> Thanks,
> Ørjan Austvold
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org