RE: [RANT] This Maven thing is killing us....

[Steve Loughran]

Jason van Zyl wrote:

>
> On 4 Jul 06, at 1:45 PM 4 Jul 06, Steve Loughran wrote:
>>
>> In a way, many of the stuff in M2 is experimental; a build tool that
>> effectively encodes beliefs about how a project should be structured
>> and delivered, focusing on component-based development instead of
>> application dev. I also think its time to look at how well some of the
>> experiment is working.
>>
>
> You make it sound like we're some sort of cult :-)

I think you are exploring cutting edge loosely coupled software
development processes. It's research. Interesting, fun research, but
research nonetheless. Just as Gump is an experiment in whether a unified
nightly build changes people's working processes.

I've been hanging round with semantic-web people recently, and have
devolved into using the word "belief" where they use "fact", because of
differences of opinion on what they and I think RDF triples are (they
think they're facts in a graph, I think every triple is a belief
published by an entity at a particular moment in time). The nice thing
about a belief-centric model is you get to accept the fact that
different entities have different beliefs, and a single entity/agent can
change its belief set, without ever having to worry about the fact that
the global belief-set is inconsistent.

in real agent-oriented-runtimes (still very much academic research, even
more than RDF engines), the resolver takes in to account the metadata
about which agent issued a belief statement and when during its
resolution process. Newer statements by the same entity can override
older ones; differences between entities are allowable but result in
ambiguities that may need to be dealt with further down the line.

When you apply the same agent-oriented view to POM metadata, you can say
"a POM file represents the pom author's beliefs about the artifact's
dependencies at the time they wrote the POM". It may be the beliefs
match what the artifact really needs, it may be those beliefs turn out
to be utterly wrong.

[interlude. I just grabbed the chair of the W3C RDF working group by the
coffee machine. Apparently "a belief is a state of mind", "a fact is
something that is believed". So all facts are beliefs, the only variable
being the number of believers]

Because the ibiblio repository contains fact/belief metadata from so
many sources, its that much harder to reconcile than those from single
entities. The good news is that we do have a very nice way to test these
assertions in java; running the program and seeing what classes get
loaded. So when someone is utterly wrong in their dependencies, its
pretty obvious. Its when they are slightly wrong, when they use some
classes in certain cases, often using reflection to bind at run time,
that you can get caught out.


>
> The phrase "encoding beliefs" is an inaccurate description. It's is
> simply the pursuit of best practices for software development and those
> practices are very much mutable, this thread being very good evidence of
> that. We also not only focused on component-oriented development, we
> ourselves develop applications ourselves and we're trying to make that
> coherent as well.

Ok. how about "encoding the team's ideas and experience in how to build
applications as sets of components, using
shared repositories to exchange components and their metadata"?

>
>> Personally, I always experience a bit of fear when adding a new
>> dependency to a project. the repository stuff, and estimate a couple
>> of hours to get every addition stable, primarily by building up a good
>> exclusion list.
>
> This is the place to talk about that as people shouldn't be fearful
> adding dependencies. But people who have an ideal setup here they
> completely control the repository they use internally don't have many of
> the problems that people are experiencing in this thread. Having a
> public repository of high quality is not a trivial task.
>
>>
>> Is it worse than before? Better? Or just, well, different? and if
>> things are either worse or not as good as they could be, what can be
>> changed?
>>
>
> The process is absolutely better. The process couple with the public
> infrastructure we have now is problematic. Two very different things.
>
>> One underlying cause seems to be pom quality. Open source software dev
>> is a vast collection of loosely coupled projects, and what we get in
>> the repository in terms of metadata matches this model. Each project
>> produces artifacts that match their immediate needs, with POM files
>> that appear to work at the time of publishing. Maven then caches those
>> and freezes that metadata forever, even if it turns out that the
>> metadata was wrong.  There's far better coherence within Gump, where
>> the metadata is effectively maintained more by the gump team
>> themselves than by the individual projects.
>
> There is absolutely no way this is scalable over time. You are saying
> that a small group of people can maintain metadata for projects that
> they are not intimately involved with? That's like saying that people
> who live outside your community have a better chance at describing your
> community. I really just don't think that's possible. How many problems
> has Gump had over the years trying to maintain the metadata? Huge
> problems, almost never in sync with projects. You basically find out
> when it breaks and go back track most of the time. There is no doubt
> that the same process will happen with Maven where users of Maven will
> eventually make their metadata better but that will take time. Gump has
> been around for 5-6 years now. People are really only starting to use
> Maven 2.x which is closing in on being out for a year. I am will to bet
> in another year a great number of the problems seen in this thread will
> be gone. I would argue that Gump will not work precisely because it is
> not the projects themselves maintaining the metadata. Projects using
> Maven will eventually get it right because it provides some value to
> them to get it right.

Oh I agree, handwritten custom-coded stuff doesn't scale. That is the
price with that model, and it makes
it hard to use the same tools within your own build process. But it does
support the low-hanging-fruit of things that depend on commons-logging
yet who don't want logkit on their classpath.

Gump's problem is not just that the metadata is written by the gumpers,
and not the projects, but that the projects don't always care if the
build is broken. Getting someone to care about what happens to their
stuff downstream is the first step to fixing the problem. As more m2
takeup occurs, you should get a lot of that feedback in the system,
moving from the "please redist on the maven repository", to "please have
good metadata", before finally, the joy of silence, as everything works.

>
>>
>> Question is, what to do about it? And if the m2 repository was an
>> attempt to leave the problems of the M1 repository behind, has it worked?
>>
>
> To a large extent I would say we have fixed many of the problems on a
> technical level. Correctly the metadata and educating projects as to how
> best maintain is it is a social problem and a matter of education.
> Couple that with some automated integrity checks that will be performed
> by the repository manager.

Yes, I think more rigorousness on accepting poms would be good. People,
even apache projects, should not be able to submit an artifact to the
repository without
-everything you depend on being there. No unresolvable artifacts.
-no dependencies on -SNAPSHOT. I know, apache projects arent meant to
release in that mode, but Apache Muse managed it, with very bad
consequences downstream.
-a (manual) review of your dependencies. You, the submitter would get
told your dependencies; the repository mail list would somehow get a
submission note that listed the complete depends graph of that component.
-the repository analyzer has some (extensible) rules about generally
"bad" dependencies, those that should be flagged with a warning. Eg
junit.jar in the runtime, any of the xml implementations in there
(rather than just the stax/xml-apis api imports, use of commons-logging
over commons-logging-api".
-flag appearance of strongly-deprecated versions of things. e.g.
junit-3.7, anything else that is not in modern use and/or with security
holes.
-scan the artifacts to see which packages they publish; store a list of
all classes. Then scan their imports to see what they explicitly import.
Warn when something they import isnt published by anything they even
optionally depend upon.

we could have some fun there, given the appropriate amount of spare
time. I quite like the idea of .class level validation...

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

On 7/5/06, David Jencks <david_jencks@...> wrote:

>
> On Jul 4, 2006, at 6:33 PM, Brett Porter wrote:
>
> > On 5/07/2006 10:54 AM, David Jencks wrote:
> >> I think the process is somewhat broken and that the maven team is
> >> being far too strict about changing broken poms that were in fact
> >> installed by the maven team, not supplied by the project.
> >> (xmlbeans is the case in point for me).  I also think that
> >> traceability of where poms came from and under what auspices they
> >> are added to either the repository svn tree or ibiblio is sorely
> >> lacking.  (again xmlbeans being my sore spot).  We are in the
> >> situation where a pom appeared from an unknown source, is wrong,
> >> did not come from the project, and can't be updated.  Much as I
> >> like maven it's hard for me to see how this is going to lead to
> >> success.
> >
> > David,
> >
> > I thought we'd agreed to fix that up? I can't find the issue on it
> > other than http://jira.codehaus.org/browse/MEV-406 which is not the
> > one I recall (that one is about stax which is a whole other problem
> > beyond the scope of Maven too).
>
> that's the one.  The xmlbeans pom does not have the required stax-api
> dependency listed in it.  As that issue notes, Carlos declined to
> change the existing pom.  IIUC Carlos said I needed to get xmlbeans
> to produce the pom, which I am currently working on, see http://
> issues.apache.org/jira/browse/XMLBEANS-277

The problem is that people want a stable repo, you just have to check
this thread. If I could go back in time I wouldn't do the
autogeneration of poms.

Another issue I've already seen several times is patches to fix poms
that at the end where not the *right* fix. For instance people saying
that dependency A is missing, so it's added. Then somebody else uses
it differently and then dependency B is missing. I don't want that to
happen again.

>
> The xmlbeans team have agreed in principle to cooperate but have not
> in fact yet reviewed my first draft for things like correct urls.  I
> originally planned to produce a complete set of poms for their 3 jars
> and 3 releases but am not sure how to test one of them.    To me it
> seems like its turned into an enormous amount of work to fix a really
> obvious problem.  One of the most frustrating things for me is that
> there is no way to find out where the existing wrong poms came from.

Brett has a good suggestion about adding traceability to uploaded
poms. But I can tell you that if the pom only has group, artifact and
version is coming from the early times of the repo autogenerated it
from a missing pom in the m1 repo.
Things from Apache, Codehaus, Objectweb,... come synced from their repos.

> Second most frustrating was that the MEV instructions turned out to
> be 100% inaccurate, so following them to the letter was a complete
> waste of time.

Sorry about that, now they are changed, not sure if they have been deployed yet.

>
> There was another problem with the maven xmlbeans plugin that Kris
> Bravo fixed immediately.
>
> thanks
> david jencks
>
> >
> > - Brett
> >
> > --
> > Brett Porter <brett@...>
> > Apache Maven - http://maven.apache.org/
> > Better Builds with Maven - http://library.mergere.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

On 7/5/06, Ralph Goers <Ralph.Goers@...> wrote:

>
>
> Carlos Sanchez wrote:
> >
> > Yes you can, it's not the best way to do it but you can, by adding
> > explicitly the dependency with the versoin you want to your pom. In
> > the very worst case you have to add all transitive deendencies to your
> > pom, like in Maven 1.
> That is so impractical as to be nonsensical. Our Configuration
> Management folks require that all projects use the same dependencies
> from the top to the bottom. For example, we build our base set of
> frameworks with one multiproject build, then a higher level of
> frameworks, and then finally the product itself. Each of these must be
> built and unit tested with the same third party jars. Furthermore, the
> product can consist of a war and one or more ejb's which may all be
> packaged in an ear. These must also all have all the same versions of
> the jars. The solution you propose makes that tedious, error prone, and
> would require our CM folks to manually inspect every pom to insure
> nothing is done improperly. At least with Maven 1 we can have a
> build.properties that all projects share.  In our case, the ideal
> solution in Maven 2 would be to have a "master" pom with nothing in it
> but a dependencyManagement section (with something like override="true"
> set as an attribute) that all our projects would reference.

so... you can do it.
In m1 anybody can override the build.properties as in m2 they can put
a different version.

i'm not saying it's the right solution but while is not implemented
you can still do it. There's a limited number of hours in the day to
do all the things we want to do ;)

>
> Ralph
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

Brett Porter wrote:
> Hi Ralph,
>
> You've got a general versioning problem here, and you'll find the answer
> to "how do I do this with Maven?" will be more straightforward once
> considering the question of how you should generally deal with them. As
> you've said, this is already a problem for you as you don't know where
> they really came from.

This is broader than just versioning, it is a "how do OSS projects do
coordinated releases?" kind of problem.

In the closed source world, everything targets a single release
milestone and either comes in on time (I'm trying to think of an example
but it escapes me) or horribly late (Vista)

In OSS-land, everyone just pushes releases out when they feel like it,
ideally with some kind of testing/QA stage. Then the downstream projects
take it, finally it is considered stable enough to go into the
"Enterprise" linux distros. Projects like fedora and SuSE get to be more
timely by bundling beta release versions of many things and skipping on
the testing.

This release process *appears* to work, at least as long as you dont
really need everything to work together properly. If you want an
integrated, testing, working distro you need a longer QA process and get
something like RHEL, though even there they sometimes seem to have a
hard time deciding which versions of which java stuff to bundle.

>
> Ignoring Maven for a moment, there's a couple of questions I'd consider
> (bear in mind I'm not a Cocoon user so I may be misunderstanding how
> they eventually get used):
> - how would a user that used one of these dependencies themselves in
> addition to that Cocoon component select which version of the dependency
> to use? Would they use the Cocoon-supplied one, one they select, or both?
> - are the changes Cocoon specific? Will you always be using a custom
> release, or will you pick up the next release when it is available?
>
> There are a couple of options for addressing this use case in Maven.
> - include the JARs in SVN, and reference it as an additional repository
> file://localhost/${basedir}/extra-jar-repo
>
> - host your own repository of these artifacts (this is basically
> equivalent to the above and probably easier to work with, and could be
> accommodated in a general ASF repository of such things, once taking
> into account the licensing guidelines)

This is effectively what the fedora/core distros do when they use
jpackage to push out releases of various things. historically they've
tended to stick to point releases of java stuff, and custom releases of
stuff like firefox and and OOo, but with redhat getting more into java,
this could change.

>
> - ask projects to do a beta/point release for you (it should be easy to
> make a case for this if the version you are using is both stable and
> contains critical fixes)

this should be your fundamental goal. You need to persuade projects that
they need to cut a tagged, labelled, supported release on your schedule.
Its pretty hard, especially if you get burned by the first time you ship
something before it is not ready (e.g axis1.0 because websphere wanted
it) and are left maintaining it for a while. The next time the team
comes back for a new release, you are going to push back and say "wait
until we are ready"

The hard part becomes convincing j-random-component.jar that they should
do a point release, with the beta testing and support costs. For
axis1.4, I think geronimo solved the problem by taking on the release
management role.

>
> - "fork" the code (taking into consideration licensing guidelines)
> either temporarily or permanently in your own repository (ie
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html). Make
> it part of your build, and do the custom group ID thing. We really need
> the "provides" functionality planned for Maven 2.1 to make this feasible
> if it is intended to be a drop in replacement of the original JAR (so
> that you don't get duplicates in the dependency chain), but it can
> certainly work.
>
> BTW, I also think we need specific support for this type of artifact (it
> is essentially a "vendor" release), and it is under consideration for
> Maven 2.1.
>

Fork someone else's project and you take ownership of all support calls
forever. Take a look at how Axis handles support emails related to the
JBoss fork of Axis 1.x, it is essentially "please, go ask them; we dont
know what they did before they shipped". And don't even get me started
on the BEA version of Ant, the one with the modified manifests and the
broken .bat and .sh files.

Now that Cocoon is using OSGi, does that change versioning rules?
Because that lets components run different versions of things
side-by-side, doesnt it?

-Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

On 7/5/06, Stephen Duncan <stephen.duncan@...> wrote:

> On 7/4/06, Carlos Sanchez <carlos@...> wrote:
> > On 7/5/06, Stephen Duncan <stephen.duncan@...> wrote:
> > > On 7/4/06, Jason van Zyl <jason@...> wrote:
> > > >
> > > > On 4 Jul 06, at 2:37 PM 4 Jul 06, Steve Loughran wrote:
> > > >
> > > > The metadata will never be perfect but right now I still
> > > > think it's far from being ideal because we have no real active
> > > > process of improving it on a large scale. Carlos puts in a _lot_ of
> > > > time trying to correct things and absorb changes submitted for
> > > > improvement but as mentioned in the previous message it's a matter of
> > > > education and automated tools running to point people in the right
> > > > direction.
> > >
> > > Well, but it seems (recently?) that a policy has been put into place
> > > that POMs already in the repository should not be corrected or
> > > improved, in order to preserve repeatability for builds depending on
> > > the existing version, and that corrections should be done by making
> > > new releases.  It's hard enough to get projects to care about
> > > providing Maven POMs, but to ask for a new release seems a bit much.
> >
> > There's always the possibiblity of adding a new version ourselves with
> > a build number, like 1.0-1 where only the pom changes. Only as an
> > exception when a project is dead or don't release often
>
> That's essentially what I suggesting later on as an option for
> by-convention fix for allowing fixes to POMs.  I don't think I agree
> that it's an exceptional case though.   What do you see as the correct
> process here?  That the issue for POM improvement be placed into the
> other projects issue tracker, not Maven Evangelism, and that the
> project make a new release with the changes?  Is that likely to
> actually happen?

If enough users complain they'll do it. If not then the maven team
plays its role and can allow that new *-1 version. First ask the
project, then if you get a no by answer we'll try to fix it.

>
> > >
> > > It also may seem ideal to have projects take care of their own POMs,
> > > but it makes it frustrating for users to provide information on fixes.
> > >  I know, personally, I've cut down on contributing to central
> > > repository improvement.  I've taken to simply installing new jars to
> > > my internal repository, because asking individual projects to do it
> > > gives slow-to-no returns.  I put top-level exclusions into
> > > dependencyManagement rather than request changes to POMs, because
> > > again, there seems no process for actually getting that to happen
> > > that's not haphazard.  I'll try to work on doing better, but the
> > > cost-reward ratio isn't helping.
> >
> > Well, if everybody does that then there's no community benefit and we
> > all lose. When I need something not in ibiblio I put it there because
> > it's not much harder than putting it in my local repo.
>
> Like I said, I know I shouldn't do that.  But it certainly doesn't
> feel as easy to get it put into ibiblio.  mvn deploy:deploy-file for
> myself seems much easier than getting someone else's stuff into
> ibiblio, where I need to make sure of all the details for groupId,
> license, the rest of the POM is accurate, etc.  Plus, it's not even
> clear that doing so for a third-party app was the encouraged way to
> go, vs. trying to get the third-party to do it themselves.  If I
> should be doing it, I guess I'll work to make an upload bundle for
> tagsoup 1.0 tomorrow...

If they don't do it you can do it. All that info in the POM is for the
benefit of the users, eg so you can see reports with all licenses of
your dependencies. At least you can do the pom and show it to the
project to get an ok if everything looks right.

>
> > > I think maybe some either feature or convention for handling version
> > > changes to just POMs so they can be improved without another release
> > > of the software would help.  Some clarification/policy statements on
> > > when I should go straight to the project responsible for a jar vs.
> > > filing in Maven evangelism for uploads & for POM improvements might be
> > > helpful.  Certainly some of the 2.1 planned features (like being able
> > > to rely on geronimo-transaction & have that take care of anything
> > > relying in javax.transaction:jta...) could help.  I think some concept
> > > work needs to go into optional dependencies, because it we can't
> > > control when Spring decides they want to stop providing modularized
> > > jars, and move to a single jar that will essentially have all optional
> > > dependencies.  I'm not looking forward to getting my projects to work
> > > with Spring 2.0.
> >
> > You can always have poms for different maven configurations against
> > only one jar, see
> > http://jroller.com/page/carlossg?entry=optional_dependencies_in_maven
> >
> > >
> > > Believe me, this is all coming from someone who's been trying.  I've
> > > filed bug reports with Spring, and Lucene, other projects to get Maven
> > > uploads.  I've volunteered to work on providing and maintaining a
> > > Maven 2 build for an incubator project so that it will be easy to
> > > provide Maven jars & poms when the time comes.
> >
> > You can see in http://opensource.atlassian.com/projects/spring/browse/SPR-1484
> > that Spring got pressure from their users to provide POMs, it's by far
> > the most popular issue. Any project that wants to succeed must listen
> > to their users
>
> Again, it doesn't feel like that means much.  I had to work with you &
> another helpful Maven user to get POMs for Spring 1.2.7.  And there
> are no source or javadoc jars there.  Spring 1.2.8 doesn't have POMs,
> and has been there for over a month:
> http://ibiblio.org/maven2/org/springframework/spring-support/1.2.8/

Spring is not a trivial project, but based in the 1.2.7 poms and
http://springframework.cvs.sourceforge.net/springframework/spring/lib/readme.txt
shouldn't be hard. Anyway you are supposed to know what versions you
should be using, with maven, ant or anything

If you build the sources and javadocs jars I'll put them in ibiblio. I
did it when I need them.

>
> > >
> > > Oh, another quality issue.  -source and -javadoc jars.  It really
> > > slows down running eclipse:eclipse when half or more of my
> > > dependencies don't have these jars.  And a lot don't.  All of
> > > spring-1.2.7, for instance.
> >
> > You can download Spring, jar the stuff up and submit them for adding
> > to ibiblio. I don't understand how can you complain when maven is the
> > only project providing that feature.
>
> I apologize, but I don't understand what you were saying here.
>
> > >
> > > My purpose isn't just to complain.  I just think that there's going to
> > > have be more to it than "it'll get better over time" for the central
> > > repository to improve, because, from the narrow view of the things I
> > > use, it's getting a bit worse, not better right now.
> >
> > My view is that it's getting better, more jars, more poms, more
> > javadocs, more sources, and more and more projects caring about the
> > repository, being a must for them.
> >
> > >
> > > --
> > > Stephen Duncan Jr
> > > www.stephenduncanjr.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

Not a bulletproof one (there's ${user.dir}, but that's only right 90% of
the time). In a multiproject scenario, you might be better off putting
the individual jars in as stubbed projects:

parent pom:
<module>jar-in-svn</module>
...

jar-in-svn/pom.xml: the POM from the repository, but add a copy file.jar
to target/artifactId-version.jar at the package phase.

Cheers,
Brett

On 5/07/2006 7:27 PM, Geoffrey De Smet wrote:

>
>
> Brett Porter wrote:
>> Hi Ralph,
>>
>> There are a couple of options for addressing this use case in Maven.
>> - include the JARs in SVN, and reference it as an additional
>> repository file://localhost/${basedir}/extra-jar-repo
>>
>>
> When you declare such a repository in your parent pom, the child poms
> don't use the parent's basedir, but their own basedir. Is there a
> workaround for that problem?
>
>

--
Brett Porter <brett@...>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

Carlos Sanchez wrote:
> so... you can do it.
> In m1 anybody can override the build.properties as in m2 they can put
> a different version.
Pardon me for going on and on about this, but the reality is that, at
least in my organization, "anybody" cannot override the
build.properties. When our CM team gets a release they will use the
correct build.properties and your project damn well better build with
it.  If a new or upgraded third party jar is required it has to be
explicitly called out in the release documentation.
>
> i'm not saying it's the right solution but while is not implemented
> you can still do it. There's a limited number of hours in the day to
> do all the things we want to do ;)
This part I understand! ;-)

Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ruelloehr]

I made some noise a few months ago about the repository poms.

There are 3 or 4 issues currently in JIRA regarding this.  I also agree that it is an issue.

http://jira.codehaus.org/browse/MNG-1954

Ruel Loehr
JBoss QA
 
-----Original Message-----
From: Brett Porter [mailto:brett@...]
Sent: Tuesday, July 04, 2006 10:13 AM
To: Maven Developers List
Cc: dev@...
Subject: Re: [RANT] This Maven thing is killing us....

On 4/07/2006 9:34 PM, Torsten Curdt wrote:
> I agree that the whole maven2 situation is currently far less than
> just acceptable ...but TBH I am not sure the maven team is (or was?)
> really aware of all the problems we have.

Not until you forwarded a message (and thanks for doing so). We don't
really have the bandwidth to follow along with everyone that is
converting builds...

>
> Maybe we can get a statement on the maven self-update and
> unreliable-messed-up-repository situation. From what it sounds they
> are working on it. So let's not work this out in our little cocoon
> corner but let's hear what they have to say.

I think we all recognise there are some issues, particularly with
ibiblio dropping out consistently, and also issues with transitivity and
versioning that have been raised on the dev@maven thread. I'm not sure
what "messed up repository" issues you are having, but would like to
hear about it.

I know this stuff needs a good hard looking at, but I don't believe
there is anything insurmountable here.

- Brett

--
Brett Porter <brett@...>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

Ralph Goers wrote:

>
>
> Carlos Sanchez wrote:
>>
>> Yes you can, it's not the best way to do it but you can, by adding
>> explicitly the dependency with the versoin you want to your pom. In
>> the very worst case you have to add all transitive deendencies to your
>> pom, like in Maven 1.
> That is so impractical as to be nonsensical. Our Configuration
> Management folks require that all projects use the same dependencies
> from the top to the bottom. For example, we build our base set of
> frameworks with one multiproject build, then a higher level of
> frameworks, and then finally the product itself. Each of these must be
> built and unit tested with the same third party jars. Furthermore, the
> product can consist of a war and one or more ejb's which may all be
> packaged in an ear. These must also all have all the same versions of
> the jars. The solution you propose makes that tedious, error prone, and
> would require our CM folks to manually inspect every pom to insure
> nothing is done improperly. At least with Maven 1 we can have a
> build.properties that all projects share.  In our case, the ideal
> solution in Maven 2 would be to have a "master" pom with nothing in it
> but a dependencyManagement section (with something like override="true"
> set as an attribute) that all our projects would reference.
>

FYI, using the maven tasks in ant, I create my own pom files based on
the values in a shared properties file. The poms are then fed in to the
tasks and used to publish the artifacts themselves. This lets me do two
things
  -have a single library.properties file to control the version of things
  -have developer-specific build.properties driven overrides of
versions, and know that those versions get picked up everywhere.
This isn't a perfect process, as it is fairly verbose, but it does
ensure consistency. It would be easier with a task that did both the pom
file creation and path setup in one go.

I run the tasks with verbose=true so I get to see what is happening
w.r.t dependency inference, something like this:

ready-to-declare-classpaths:

core-libraries:
unspecified:unspecified:jar:0.0 (selected)
   commons-lang:commons-lang:jar:2.1 (selected)
   commons-logging:commons-logging:jar:1.0.4 (selected)
     log4j:log4j:jar:1.2.6 (selected)
   log4j:log4j:jar:1.2.6 (removed - nearer found: 1.2.13)
   log4j:log4j:jar:1.2.13 (selected)

smartfrog-modules-classpath:
unspecified:unspecified:jar:0.0 (selected)
   org.smartfrog:sf-cdl:jar:3.08.steve-private (selected)
[m2:libraries] [INFO] snapshot org.ggf:cddlm:ggf16-SNAPSHOT: checking
for updates from remote
     org.ggf:cddlm:jar:ggf16-SNAPSHOT (selected)
     commons-logging:commons-logging-api:jar:1.0.4 (selected)
     org.smartfrog:sf-xml:jar:3.08.steve-private (selected)
       xerces:xmlParserAPIs:jar:2.6.2 (selected)
       xerces:xercesImpl:jar:2.6.2 (selected)
       xom:xom:jar:1.1 (selected)
         xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
         jaxen:jaxen:jar:1.1-beta-8 (selected)
   org.smartfrog:sf-www:jar:3.08.steve-private (selected)
   org.smartfrog:sf-m32:jar:3.08.steve-private (selected)
     commons-httpclient:commons-httpclient:jar:3.0 (selected)
       commons-codec:commons-codec:jar:1.2 (selected)
     servletapi:servletapi:jar:2.3 (selected)
     xerces:xmlParserAPIs:jar:2.6.2 (selected)
     xom:xom:jar:1.1 (selected)
       xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
       jaxen:jaxen:jar:1.1-beta-8 (selected)
     xerces:xercesImpl:jar:2.6.2 (selected)
   org.smartfrog:sf-jetty:jar:3.08.steve-private (selected)
   org.smartfrog:sf-loggingservices:jar:3.08.steve-private (selected)
     org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
     log4j:log4j:jar:1.2.13 (selected)
   org.smartfrog:sf-xml:jar:3.08.steve-private (selected)

smartfrog-core-classpath:
unspecified:unspecified:jar:0.0 (selected)
   org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
   org.smartfrog:sfServices:jar:3.08.steve-private (selected)

jetty-classpath:
unspecified:unspecified:jar:0.0 (selected)
   jetty:jetty:jar:4.2.24 (selected)
   servletapi:servletapi:jar:2.3 (selected)

declare-compile.classpath:

declare-exec.classpath:

smartfrog-testharness-classpath:
unspecified:unspecified:jar:0.0 (selected)
   org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
unspecified:unspecified:jar:0.0 (selected)
   org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
   junit:junit:jar:3.8.1 (selected)

Everything with steve-private is tagged as a release for me only; built
locally and never saved up to the net. I am just using the local cache
as a way of sharing artifacts.

One problem with this (ant-centric, obviously) approach is that I'm
building up multiple graphs of dependencies, and the version logic only
works in the scope of one graph, but ant lets me merge them. In an ideal
world, you'd have the ability to merge two dependency graphs and have
the resolution thing kick in again. I suppose if I had a separate pom
for each path I could do that. But this is a single artifact that goes
through some phases, like unit tests, local functional tests, then full
distributed-junit deployment of the interop test suites on four
processes at the same time, each hitting a different endpoint.

 From a m2/pom perspective, a good tactic may be to create poms that
dont serve up any artifacts, just dependencies of stuff known to work
together. Like mail+attachments, the ejb3 spec+jta, or an apache-xml-api
(dom, xsl, stax apis), and an apache-xml-implementation. So you have
single poms to change the rules for these packages, and yet have bigger
things depend upon the combinations without having to relist them. That
is, using the metadata files as artifacts in their own rights.

-steve

ps, look at Xom:

       xom:xom:jar:1.1 (selected)
         xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)

that can't be right, surely? I depend on an older version of myself.
That is something that pom validation logic should catch at pom upload
time. Here it's coming in from jaxen-1.1-beta8 that also pulls in a copy
of dom4j that I don't need.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jerome Lacoste-2]

On 7/5/06, Steve Loughran <stevel@...> wrote:
> Ralph Goers wrote:
> >
> >
> > Carlos Sanchez wrote:
> >>
> >> Yes you can, it's not the best way to do it but you can, by adding
> >> explicitly the dependency with the versoin you want to your pom. In
> >> the very worst case you have to add all transitive deendencies to your
> >> pom, like in Maven 1.


[..]

I've been following this thread with interest.

It makes me think of the various problems Linux distribution have to
deal with when making their own repositories. It took 10 years for
these solutions to be what they are today. I really think some ideas
should be reused, even though the goals are slightly different.

Some features/ways of working that may or may not be applicable:

- they typically use a versionning similar to x.y.z-n sometimes
adding. -n can be used to fix packaging issues (POM in the case of
maven). Vendor fixes are also accepted and version names reflect the
vendor name.

- the distributions with the best repositories typically require the
package to be buildable from source. The build is tested in a separate
environment where all the required build dependencies are listed, to
make sure that the dependency list is accepted. Something similar
should maybe be done before accepting a project on a POM, setting up a
build environment based on the given pom.

- number of versions of a particular package in a repo is reduced to a
minimum. users are adviced to upgrade to the latest & greatest to make
sure that fixes are always present in the last released versions

- responsibilities of preparing packages is spread around 10s of
people. Packages are orphaned when no one is taking care of them.
People can reuse tricks/scripts learned by former packagers to go on
with the job.

- use of provides and various other dependency markers (that's coming
in m2 2.1 if I got it right)

Cheers,

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mike Perham]

The more I think about it, the more I agree with this.  I believe we
will need to start using this -n versioning for POM fixes.  It's easy to
develop and test a java module but screw up the POM and make it unusable
to the public.  How long and how many revisions did it take for us to
get hibernate or spring in decent shape?  ;-)

> -----Original Message-----
> From: jerome lacoste [mailto:jerome.lacoste@...]
> Sent: Wednesday, July 05, 2006 10:33 AM
> To: Maven Developers List
> Subject: Re: [RANT] This Maven thing is killing us....
>
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

Mike Perham wrote:
> The more I think about it, the more I agree with this.  I believe we
> will need to start using this -n versioning for POM fixes.  It's easy to
> develop and test a java module but screw up the POM and make it unusable
> to the public.  How long and how many revisions did it take for us to
> get hibernate or spring in decent shape?  ;-)
>

OK, but the other part of the problem is pushing the changes out to the
user.

in a linux distro, what you are effectively buying is a set of artifacts
compiled on the same gcc version/options, and a subscription that keeps
your box up to date. They are usually manual or cron updates.

If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to
get that new pom, without having your stuff updated. Except when you
dont, of course, because you've just QA'd everything against a previous
version and dont want stuff with new metadata creeping in.

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Pete Marvin King]

   sometimes it makes me wonder how gentoo manages their ebuilds.
   portage and maven both supports transitive dependencies, but somehow
   the portage ebuilds which can be compared to the maven pom is more
   stable and reliable. currently the number of portage ebuilds is
around 24,000+,
   a large amount of ebuilds to maintain.

   i'm guessing the community plays a crucial part in the health of the
ebuilds.
   the gentoo community has a lot of passionate people taking care of
the ebuilds.



jerome lacoste wrote:

> On 7/5/06, Steve Loughran <stevel@...> wrote:
>> Ralph Goers wrote:
>> >
>> >
>> > Carlos Sanchez wrote:
>> >>
>> >> Yes you can, it's not the best way to do it but you can, by adding
>> >> explicitly the dependency with the versoin you want to your pom. In
>> >> the very worst case you have to add all transitive deendencies to
>> your
>> >> pom, like in Maven 1.
>
>
> [..]
>
> I've been following this thread with interest.
>
> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.
>
> Some features/ways of working that may or may not be applicable:
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
>
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions
>
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.
>
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)
>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[arikkfir]

Hello all,

A while back I suggested that the Maven team delegate some of the
reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
equivalent, as Jerome has noted earlier in the thread). Each such voluteer
can maintain a specific area in the repo; so, someone who uses hibernate
frequently can maintain its poms, until the hibernate team agrees to do it
for us.

The idea was generally accepted by brett, with a slight modification that
volunteers go through a screening process, just like normal commit access is
provisioned (someone who submits enough pom patches will slowly be given
commit access to ibiblio).

for more info, see
http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495

perhaps it is time to move this forward?




On 7/5/06, jerome lacoste <jerome.lacoste@...> wrote:

>
> On 7/5/06, Steve Loughran <stevel@...> wrote:
> > Ralph Goers wrote:
> > >
> > >
> > > Carlos Sanchez wrote:
> > >>
> > >> Yes you can, it's not the best way to do it but you can, by adding
> > >> explicitly the dependency with the versoin you want to your pom. In
> > >> the very worst case you have to add all transitive deendencies to
> your
> > >> pom, like in Maven 1.
>
>
> [..]
>
> I've been following this thread with interest.
>
> It makes me think of the various problems Linux distribution have to
> deal with when making their own repositories. It took 10 years for
> these solutions to be what they are today. I really think some ideas
> should be reused, even though the goals are slightly different.
>
> Some features/ways of working that may or may not be applicable:
>
> - they typically use a versionning similar to x.y.z-n sometimes
> adding. -n can be used to fix packaging issues (POM in the case of
> maven). Vendor fixes are also accepted and version names reflect the
> vendor name.
>
> - the distributions with the best repositories typically require the
> package to be buildable from source. The build is tested in a separate
> environment where all the required build dependencies are listed, to
> make sure that the dependency list is accepted. Something similar
> should maybe be done before accepting a project on a POM, setting up a
> build environment based on the given pom.
>
> - number of versions of a particular package in a repo is reduced to a
> minimum. users are adviced to upgrade to the latest & greatest to make
> sure that fixes are always present in the last released versions
>
> - responsibilities of preparing packages is spread around 10s of
> people. Packages are orphaned when no one is taking care of them.
> People can reuse tricks/scripts learned by former packagers to go on
> with the job.
>
> - use of provides and various other dependency markers (that's coming
> in m2 2.1 if I got it right)
>
> Cheers,
>
> Jerome
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
______________________________________
Cheers,
      Arik Kfir                                   arikkfir@...
      Linux user, number 415067 - http://counter.li.org/
      http://corleon.dnsalias.org

[mihobson]

On 05/07/06, Steve Loughran <stevel@...> wrote:

> OK, but the other part of the problem is pushing the changes out to the
> user.
>
> in a linux distro, what you are effectively buying is a set of artifacts
> compiled on the same gcc version/options, and a subscription that keeps
> your box up to date. They are usually manual or cron updates.
>
> If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to
> get that new pom, without having your stuff updated. Except when you
> dont, of course, because you've just QA'd everything against a previous
> version and dont want stuff with new metadata creeping in.

Could we not use the syntax 3.7 to represent 'the latest revision of
3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
during development people could use 3.7 to allow updated revisions of
the pom to be pushed to them, and then for reproducable builds they
could use the 3.7-1 syntax.

The release plugin could fully-qualify any version numbers of the form
3.7 to the currently-used revision, e.g. 3.7-1, at release time.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Carlos Sanchez-4]

I remember more or less who makes good upload requests and who doesn't ;)

Anyway that's why the field in jira proving that you're a member of
the project is. If you are member and you request an upload that goes
directly without checking correctness if the group already exist.

We can start a wiki with people volunteering for projects that don't
collaborate.

On 7/5/06, Arik Kfir <arikkfir@...> wrote:

> Hello all,
>
> A while back I suggested that the Maven team delegate some of the
> reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
> equivalent, as Jerome has noted earlier in the thread). Each such voluteer
> can maintain a specific area in the repo; so, someone who uses hibernate
> frequently can maintain its poms, until the hibernate team agrees to do it
> for us.
>
> The idea was generally accepted by brett, with a slight modification that
> volunteers go through a screening process, just like normal commit access is
> provisioned (someone who submits enough pom patches will slowly be given
> commit access to ibiblio).
>
> for more info, see
> http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
>
> perhaps it is time to move this forward?
>
>
>
>
> On 7/5/06, jerome lacoste <jerome.lacoste@...> wrote:
> >
> > On 7/5/06, Steve Loughran <stevel@...> wrote:
> > > Ralph Goers wrote:
> > > >
> > > >
> > > > Carlos Sanchez wrote:
> > > >>
> > > >> Yes you can, it's not the best way to do it but you can, by adding
> > > >> explicitly the dependency with the versoin you want to your pom. In
> > > >> the very worst case you have to add all transitive deendencies to
> > your
> > > >> pom, like in Maven 1.
> >
> >
> > [..]
> >
> > I've been following this thread with interest.
> >
> > It makes me think of the various problems Linux distribution have to
> > deal with when making their own repositories. It took 10 years for
> > these solutions to be what they are today. I really think some ideas
> > should be reused, even though the goals are slightly different.
> >
> > Some features/ways of working that may or may not be applicable:
> >
> > - they typically use a versionning similar to x.y.z-n sometimes
> > adding. -n can be used to fix packaging issues (POM in the case of
> > maven). Vendor fixes are also accepted and version names reflect the
> > vendor name.
> >
> > - the distributions with the best repositories typically require the
> > package to be buildable from source. The build is tested in a separate
> > environment where all the required build dependencies are listed, to
> > make sure that the dependency list is accepted. Something similar
> > should maybe be done before accepting a project on a POM, setting up a
> > build environment based on the given pom.
> >
> > - number of versions of a particular package in a repo is reduced to a
> > minimum. users are adviced to upgrade to the latest & greatest to make
> > sure that fixes are always present in the last released versions
> >
> > - responsibilities of preparing packages is spread around 10s of
> > people. Packages are orphaned when no one is taking care of them.
> > People can reuse tricks/scripts learned by former packagers to go on
> > with the job.
> >
> > - use of provides and various other dependency markers (that's coming
> > in m2 2.1 if I got it right)
> >
> > Cheers,
> >
> > Jerome
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
>
>
> --
> ______________________________________
> Cheers,
>       Arik Kfir                                   arikkfir@...
>       Linux user, number 415067 - http://counter.li.org/
>       http://corleon.dnsalias.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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mihobson]

On 05/07/06, Arik Kfir <arikkfir@...> wrote:

> Hello all,
>
> A while back I suggested that the Maven team delegate some of the
> reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
> equivalent, as Jerome has noted earlier in the thread). Each such voluteer
> can maintain a specific area in the repo; so, someone who uses hibernate
> frequently can maintain its poms, until the hibernate team agrees to do it
> for us.
>
> The idea was generally accepted by brett, with a slight modification that
> volunteers go through a screening process, just like normal commit access is
> provisioned (someone who submits enough pom patches will slowly be given
> commit access to ibiblio).
>
> for more info, see
> http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
>
> perhaps it is time to move this forward?

Definitely +1 to seeing the ibiblio repostory devolving responsibility
to smaller, more managable, repositories - ideally maintained by
developers closer to the hosted projects.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexandre Poitras]

+1, really great idea.

On 7/5/06, Mark Hobson <markhobson@...> wrote:

> On 05/07/06, Arik Kfir <arikkfir@...> wrote:
> > Hello all,
> >
> > A while back I suggested that the Maven team delegate some of the
> > reponsibility of maintaining the ibiblio repo to volunteers (as in the linux
> > equivalent, as Jerome has noted earlier in the thread). Each such voluteer
> > can maintain a specific area in the repo; so, someone who uses hibernate
> > frequently can maintain its poms, until the hibernate team agrees to do it
> > for us.
> >
> > The idea was generally accepted by brett, with a slight modification that
> > volunteers go through a screening process, just like normal commit access is
> > provisioned (someone who submits enough pom patches will slowly be given
> > commit access to ibiblio).
> >
> > for more info, see
> > http://www.nabble.com/critique-of-maven-2.0.2-tf1052845.html#a2738495
> >
> > perhaps it is time to move this forward?
>
> Definitely +1 to seeing the ibiblio repostory devolving responsibility
> to smaller, more managable, repositories - ideally maintained by
> developers closer to the hosted projects.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[jmcconnell]

might be better off using the version ranges notation for this kind of
thing, I don't think you want to get into the habit of x.y being some
kinda fuzzy defintion, it should refer to a specific version.

[3.7,) or something along those lines...

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

then when it comes to your release time, pin it down to a specific
version of the pom for release

jesse

On 7/5/06, Mark Hobson <markhobson@...> wrote:

> On 05/07/06, Steve Loughran <stevel@...> wrote:
> > OK, but the other part of the problem is pushing the changes out to the
> > user.
> >
> > in a linux distro, what you are effectively buying is a set of artifacts
> > compiled on the same gcc version/options, and a subscription that keeps
> > your box up to date. They are usually manual or cron updates.
> >
> > If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to
> > get that new pom, without having your stuff updated. Except when you
> > dont, of course, because you've just QA'd everything against a previous
> > version and dont want stuff with new metadata creeping in.
>
> Could we not use the syntax 3.7 to represent 'the latest revision of
> 3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1?  So
> during development people could use 3.7 to allow updated revisions of
> the pom to be pushed to them, and then for reproducable builds they
> could use the 3.7-1 syntax.
>
> The release plugin could fully-qualify any version numbers of the form
> 3.7 to the currently-used revision, e.g. 3.7-1, at release time.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mihobson]

On 05/07/06, Jesse McConnell <jesse.mcconnell@...> wrote:

> might be better off using the version ranges notation for this kind of
> thing, I don't think you want to get into the habit of x.y being some
> kinda fuzzy defintion, it should refer to a specific version.
>
> [3.7,) or something along those lines...
>
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> then when it comes to your release time, pin it down to a specific
> version of the pom for release

I did think of ranges, but even atm 3.7 is just a 'soft' version -
merely a recommendation.  This notion could be extended to accommodate
the above, with it becoming the 'hard' version [3.7-1] at release
time.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...