On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:
On 7/4/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> On 7/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:
> > On 7/4/06, Jason van Zyl <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
