Re: Getting Maven Site Plugin 2.1 out the door...
Thanks Dennis for the initiative. Unfortunately it comes at a bad time for me, I'm afraid I won't be able to help much in the next weeks (new job, new country, new home...) but I fully endorse your plan of action. See my comments below. Dennis Lundberg wrote: Hi all I think it's about time we release Maven Site Plugin 2.1. There are *a lot* of issued fixed in there, many of them thanks to the upgrade to Doxia 1.1. To get a release out there are a couple of this to consider: 1. What releases are needed? maven-doxia-tools-1.1 doxia-1.1.2 doxia-sitetools-1.1.2 maven-site-plugin-2.1 maven-reporting-impl-2.1 is also on my list and would be ready too. OTOH, what has changed in maven-doxia-tools-1.1? There are no JIRA's associated with it? 2. Which issues do we include? Here's a list of the issues currently scheduled for the above releases: http://jira.codehaus.org/browse/MSHARED-102 http://jira.codehaus.org/browse/DOXIA-354 http://jira.codehaus.org/browse/DOXIA-355 http://jira.codehaus.org/browse/DOXIASITETOOLS-32 http://jira.codehaus.org/browse/MSITE-227 http://jira.codehaus.org/browse/MSITE-244 http://jira.codehaus.org/browse/MSITE-273 http://jira.codehaus.org/browse/MSITE-358 http://jira.codehaus.org/browse/MSITE-419 I propose that we fix only DOXIASITETOOLS-32 (Deployed decoration-1.0.1.xsd) and MSITE-419 (Update to Doxia 1.1.2). We push the rest to later versions. What do other think? I have updated the JIRA roadmaps for DOXIA and MSITE, it's fine for me like that. Thanks! -Lukas 3. Who does what? I can release maven-doxia-tools and maven-site-plugin, if someone else can make the two Doxia releases. The Doxia Release Plan can be found on the wiki at http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: [DISCUSS] Handling of repositories in POMs of dependencies
Hi! Just make a step back and look at the repository problematic from a bit different perspective. I'm working for a few companies and even different projects in those companies use different sections in their poms. But in my local repo, all the artifacts from those repositories gets merged to a single big landfill. When I switch to a different project, with no repositories configured, I may pick up a wrong dependency this way. Or I may be able to compile and even release, but my colleagues are not, because this very is missing in the projects pom. What about remembering where an artifact came from in the local repo? E.g. something like ~/.m2/repository // this contains the locally installed artifacts and stuff, and also acts for backward compatibility. It is always 'active'] ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache... ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise... ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby... If a is not activated for a specific project then the local artifacts will not be picked up. from .m2/repositories. If a transitive dependency defines a new those will be added at the end of the chain. We should think about collision detection, but this should be detectable at least. There are most probably also things to consider for repository managers. I'm not sure if it is worth the effort though. LieGrue, strub - Ursprüngliche Mail > Von: Brian Fox > An: Maven Developers List > Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr > Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > > It's amazing how google's thread compression of a discussion can cause > me to overlook a huge thread so near and dear to my heart. > > To start, Benjamin has hit the nail on the head of a discussion point > Jason and I have had going for quite some time. In fact, we even wrote > up a proposal for it months ago that got little feedback. I've also > blogged on this subject before. > > Written and suggested reading in this order: > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ > http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery > > I won't rehash all of what I've already written, and leave it to the > reader to follow the above urls for the majority of the points however > I think there is one key argument that is worth reiterating: > > The ability of a user to checkout an open source project with no prior > knowledge of it and simply be able to build it, run the tests and > patch it the first try is the most powerful way to demonstrate the > Maven to new users. Simply removing or ignoring repositories in the > poms will break this functionality that I feel pretty strongly about. > > All of the arguments so far in this thread mostly revolve around > issues in corporate / enterprise use, and for these issues repository > managers are the best solution. I don't think its in the best interest > of the community to break OSS use to support Enterprise use, > particularly when that problem is already covered. > > Specifically, I'm pretty strongly in favor of continuing to support > repositories declared in poms, however they should be scoped for only > the subtree of dependencies introduced by the pom declaring the repo. > Further, I recognize that having urls burned into immutable poms is > not the best way to accomplish this, and I think we need to find a > better one pretty quickly. > > --Brian > > On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly > wrote: > > 2009/10/28 Brett Porter > > > >> > >> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: > >> > >> On Wed October 28 2009 10:53:10 am John Casey wrote: > >>> > I tend to agree, they should not really be used. It seems like these > third-party repositories have a strong potential for causing network > errors (in cases where the repo is down or on a private network), and > they definitely push the user in the direction of trusting anything that > comes from anywhere on the internet without thinking twice...not a great > idea, and an understandably unpopular one with companies. > > I think the role of the declaration in the POM should be > shifted in Maven 3. I think this along the same lines that Brett was > talking, but I'd really like to see them take on an advisory role rather > than actively participate in resolution. In other words, if an artifact > cannot be found, then display the list of third-party repositories which > MIGHT contain the artifact, along with the POM that lists that > repository. > > >>> > >>> I'm OK with that EXCEPT for repositories defined in the current > >>> pom+parents. > >>> For transitive dependencies, yes, but not for building the current > >>> project. > >>> > >>> > >> +1 > >> > >> This avoids fudging with settings.xml, which has other
Re: [DISCUSS] Handling of repositories in POMs of dependencies
This was a proposal about a year or two back IIRC there were other more pressing issues and nothing much happened since. The proposal was part of the "make repository access thread-safe" for people using maven on CI systems, or running builds in parallel from the CLI -Stephen 2009/10/30 Mark Struberg : > Hi! > > Just make a step back and look at the repository problematic from a bit > different perspective. > > I'm working for a few companies and even different projects in those > companies use different sections in their poms. > But in my local repo, all the artifacts from those repositories gets merged > to a single big landfill. > > When I switch to a different project, with no repositories configured, I may > pick up a wrong dependency this way. Or I may be able to compile and even > release, but my colleagues are not, because this very is missing > in the projects pom. > > What about remembering where an artifact came from in the local repo? > E.g. something like > > ~/.m2/repository // this contains the locally installed artifacts and > stuff, and also acts for backward compatibility. It is always 'active'] > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache... > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise... > ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby... > > If a is not activated for a specific project then the local > artifacts will not be picked up. from .m2/repositories. If a transitive > dependency defines a new those will be added at the end of the > chain. We should think about collision detection, but this should be > detectable at least. > > There are most probably also things to consider for repository managers. > > I'm not sure if it is worth the effort though. > > LieGrue, > strub > > > > > > - Ursprüngliche Mail >> Von: Brian Fox >> An: Maven Developers List >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies >> >> It's amazing how google's thread compression of a discussion can cause >> me to overlook a huge thread so near and dear to my heart. >> >> To start, Benjamin has hit the nail on the head of a discussion point >> Jason and I have had going for quite some time. In fact, we even wrote >> up a proposal for it months ago that got little feedback. I've also >> blogged on this subject before. >> >> Written and suggested reading in this order: >> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ >> http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery >> >> I won't rehash all of what I've already written, and leave it to the >> reader to follow the above urls for the majority of the points however >> I think there is one key argument that is worth reiterating: >> >> The ability of a user to checkout an open source project with no prior >> knowledge of it and simply be able to build it, run the tests and >> patch it the first try is the most powerful way to demonstrate the >> Maven to new users. Simply removing or ignoring repositories in the >> poms will break this functionality that I feel pretty strongly about. >> >> All of the arguments so far in this thread mostly revolve around >> issues in corporate / enterprise use, and for these issues repository >> managers are the best solution. I don't think its in the best interest >> of the community to break OSS use to support Enterprise use, >> particularly when that problem is already covered. >> >> Specifically, I'm pretty strongly in favor of continuing to support >> repositories declared in poms, however they should be scoped for only >> the subtree of dependencies introduced by the pom declaring the repo. >> Further, I recognize that having urls burned into immutable poms is >> not the best way to accomplish this, and I think we need to find a >> better one pretty quickly. >> >> --Brian >> >> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly >> wrote: >> > 2009/10/28 Brett Porter >> > >> >> >> >> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: >> >> >> >> On Wed October 28 2009 10:53:10 am John Casey wrote: >> >>> >> I tend to agree, they should not really be used. It seems like these >> third-party repositories have a strong potential for causing network >> errors (in cases where the repo is down or on a private network), and >> they definitely push the user in the direction of trusting anything that >> comes from anywhere on the internet without thinking twice...not a great >> idea, and an understandably unpopular one with companies. >> >> I think the role of the declaration in the POM should be >> shifted in Maven 3. I think this along the same lines that Brett was >> talking, but I'd really like to see them take on an advisory role rather >> than actively participate in resolution. In other words, if an artifact >> can
AW: [DISCUSS] Handling of repositories in POMs of dependencies
Thanks Stephen! Wasn't aware that Brett had the same idea a long time ago. Found it now: http://markmail.org/thread/wqi43wiwbj43vwq6 It would be a good amount of work, but since this seems to pop up regulary, we may think about it for m3. LieGrue, strub - Ursprüngliche Mail > Von: Stephen Connolly > An: Maven Developers List > Gesendet: Freitag, den 30. Oktober 2009, 10:27:36 Uhr > Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > > This was a proposal about a year or two back IIRC there were other > more pressing issues and nothing much happened since. > > The proposal was part of the "make repository access thread-safe" for > people using maven on CI systems, or running builds in parallel from > the CLI > > -Stephen > > 2009/10/30 Mark Struberg : > > Hi! > > > > Just make a step back and look at the repository problematic from a bit > different perspective. > > > > I'm working for a few companies and even different projects in those > > companies > use different sections in their poms. > > But in my local repo, all the artifacts from those repositories gets merged > > to > a single big landfill. > > > > When I switch to a different project, with no repositories configured, I > > may > pick up a wrong dependency this way. Or I may be able to compile and even > release, but my colleagues are not, because this very is missing in > the projects pom. > > > > What about remembering where an artifact came from in the local repo? > > E.g. something like > > > > ~/.m2/repository // this contains the locally installed artifacts and > > stuff, > and also acts for backward compatibility. It is always 'active'] > > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache... > > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise... > > > ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby... > > > > If a is not activated for a specific project then the local > artifacts will not be picked up. from .m2/repositories. If a transitive > dependency defines a new those will be added at the end of the > chain. We should think about collision detection, but this should be > detectable > at least. > > > > There are most probably also things to consider for repository managers. > > > > I'm not sure if it is worth the effort though. > > > > LieGrue, > > strub > > > > > > > > > > > > - Ursprüngliche Mail > >> Von: Brian Fox > >> An: Maven Developers List > >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr > >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > >> > >> It's amazing how google's thread compression of a discussion can cause > >> me to overlook a huge thread so near and dear to my heart. > >> > >> To start, Benjamin has hit the nail on the head of a discussion point > >> Jason and I have had going for quite some time. In fact, we even wrote > >> up a proposal for it months ago that got little feedback. I've also > >> blogged on this subject before. > >> > >> Written and suggested reading in this order: > >> > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ > >> > http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery > >> > >> I won't rehash all of what I've already written, and leave it to the > >> reader to follow the above urls for the majority of the points however > >> I think there is one key argument that is worth reiterating: > >> > >> The ability of a user to checkout an open source project with no prior > >> knowledge of it and simply be able to build it, run the tests and > >> patch it the first try is the most powerful way to demonstrate the > >> Maven to new users. Simply removing or ignoring repositories in the > >> poms will break this functionality that I feel pretty strongly about. > >> > >> All of the arguments so far in this thread mostly revolve around > >> issues in corporate / enterprise use, and for these issues repository > >> managers are the best solution. I don't think its in the best interest > >> of the community to break OSS use to support Enterprise use, > >> particularly when that problem is already covered. > >> > >> Specifically, I'm pretty strongly in favor of continuing to support > >> repositories declared in poms, however they should be scoped for only > >> the subtree of dependencies introduced by the pom declaring the repo. > >> Further, I recognize that having urls burned into immutable poms is > >> not the best way to accomplish this, and I think we need to find a > >> better one pretty quickly. > >> > >> --Brian > >> > >> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly > >> wrote: > >> > 2009/10/28 Brett Porter > >> > > >> >> > >> >> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: > >> >> > >> >> On Wed October 28 2009 10:53:10 am John Casey wrote: > >> >>> > >> I tend to agree, they should not really be used. It seems like these > >> t
Re: [DISCUSS] Handling of repositories in POMs of dependencies
Reading the original proposal again, I've an idea:
The structure of the local repository should become:
>
> ~/.m2/repository
> |-- cache
> |-- remote
> | |-- apache.snapshots
> | |-- central
> | |-- codehaus.snapshots
> | `-- ...
> `-- workspace
> |-- default
> |-- workspace1
> `-- ...
>
> The purposes of these directories are as follows:
>
> * cache: immutable artifacts downloaded from a remote repository. No
> metadata is stored in this directory tree.
>
> * remote: contains a directory for each remote repository (by repository
> identifier). This contains the metadata and mutable artifacts from that
> repository. Metadata files will return to the format {{maven-metadata.xml}}
> instead of the current {{maven-metadata- .xml}} file format. Files in
> these repositories will typically be snapshots and metadata for releases,
> since actual releases are not mutable and can be stored in the {{cache}}
> directory
>
> * workspace: contains a directory for each local workspace, with the
> primary one being {{default}}. This contains the metadata and files for any
> artifact built by maven (both snapshots, and releases).
>
Perhaps a better structure would be
~/.m2/
|-- repository (takes the form of cache from above)
|-- metadata (takes the form of remote from above)
||-- local
||-- apache.snapshots
||-- central
||-- codehaus.snapshots
|`-- ...
|-- temp (workspace for downloads prior to final move into storage)
`-- workspace (if necessary)
The idea is that the release artifacts will be stored in repository in the
current format (but we don't store the metadata there)
That way if m3 downloads an artifact, m2 can still pick it up.
We keep the metadata that m3 looks at in a separate tree, and we store the
-SNAPSHOTs along with the metadata in that tree.
We can provide tooling to purge -SNAPSHOTs from repository and to purge
artifacts associated with a specific metadata tree
-Stephen
2009/10/30 Mark Struberg :
> Thanks Stephen!
>
> Wasn't aware that Brett had the same idea a long time ago.
> Found it now:
>
> http://markmail.org/thread/wqi43wiwbj43vwq6
>
> It would be a good amount of work, but since this seems to pop up
regulary, we may think about it for m3.
>
> LieGrue,
> strub
>
>
>
> - Ursprüngliche Mail
>> Von: Stephen Connolly
>> An: Maven Developers List
>> Gesendet: Freitag, den 30. Oktober 2009, 10:27:36 Uhr
>> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies
>>
>> This was a proposal about a year or two back IIRC there were other
>> more pressing issues and nothing much happened since.
>>
>> The proposal was part of the "make repository access thread-safe" for
>> people using maven on CI systems, or running builds in parallel from
>> the CLI
>>
>> -Stephen
>>
>> 2009/10/30 Mark Struberg :
>> > Hi!
>> >
>> > Just make a step back and look at the repository problematic from a bit
>> different perspective.
>> >
>> > I'm working for a few companies and even different projects in those
companies
>> use different sections in their poms.
>> > But in my local repo, all the artifacts from those repositories gets
merged to
>> a single big landfill.
>> >
>> > When I switch to a different project, with no repositories configured,
I may
>> pick up a wrong dependency this way. Or I may be able to compile and even
>> release, but my colleagues are not, because this very is missing in
>> the projects pom.
>> >
>> > What about remembering where an artifact came from in the local repo?
>> > E.g. something like
>> >
>> > ~/.m2/repository // this contains the locally installed artifacts and
stuff,
>> and also acts for backward compatibility. It is always 'active']
>> > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache...
>> > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise...
>> >
>>
~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby...
>> >
>> > If a is not activated for a specific project then the local
>> artifacts will not be picked up. from .m2/repositories. If a transitive
>> dependency defines a new those will be added at the end of the
>> chain. We should think about collision detection, but this should be
detectable
>> at least.
>> >
>> > There are most probably also things to consider for repository
managers.
>> >
>> > I'm not sure if it is worth the effort though.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> >
>> > - Ursprüngliche Mail
>> >> Von: Brian Fox
>> >> An: Maven Developers List
>> >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr
>> >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of
dependencies
>> >>
>> >> It's amazing how google's thread compression of a discussion can cause
>> >> me to overlook a huge thread so near and dear to my heart.
>> >>
>> >> To start, Benjamin has hit the nail on the head of a discussion point
>> >> Jason and I have had going for quite some time. In fact, we even wrote
>> >>
Re: [VOTE] Release Maven Parent POM 15, Maven Plugins Parent POM 16 and Maven Shared Components Parent POM 14
+1 Arnaud On Fri, Oct 30, 2009 at 12:29 AM, Olivier Lamy wrote: > +1 > > -- > Olivier > > 2009/10/30 Benjamin Bentmann : > > Hi, > > > > if some of you have a déjà vu while regarding the mail title, that's > fine... > > my previous attempt at making our release processes smoother failed due > to > > missing site descriptors in the deployment. So if you liked the > predecessor > > versions of the parents being voted on, I hope you also like these ones > that > > now even ship with a site descriptor next to them, isn't that awesome? > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-005/ > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > +1 from me > > > > > > Benjamin > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > -- > Olivier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Maven source plugin version 2.1.1
Le Tue, 13 Oct 2009 10:09:34 -0400, John Casey a écrit : Hi guys, I'd like to know if I can vote with you ? or is it reserved to people with credentials on svn ? > +1 > > Arnaud HERITIER wrote: > > Hi, > > > > We solved 2 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147&styleName=Html&version=15244 > > Those one are very important for many projects because the plugin failed in > > a project without sources which is really annoying when we use it in a > > multi-modules project. > > > > > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11147&status=1 > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-staging-017/ > > > > Staging site: > > http://maven.apache.org/plugins/maven-source-plugin-2.1.1/ > > (Will be available in few hours after the next rsync) > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > My +1. > > > > Cheers, > > > > Arnaud > > > > # Arnaud Héritier > > # Software Factory Manager > > # eXo Platform > > # http://www.exoplatform.com > > # http://blog.aheritier.net > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: AW: [DISCUSS] Handling of repositories in POMs of dependencies
Mark Struberg wrote: But in my local repo, all the artifacts from those repositories gets merged to a single big landfill. That seems to be a completely independent issue, isn't it? The question I originally raised was about what repositories ought to be considered during dependency resolution, not where we should store the local artifacts/metadata retrieved from them. So please consider to move this part of the discussion off into another thread, keeping this thread focused on its actual topic and thereby easing review of the thread. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven source plugin version 2.1.1
Everybody can vote, and you are encouraged to do so if you have tested the release. Even though officially only PMC votes count to determine the result, every other vote is appreciated as additional feedback. See http://www.apache.org/foundation/voting.html. Cheers, -Lukas Tony Chemit wrote: Le Tue, 13 Oct 2009 10:09:34 -0400, John Casey a écrit : Hi guys, I'd like to know if I can vote with you ? or is it reserved to people with credentials on svn ? +1 Arnaud HERITIER wrote: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147&styleName=Html&version=15244 Those one are very important for many projects because the plugin failed in a project without sources which is really annoying when we use it in a multi-modules project. There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11147&status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-017/ Staging site: http://maven.apache.org/plugins/maven-source-plugin-2.1.1/ (Will be available in few hours after the next rsync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 My +1. Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
In general I think this could be handy, but I'm mostly thinking from the angle of separating things needed BY the build from things needed FOR the build. Ie separating Maven and plugin dependencies from the project being built's dependencies. Specifically to handle things like blocking GPL artifacts from being used by a project while still allowing them to be used by a plugin. Brett wrote a proposal for this a while back, it's also on codehaus. On Fri, Oct 30, 2009 at 5:21 AM, Mark Struberg wrote: > Hi! > > Just make a step back and look at the repository problematic from a bit > different perspective. > > I'm working for a few companies and even different projects in those > companies use different sections in their poms. > But in my local repo, all the artifacts from those repositories gets merged > to a single big landfill. > > When I switch to a different project, with no repositories configured, I may > pick up a wrong dependency this way. Or I may be able to compile and even > release, but my colleagues are not, because this very is missing > in the projects pom. > > What about remembering where an artifact came from in the local repo? > E.g. something like > > ~/.m2/repository // this contains the locally installed artifacts and > stuff, and also acts for backward compatibility. It is always 'active'] > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache... > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise... > ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby... > > If a is not activated for a specific project then the local > artifacts will not be picked up. from .m2/repositories. If a transitive > dependency defines a new those will be added at the end of the > chain. We should think about collision detection, but this should be > detectable at least. > > There are most probably also things to consider for repository managers. > > I'm not sure if it is worth the effort though. > > LieGrue, > strub > > > > > > - Ursprüngliche Mail >> Von: Brian Fox >> An: Maven Developers List >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies >> >> It's amazing how google's thread compression of a discussion can cause >> me to overlook a huge thread so near and dear to my heart. >> >> To start, Benjamin has hit the nail on the head of a discussion point >> Jason and I have had going for quite some time. In fact, we even wrote >> up a proposal for it months ago that got little feedback. I've also >> blogged on this subject before. >> >> Written and suggested reading in this order: >> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ >> http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery >> >> I won't rehash all of what I've already written, and leave it to the >> reader to follow the above urls for the majority of the points however >> I think there is one key argument that is worth reiterating: >> >> The ability of a user to checkout an open source project with no prior >> knowledge of it and simply be able to build it, run the tests and >> patch it the first try is the most powerful way to demonstrate the >> Maven to new users. Simply removing or ignoring repositories in the >> poms will break this functionality that I feel pretty strongly about. >> >> All of the arguments so far in this thread mostly revolve around >> issues in corporate / enterprise use, and for these issues repository >> managers are the best solution. I don't think its in the best interest >> of the community to break OSS use to support Enterprise use, >> particularly when that problem is already covered. >> >> Specifically, I'm pretty strongly in favor of continuing to support >> repositories declared in poms, however they should be scoped for only >> the subtree of dependencies introduced by the pom declaring the repo. >> Further, I recognize that having urls burned into immutable poms is >> not the best way to accomplish this, and I think we need to find a >> better one pretty quickly. >> >> --Brian >> >> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly >> wrote: >> > 2009/10/28 Brett Porter >> > >> >> >> >> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: >> >> >> >> On Wed October 28 2009 10:53:10 am John Casey wrote: >> >>> >> I tend to agree, they should not really be used. It seems like these >> third-party repositories have a strong potential for causing network >> errors (in cases where the repo is down or on a private network), and >> they definitely push the user in the direction of trusting anything that >> comes from anywhere on the internet without thinking twice...not a great >> idea, and an understandably unpopular one with companies. >> >> I think the role of the declaration in the POM should be >> shifted in Maven 3. I think this along the sam
Re: Intention to release Changes and JAR plugins
If I understand your comments om MSHARED-120 correctly, the Changes Plugin should not be affected by this, because the previous 2.1 version of the plugin uses Doxia 1.0-alpha-11. Vincent Siveton wrote: > Hi Dennis, > > For the changes plugin, we probably need to release before > maven-reporting-impl due to MSHARED-120 > I could help you probably next week. > > Cheers, > > Vincent > > 2009/10/28 Dennis Lundberg : >> Hi >> >> I plan on making 2 releases in the near future: >> >> Maven Changes Plugin 2.2 >> http://jira.codehaus.org/browse/MCHANGES?report=com.atlassian.jira.plugin.system.project:roadmap-panel >> >> Maven JAR Plugin 2.3 >> http://jira.codehaus.org/browse/MJAR?report=com.atlassian.jira.plugin.system.project:roadmap-panel >> I will need to go through the documentation first. >> >> >> I have pushed out new SNAPSHOTS today, if someone wants to give them a try. >> >> If anyone else has something to include, please reply to this mail and >> present your todo list. >> >> -- >> Dennis Lundberg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Regression with maven-javadoc-plugin 2.6.1 and release:perform
Hi,
I have a multimodule project and it fails during release:perform with new
javadoc plugin.
I'm working on a simple project to open an issue, but let me explain the issue
in case someone can tell me if there is something wrong in my configuration.
Say my project is composed of:
Parent
- moduleA
- moduleB
- moduleC
moduleB depends on moduleC.
When release:perform execture mvn deploy -Dperformrelease=true on the freshly
checkouted parent, the build fails
log says:
INFO
INFO Building MyCompany moduleA
INFO task-segment: [deploy]
INFO
[...]
INFO [javadoc:jar {execution: attach-javadocs}]
INFO The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc' has
not be previously called for the project: 'com.mycompany:moduleB:jar:3.1.9'.
Trying to invoke it...
INFO MavenInvocationException: Error when invoking Maven, consult the invoker
log file:
D:\Projects\parent\target\checkout\moduleA\target\invoker\maven-javadoc-plugin1287795137.txt
INFO
INFO BUILD ERROR
INFO
And in the file there is:
Invoking Maven for the goals:
[org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc] with no properties
M2_HOME=d:\apache-maven-2.2.1\bin\..
MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=256m
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14\jre\..
JAVA_OPTS=null
INFO Scanning for projects...
INFO
INFO Building MyCompany - moduleB
INFOtask-segment:
[org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc]
INFO
INFO Preparing javadoc:javadoc
INFO No goals needed for project - skipping
Downloading: http:///com/mycompany/moduleC/3.1.9/moduleC-3.1.9.pom
INFO Unable to find resource 'com.mycompany:moduleC:pom:3.1.9' in repository
central (http://central)
INFO
ERROR BUILD ERROR
INFO
INFO Failed to resolve artifact.
Missing:
--
1) com.mycompany:moduleC:jar:3.1.9
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file xxx
Path to dependency:
1) com.mycompany:moduleB:jar:3.1.9
2) com.mycompany:moduleC:jar:3.1.9
Regards,
Julien
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Getting Maven Site Plugin 2.1 out the door...
It's a great new. Thanks Dennis for the initiative. > 2. Which issues do we include? > > Here's a list of the issues currently scheduled for the above releases: > > http://jira.codehaus.org/browse/MSHARED-102 > http://jira.codehaus.org/browse/DOXIA-354 > http://jira.codehaus.org/browse/DOXIA-355 > http://jira.codehaus.org/browse/DOXIASITETOOLS-32 > http://jira.codehaus.org/browse/MSITE-227 > http://jira.codehaus.org/browse/MSITE-244 > http://jira.codehaus.org/browse/MSITE-273 > http://jira.codehaus.org/browse/MSITE-358 > http://jira.codehaus.org/browse/MSITE-419 > > I propose that we fix only DOXIASITETOOLS-32 (Deployed > decoration-1.0.1.xsd) and MSITE-419 (Update to Doxia 1.1.2). We push the > rest to later versions. What do other think? > That's really nice. We are waiting for MSITE-419 (see http://jira.codehaus.org/browse/MSCMCHGLOG-15). Rémy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: AW: [DISCUSS] Handling of repositories in POMs of dependencies
Yes, these things tend to degrade. Please stay on topic. This can be another discussion but I separated and layered the local repository implementation some time ago to allow for: 1) snapshot only local repositories 2) per project local repositories And there are still fundamental issues with the artifact resolution system in general which prevent fully atomic operations. The work on the Jetty client address many of these issues, and Oleg also has made attempts in Mercury. Don't worry I've been thinking about it for the last year and bits have gone into the core to address that. Look the delegating local repository implementation in trunk if you're interested. At any here I would stick to the repository in POMs issue. How the local repository works and atomic operations is a whole other issue. On 2009-10-30, at 4:01 AM, Benjamin Bentmann wrote: Mark Struberg wrote: But in my local repo, all the artifacts from those repositories gets merged to a single big landfill. That seems to be a completely independent issue, isn't it? The question I originally raised was about what repositories ought to be considered during dependency resolution, not where we should store the local artifacts/metadata retrieved from them. So please consider to move this part of the discussion off into another thread, keeping this thread focused on its actual topic and thereby easing review of the thread. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AW: AW: [DISCUSS] Handling of repositories in POMs of dependencies
Txs Benjamin! I don't think it is that different, because my real problem is that I cannot distinguish between those artifacts because of that. So the problem of _retrieving_ those artifacts (and detecting problems within them) maybe can be solved by storing them in a different way? In other words, the original problem: > project ---depends-on---> A ---depends-on---> B could be solved IF we can distinguish between the repository scope of the artifacts as raised in [1]. e.g. even if A introduces a fully blown repo2 (containing B),'project' itself could still use the artifacts from central. Kind of a repo-resolve hierarchy analogue to a classloader hierarchy. Resolving version crashes and things might get tricky though, but should be doable. LieGrue, strub [1] http://jira.codehaus.org/browse/MNG-3056 - Ursprüngliche Mail > Von: Benjamin Bentmann > An: Maven Developers List > Gesendet: Freitag, den 30. Oktober 2009, 12:01:28 Uhr > Betreff: Re: AW: [DISCUSS] Handling of repositories in POMs of dependencies > > Mark Struberg wrote: > > > But in my local repo, all the artifacts from those repositories gets merged > > to > a single big landfill. > > That seems to be a completely independent issue, isn't it? The question I > originally raised was about what repositories ought to be considered during > dependency resolution, not where we should store the local artifacts/metadata > retrieved from them. > > So please consider to move this part of the discussion off into another > thread, > keeping this thread focused on its actual topic and thereby easing review of > the > thread. > > > Benjamin > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
There are three primary variants of how the artifact resolution can work with respect to repositories where RS is the set of remote repositories that will be used for artifact resolution: 1) RS is what's available in the effective POM. Easy. 2) RS is collect from inspecting metadata transitively and reconciling the repositories found as a set before artifact resolution. Difficult. 3) RS is collection of partitions of sub-trees where the individual repositories are found. The reconciliation process becomes a backchaining mediation. Extremely difficult. 1) Pretty simple, and works with repository managers. Most large organizations will use one within a year. I love this idea from a Sonatype perspective, but from a Maven user perspective we potentially cripple OSS projects. What we decide to do here has long lasting effects. A variation on what Josh Bloch says about APIs. API design (and corresponding behavior) is like sex. Make one mistake and you support it for the rest of your life. If we pick this method it will categorically change the internals of the repository system and it will make it pretty much impossible to change to 2) or 3) in a practical way. Based on empirical observations in that aside from Oleg, Benjamin, Igor, and myself (all Sonatype at the time of implementation) no one has contributed anything. This is just not something that can be tinkered with so thinking we can try this method and then back it out and make it more sophisticated later is a pipe dream. I think 2) and 3) require a lot of discussion. So really I think it boils down to are we going to really make 1) the way it works? Otherwise I think we are also obliged to look at the models in P2 and OBR because it probably doesn't make sense to re-invent another mediation and reconciliation mechanism. On 2009-10-29, at 12:27 PM, Brian Fox wrote: It's amazing how google's thread compression of a discussion can cause me to overlook a huge thread so near and dear to my heart. To start, Benjamin has hit the nail on the head of a discussion point Jason and I have had going for quite some time. In fact, we even wrote up a proposal for it months ago that got little feedback. I've also blogged on this subject before. Written and suggested reading in this order: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery I won't rehash all of what I've already written, and leave it to the reader to follow the above urls for the majority of the points however I think there is one key argument that is worth reiterating: The ability of a user to checkout an open source project with no prior knowledge of it and simply be able to build it, run the tests and patch it the first try is the most powerful way to demonstrate the Maven to new users. Simply removing or ignoring repositories in the poms will break this functionality that I feel pretty strongly about. All of the arguments so far in this thread mostly revolve around issues in corporate / enterprise use, and for these issues repository managers are the best solution. I don't think its in the best interest of the community to break OSS use to support Enterprise use, particularly when that problem is already covered. Specifically, I'm pretty strongly in favor of continuing to support repositories declared in poms, however they should be scoped for only the subtree of dependencies introduced by the pom declaring the repo. Further, I recognize that having urls burned into immutable poms is not the best way to accomplish this, and I think we need to find a better one pretty quickly. --Brian On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly wrote: 2009/10/28 Brett Porter On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: On Wed October 28 2009 10:53:10 am John Casey wrote: I tend to agree, they should not really be used. It seems like these third-party repositories have a strong potential for causing network errors (in cases where the repo is down or on a private network), and they definitely push the user in the direction of trusting anything that comes from anywhere on the internet without thinking twice...not a great idea, and an understandably unpopular one with companies. I think the role of the declaration in the POM should be shifted in Maven 3. I think this along the same lines that Brett was talking, but I'd really like to see them take on an advisory role rather than actively participate in resolution. In other words, if an artifact cannot be found, then display the list of third-party repositories which MIGHT contain the artifact, along with the POM that lists that repository. I'm OK with that EXCEPT for repositories defined in the current pom+parents. For transitive dependencies, yes, but not for building the current project. +1 This avoids fudging with settings.xml, which h
Maven 3: Deprecating old-style references?
I was reading the Introduction to the POM page. It says: >> These variables are all referenced by the prefix "project.". >> You may also see references with pom. as the prefix, or the >> prefix omitted entirely - these forms are now deprecated and >> should not be used. Will these old-style uses finally be disallowed in Maven 3? Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
On 2009-10-30, at 10:17 AM, Paul Benedict wrote: I was reading the Introduction to the POM page. It says: These variables are all referenced by the prefix "project.". You may also see references with pom. as the prefix, or the prefix omitted entirely - these forms are now deprecated and should not be used. Will these old-style uses finally be disallowed in Maven 3? For backward compat they will remain during 3.0. We should collapse them in 3.1. Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit : > On 2009-10-30, at 10:17 AM, Paul Benedict wrote: > > I was reading the Introduction to the POM page. It says: > >>> These variables are all referenced by the prefix "project.". > >>> You may also see references with pom. as the prefix, or the > >>> prefix omitted entirely - these forms are now deprecated and > >>> should not be used. > > > > Will these old-style uses finally be disallowed in Maven 3? > > For backward compat they will remain during 3.0. We should collapse > them in 3.1. Will we get WARNINGS about their use to ease existing poms clean up ? /Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
Yes, I agree. Providing warnings is a simple incentive to push people away from their use. Paul On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN wrote: > Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit : >> On 2009-10-30, at 10:17 AM, Paul Benedict wrote: >> > I was reading the Introduction to the POM page. It says: >> >>> These variables are all referenced by the prefix "project.". >> >>> You may also see references with pom. as the prefix, or the >> >>> prefix omitted entirely - these forms are now deprecated and >> >>> should not be used. >> > >> > Will these old-style uses finally be disallowed in Maven 3? >> >> For backward compat they will remain during 3.0. We should collapse >> them in 3.1. > > Will we get WARNINGS about their use to ease existing poms clean up ? > > /Paul > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
> I think 2) and 3) require a lot of discussion. So really I think it boils > down to are we going to really make 1) the way it works? Otherwise I think > we are also obliged to look at the models in P2 and OBR because it probably > doesn't make sense to re-invent another mediation and reconciliation > mechanism. I think we have to also consider that 2) is what Maven does now. (Benjamin thinks it might be 3 but I seem to recall repos added along the way stick around forever) However the way it's done by recursively walking the tree and grabbing things has to go since that's the source of most oddities in resolution (for example the preference to the first artifact seen in a pom). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
Yeah deprecated in 3.x. However we'll always have to support them when resolving things from the repo since that's cast in stone for projects already released. We should not support them for projects being built with 3.x though. On Fri, Oct 30, 2009 at 1:34 PM, Paul Benedict wrote: > Yes, I agree. Providing warnings is a simple incentive to push people > away from their use. > > Paul > > On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN wrote: >> Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit : >>> On 2009-10-30, at 10:17 AM, Paul Benedict wrote: >>> > I was reading the Introduction to the POM page. It says: >>> >>> These variables are all referenced by the prefix "project.". >>> >>> You may also see references with pom. as the prefix, or the >>> >>> prefix omitted entirely - these forms are now deprecated and >>> >>> should not be used. >>> > >>> > Will these old-style uses finally be disallowed in Maven 3? >>> >>> For backward compat they will remain during 3.0. We should collapse >>> them in 3.1. >> >> Will we get WARNINGS about their use to ease existing poms clean up ? >> >> /Paul >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
I created MNG-4421 to track this issue: http://jira.codehaus.org/browse/MNG-4421 Paul On Fri, Oct 30, 2009 at 5:15 PM, Brian Fox wrote: > Yeah deprecated in 3.x. However we'll always have to support them when > resolving things from the repo since that's cast in stone for projects > already released. We should not support them for projects being built > with 3.x though. > > On Fri, Oct 30, 2009 at 1:34 PM, Paul Benedict wrote: >> Yes, I agree. Providing warnings is a simple incentive to push people >> away from their use. >> >> Paul >> >> On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN wrote: >>> Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit : On 2009-10-30, at 10:17 AM, Paul Benedict wrote: > I was reading the Introduction to the POM page. It says: >>> These variables are all referenced by the prefix "project.". >>> You may also see references with pom. as the prefix, or the >>> prefix omitted entirely - these forms are now deprecated and >>> should not be used. > > Will these old-style uses finally be disallowed in Maven 3? For backward compat they will remain during 3.0. We should collapse them in 3.1. >>> >>> Will we get WARNINGS about their use to ease existing poms clean up ? >>> >>> /Paul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
Brian Fox wrote: I think we have to also consider that 2) is what Maven does now. (Benjamin thinks it might be 3 but I seem to recall repos added along the way stick around forever) I was trying to check what Maven 2.x actually does and came up with this POM snippet: org.sonatype.nexus nexus-utils 1.4.0 edu.purdue.cs.bloat edu.purdue.cs.bloat 1.0 The first dependency nexus-utils is available from central and its POM inherits a repository called sonatype-forge from its parent. The second dependency is not available from central but only from sonatype-forge. Now in an environment without any mirrors, invoking something like "mvn compile" on this POM to trigger dependency resolution, I observed Maven 2.x failing to resolve the second dependency because it only tried to download it from central and did not consider the repository declared in the POM of nexus-utils. This seems to indicate that Maven 2 is scoping the repositories discovered in dependency POMs to the sub tree of the dependency graph its about to process. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3: Deprecating old-style references?
It is going interesting to see lots/logs of warnings when we starting using 3.0 :-) -Dan On Fri, Oct 30, 2009 at 4:12 PM, Paul Benedict wrote: > I created MNG-4421 to track this issue: > http://jira.codehaus.org/browse/MNG-4421 > > Paul > > On Fri, Oct 30, 2009 at 5:15 PM, Brian Fox wrote: >> Yeah deprecated in 3.x. However we'll always have to support them when >> resolving things from the repo since that's cast in stone for projects >> already released. We should not support them for projects being built >> with 3.x though. >> >> On Fri, Oct 30, 2009 at 1:34 PM, Paul Benedict wrote: >>> Yes, I agree. Providing warnings is a simple incentive to push people >>> away from their use. >>> >>> Paul >>> >>> On Fri, Oct 30, 2009 at 12:31 PM, Paul MERLIN wrote: Le vendredi 30 octobre 2009 18:21:22, Jason van Zyl a écrit : > On 2009-10-30, at 10:17 AM, Paul Benedict wrote: > > I was reading the Introduction to the POM page. It says: > >>> These variables are all referenced by the prefix "project.". > >>> You may also see references with pom. as the prefix, or the > >>> prefix omitted entirely - these forms are now deprecated and > >>> should not be used. > > > > Will these old-style uses finally be disallowed in Maven 3? > > For backward compat they will remain during 3.0. We should collapse > them in 3.1. Will we get WARNINGS about their use to ease existing poms clean up ? /Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
On 2009-10-30, at 3:13 PM, Brian Fox wrote: I think 2) and 3) require a lot of discussion. So really I think it boils down to are we going to really make 1) the way it works? Otherwise I think we are also obliged to look at the models in P2 and OBR because it probably doesn't make sense to re-invent another mediation and reconciliation mechanism. I think we have to also consider that 2) is what Maven does now. Not really, it does a weird hybrid of 2) and 3). (Benjamin thinks it might be 3 but I seem to recall repos added along the way stick around forever) However the way it's done by recursively walking the tree and grabbing things has to go since that's the source of most oddities in resolution (for example the preference to the first artifact seen in a pom). - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Handling of repositories in POMs of dependencies
On 2009-10-30, at 4:39 PM, Benjamin Bentmann wrote: Brian Fox wrote: I think we have to also consider that 2) is what Maven does now. (Benjamin thinks it might be 3 but I seem to recall repos added along the way stick around forever) I was trying to check what Maven 2.x actually does and came up with this POM snippet: org.sonatype.nexus nexus-utils 1.4.0 edu.purdue.cs.bloat edu.purdue.cs.bloat 1.0 The first dependency nexus-utils is available from central and its POM inherits a repository called sonatype-forge from its parent. The second dependency is not available from central but only from sonatype-forge. Now in an environment without any mirrors, invoking something like "mvn compile" on this POM to trigger dependency resolution, I observed Maven 2.x failing to resolve the second dependency because it only tried to download it from central and did not consider the repository declared in the POM of nexus-utils. This seems to indicate that Maven 2 is scoping the repositories discovered in dependency POMs to the sub tree of the dependency graph its about to process. Scoping is the relatively easy part. Start trying to figure what to do when sub-trees contribute conflicting artifacts. We have the simple depMan approach which is just to override absolutely everything. This may be fine if you know what your target platform is (and I use the term used by the eclipse folks intentionally), but when it's not described then you're back to full conflict resolution. It may simply be we do what the Eclipse folks do which is to iteratively correct the target platform until you have something that works. Where this breaks down is when you start combining disparate target platforms and now you start doing conflict resolution again or it simply doesn't work. This is the general problem with people having an eclipse installation and they download some plugin which was developed apart from the standard eclipse distributions and you get a conflict which renders your system unusable. Do we try to be proactive and store the information to allow thing developed separately to be reconciled more automatically? Is letting the user reconcile this through an iterative process the way to go? We could make some simplifications like an artifact having a canonical repository, or home repository as Igor calls it, so that when people hijack another projects artifactId/groupId these artifacts are not considered in the calculation unless specific instructions are issued by users with additional knowledge. Ultimately this may all be too complicated and the reality may be that we can provide tools to help reconcile these differences but ultimately you arrive at a hand- crafted target platform for your final resultant application. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
