Re: Update versions of all plugins in default-bindings.xml
I think the warning is a really good idea but I don’t think this wording will mean anything to the average maven user, as I don’t understand from it what I should do to fix the problem. How about something like: “Specify explicit versions for these plugins in the project pom or an ancestor pom:...” If someone is maintaining plug-in versions manually is there a tool to point out all the upgrade possibilities? Thanks David Jencks Sent from my iPhone > On Jan 12, 2019, at 7:39 PM, Hervé BOUTEMY wrote: > > we have 2 opposite objectives: > - make default near-empty pom work at best, > - but force people to have defined plugins versions (then not really empty > pom) to get stable build > > and I checked about the warning message: I was wrong, there is no warning > message when plugins without versions are injected by default lifecycle > bindings > > Just test for yourself following pom.xml from any beginner: > >4.0.0 >com.mycompany.app >my-app >1.0-SNAPSHOT > > > it works = what we expect to ease newcomers experience > but there is no warning... > > IMHO, this is where we need to improve the tool, by adding a warning: > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that > displays: > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for com.mycompany.app:my-app:jar:1.0-SNAPSHOT > [WARNING] Using default plugins versions from bindings: > [org.apache.maven.plugins:maven-clean-plugin, > org.apache.maven.plugins:maven-install-plugin, > org.apache.maven.plugins:maven-resources-plugin, > org.apache.maven.plugins:maven-surefire-plugin, > org.apache.maven.plugins:maven-compiler-plugin, > org.apache.maven.plugins:maven-jar-plugin, > org.apache.maven.plugins:maven-deploy-plugin, > org.apache.maven.plugins:maven-site-plugin] > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] > > With this warning, and a parent pom to have an easy fix (instead of 8 plugins > versions definition), IMHO, we have what we strongly need. > > And even better, with this warning in place to avoid people to continue to > rely on default plugins versions (because of the nasty warning), I could find > upgrading default plugins versions not an issue any more!!! > > Should we try to go this route? > > Regards, > > Hervé > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit : >> The original plan was to make plugin version mandatory. Perhaps 3.7.0 is >> the time to do that, with a CLI option (to be removed after 3.7.x) to pull >> in the 3.6.x default versions if your pom is missing plugin versions. >> >> The warning has been there long enough. Let’s pull the trigger. >> >>> On Sat 12 Jan 2019 at 21:34, Tibor Digana wrote: >>> I have a strong reason to update Surefire due to new JRE versions have >>> been >>> updated too many times last two years. >>> They required a fix done within a few days and some of them are shaking on >>> the chair... >>> Our Maven Core is stable and Java 9+ ready but the obsolete plugins are >>> not. >>> I want only the same compatibility with default plugins because people do >>> not see these plugins as a distinct community. They are both Maven and >>> plugins from us Apache, so they most probably would expect it consistent >>> altogether. >>> Makes sense? >>> >>> On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels >>> >>> wrote: >>>> I think that’s a real bad idea if you have to do local modifications to >>>> get to a working build environment. Maven is all about not requiring you >>> >>> to >>> >>>> do that (anymore). So even requiring a certain Maven Version does not >>>> fit >>>> in that pattern (although unavoidable if you do not want to work with >>>> wrappers). >>>> >>>> So this means: keep old standard versions and overwrite them always in >>>> poms. (And it means the amount of default versions should be reduced or >>> >>> at >>> >>>> least not add new ones) >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> >>>> Von: Robert Scholte >>>> Gesendet: Samstag, Januar 12,
Re: Merging via GitHub
It's possible to configure GitHub to allow rebase and merge, which I think is what you want. It may be possible to configure GitHub to only allow this. I’m not sure if this is something infra has to do or if a project admin can set it up. Camel recently made a related change. David Jencks > On May 11, 2020, at 3:23 PM, Benson Margulies wrote: > > Could you send me a pointer to refresh my memory on procedures? It's been a > while ... > > On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > >> Folks, >> >> please do NOT merge via merge button in GitHub: >> >>> commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, >> origin/HEAD) >>> Merge: 34253e3d f7de3a6e >>> Author: Elliotte Rusty Harold >>> Commit: GitHub >>> >>>Merge pull request #66 from apache/plex >>> >>>[SCM-930] update plexus-utils >>> >>> commit f7de3a6ea5e182d7fab28e8f0548da2324097ba9 >>> Author: Elliotte Rusty Harold >>> Commit: Elliotte Rusty Harold >>> >>>update plexus-utils >> >> 1. It produces useless merge commits >> 2. GitHub is NOT a blessed committer >> >> It is OK, wenn a clean rebased merge is performed and not traces of >> GitHub are left. >> >> Michael >> >> - >> 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: Merging via GitHub
As a side note, I’m personally in favor of the author squashing manually and the “merge” into master using rebase-and-commit. To your main issue, I’m pretty sure that GitHub doesn’t keep any secret information, instead you are using an insufficiently verbose log command. Try git log --pretty=fuller By default git log just shows the author, and you are looking for the committer (person who merged in the commit). See git-log <https://git-scm.com/docs/git-log#_pretty_formats> david jencks > On May 16, 2020, at 4:53 PM, Olivier Lamy wrote: > > I wonder what is exactly the problem here? (except a noisy commit but who > cares really compared to the useless noise email notifications when someone > rebase a branch) > But at least there are real person name. > That's weird because I just used the "Squash and merge' for this PR ( > https://github.com/apache/maven-shared-utils/pull/30) and got nice commit > https://github.com/apache/maven-shared-utils/commit/32942621ff5df2f8779e0f55276c902a1fcb42b9 > Elliotte Maybe something with your GH configuration? > > I have definitely more concerns with this one > https://github.com/apache/maven-shared-utils/commit/bb2f85e98c3c651ae50b7f642500cb74f50abb0d > > some github UI features show it as `dependabot-preview authored and > slachiewicz committed` > But looking at log with a real git tool call 'git' :) I get > > > commit bb2f85e98c3c651ae50b7f642500cb74f50abb0d > Author: dependabot-preview[bot] <27856297+dependabot-preview[bot]@ > users.noreply.github.com> > Date: Mon Mar 9 04:19:41 2020 + >Bump hamcrest-core from 1.3 to 2.2 > Bumps [hamcrest-core](https://github.com/hamcrest/JavaHamcrest) from 1.3 to > 2.2. > - [Release notes](https://github.com/hamcrest/JavaHamcrest/releases) > - [Changelog]( > https://github.com/hamcrest/JavaHamcrest/blob/master/CHANGES.md) > - [Commits]( > https://github.com/hamcrest/JavaHamcrest/compare/hamcrest-java-1.3...v2.2) > > Signed-off-by: dependabot-preview[bot] > > And this is totally wrong! we must have a real person name in the commit > logs (and github UI is not the real commit logs). > not sure how to fix that
Re: How does maven-site publishing work?
I strongly recommend using the most up to date infra site support which involves a git repo with an asf.yaml file indicating that it’s your website. Push to the git repo and as if by magic your website appears. See https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features I’m also strongly in favor of using asciidoc rather than markdown and using Antora, however that’s a separate issue. Completely off topic for this thread, but…. how hard would it be for the maven site plugin to generate asciidoc? David Jencks > On Oct 19, 2020, at 11:38 AM, Michael Osipov wrote: > > Folks, > > we at the HttpComponents TLP we'd like use the same approach as maven-site > does. We'd ilke to automatate as much as possible, means: push to repo should > trigger a a push to the website. I can see that svnpubub is obviously used in > the POM. But the question is, where is the trigger performing the actual > step? Who knows best? > > See discussion [1] > > Thanks, > > Michael > > [1] https://www.mail-archive.com/dev@hc.apache.org/msg27650.html > > - > 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: APT vs Markdown formats for site docs
Asciidoctor Maven Tools is the more supported way of using Asciidoctor from maven, either directly or through Doxia. https://docs.asciidoctor.org/maven-tools/latest/ <https://docs.asciidoctor.org/maven-tools/latest/> (docs) https://github.com/asciidoctor/asciidoctor-maven-plugin <https://github.com/asciidoctor/asciidoctor-maven-plugin> (GitHub) AsciiDoc support in Jekyll using jekyll-asciidoc is quite good, and GitHub is rather jekyll-friendly. You do have to build the site yourself, GitHub’s built in AsciiDoc rendering is somewhat crippled for incomprehensible reasons. I’m now the primary maintainer of jekyll-asciidoc so issues may receive prompt attention. I think Antora is incomparable, and would certainly produce fabulous results properly used for maven documentation, but with the investment in Doxia organization that may be a better choice. David Jencks > On Feb 1, 2021, at 3:34 AM, Andres Almiray wrote: > > FWIW Doxia supports Asciidoc pretty well. You just have to add an extra > dependency for it to find Asciidoctorj, as demonstrated at > > https://github.com/kordamp/pomchecker/blob/master/pom.xml#L200-L227 > > You can mix all kind of supported formats if needed. Or use only asciidoc, > the choice is yours ;-) > > Cheers, > Andres > > --- > Java Champion; Groovy Enthusiast > http://andresalmiray.com > http://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, and > those who don't. > To understand recursion, we must first understand recursion. > > > On Mon, Feb 1, 2021 at 12:29 PM Artem Krosheninnikov < > artem.krosheninni...@gmail.com> wrote: > >> I agree that there are several implementations thus it may be not a good >> choice. >> >> FML looks very ancient from my point of view but asciidoc is more or less a >> standard format in docops community. >> >> It's not that everything should be immediately converted to another format, >> just trying to understand whether apt is convenient for all and is a >> standard for all maven projects. >> >> пн, 1 февр. 2021 г. в 13:32, Benjamin Marwell : >> >>> Markdown is not a "standard" or "standardized". >>> Even worse, different implementations have different feature sets. >>> Thus my -1 for md. >>> >>> But another format might be feasible, really. fml looks verbose. >>> >>> Asciidoc might be a sane choice here. It was specially designed for >>> technical documentation and >>> has neat features which are handy for exactly those cases. >>> Besides, it is also supported on GitHub. >>> >>> --- >>> >>> A quick check revealed there was no such discussion in the last 12 >>> months on the mailing list. >>> >>> - Ben >>> >>> >> >> -- >> Sincerely yours, >> Krosheninnikov Artem. >>
Re: APT vs Markdown formats for site docs
I looked for a few minutes at https://github.com/apache/logging-log4j2 and found 3 or 4 markdown pages under site that didn’t appear to have anything that would be hard to write in AsciiDoc. The root level pages such as README.md, if written in (limited) AsciiDoc, will display nicely at GitHub. David Jencks > On Feb 1, 2021, at 7:24 AM, Ralph Goers wrote: > > Log4j didn’t switch everything. A couple pages had to be left as Markdown for > things AsciiDoc doesn’t support, although at the moment I don’t remember what > those things were at the moment. > > Ralph > >> On Feb 1, 2021, at 6:30 AM, Gary Gregory wrote: >> >> FYI, over at Log4j, we switched to Asciidoc. >> >> Gary >> >> On Mon, Feb 1, 2021, 05:19 Artem Krosheninnikov < >> artem.krosheninni...@gmail.com> wrote: >> >>> Hello there, whilst looking at some docs in maven-enforcer-plugin, I found >>> .apt.vm format not very convenient and developer-friendly, especially for a >>> newcomer. >>> >>> Is it a standard for all maven plugins or were there any discussions on >>> using another format? I see that maven-parent-34 has several modules for >>> other formats like markdown or fml. >>> -- >>> Sincerely yours, >>> Krosheninnikov Artem. >>> > > > > - > 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] Automatically format and sort imports
A possible data point… For a while I worked on isomorphic-git (javascript) which had a pre-commit hook to format the code. It was rather surprising at first, but I ended up really liking it, more than projects that attempted to check the formatting during the build, which were susceptible to ways of running the build that skipped the format check. David Jencks > On Oct 13, 2022, at 8:31 AM, Guillaume Nodet wrote: > > Le jeu. 13 oct. 2022 à 17:13, Łukasz Dywicki <mailto:l...@code-house.org>> a écrit : > >> Some of findings I have: >> >> - Static code analysis might be slow, reformatting code will add >> additional time to the build which might not be desired for developer >> experience >> > > This is usually reduced to 0 because the plugins just check on files that > have been modified since the last build. > > >> - Error messages produced after reformatting might mistake first time >> contributors who are not familiar with reformatting step done before >> compilation >> > > Not sure to understand what you mean. Formatting is not supposed to throw > errors... > > >> - I recently found a plugin for IJ: >> https://github.com/krasa/EclipseCodeFormatter >> <https://github.com/krasa/EclipseCodeFormatter> (allows to unify two >> dominant IDEs) >> > > Forcing specific a environment in IDE is not ideal imho. If you work on > different projects, you then need to activate / deactivate plugins or > your code style everytime you switch. > In addition, not enforcing the code style strictly leads to source files > being not inline with the formatter settings. WHich in turns means that > you can't really use it because whenever you do, you end up with many > changes unrelated to your current work that you need to undo in order to > keep your PR clean and minimal. > I think that's a real problem, and that would also be solved by an > automatic format imho. > > >> - Verification of code style might be automated via pull requests, if >> PRs are enforced. Otherwise core developers must take care of their >> habits or commit hooks. >> > > I still don't see the problems with an automatic format step. I've been > using it in projects for years in camel. The only problem is when people > don't build before committing, but that can't really happen in the maven > land > where almost all changes are done through PRs and validated. We just need > to enforce the no-file modified step in PRs. Ideally, we'd even have a > commit hook to enforce that. Not sure if that's doable. > > If there a real problems, what could be done is move the autoformatting > step in a separate profile which could be deactivated by default (though > people that want it can activate it in their settings). The PR workflow > would enable this profile and ensure there's no modification to the input > files. I really don't see the benefit of not running it for everyone, but > if some people do, that's fine with me. > > >> >> Cheers, >> Łukasz >> >> On 13.10.2022 15:27, Guillaume Nodet wrote: >>> Le jeu. 13 oct. 2022 à 12:50, Olivier Lamy a écrit : >>> >>>> On Thu, 13 Oct 2022 at 17:47, Tamás Cservenák >> wrote: >>>>> >>>>> Howdy, >>>>> >>>>> to not get lost in implementation details, it is really unimportant >>>>> (spotless, this or that...) >>>>> >>>>> What IS important is that we agree to implement "IDE agnostic source >>>>> formatting", that happens during build >>>>> (by maven plugin). This means _everyone_ will end up with 100% the same >>>>> result. >>>>> >>>>> The only thing that comes to my mind is "sloppy committer" who does not >>>>> build but pushes >>>> >>>> not sure to understand. You mean formatting sources will be bind to a >>>> phase and be executed automatically? >>>> >>> >>> Yes, I meant "automatic" in opposition to "on demand". Sorry if that was >>> not clear. >>> >>> >>>> >>>> Wouldn’t it be better to still have a check as today (checkstyle:check >>>> or the used foo-bar-formatter-plugin:check) which checks the sources >>>> at validate phase. >>>> Then in case of failure, the committer can just run >>>> foo-bar-formatted-plugin:format. >>>> So committer can apply some manual changes as well. >>>> this wi
Re: [jira] (SCM-775) Request for new optional parameter RTC (workItem) with release:prepare to associate workitem with changesets got created during build process
Sorry for the reply on list, my codehaus jira credentials seem to have gotten
messed up….
I would expect the best normal workflow would be to have the release plugin
create the work item, then attach the change sets to it. I have some evidence
that it is possible for external programs to do stuff like this, but I have no
idea how.
david jencks
On Sep 10, 2014, at 8:51 AM, "AShit Shah (JIRA)" wrote:
>
>[
> https://jira.codehaus.org/browse/SCM-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352607#comment-352607
> ]
>
> AShit Shah commented on SCM-775:
>
>
> Both options are fine.
>
> I think ANT have it via build.xml. I personally would prefer to have it via a
> -D option at command line and not hard-coded in pom.xml.
>
> I was thinking of creating one release build WI for every agile sprint. Not
> sue if this is right approach though.
>
>> Request for new optional parameter RTC (workItem) with release:prepare to
>> associate workitem with changesets got created during build process
>> -
>>
>>Key: SCM-775
>>URL: https://jira.codehaus.org/browse/SCM-775
>>Project: Maven SCM
>> Issue Type: Improvement
>> Components: maven-scm-provider-jazz
>> Affects Versions: 1.9.1
>> Reporter: AShit Shah
>>
>> Maven {{release:prepare}} command is failing with below error while
>> delivering updated pom.xml to the stream due to Preconditions configured in
>> RTC to have comments and associated work item with every delivery.
>> [ERROR] Name: Deliver
>> [ERROR] Participant Reports:
>> [ERROR] Name: Require Work items and Comments
>> [ERROR] A work item must be associated with the change set.`
>> [ERROR] At least one of the associated work items must specify that the work
>> is planned for the current iteration.
>> [ERROR] At least one of the associated work items must be assigned to you.
>> [ERROR] Problem running 'deliver':
>> [ERROR] 'Deliver' failed. Preconditions have not been met: A work item must
>> be associated with the change set.
>> [ERROR] -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>> goal org.apache.maven.plugins:maven-release-plugin:2.5:prepare (default-cli)
>> on project junit-ext: Unable to commit files
>> Provider message:
>> Error code for Jazz SCM deliver command - 17
>> I can not find any optional parameters on
>> http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html
>> for release:prepare command which I can use and pass the RTC workitem number
>> on command line.
>> Suggestion:
>> It will be great if you can provide optional parameters like "workItem"
>> which I can use and pass RTC workitem number with release:prepare at command
>> line.
>> Example: mvn -PmyProfile release:prepare -DworkItem=123456
>> So build process should associate change sets created by release:prepare
>> with work item 123456 and deliver change sets to the stream.
>> As of now I have to use "-DpushChanges=false" parameter to block delivery
>> process and I have to manually find the change sets, associate them with
>> work item and deliver them before I run release:perform.
>> Thanks.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.6#6162)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Ticket Transition Workflow: Abandoned issues
Retired rather than Archived? This cleanup seems like a really good idea :-) david jencks On Nov 26, 2014, at 12:41 PM, Paul Benedict wrote: > My 2-cents on the word "Archived" is that it's a synonym for > Backup/Storage, which I don't think is what this process is about. > > > Cheers, > Paul > > On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov wrote: > >> Am 2014-11-26 um 16:16 schrieb Paul Benedict: >> >>> This email is related to thread "Abandoned bug analysis" [1]. >>> >>> We have done the Great Ticket Cleanup of 2014 twice this year. It has >>> really been productive for anyone who triages outstanding bugs and >>> enhancements. We've been adding a note in the ticket, as a courtesy to the >>> participants, and closing them as "Won't Fix". >>> >>> This is certainly one valid way of accomplishing the goal. However, I do >>> believe we should enhance our workflow by adding an "Abandoned" (my fav) >>> or >>> "Archived" resolution. Why? Because "Won't Fix" is typically is used to >>> close out a bug that will never be fixed (i.e., too many people rely on >>> the >>> bad behavior) or the enhancement is deemed worthless or incorrect. But >>> more >>> importantly, it's not possible to do a JIRA search and distinguish between >>> these two conditions unless a new resolution is introduced. >>> >> >> We need two new things: >> >> 1. Status: Awaiting Feedback (not just labels). >> 2. Resolution: Archived >> >> Michael >> >> - >> 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: Ticket Transition Workflow: Abandoned issues
In my work life use of RTC Backlog means "needs to be investigated by a developer". I think Cancelled as Incomplete might be a closer RTC match to the meaning we are looking for here. david jencks On Nov 26, 2014, at 2:14 PM, Chris Graham wrote: > RTC uses Backlog. Does Jira have something similar? > > Sent from my iPhone > > On 27/11/2014, at 8:13 AM, David Jencks > wrote: > >> Retired rather than Archived? >> >> This cleanup seems like a really good idea :-) >> >> david jencks >> >> On Nov 26, 2014, at 12:41 PM, Paul Benedict wrote: >> >>> My 2-cents on the word "Archived" is that it's a synonym for >>> Backup/Storage, which I don't think is what this process is about. >>> >>> >>> Cheers, >>> Paul >>> >>> On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov wrote: >>> >>>> Am 2014-11-26 um 16:16 schrieb Paul Benedict: >>>> >>>>> This email is related to thread "Abandoned bug analysis" [1]. >>>>> >>>>> We have done the Great Ticket Cleanup of 2014 twice this year. It has >>>>> really been productive for anyone who triages outstanding bugs and >>>>> enhancements. We've been adding a note in the ticket, as a courtesy to the >>>>> participants, and closing them as "Won't Fix". >>>>> >>>>> This is certainly one valid way of accomplishing the goal. However, I do >>>>> believe we should enhance our workflow by adding an "Abandoned" (my fav) >>>>> or >>>>> "Archived" resolution. Why? Because "Won't Fix" is typically is used to >>>>> close out a bug that will never be fixed (i.e., too many people rely on >>>>> the >>>>> bad behavior) or the enhancement is deemed worthless or incorrect. But >>>>> more >>>>> importantly, it's not possible to do a JIRA search and distinguish between >>>>> these two conditions unless a new resolution is introduced. >>>>> >>>> >>>> We need two new things: >>>> >>>> 1. Status: Awaiting Feedback (not just labels). >>>> 2. Resolution: Archived >>>> >>>> Michael >>>> >>>> - >>>> 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: [VOTE] Name our mascot: "Shotgun" vs "The Maven Owl"
B david jencks On Dec 15, 2014, at 5:39 AM, Stephen Connolly wrote: > After the run-off round, we are left with two names standing. > > This second vote will be a straight and simple majority wins. > > The vote will be open for at least 72 hours (with the potential of an > extension until I send a message saying that the polls are closed) > > There will be no discussion in this thread, we have talked it all enough > already. If you want to discuss something, please use a different thread. > > Vote: > > [A]: Shotgun > [B]: The Maven Owl > > Thank you very much for your time > > -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Formal verification of thread correctness in maven core
I wonder that too. I don't think cglib is maintained, AFAIK most people use asm nowadays. I believe it is fairly easy to use asm to add byte code to the beginning and end of every method for e.g. logging method entry/exit. Apache Aries has an asm based thing to enable adding some kind of before/after logic (this is designed for osgi weaving hooks). With this approach you would not need subclasses. david jencks On Jan 5, 2015, at 9:51 AM, Igor Fedorenko wrote: > What kind of changes to the model do you expect? Can you give some > pointers that explain verification logic you have in mind? > > -- > Regards, > Igor > > On 2015-01-05 9:11, Kristian Rosenvold wrote: >> I'd be interested in using cglib to generate a full set of subclasses >> for the entire maven model. These subclasses could assert stuff about >> "proper" thread correctness wrt the current "correct" threading model >> for maven. This would be capable of blowing up /immediately/ a plugin >> violates the contract and could be used to make a "formal" >> verficiation that the entire set of plugins performs to specification >> in a given build. >> >> I could potentially see this added as a "diagnostic" mode to core. >> >> I know how to create the verification logic, but I am totally blank >> when it comes to cglib. Is there anyone who can help me a bit ? Maybe >> even someone who could code the actual cglib bit :) ? >> >> Kristian >> >> - >> 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] Speed up release process?
+1 from the sidelines.
I don’t understand
>>>* current process causes (forced) context switching, and can likely lead to
human mistakes: when the release vote is announced, developer is FORCED to
stop for 72h and possibly switch. This is just a productivity killer.
<<<
Who is forced to do anything and for what reason?
AFAIK cascading dependencies can be handled by releasing cause + all effects at
once. If that’s hard to do now, maybe there’s a way to make it easier. I’d
expect it would make testing a change more plausible as well.
David Jencks
> On Nov 18, 2022, at 10:44 AM, Romain Manni-Bucau
> wrote:
>
> Hi Tamás,
>
> Is 3 days that bothering - didnt spot it to be honest?
> Indeed, strictly speaking you can do "until we get 3 bindings +1" - don't
> think you can say for a maximum otherwise it means you need to cancel if
> you don't get it ;) - but it also means you mean the project does not care
> about its core people - if you start the release on friday night you
> potentially let 0s to some PMC and users to review the release.
> Indeed it is ont an apache requirement but I think it is a good thing to
> enable people to review a release and have the opportunity to give feedback
> so 3 days sounds like a very good default if you take into account the
> world side - timezones - of our project.
>
> Side note: guess exceptions can be done for CVE, milestones, beta, alpha,
> ... - anything not final or urgent but very located.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le ven. 18 nov. 2022 à 18:55, Tamás Cservenák a
> écrit :
>
>> Howdy,
>>
>> My pet peeve these days is our release process. IMHO, we should be able to
>> release ("move") much faster than today.
>>
>> My proposal would be:
>> * vote is "done done" the moment quorum is reached
>> * change the wording in the vote email from "Vote open for at least 72
>> hours." to "Vote open for a maximum of 72 hours.".
>>
>> Reasoning:
>> * vote cannot be vetoed by definition (only release mgr can cancel it).
>> * change would not conflict with ASF defined rules, the 72h is not
>> compulsory (document states "should" not "must").
>> * the release process is already wearisome, complex, and is easy to miss
>> (over-represented) manual steps. For example yesterday for some reason it
>> took almost 2 hours to sync release artifacts to Maven Central, during
>> which you are in a "busy loop" (the announcement and site depends on sync).
>> Leaving it "for tomorrow" may cause users to learn about a new release thru
>> Artifact Listener or whatever other service, causing confusion. Ideally,
>> site and announcement mail should be tied to sync, and that does lead to
>> "busy loop".
>> * current process causes (forced) context switching, and can likely lead to
>> human mistakes: when the release vote is announced, developer is FORCED to
>> stop for 72h and possibly switch. This is just a productivity killer.
>> * which part do you like: as a developer sitting on needles while being
>> blocked on upstream (dependency) bugfix or as a user waiting for bugfix?
>> * we already agreed on one minor process improvement: we have quite long
>> "chains" of dependencies, so a bugfix that can span on long trails could
>> take weeks to be done serially, even if the bugfix itself is trivial. Hence
>> we did accept that we can do "batch votes" (release together) and can do
>> one vote for this case.
>> * on positive site this could lead to mindset change of bugfix releases, as
>> today, few wants to go thru painful release process for "single simple
>> change" (see ASF Slack #maven for "ahh Apache process..."), that IMHO is
>> wrong: we all should release early and often. And be happy with it, not
>> feel it like chores :)
>>
>> Finally some "canned responses":
>> * "time is needed for all interested parties to review": If someone cannot
>> get to it in 5 minutes, or in 5 hours or in 5 days, it really but really
>> does not matter, as release is to happen anyway (unless release mgr cancels
>> it). One not getting to it, will be notified via mails anyway (vote,
>
Re: [DISCUSS] Speed up release process?
Which developers have to pause what activities? From previous discussions elsewhere, I’m strongly of the opinion that < 72 hr release votes are intended only for emergency security fixes and similar events, and that “we’re impatient” isn’t going to cut it with the board. It certainly wouldn’t with me. How many of these annoyances would be eliminated by an easy way to release and vote on a set of changed artifacts + the cascading dependencies all at once? thanks David Jencks > On Nov 18, 2022, at 11:17 AM, Tamás Cservenák wrote: > > David, > > I just meant that there is a "forced pause" of 72h. > > T > > On Fri, Nov 18, 2022 at 7:50 PM David Jencks > wrote: > >> +1 from the sidelines. >> >> I don’t understand >>>>> * current process causes (forced) context switching, and can likely >> lead to >> human mistakes: when the release vote is announced, developer is FORCED to >> stop for 72h and possibly switch. This is just a productivity killer. >> <<< >> Who is forced to do anything and for what reason? >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Speed up release process?
Lets try one question/issue per email… Which developers have to pause what activities. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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] Speed up release process?
You are free to do your own research. I’ve seen plenty of “but we want the convenience of <72hr releases” discussions over the years, and the feedback I’ve seen is consistently that the reason for the “should” rather than “must” is to account for emergency security patches etc, not normal releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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] Speed up release process?
If all 153 projects released at once with 72 hour windows, that would be 72 hours. That’s just as plausible as sequential releases. David Jencks > On Nov 18, 2022, at 11:54 AM, Tamás Cservenák wrote: > > As I wrote, we did have examples of changes + cascading, it is okay. > > But I don't agree with your statement about the board, as they themselves > state "should" not "must" for 72h. If it does not cut with them, they > should modify the refd page(s). > > And it's not "we're impatient" either, part of the response for that is in > "hasty changes" canned response. > > Simply put: > - people see releases as a chore, as some "burden" that needs to be done > once in a while (see refd Slack messages in 1st mail), and when it comes to > be done, "let's do it when it's worth". We have MANY user questions on ML > of type "when is X released? As the issue [the user is interested in] is > fixed". And we have too many "dropped balls" in our court. IMHO, modifying > the process (to take less than 72+2h) is one step toward making release > less painful, less blocker. > > Fun fact: maven project consists of (not sure of exact count, just > guessing) 150+ repositories (GH on ASF org gives 153 when I type in > "maven-" in the repo search bar). This is a LOT. If we'd, for some reason, > start releasing all of those in 72h windows, it would be 10800 hours, or > 450 days, more than a year. > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks > wrote: > >> Which developers have to pause what activities? >> >> From previous discussions elsewhere, I’m strongly of the opinion that < 72 >> hr release votes are intended only for emergency security fixes and similar >> events, and that “we’re impatient” isn’t going to cut it with the board. >> It certainly wouldn’t with me. >> >> How many of these annoyances would be eliminated by an easy way to release >> and vote on a set of changed artifacts + the cascading dependencies all at >> once? >> >> thanks >> David Jencks >> >>> On Nov 18, 2022, at 11:17 AM, Tamás Cservenák >> wrote: >>> >>> David, >>> >>> I just meant that there is a "forced pause" of 72h. >>> >>> T >>> >>> On Fri, Nov 18, 2022 at 7:50 PM David Jencks >>> wrote: >>> >>>> +1 from the sidelines. >>>> >>>> I don’t understand >>>>>>> * current process causes (forced) context switching, and can likely >>>> lead to >>>> human mistakes: when the release vote is announced, developer is FORCED >> to >>>> stop for 72h and possibly switch. This is just a productivity killer. >>>> <<< >>>> Who is forced to do anything and for what reason? >>>> >>>> >> >> >> - >> 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] Speed up release process?
Evidently you know something I don’t, and I hope you’ll explain it to me. For the 3rd time, >>>>> Which developers have to pause what activities? — Right now there are usually release votes in parallel. As I pointed out, all 308 could be in parallel. What relevance does your calculation have to anything? This discussion looks to me like the others I’ve seen about shortening release votes: someone is basically complaining that the apache process is inconvenient for a particular subset of developers on a particular project, without examining what the actual roadblocks to effective development are or what other solutions might be possible. In particular, I’d like to see an analysis of what would happen if a “release” was for a particular project plus all downstream changes needed to use it, whether as a single vote or as concurrent votes. Thanks David Jencks > On Nov 18, 2022, at 1:48 PM, Tamás Cservenák wrote: > > damn me > > 16848 hours = 702 days = almost TWO YEARS of Maven releases just to build > Maven itself. > > But, if you consider all apache artifacts (almost all, unsure is there > other in different groupId) > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep > "commons-" | wc -l > 45 > [cstamas@blondie local (master %)]$ find * -type f -name "*.jar" | grep > "org/apache" | wc -l > 263 > > In total, 308 JARs = 22176 hours = 924 days = 2,5 years. > > T > > On Fri, Nov 18, 2022 at 10:30 PM Tamás Cservenák > wrote: > >> David, >> >> I agree, and understand. >> >> But let me step back a bit: >> ASF (as it all started around httpd) as a foundation hosts MANY projects >> wildly different projects, and those projects usually have a handful (few, >> when compared to Maven) of "deliverables" or "artifacts" being released. Or >> in other words (and am not trying to lessen their complexity or nor to >> present Maven as something "special" here), most of ASF projects have few, >> very few deliverables (again, I am talking about the majority, correct me >> if I am wrong). Really, are there any statistics about: >> - number of reposes used per ASF project >> - number of different (!) artifact releases done per project? >> >> Maven on the other hand, while id DOES also have ONE "downloadable" item >> on download page (https://maven.apache.org/download.cgi) we all know that >> story does not end there: it is known to "download the whole internet", >> just to run Maven "mvn clean verify" it will download zillion of plugins >> and their dependant artifacts (and I did not even mention 3rd party, non >> ASF plugins). So, Maven, as a "deliverable" or "product" is definitely not >> one ZIP file you see on the download page. ASF Maven project has many >> interconnected reposes/artifacts/releases. >> >> So, what I want to say: is it possible that ASF "way" works for "typical" >> projects, while Maven is more like "atypical"? >> >> Or, to make my example more concrete: >> 1. I checked out master of maven from http://github.com/apache/maven >> 2. built it w/ pristine local repo >> 3. and run some stats on it: >> 4. https://gist.github.com/cstamas/ee2bba03f61d09fa3f5e9c57844207b7 >> >> This simply means that for the end user, the "experience of ASF Maven" is >> literally 1 (that on download page) + 233 = 234 releases. And it is all >> very interconnected. >> >> Btw, I just downloaded 16848 hours :) >> >> T >> >> On Fri, Nov 18, 2022 at 9:53 PM David Jencks >> wrote: >> >>> You are free to do your own research. I’ve seen plenty of “but we want >>> the convenience of <72hr releases” discussions over the years, and the >>> feedback I’ve seen is consistently that the reason for the “should” rather >>> than “must” is to account for emergency security patches etc, not normal >>> releases. >>> >>> David Jencks >>> >>>> On Nov 18, 2022, at 11:54 AM, Tamás Cservenák >>> wrote: >>>> >>>> As I wrote, we did have examples of changes + cascading, it is okay. >>>> >>>> But I don't agree with your statement about the board, as they >>> themselves >>>> state "should" not "must" for 72h. If it does not cut with them, they >>>> should modify the refd page(s). >>>> >>>> And it's not "we're impatient" either, part of the response for th
Re: Question - JDK Minimum of future Apache Maven 4.0.0
I wonder if having maven require java 8 syntax discourages any potential contributors who are used to coding using more recent developments. I have no idea how to tell, but maybe someone else does. David Jencks > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise wrote: > > Hi, > > my clear opinion is to go with most recent JDK LTS version for the > release point of Maven 4.0.0 which I assume will be JDK 21... > > That means clear the build time requirement which is completely > different from runtime of an application. > > > Older JDK's are supported by some vendors by having particular special > support which most of the time requires special contracts (means also > paying money for it)..some of them offering builds without paying money > yes.. > > Older runtime target are supported with different approaches like > Toolchain or via `--release XX` which exists since JDK9+. > > > Furthermore if someone is not capable of upgrading the build environment > to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X... > > If it would be requirement to port things back to 3.8.X or 3.9.X it > could be handled by someone who has the time etc. to do that ... if not, > those people might think of paying someone to do that work... > > > The given argument about JPMS for migration causes issues is from my > point of view false-positive because migration to newer JDK versions > does not require JPMS usage... > > Even platforms like AWS support JDK17 in the meantime which is the > runtime... > > > Based on the argument we don't need features of JDK17+ I see a number > of things which could make our handling/maintenance easier for example > using sealed classes to prevent exposing internal things to public which > could be used etc. also some other small features (`var` for example; > Text-Blocks in Tests etc) or using records in some situation... > > > Based on the maintenance part it would mean in consequence to downgrade > to even JDK7... (or even lower) because you can get support for older > JDK version in some ways... (JDK7 from azul for example) > > Kind regards > Karl Heinz Marbaise > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > - > 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] Java version for Maven
I’ve been wondering for some time… My uninformed impression is that most corporate development uses Eclipse or IntilliJ, which I believe run only on the java version they come packaged with, which presumably is not usually the target java version for the code being developed. Aside from packaging questions (IIUC there’s no way for the maven project to ship a java implementation), why should Maven be different? Thanks David Jencks > On Feb 20, 2024, at 1:30 PM, Tamás Cservenák wrote: > > Romain, > > you immediately revealed your WHY: > Take off your "paid dev" hat, and please try again. > > We ARE an open source project. > So it IS about us, the volunteers. > Is not about THEM, downstream users. > > As it was told a million times: > if they are stuck (due whatever policy or who knows what), they can just > stay with 3.9, 3.8 or whatever suits them. > Why align with the "stuck" ones? > > T > > PS: and no, I just collected the last release VOTEs w/ Herve responses on > ML. If you consider that biased, then you have a problem ;) > > > > On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau > wrote: > >>> I am sure the majority of Maven users do not run Maven on the same Java >> version they target with their build. >> >> Do you use that and the following figures to do a biased conclusion? >> >> "If people don't use the same version then we can higher the version"? >> >> I think we need to consider two things: >> >> * We are OSS dev so not representative of the majority - in a company you >> most of the time use the same version you target and want to run that, just >> either laziness, policy or quality (building with different versions can >> lead to surprises and falsy passing tests = broken prod), sadly it is hard >> to find data there but I'm pretty sure it is a common experience >> * Guess there is a "use the first matching version I have" in the stats you >> mention, so if you target 11 and have 17 you would use 17 but does not mean >> you are ok to run 21 (random numbers, move them a bit to be a counter >> example on whatever digit you want for maven 4) >> * Guess very few people want to have >= 1 JDK >> >> So clearly the question is not the latest LTS which would be for me just a >> moving version we can't support and would be bad for our end users IMHO but >> only the version we pick to start at 4.0.0. >> Choices stay: >> >> * Latest LTS at that moment to start fresh and not inherit from a legacy at >> day 0 >> * Latest LTS - 1 - which would enable to cover more projects and get more >> adoptions >> * Something older but I don't find any valid reason since people skipping 2 >> LTS will likely never reach maven 4 before we discuss to move our baseline >> again. >> >> The other question we should probably anticipate is when do we move our >> support version range. >> Since java is not more predictable in terms of releases I think it can make >> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS >> - indeed with best effort on later versions but no guarantee upfront. >> With such a policy calendar can be communicated and people can follow or >> not without surprises. >> >> So today, since we don't have yet a final I think 21 can make sense but not >> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0 >> time. >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://rmannibucau.metawerx.net/> | Old Blog >> <http://rmannibucau.wordpress.com> | Github < >> https://github.com/rmannibucau> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >> < >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>> >> >> >> Le mar. 20 févr. 2024 à 21:50, Tamás Cservenák a >> écrit : >> >>> Howdy, >>> >>> I intentionally used "Maven" here, and not "Maven 4" as I am sure the >>> majority of Maven users do not run Maven on the same Java version they >>> target with their build. We do not do that either. >>> >>> Some snippets from Herve (who is the ONLY one doing reproducible checks, >>> kudos for that) votes: >>> >>> Sun, Feb 18, 2024, 9:38 AM >>> [VOTE] Release Apache Maven Shade Plugin version 3.5.2 >>> Reproducible Build ok: reference build done with JDK 11 on *nix >>> >>> Wed, Jan 31
Re: [DISCUSS] Java version for Maven
From your first paragraph I’d guess you would be on the “maven built on a recent LTS java” side. I was wondering, given these omnipresent IDES, and possibly from a philosophical perspective, what the arguments for “maven built on an antique JVM” would be. Thanks David Jencks > On Feb 20, 2024, at 8:10 PM, Hunter C Payne > wrote: > > IDEs, including the 2 you named, have a configuration system for multiple > JDKs. This allows devs to build for multiple versions of the JVM. Likewise, > Maven has multiple ways to configure multiple JDKs for use by different > phases or plugins used in a given compilation setup and to target different > versions of the JVM. Javac can target any older version than itself when > compiling to classfiles. So my JDK 17 can compile for Java 8-17 but not 18 > or higher. > > On the JVM, packaging is just a jar and inside that jar's classfiles will be > a specific minimum version of the JVM required for it to run. Generally > speaking, for a variety of reasons, most Java code is backwards compatible to > Java 8 which was released about 15 years ago. No specific code is that > backwards compatible but most of it is. That's why you don't realize that > these things exist. Because unless you are a professional developer, why > would you ever care in a language with 15 years of backwards compatibility > baked into the culture and large base of 3rd party code. Hope this answers > your question. > > Hunter > >On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks > wrote: > > I’ve been wondering for some time… My uninformed impression is that most > corporate development uses Eclipse or IntilliJ, which I believe run only on > the java version they come packaged with, which presumably is not usually the > target java version for the code being developed. Aside from packaging > questions (IIUC there’s no way for the maven project to ship a java > implementation), why should Maven be different? > > Thanks > David Jencks > >> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák wrote: >> >> Romain, >> >> you immediately revealed your WHY: >> Take off your "paid dev" hat, and please try again. >> >> We ARE an open source project. >> So it IS about us, the volunteers. >> Is not about THEM, downstream users. >> >> As it was told a million times: >> if they are stuck (due whatever policy or who knows what), they can just >> stay with 3.9, 3.8 or whatever suits them. >> Why align with the "stuck" ones? >> >> T >> >> PS: and no, I just collected the last release VOTEs w/ Herve responses on >> ML. If you consider that biased, then you have a problem ;) >> >> >> >> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau >> wrote: >> >>>> I am sure the majority of Maven users do not run Maven on the same Java >>> version they target with their build. >>> >>> Do you use that and the following figures to do a biased conclusion? >>> >>> "If people don't use the same version then we can higher the version"? >>> >>> I think we need to consider two things: >>> >>> * We are OSS dev so not representative of the majority - in a company you >>> most of the time use the same version you target and want to run that, just >>> either laziness, policy or quality (building with different versions can >>> lead to surprises and falsy passing tests = broken prod), sadly it is hard >>> to find data there but I'm pretty sure it is a common experience >>> * Guess there is a "use the first matching version I have" in the stats you >>> mention, so if you target 11 and have 17 you would use 17 but does not mean >>> you are ok to run 21 (random numbers, move them a bit to be a counter >>> example on whatever digit you want for maven 4) >>> * Guess very few people want to have >= 1 JDK >>> >>> So clearly the question is not the latest LTS which would be for me just a >>> moving version we can't support and would be bad for our end users IMHO but >>> only the version we pick to start at 4.0.0. >>> Choices stay: >>> >>> * Latest LTS at that moment to start fresh and not inherit from a legacy at >>> day 0 >>> * Latest LTS - 1 - which would enable to cover more projects and get more >>> adoptions >>> * Something older but I don't find any valid reason since people skipping 2 >>> LTS will likely never reach maven 4 before we discuss to move our baseline >
Re: [VOTE] Require Java 17 for Maven 4
+1 (non binding, occasional user) David Jencks > On Feb 27, 2024, at 11:30 PM, Benjamin Marwell wrote: > > Hi Maven Devs/Users/Committers and PMC members! > > After several discussions on the mailing lists, I would like to > start a vote in favour of setting the minimal Java bytecode target > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. > > This is a procedural majority vote [1*]: > You can also vote with fractions and negative votes are not vetoes. > > Please also notice: > * Maven 3 will stay at Java 8 no matter what. > * We may raise Maven 4 to JDK 21 later if we feel like it (depending > on the release date). > This is not part of this vote. > * The linked PR is not part of this vote (this is not a code vote). > But you may take a look at it to understand the intended change. > > PR: https://github.com/apache/maven/pull/1430 > > Maven-Parent will not be raised with this vote, the other PR is not > part of this vote. > > Please refrain from starting discussions in this thread, but do > include a reasoning on downvotes and feel free to start a new > discussion on the mailing list, or comment on the existing ones. > > --- > > Vote open for 72 hours: > > [ ] +1 (set JDK17 min version for Maven 4.x) > [ ] +0 > [ ] -1 (please include reasoning) > > --- > > - Ben > > [1*]: https://www.apache.org/foundation/voting.html > > - > 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: improving incremental builds
Is what you want different from what mvn -amd moduleA does? So your idea is to find the list of changed modules and then build that list with -amd? thanks david jencks On Aug 25, 2012, at 1:32 PM, Mark Struberg wrote: > Hi folks! > > After a short discussion with Kristian, I've created a small app with 2 > modules which shows a few problems with mavens incremental build logic. > And since incremental builds do not work well, people use > > $> mvn _clean_ install > all the time. > > We could speed up the development effort heavily if we make > $> mvn install > (without an upfront clean) more reliable. > > > The sample [1] consists of moduleA and moduleB with BeanA and BeanB > respectively. > BeanB has a private BeanA field and moduleB has a dependency on moduleA. > > If I change BeanA and just invoke mvn install then only moduleA gets rebuilt. > We currently do not rebuild moduleB, but we should do to create a reliable > output. > > In fact, the incremental build within a single module already works to some > degrees, but we must detect a change in dependencies and trigger a full > rebuild on all depending modules. This could be done by storing the md5 of > all dependency artifacts and compare them on the next build. If the md5 of a > dependency did change, then we need to build the module full cycle. > Other ideas are welcome. Slaps as well if I forgot some obvious stuff and all > works well already. > > > LieGrue, > strub > > > - > 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: Git as the canonical SCM
On Sep 5, 2012, at 10:08 PM, Kristian Rosenvold wrote: > 2012/9/5 Romain Manni-Bucau : >> Last note: i think the plugin you speak about (create a kind of virtual >> project) will be a nightmare. Scm are nice but can be broken and when you >> dont have a 1:1 with remote repo it is even harder > > I would really like some elaboration on this, since I'm not sure I > understand what > you're trying to say. I work with the maven codebase > all the time and I generally find working with layered components that are > from different release modules to be a little painful although > manageable. Most of this pain does > /not/ stem from the fact that they are in different version control systems > or different checkouts from the version control system (which they are). I think from my experience that your proposed plugin is sort of essential for working with maven code. I usually give up quickly because I can't find all the dependencies that some plugin I want to improve uses in a finite amount of time. However, I wonder how useful it will be on projects with more separation between interface and implementation, as in some osgi projects. If you have a module AIntf with interfaces and then the implementations in AImpl and project B uses AIntf how do you know to check out AImpl? (or the several AImpls). I'd love to see this work > > I like to think there are a few main use cases for checking out code: > A) I want to fix a single problem/issue and when I'm done with that > I'm going to submit a patch and get on with my life. > B) I'm hooked. I fix things in a limited subset of the code base all > the time. So I need to keep it recent, fresh and patched. > C) I'm all over the place. I do global updates to dependencies and > reformat code like there's no tomorrow. > > I think these are the three models we need to support well. I think > especially A is important, since it's the > gateway to entry ;) I like this division. And BTW as a very occasional maven patcher and git user elsewhere I think git would be an improvement over svn. thanks! david jencks > > Kristian > > - > 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: the simplest possible maven plugin, sort of
Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: > > Interesting… I wonder how I've managed to do CXF releases for all these > years then. :-) > > Seriously, for CXF <=2.5.x, I use Maven 2.2.1 and it "just works". Parts of > the build certainly do use the plugins that are built as part of the reactor. > > That said, we use "install" as the default target and not test or anything. > I'm fairly certain it wouldn't work if we didn't use install as the target, > but I'm not sure if that would work with 3.x either. > > The "clean" target doesn't work if the plugin is part of the reactor and not > in .m2/repository. I'll give you that. > > Dan > > > > > On Sep 10, 2012, at 2:59 PM, Anders Hammar wrote: > >> I'm fairly sure this didn't work in Maven 2.x. It was one of the >> unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround >> would be to use an older released version of the plugin. Don't think >> running a build twice is/was a workable workaround as I can't see how >> that would work in a release process. >> >> /Anders >> >> On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier wrote: >>> On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies >>> wrote: >>> >>>> On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp wrote: >>>>> >>>>> On Sep 10, 2012, at 11:14 AM, Benson Margulies >>>> wrote: >>>>> >>>>>> In Maven 2.x, the following was true; the reactor could not apply a >>>>>> plugin it had just built. So, if a particular problem required a >>>>>> plugin (e.g., for generating code), the plugin has to be an >>>>>> independent project that is built in advance. Is this still true in >>>>>> 3.x? >>>>> >>>>> I don't think this is/was true. CXF has always used it's own codegen >>>> plugins within its reactor build, even with Maven 2.x. >>>> >>>> Dan, I'll try it again, but I could have sworn that this only works by >>>> running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. >>>> >>> >>> >>> I'm almost sure I had the same experience like Benson. >>> It doesn't work in one step because maven reads all projects in the >>> reactor, then tries to resolve the plugin where you are using it and cannot >>> because it was built. >>> >>> Arnaud >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > -- > Daniel Kulp > dk...@apache.org - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > > - > 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: RFP: Version Range Policy
Can you explain how you think osgi semantic versioning can reasonably be applied to non-osgi-bundles? It typically takes a project a year or two to figure out what semantic versioning means when converting a project to osgi, I think you would find that trying to apply semantic versioning to non-osgi projects will mean that every update is a major version change. It would be nice if all projects converted to osgi and used semantic versioning correctly, but I don't think that is going to happen any time soon and I don't think the majority of maven projects will be osgi any time soon. thanks david jencks On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin wrote: >*Maven Developers* > >1) This is a formal request to resolve long standing version range >policy problem in maven, >expressed for example in the following ticket: >http://jira.codehaus.org/browse/MNG-3092 > >THE PROBLEM: LACK OF VERSION RANGE POLICY. > >2) I there are no better ideas, I suggest Maven to adopt OSGI >Semantic Version Guidelines. >https://github.com/barchart/barchart-version-tester/wiki/Version-Policy > >3) I have working prototype based on maven 3.0.4 with back port of >aether 0.9.0.M2 >specifically applied to karaf use case, which could be generalized. >https://github.com/barchart/barchart-maven-karaf-plugin > >4) there is an Aries version check plugin, that shows generic java >binary compatibility checks >which should be part of the new maven semantic version contract. >https://github.com/apache/aries/tree/trunk/versioning > >Thank you, > >Andrei > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFP: Version Range Policy
so you are basically saying all packages are exported. I think you will find that few meaningful code changes will result in a non-major-version change whether or not the intended api changes. Have you tried this out with some real non-osgi projects to see what versions you'd come up with and whether they correspond in any way with what the project developers think the versions are? thanks david jencks On Apr 10, 2013, at 3:23 PM, Andrei Pozolotin wrote: > I am more optimistic then you. here is the idea > https://github.com/barchart/barchart-version-tester/wiki/Maven-OSGI > > Original Message > Subject: Re: RFP: Version Range Policy > From: David Jencks > To: Maven Developers List > Date: Wed 10 Apr 2013 12:44:19 PM CDT >> Can you explain how you think osgi semantic versioning can reasonably be >> applied to non-osgi-bundles? It typically takes a project a year or two to >> figure out what semantic versioning means when converting a project to osgi, >> I think you would find that trying to apply semantic versioning to non-osgi >> projects will mean that every update is a major version change. >> >> It would be nice if all projects converted to osgi and used semantic >> versioning correctly, but I don't think that is going to happen any time >> soon and I don't think the majority of maven projects will be osgi any time >> soon. >> >> thanks >> david jencks >> On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin >> wrote: >> >>> *Maven Developers* >>> >>> 1) This is a formal request to resolve long standing version range >>> policy problem in maven, >>> expressed for example in the following ticket: >>> http://jira.codehaus.org/browse/MNG-3092 >>> >>> THE PROBLEM: LACK OF VERSION RANGE POLICY. >>> >>> 2) I there are no better ideas, I suggest Maven to adopt OSGI >>> Semantic Version Guidelines. >>> https://github.com/barchart/barchart-version-tester/wiki/Version-Policy >>> >>> 3) I have working prototype based on maven 3.0.4 with back port of >>> aether 0.9.0.M2 >>> specifically applied to karaf use case, which could be generalized. >>> https://github.com/barchart/barchart-maven-karaf-plugin >>> >>> 4) there is an Aries version check plugin, that shows generic java >>> binary compatibility checks >>> which should be part of the new maven semantic version contract. >>> https://github.com/apache/aries/tree/trunk/versioning >>> >>> Thank you, >>> >>> Andrei >>> >> >> - >> 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
Legal files and maven automation
www.apache.org/licenses/LICENSE-2.0.txt) - Maven Wagon API org.apache.maven.wagon:wagon-provider-api:jar: 1.0-alpha-6 License: The Apache Software License, Version 2.0 (http:// www.apache.org/licenses/LICENSE-2.0.txt) From: 'Codehaus' (http://codehaus.org) - Plugin Support (http://mojo.codehaus.org/plugin-support) org.codehaus.mojo:plugin-support:jar:1.0-alpha-1 From: 'Codehaus' (http://www.codehaus.org/) - Default Plexus Container org.codehaus.plexus:plexus-container- default:jar:1.0-alpha-9 - Plexus Common Utilities org.codehaus.plexus:plexus-utils:jar:1.2 From: 'The Apache Software Foundation' (http://jakarta.apache.org) - Commons JEXL (http://jakarta.apache.org/commons/jexl/) commons- jexl:commons-jexl:jar:1.1 License: The Apache Software License, Version 2.0 (/LICENSE.txt) - Lang (http://jakarta.apache.org/commons/lang/) commons- lang:commons-lang:jar:2.3 License: The Apache Software License, Version 2.0 (/LICENSE.txt) - Logging (http://jakarta.apache.org/commons/logging/) commons- logging:commons-logging:jar:1.0.4 License: The Apache Software License, Version 2.0 (/LICENSE.txt) From: 'The Codehaus' (http://codehaus.org/) - classworlds (http://classworlds.codehaus.org/) classworlds:classworlds:jar:1.1-alpha-2 -- As with any resource bundle for the m-r-r-p, you can supply missing information such as organization and license in a src/main/remote- resources/supplemental-models.xml file. -- Note on javaee5 artifacts: Some javaee5 artifacts such as wars and ears when built by maven usually physically include all or some of the dependencies of the maven project. While it might be nice to have the m-r-r-p roll up the LICENSE and NOTICE files from the contents and come up with something, that is out of scope of this proposal. I expect anyone building such an assembly will examine the contents and construct by hand suitable files to append to the standard LICENSE and NOTICE files. ------ Objections? Comments? many thanks david jencks
Re: Legal files and maven automation
On Mar 10, 2008, at 12:43 PM, Henri Yandell wrote: On Mon, Mar 10, 2008 at 11:44 AM, David Jencks <[EMAIL PROTECTED]> wrote: Here's what it does: By default, the LICENSE file is the standard apache license. The NOTICE file is generated from a velocity template; here's an example of the output (between - lines which are not included) -- Geronimo :: Directory Plugin Copyright 2003-2008 Apache Software Foundation This product includes software developed at Apache Software Foundation (http://www.apache.org/). -- In the 99% of the time when this is the correct LICENSE and NOTICE, that's all you do. In the remaining 1% of the time where additional information is needed appended to these standard files, you put the additions in src/main/appended-resources/LICENSE and src/main/appended-resources/NOTICE In the remaining 0.1% of the time where the standard files are not correct you can arrange by other means to insert custom LICENSE and NOTICE files. Looks good to me. Two thoughts: 1) How is the end-year of the copyright done? AIUI, that should be the year of last edit and not the year in which it is built. So if I build something that hasn't been touched in a year, it should still have last year's year on it. I think it is the current year. I could argue that this is only relevant for releases, at which time the version in the pom has changed, and the pom is included in the artifacts, therefore something has changed, but that argument is a bit weak. Personally I think having a copyright date range from project inception to now is better than having definitely out-of-date NOTICE files included in most or all artifacts, which is positively assured if this process is done by hand. Is this a blocker? 2) Add a macro language for the license/notice so it can pull things in from the transitives when added in. It should also fail when it can't find said license information. At least for the LICENSE part as that applies to all licenses etc. I'm not sure we have NOTICEs in the Maven repository. I thought the whole point of the discussion up to now on what goes in LICENSE and NOTICE files is that they definitely apply to ONLY what is actually IN the artifact and not any of its dependencies or what might be required to actually use the artifact in any meaningful way. Given that I said that rolling up LICENSE and NOTICE files for artifacts that assemble and contain other artifacts such as wars and ears is out of scope for this proposal, I'm very confused about what you might be suggesting. Could you please clarify how this macro language would apply to this proposal? I'd really prefer to discuss the actual possibility of using exactly what I am proposing in this thread on legal-discuss and discuss possible enhancements and improvements elsewhere. There is a gigantic tendency on legal discuss to have infinitely long discussions with no conclusion, but I would like to know if there are actual problems with using this actual resource bundle right now in projects I would like to release this week. Could we restrict all discussion of possible future enhancements to the maven-dev list? many thanks david jencks Hen - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See <http://www.apache.org/licenses/> for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Legal files and maven automation
On Mar 10, 2008, at 2:55 PM, Erik Abele wrote: On 10.03.2008, at 20:10, Shane Isbell wrote: ... -- Geronimo :: Directory Plugin Copyright 2003-2008 Apache Software Foundation This product includes software developed at Apache Software Foundation (http://www.apache.org/). -- It's always "The Apache Software Foundation". So -- Geronimo :: Directory Plugin Copyright 2003-2008 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). -- (2 "the"s inserted) would be correct? Is this error a blocker or can it be fixed in the next release of the resource bundle? ... From: 'Apache Software Foundation' (http://www.apache.org/) Same here. The stuff in the DEPENDENCIES file is derived from other released poms generally not under the control of the current project release. You are welcome to beat the other PMCs with a variety of large blunt objects, but I think trying to second guess them in this informational report is not practical. thanks david jencks ... From: 'The Apache Software Foundation' (http://jakarta.apache.org) And here it's fine :-) Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Legal files and maven automation
I fixed the typo (missing "The" in "The Apache Software Foundation") in the actual artifacts voted on for geronimo release. The project name is the responsibility of the project using the legal-bundle. Its been 72 hours... IIUC there are no objections in principle to this scheme of generating the LICENSE and NOTICE files so I'll go ahead and propose that maven adopt this as the standard recommended maven-remote- resources-plugin bundle for apache projects. thanks david jencks On Mar 11, 2008, at 6:27 AM, sebb wrote: On 10/03/2008, Erik Abele <[EMAIL PROTECTED]> wrote: On 10.03.2008, at 23:46, David Jencks wrote: ... -- Geronimo :: Directory Plugin Copyright 2003-2008 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). -- (2 "the"s inserted) would be correct? Yep, looks good - though as Sebastian already pointed out it probably should also say "Apache Geronimo"... Here's an example from HTTP: https://svn.apache.org/repos/asf/httpd/ httpd/trunk/NOTICE Is this error a blocker or can it be fixed in the next release of the resource bundle? Not a blocker IMHO. I'd say it is a blocker: AIUI, this is a new plugin, so the release is not being made to fix an existing bug. If the plugin is released as is, then all the projects that use it are going to have incorrect text in the NOTICE file. How are they going to deal with that if/when the next release vote is called? I could be wrong, but it seems to me that it should not be difficult to fix these issues. It will obviously be a bit more work for the plugin maintainer now, but will save potentially quite a lot of work later. ... From: 'Apache Software Foundation' (http://www.apache.org/) Same here. The stuff in the DEPENDENCIES file is derived from other released poms generally not under the control of the current project release. You are welcome to beat the other PMCs with a variety of large blunt objects, but I think trying to second guess them in this informational report is not practical. Hehe, sure :-) Cheers, Erik - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See <http://www.apache.org/licenses/> for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See <http://www.apache.org/licenses/> for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Generated NOTICE files.... a solution
As I noted in a previous thread the current NOTICE files generated by the apache-jar-resource-bundle 1.3 are not consistent with apache policy. After some discussion on legal-discuss I've come up with a bundle that no one seems to be able to find anything seriously wrong with: we're starting to use it in geronimo. Aside from possible use by other projects I'd like to use this in an upcoming ApacheDS release, so getting it quickly into a more neutral location would be desirable. I've opened http://jira.codehaus.org/ browse/MRRESOURCES-32 and attached a patch. The basic idea is that the NOTICE file contains only the required apache notice, with no extra text, explanation, horizontal rules, or anything else. Additional required notices can be put in a NOTICE file in appended-resources and automatically appended. Dependencies are listed in an additional generated DEPENDENCIES file, by organization, and listing the license. Note that NOTICE files apply only to the exact contents of the jar in question, not to any dependencies that might be necessary to actually use the jar. For work at apache the normal situation is that the minimal NOTICE is all that is required, and if more is needed its going to be because of some special historical circumstances that can't plausibly be tracked by maven, so explicitly recording this information in a human-written additional NOTICE file is quite appropriate. There is certainly scope for some kind of aggregating bundle for assemblies that do actually contain stuff from other artifacts, such as wars, ears, tar.gzs, etc, but these are pretty clearly an entirely separate use case and likely to require considerably more work to get right. I think starting work on a separate bundle for these might be appropriate. I know of two problems in the patch, both in NOTICE.vm, and I haven't been able to figure out solutions to either: - I can't get a blank line in between the project name and the notice - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. Despite these problems I think this proposal is clearly more in line with apache policy and hope it can be accepted and released quickly. Many thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generated NOTICE files.... a solution
On Mar 13, 2008, at 6:51 PM, Daniel Kulp wrote: David, I deployed a new snapshot, can you give that a try and make sure it's all OK? Looks great to me! - I can't get a blank line in between the project name and the notice Fixed I'm sure I tried that and it didn't work when I did it :-) - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. In the configuration for the remote-resources plugin, add something like: Apache CXF Aha! that works too many thanks david jencks Dan On Thursday 13 March 2008, David Jencks wrote: As I noted in a previous thread the current NOTICE files generated by the apache-jar-resource-bundle 1.3 are not consistent with apache policy. After some discussion on legal-discuss I've come up with a bundle that no one seems to be able to find anything seriously wrong with: we're starting to use it in geronimo. Aside from possible use by other projects I'd like to use this in an upcoming ApacheDS release, so getting it quickly into a more neutral location would be desirable. I've opened http://jira.codehaus.org/ browse/MRRESOURCES-32 and attached a patch. The basic idea is that the NOTICE file contains only the required apache notice, with no extra text, explanation, horizontal rules, or anything else. Additional required notices can be put in a NOTICE file in appended-resources and automatically appended. Dependencies are listed in an additional generated DEPENDENCIES file, by organization, and listing the license. Note that NOTICE files apply only to the exact contents of the jar in question, not to any dependencies that might be necessary to actually use the jar. For work at apache the normal situation is that the minimal NOTICE is all that is required, and if more is needed its going to be because of some special historical circumstances that can't plausibly be tracked by maven, so explicitly recording this information in a human-written additional NOTICE file is quite appropriate. There is certainly scope for some kind of aggregating bundle for assemblies that do actually contain stuff from other artifacts, such as wars, ears, tar.gzs, etc, but these are pretty clearly an entirely separate use case and likely to require considerably more work to get right. I think starting work on a separate bundle for these might be appropriate. I know of two problems in the patch, both in NOTICE.vm, and I haven't been able to figure out solutions to either: - I can't get a blank line in between the project name and the notice - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. Despite these problems I think this proposal is clearly more in line with apache policy and hope it can be accepted and released quickly. Many thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency policies
maybe you could enhance that rule to do regexp matching on each maven coordinate component and implement your category concept using a naming convention? david jencks On Oct 1, 2010, at 10:51 AM, Alan D. Cabrera wrote: > It's close but not exactly what I need. I don't want to maintain rules on > artifacts. I want to maintain restrictions between categories of artifacts. > > > Regards, > Alan > > On Oct 1, 2010, at 10:22 AM, Rex Hoffman wrote: > >> I haven't used it: but this, and profiles, should do the trick. >> http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html >> >> I'm just trying to get some contributions in to maven (other enforcer >> rules) but still feel the need to say you probably should have asked >> this on the user mailing list. >> >> Rex >> >> On Fri, Oct 1, 2010 at 9:56 AM, Alan D. Cabrera wrote: >>> Is there some way to categorize jars and restrict the dependencies between >>> categories of those jars? At least maybe reports dependency violations? >>> >>> For example let's say I have two categories, api and impl. Impl can depend >>> on Api but not others' impl. Api can rely on Api. When I perform a build >>> it would be nice if the build failed or at least an warning is reported. >>> >>> >>> Regards, >>> Alan >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> >> >> -- >> Rex Hoffman >> >> (415) 273-9438 >> 415-2REXGET >> http://www.e-hoffman.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: Auto apache version standard as an enforcer rule?
The BND tool used in the (misnamed) felix maven-bundle-plugin has, in recent versions not yet used in the maven-bundle plugin, some logic to determine whether an Import-Package constraint is "uses" or "implements" and decides which segment of the version number to increment based on that. might be useful... david jencks On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote: > On 11/08/2010 02:21 AM, Rex Hoffman wrote: >> project: java-version-delta > > By the way, you should look at https://sigtest.dev.java.net/ if you have not > done so already. I'm not sure if the license & feature set suits your needs > but it would make a potentially useful alternate impl. This is the tool used > by some of Oracle's teams to check (primarily binary) compatibility of Java > APIs. > > My background: for netbeans.org API modules we run this tool to check for > compatible & incompatible changes among packages marked public. Currently we > have an idiosyncratic Ant build (is there any other kind?) so comparisons are > done against the modules as they existed in the last product release, but of > course in a Maven setup we would use the policy you are proposing: x.y -> > x.(y+1) may have compatible but not incompatible changes, etc. > >> The apache portable runtime version standard does want the name of a library >> to include it's major version number, so for ubuntu/debian xerces look like: >> libxerces2-java_2.9.0-1_all.deb > > Not sure this is applicable to most Java development. If you are using a > container (such as OSGi) which supports class loader isolation, *and* this > container permits multiple components with the same ID (but possibly > different versions) to be loaded in parallel, then it is unnecessary. > Containers with isolation but which enforce uniqueness on loaded IDs might > benefit, so long as it really makes sense to load two copies of the component > - true for plain old class libraries, not necessarily true for "active" > components which might register services of some sort. Apps not using a > container are unlikely to benefit since you could only use multiple versions > of a library in case the package hierarchy was also renamed. Anyway, I agree > that this is not likely something that an API compatibility plugin should > address (a separate enforcer rule would suffice). > >> the default would be to >> assume that a client of an artifact is not expected to implement [any >> interfaces] > > This seems like a poor default - directly contradicts the longstanding Java > compatibility policy. (*) If anything, I would place the burden on API > designers who publish interfaces (or abstract classes) they expect no one > else to implement, despite there being no such enforcement from the Java > language. (**) An annotation for this purpose makes some sense, but it would > have to be hosted in a very generic place quite unrelated to a Maven plugin. > In the short term, plugin configuration to exclude implements checking on > certain types or packages may be a better workaround. > > (*) For binary compatibility it is permitted to add an interface method > without breaking existing implementers, so long as this method is never > called - but that condition is unlikely, since why would there be a method no > one is calling? You cannot even check whether a given object implements a new > method or not without using reflection. Better to just introduce a new > interface (possibly extending the old one) when you want to change signatures. > > (**) If the API designer wants, it is possible to expose an abstract class > which can be implemented only within the same component. JSR 294 would be > very helpful here, but it is possible today so long as all the > implementations are in the same package, *or* the component uses a format > (such as OSGi bundle) which permits restrictions on the exported types or > packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing > with a more fine-grained system but for now it requires javac from JDK 7. > > > - > 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: Cleanup to SNAPSHOT version handling
I think I've seen some projects, although I don't recall where, that use .SNAPSHOT because then you get legal osgi bundle versions in require-bundle instructions in the maven-bundle-plugin. Presumably this could be fixed in the maven-bundle-plugin since it already converts -SNAPSHOT to .SNAPSHOT when generating the bundle's own osgi version. david jencks On Dec 10, 2010, at 9:18 AM, Benjamin Bentmann wrote: > Hi, > > as part of MNG-4893 [0] an inconsistency in the way a version string is > treated as a snapshot or release was detected. In short, the issue is about > what suffix exactly marks a snapshot version. > > The current intention is to revise the logic such that the suffix "-SNAPSHOT" > (note the leading hyphen) and not just "SNAPSHOT" is required to denote a > snapshot. > > This mail is meant as a heads up for users that unintentionally use irregular > SNAPSHOT versioning and allow them to adjust their builds. If changing the > builds to use "-SNAPSHOT" isn't possible, we would like to hear the technical > reasons for this. > > Thanks > > > Benjamin > > > [0] http://jira.codehaus.org/browse/MNG-4893 > > - > 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
How do you get aether to traverse the entire dependency tree?
One of the nice side effects of moving the maven resolution code away from
apache is that people who work for companies with IP policies need additional
approval to look at the source to find out how it works. Since I don't have
such approval I'm really hoping for some advice.
I've been following the sample code at
http://aether.sonatype.org/using-aether-in-maven-plugins.html
http://www.sonatype.com/people/2011/01/how-to-use-aether-in-maven-plugins/#more-6838
I am working on a maven plugin that needs to traverse the entire dependency
tree starting from a project artifact. Aether is not finding the whole tree.
Why not? How do I make it?
To be more specific, aether is finding no children for an artifact that...
-- is only present in my local repo
-- is a custom packaging
-- the artifact for this custom packaging has a classifier
-- the type is not the same as the packaging name
I'll call this artifact A below.
i've made some spot checks for jars that are deployed to apache snapshot repo
or central and aether seems to be finding the children for these.
I think the relevant code is:
/**
* The entry point to Aether, i.e. the component doing all the work.
*
* @component
*/
private RepositorySystem repoSystem;
/**
* The current repository/network configuration of Maven.
*
* @parameter default-value="${repositorySystemSession}"
* @readonly
*/
private RepositorySystemSession repoSession;
/**
* The project's remote repositories to use for the resolution of project
dependencies.
*
* @parameter default-value="${project.remoteProjectRepositories}"
* @readonly
*/
private List projectRepos;
private DependencyNode getDependencyTree(Artifact artifact) throws
MojoExecutionException {
try {
List managedArtifacts = new
ArrayList();
CollectRequest collectRequest = new CollectRequest(new
org.sonatype.aether.graph.Dependency(artifact, "compile"), managedArtifacts,
projectRepos);
CollectResult result = repoSystem.collectDependencies(repoSession,
collectRequest);
return result.getRoot();
} catch (DependencyCollectionException e) {
throw new MojoExecutionException("Cannot build project dependency
tree", e);
}
}
getDependencyTree when called on my project artifact returns a tree where the
node for A has no children. Furthermore calling getDependencyTree on A
directly also finds no children. On the other hand running this plugin on the
project for A does find the children of A (the dependencies listed in the pom
for A).
changing the dependency on A from
org.apache.geronimo.features
org.apache.geronimo.jaxb-support
xml
features
3.99.99-SNAPSHOT
(xml is the primary artifact file extension)
to
org.apache.geronimo.features
org.apache.geronimo.jaxb-support
feature
features
3.99.99-SNAPSHOT
(feature is the packaging type)
causes a resolution error:
[ERROR] Failed to execute goal on project org.apache.geronimo.transaction.kar:
Could not resolve dependencies for project
org.apache.geronimo.features:org.apache.geronimo.transaction.kar:kar:3.99.99-SNAPSHOT:
Could not find artifact
org.apache.geronimo.features:org.apache.geronimo.jaxb-support:feature:features:3.99.99-SNAPSHOT
in nexus (http://localhost:8081/nexus/content/groups/public) -> [Help 1]
Any advice?
thanks
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: How do you get aether to traverse the entire dependency tree?
This ended up being good advice. The problem was an antique maven-install-plugin specified in a parent pom. Is there some way to require minimum plugin versions in a custom packaging or its LifecycleMapping? thanks david jencks On Mar 21, 2011, at 3:06 AM, Benjamin Bentmann wrote: > David Jencks wrote: > >> Any advice? > > Provide a standalone example project that allows others to reproduce/analyze > the problem. > > > 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
really threadsafe?
I've been trying out the parallel stuff in maven 3.0.3 and when it works it's great.However I'm wondering what's going on here with this intermittent error. I've never gotten this error bulding single threaded. https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html says the maven-remote-resources-plugin 1.2 is threadsafe. However... [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering velocity resource. at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.lang.NullPointerException at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) ... 16 more I ran with -T 4. It looks like there were 3 failures with this same stack trace all in pom projects that aggregate subprojects. I don't have a lot of time to track down whats going on but might be able to spend a little time given enough advice. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: really threadsafe?
http://jira.codehaus.org/browse/MRRESOURCES-54 thank you so much for looking into this the parallel build is great! thanks david jencks On Mar 27, 2011, at 11:17 PM, Kristian Rosenvold wrote: > I was sent the url to the old velocity stuff and I see several thread safety > issues in the (*really* old) version being used by m-r-r-p. > > I checked out the latest version of velocity and all the problems I found > were fixed there, so I think we'll just give it a shot. > > Just make an issue under http://jira.codehaus.org/browse/MRRESOURCES and I'll > push it through. > > > Kristian > > > Den 23.03.2011 23:29, skrev David Jencks: >> I've been trying out the parallel stuff in maven 3.0.3 and when it works >> it's great.However I'm wondering what's going on here with this >> intermittent error. I've never gotten this error bulding single threaded. >> >> https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html says the >> maven-remote-resources-plugin 1.2 is threadsafe. However... >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) >> on project assemblies: Error rendering velocity resource. >> NullPointerException -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute >> goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process >> (default) on project assemblies: Error rendering velocity resource. >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) >> at >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) >> at >> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) >> at >> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >> at java.lang.Thread.run(Thread.java:680) >> Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering >> velocity resource. >> at >> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) >> at >> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) >> at >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) >> ... 13 more >> Caused by: java.lang.NullPointerException >> at >> org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) >> at >> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) >> at >> org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) >> at >> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) >> ... 16 more >> >> I ran with -T 4. It looks like there were 3 failures with this same stack >> trace all in pom projects that aggregate subprojects. >> >> I don't have a lot of time to track down whats going on but might be able to >> spend a little time given enough advice. >> >> thanks >> david jencks >> >> >> - >> 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: Article proposed for Maven Article Page
I think what Jochen is trying to convey is that you are leaving it entirely up to the developers to assure that the api/client jar can be used without the contents of the impl jar. There is nothing in the build system stopping developers from putting a subclass of an implementation class in the api jar, thus making the api jar completely useless as a guide to an "api". If you make separate projects for the api and implementation, the build system will prevent you from doing this. It is definitely less convenient for developers to have to deal with 2 projects, but you get enforcement of the principle that the api is usable without implementation classes from the build system, not from developers possibly remembering to think. In extreme cases where the build system doesn't enforce any separation rules you get projects like tomcat which build all their classes together and then partition them into jars that have circular uses relationships so that it is impossible to build them individually in any order. My experience is that if you rely on developers you can set something up that initially works but good intentions quickly give way to expedience and very quickly your intended separation has disappeared. I'm now willing to put up with a really lot of build system annoyance to get it to enforce this kind of separation. hope I haven't made this thread too long... thanks david jencks On Apr 20, 2011, at 2:45 AM, xanadu72 wrote: > Jochen, > I agree with you. The isolation is achieved for "external" usage but not > between the api and the implementation. It is not the recommended way to > distribute framework libraries but i find it more suitable for multi tier > application to reduce the configuration management work load. In this > context the API is not intended to provided a way to implement multiple > implementations. The term api can be replaced with client. > > On Wed, Apr 20, 2011 at 11:34 AM, jochen-2 [via Maven] < > ml-node+4315334-12416097-197...@n5.nabble.com> wrote: > >> On Wed, Apr 20, 2011 at 11:28 AM, xanadu72 <[hidden >> email]<http://user/SendEmail.jtp?type=node&node=4315334&i=0&by-user=t>> >> wrote: >> >>> The client api is a separate artifact. You can reuse it as you want. In >> your >>> repository you will get in the same release folder two artifacts : >> >> That's completely understood. But as a separate jar file, you should >> ensure that it is compilable without any of the other classes. For >> example, it might accidentally import something from the rest of the >> packages. You don't get that safety by just repackaging a bunch of >> class files in another jar file. >> >> >> -- >> I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-assembly-plugin] smart(er) dependency merge
I think the shade plugin does something like this. david jencks On Jun 30, 2011, at 12:45 AM, Robert Burrell Donkin wrote: > (If support for this use case already exists then apologies in advance > but I suspect it's not supported and that I'll need to hack some extra > code...) > > specific use case: > assemble a jar containing all dependencies without losing legal meta-data > > example: > LICENSE and NOTICE in META-INF must be preserved when including an > Apache License, Version 2 dependency > > workaround: > manually maintaining specific LICENSE and NOTICE for the assembly and > updating any time any dependency changes upstream > > > Perhaps add this would be a little too specific for a general plugin. > So, one way to satisfy this case is by adding a solution to > > more general use case: > extensible support for smart dependency mergers with collision > detection and resolution > > > Opinions? > > Robert > > - > 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
Possible feature request about scary warnings
I often see lots of stuff like this in my m3 builds: [WARNING] Invalid POM for org.apache.openejb:openejb-core:jar:4.0.0-SNAPSHOT, transitive dependencies (if any) will not be available, enable debug logging for more details but the build appears to work fine and I sure can't see for myself what the problem might be. If I turn on debug logging then I get a multimegabyte text file that it's very hard to find the relevant info in. Would it make sense to have something like a build option that would fail the build for invalid poms and print the relevant info? Or maybe this is already possible but there's no way to find out about it? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: > The board made it pretty clear that option b is also highly discouraged so I > wouldn't list that as an option. The only viable path I see will be to > ultimately include the EPL version of Aether and then replace it with our own > code when someone decides there is something they want to do that requires > it. A dual licensed version of Aether would probably insure a complete > replacement is never necessary. > > Ralph > > On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: > >> I'd like to to try to put a little oxygen into this thread now, given >> the rather clear results of the vote thread. >> >> Ralph posed the following question on Legal Discuss: 'Can the Maven >> PMC pull a dual-licensed version of AEther back into Apache without a >> grant from Sonatype?' >> >> The answer was, "legally yes, but it is counter to long-established >> policy, and strongly discouraged by a number of senior ASF people >> (including a board member or two)". >> >> So, the community has some choices. It seems to me that the viability >> of these different choices depends on the viability of walking away >> from AEther. In practical terms, the choices are: >> >> a) Use versions of AEther controlled by 'someone else'. >> b) Create our own 'someone else' at apache-extras or elsewhere. >> c) Go down the path of becoming an exception to the policy and take on >> reworking AEther from the last dual-licensed version. >> d) Start All Over Again from Maven 2.2. >> >> From the vote comments, it seemed to me that a plurality of people >> felt that EPL at Eclipse was tolerable. So that argues for sitting >> still for now. I offer only the observation that forking into >> apache-extras 'works' the same way today, or after the code appears in >> Eclipse. In other words, adopting what's out there today only makes >> choice (c) harder, it doesn't have any impact that I see on a, b, or >> d. However, a 'no' vote is a 'no' vote, so this is all just food for >> thought. >> >> - >> 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
are multi-threaded builds still working reliably?
I tried out the multi-threaded builds again recently (https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html) (maven 3.0.3) and got some really strange results several minutes into the build. - the compiler plugin seemed to get corrupted source files and reported lots of nonexistent syntax errors - transitive dependencies didn't work the same as with a normal build I don't really have time to investigate what's going on but wonder if anyone has a stable large-project multi-threaded build running on a recent macbook pro with snow leopard? OSX 10.6.8 java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: are multi-threaded builds still working reliably?
Maybe it would be a good idea to mention this on the siki page? Anyone know why? I thought maven used the eclipse compiler which is IIUC just java code so why would it behave differently on different os? thanks david jencks On Sep 24, 2011, at 12:11 AM, Olivier Lamy wrote: > On osx you must fork compiler. > > -- > Olivier > Le 24 sept. 2011 04:41, "David Jencks" a écrit : >> I tried out the multi-threaded builds again recently ( > https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html) (maven > 3.0.3) and got some really strange results several minutes into the build. >> >> - the compiler plugin seemed to get corrupted source files and reported > lots of nonexistent syntax errors >> - transitive dependencies didn't work the same as with a normal build >> >> I don't really have time to investigate what's going on but wonder if > anyone has a stable large-project multi-threaded build running on a recent > macbook pro with snow leopard? >> >> OSX 10.6.8 >> >> java version "1.6.0_26" >> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) >> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) >> >> thanks >> david jencks >> >> >> - >> 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 release plugin not honoring -Darguments
IIRC you have to include your forked maven arguments in the release plugin configuration under -DskipTests=true -DfailIfNoTests=false Perhaps someone else can say _why_ the m-r-p is set up so you can't set this on the command line? thanks david jencks On Sep 27, 2011, at 5:40 AM, David Blevins wrote: > Is it a known issue that the release plugin does not honor the -Darguments? > > Specifically, I'm attempting to: > > mvn release:prepare -DdryRun=true -Darguments="-DskipTests=true > -DfailIfNoTests=false" > > It takes 40 minutes to get through a dryRun with tests on. We still have > several kinks in the build to work out before the release plugin will work, > so obviously running with tests on every dryRun is just making a hard task > impossible. > > maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1 > > > -David > > > - > 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: [VOTE] Usage of Aether and Sisu as dependencies of maven core with EPL licenses - take 2
Another month went by any progress? david jencks On Sep 30, 2011, at 3:50 AM, Stephen Connolly wrote: > To clarify... I last checked yesterday, and the PMC in question is some > eclipse PMC but it is unclear to me, only having just got my eclipse account > set up, exactly which > > On 30 September 2011 11:48, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> When I last checked, the code import is still waiting for PMC approval... I >> suspect that until the code has been imported there cannot be a release ;-) >> >> >> On 30 September 2011 10:05, Mark Derricutt wrote: >> >>> Jason - is there any further news on the Aether/Sisu front? Really >>> starting >>> to get an itch for a 3.0.4 release - my manager this morning was having >>> strange resolution issues that I traced to same issues I've been seeing >>> with >>> the currently shipped aether. >>> >>> Would be good to get a 3.0.4 release out with some updated plugin versions >>> set as well ( the new wagon, archetype come to mind ). >>> >>> Mark >>> >>> >>> -- >>> "Great artists are extremely selfish and arrogant things" — Steven Wilson, >>> Porcupine Tree >>> >>> >>> On Wed, Sep 21, 2011 at 12:17 AM, Baptiste MATHUS wrote: >>> >>>> To be sure, are you talking about renaming Aether packages to something >>>> like >>>> org.eclipse.aether? >>>> >>> >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Meta information about dependencies in a pom?
I've run into this problem in 3 or 4 situations and the only practical solution is to individually list the dependencies with the extra info in the plugin configurations. I don't really understand the mindset that only the information needed for some bits of well-known maven can be associated with dependencies, and all other uses should just duplicate large swathes of maven configuration to be able to add a couple bits of info per dependency. My impression is that aether takes a more inclusive view of dependency properties. thanks david jencks On Nov 8, 2011, at 9:00 AM, Brett Porter wrote: > > On 08/11/2011, at 8:15 AM, Carsten Ziegeler wrote: > >> Yes, we were using that approach for years now and it turned out to be >> too error prone as you have to keep the plugin configuration and the >> dependency list in sync. It doesn't sound like a hard task first, but >> in our case it caused trouble many times. That's why we would like to >> have a single point of information. > > So, wildcards or excludes lists don't help with the sync task? There's no > convention that can be applied (e.g. all dependencies of a certain type, or > the same group ID as the project)? > > How would you handle transitive dependencies? > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > - > 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
Current status of moving apache projects to apache's nexus instance?
I'm trying to help the apache portals project set up some root poms. They are currently using the apache pom version 5 which IIUC deploys releases and snapshots to the apache nexus instance. I googled but couldn't find any instructions on how to proceed with this. I think it would be pretty handy if the maven site had a page linked from the front page with some up to date instructions. For instance IIUC when portals releases these poms (to nexus, right?) all the existing portals stuff also has to be moved by hand to nexus and all future portals releases have to go to nexus. Or did I make this up? Something else I'd find pretty helpful is info on what the recommended release profile for apache projects is and whether you even need one or if some default is adequate. In case anyone wants to review the portals poms to advise on whether they are likely to work... https://svn.apache.org/repos/asf/portals/portals-pom/trunk/pom.xml https://svn.apache.org/repos/asf/portals/applications/applications-pom/trunk/pom.xml thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Current status of moving apache projects to apache's nexus instance?
jdcasey helped a bit on IRC, thanks. I think the documentation on this is really unsatisfactory. At least I can't find anything by googling. John pointed be to the maven release instructions http://maven.apache.org/developers/release/releasing.html which might be OK for maven components but are a bit lacking as a guide to best practices for apache projects. I've opened a jira with a few suggestions for improvements to this page http://jira.codehaus.org/browse/MNG-4095 Having the apache nexus instance there is great but I'm afraid you'll get extremely bad press if the apache 5 pom is out there and there is no trivially accessible documentation about what the consequences are of using it. For instance portals recently decided having a root pom might be a good idea and naturally chose the most recent apache pom as the parent with no awareness of the consequences about where their deployments will end up and whether or not any other steps need to be taken for other portals project release destinations. thanks david jencks On Mar 17, 2009, at 3:48 PM, David Jencks wrote: I'm trying to help the apache portals project set up some root poms. They are currently using the apache pom version 5 which IIUC deploys releases and snapshots to the apache nexus instance. I googled but couldn't find any instructions on how to proceed with this. I think it would be pretty handy if the maven site had a page linked from the front page with some up to date instructions. For instance IIUC when portals releases these poms (to nexus, right?) all the existing portals stuff also has to be moved by hand to nexus and all future portals releases have to go to nexus. Or did I make this up? Something else I'd find pretty helpful is info on what the recommended release profile for apache projects is and whether you even need one or if some default is adequate. In case anyone wants to review the portals poms to advise on whether they are likely to work... https://svn.apache.org/repos/asf/portals/portals-pom/trunk/pom.xml https://svn.apache.org/repos/asf/portals/applications/applications-pom/trunk/pom.xml thanks david jencks - 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: Is it now possible to affect reactor build ordering without using a normal module dependency?
Why do you want to affect the reactor build ordering without using a dependency? The only use for something like this I have thought of so this might be a feature request is that I would like to be able to assure that a large project with deeply nested structure can be built in stages. For instance if I have a project like this: base -sub1 --p1 --p2 -sub2 --p3 --p4 where base, sub1 and sub2 are pom packaging and p1...p4 have the code in them, I would like to be able to assure that all of sub1 gets built before any of sub2 to assist in preventing any dependencies of p1 or p2 on p3 or p4. AFAICT the current behavior is that maven puts p1...p4 in a single bucket and tries to find a build order that satisfies the dependencies. thanks david jencks On Apr 3, 2009, at 9:11 AM, James Carpenter wrote: In the past plugins such as the dependency plugin didn't have a way to affect the reactor build order without having the user add a real dependency (say test scope) to the module using the plugin (or having the plugin programatically do the same) just to ensure proper build ordering. I assume this problem will eventually be solved in some manner (say a ghost dependency scope), but that it is likely a difficult one for some reason or other and therefore has not been solved long ago. If all the referenced artifacts are jars one can sometimes workaround the problem using plugin dependencies like I did when enhancing the exec:java plugin for non-java modules. http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-plugin-dependencies.html I am about to write a plugin which automatically downloads a few archives specified by GAVs, and I'm wondering if the situation has improved. If not I will simply use have to work around the issue. Can anyone provide some color the current status of this issue? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is it now possible to affect reactor build ordering without using a normal module dependency?
On Apr 3, 2009, at 10:14 AM, Brian E. Fox wrote: It's because a plugin may have a defacto dependency based on something in its configuration. Maven won't know about this so if that dep is in the same reactor, it may not be ordered correctly. The dependency:copy is an example of this. There should be a way for a plugin to participate in the reactor ordering for cases like this. There's a proposal but I can't find it at this time. Hmmm I guess when I read the dependency plugin docs and it said that it could download artifacts all by itself it didn't really register. I don't really understand any point of view other than these required artifacts are dependencies that happen to be declared only in the plugin configuration, not in the normal dependencies section of the pom. As such I'd expect that if you don't want to have to explicitly list them as dependencies then the plugin ought to get a chance to add dependencies during some kind of setup phase. I have a plugin for which this would be extremely handy. Is this what is planned for 3.0 or is there another point of view I have yet to comprehend? thanks david jencks -Original Message- From: David Jencks [mailto:david_jen...@yahoo.com] Sent: Friday, April 03, 2009 12:34 PM To: Maven Developers List Subject: Re: Is it now possible to affect reactor build ordering without using a normal module dependency? Why do you want to affect the reactor build ordering without using a dependency? The only use for something like this I have thought of so this might be a feature request is that I would like to be able to assure that a large project with deeply nested structure can be built in stages. For instance if I have a project like this: base -sub1 --p1 --p2 -sub2 --p3 --p4 where base, sub1 and sub2 are pom packaging and p1...p4 have the code in them, I would like to be able to assure that all of sub1 gets built before any of sub2 to assist in preventing any dependencies of p1 or p2 on p3 or p4. AFAICT the current behavior is that maven puts p1...p4 in a single bucket and tries to find a build order that satisfies the dependencies. thanks david jencks On Apr 3, 2009, at 9:11 AM, James Carpenter wrote: In the past plugins such as the dependency plugin didn't have a way to affect the reactor build order without having the user add a real dependency (say test scope) to the module using the plugin (or having the plugin programatically do the same) just to ensure proper build ordering. I assume this problem will eventually be solved in some manner (say a ghost dependency scope), but that it is likely a difficult one for some reason or other and therefore has not been solved long ago. If all the referenced artifacts are jars one can sometimes workaround the problem using plugin dependencies like I did when enhancing the exec:java plugin for non-java modules. http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-p lugin-dependencies.html I am about to write a plugin which automatically downloads a few archives specified by GAVs, and I'm wondering if the situation has improved. If not I will simply use have to work around the issue. Can anyone provide some color the current status of this issue? - 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
Archetype capabilities/limitations?
I'd like to write something I'll call it an archetype for now that generates a maven project but needs to run a _lot_ of java code in order to figure out what to put in the new pom.xml. What's my best strategy here? From a quick glance at the archetype plugin stuff it looks like this is not currently supported but that it might be possible to add a third kind of archetype, something like "code-based" along with file-set and old. Is this interesting to anyone else? Is it likely to be simpler to just start over and ignore the archetype plugin stuff? I'd also like it push dependencyManagement stuff and possibly some properties into parent poms and check that it's not duplicating stuff. Is there already code in the archetype plugin stuff that does this or would I be adding a new capability? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Archetype capabilities/limitations?
On Apr 4, 2009, at 11:15 AM, Jason van Zyl wrote: On 4-Apr-09, at 10:13 AM, David Jencks wrote: I'd like to write something I'll call it an archetype for now that generates a maven project but needs to run a _lot_ of java code in order to figure out what to put in the new pom.xml. The basis of it is there given we have velocity templates in there. I think what you want is to be able to deploy a class along with the archetype that would execute and manipulate the velocity context before rendering the files of the archetype. Something like a delegate for each template that's rendered? For this template do some mumbo jumbo and set object and flags in the Velocity context. For sophisticated POM manipulation we can just put a tool in the velocity context or provide a hook to write out your own POM completely. 95% of what you need is there already. You definitely don't need to start over. Thinking about this a bit more I'm even more confused about how to proceed. In my case the "lot of java code" is about half of geronimo. So, I need the archetype to have the same classloader setup/ classloading capabilities as a plugin. So it seems like one choice would be to simply write a plugin that happens to use the archetype common code. But this wouldn't fit nicely into the m2eclipse ability to run the archetype plugin. Is there a reasonably simple way to have an archetype be a whole plugin whose pom sets up the classloader for the archetype's code and to have the arechetype plugin manage this? Is there another approach I haven't thought of? thanks david jencks What's my best strategy here? From a quick glance at the archetype plugin stuff it looks like this is not currently supported but that it might be possible to add a third kind of archetype, something like "code-based" along with file-set and old. Is this interesting to anyone else? Is it likely to be simpler to just start over and ignore the archetype plugin stuff? I'd also like it push dependencyManagement stuff and possibly some properties into parent poms and check that it's not duplicating stuff. Is there already code in the archetype plugin stuff that does this or would I be adding a new capability? thanks david jencks - 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 -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks - 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: Archetype capabilities/limitations?
On Apr 6, 2009, at 9:43 AM, Jason van Zyl wrote: On 6-Apr-09, at 9:13 AM, David Jencks wrote: On Apr 4, 2009, at 11:15 AM, Jason van Zyl wrote: On 4-Apr-09, at 10:13 AM, David Jencks wrote: I'd like to write something I'll call it an archetype for now that generates a maven project but needs to run a _lot_ of java code in order to figure out what to put in the new pom.xml. The basis of it is there given we have velocity templates in there. I think what you want is to be able to deploy a class along with the archetype that would execute and manipulate the velocity context before rendering the files of the archetype. Something like a delegate for each template that's rendered? For this template do some mumbo jumbo and set object and flags in the Velocity context. For sophisticated POM manipulation we can just put a tool in the velocity context or provide a hook to write out your own POM completely. 95% of what you need is there already. You definitely don't need to start over. Thinking about this a bit more I'm even more confused about how to proceed. In my case the "lot of java code" is about half of geronimo. Ok, you've lost me. I don't understand what it is you're trying to do. So, I need the archetype to have the same classloader setup/ classloading capabilities as a plugin. So it seems like one choice would be to simply write a plugin that happens to use the archetype common code. But this wouldn't fit nicely into the m2eclipse ability to run the archetype plugin. Is there a reasonably simple way to have an archetype be a whole plugin whose pom sets up the classloader for the archetype's code and to have the arechetype plugin manage this? Is there another approach I haven't thought of? I think you need to write something up, I honestly have no idea what you're talking about now. I want to write something that will generate a geronimo plugin maven project and fill in as much as possible of the pom. When you write a geronimo plugin project, you need to include as maven dependencies the parts of geronimo that are needed to run your plugin. If you are deploying a services plugin, these geronimo parts are most likely the maven dependencies of the java code that implements your service, so there's no problem. However if your plugin is a javaee app, then you need to list the javaee bits that your app needs. For instance, if its a web app with jsps and jsf, you need to list the geronimo parts for a web container (jetty/tomcat), jasper, and myfaces. With the current geronimo plugin archetype you have to go in and figure all this out for yourself. However, the geronimo deployment system has a lot of code devoted exactly to figuring this out for you. I want to run that code when you use the geronimo plugin archetype. In more detail what I want: run the geronimo-plugin-archetype specify a javaee app as the module to be turned into a geronimo plugin geronimo-plugin-archetype runs (part of) the geronimo deployment system on the javaee app to figure out what it is and determine required dependencies geronimo-plugin-archetype includes these dependencies in the generated pom We already have a plugin (car-maven-plugin) that can run the geronimo deployment system, so I can probably figure out a way to just write a plugin to do this fairly easily. However it would be nice to have this functionality as an archetype so it can easily be run from e.g. m2eclipse. Hopefully this is a little bit clearer... thanks david jencks thanks david jencks What's my best strategy here? From a quick glance at the archetype plugin stuff it looks like this is not currently supported but that it might be possible to add a third kind of archetype, something like "code-based" along with file-set and old. Is this interesting to anyone else? Is it likely to be simpler to just start over and ignore the archetype plugin stuff? I'd also like it push dependencyManagement stuff and possibly some properties into parent poms and check that it's not duplicating stuff. Is there already code in the archetype plugin stuff that does this or would I be adding a new capability? thanks david jencks - 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 -- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart.
Re: Update on ASF Release requirements
Could I ask what's going to happen after you get the assembly plugin improved? Will there be an apache 7 pom or, how else would we get this new functionality? thanks david jencks On May 7, 2009, at 8:13 PM, Brian E. Fox wrote: I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll > wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2- beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck" -- S.Yegge - 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: Progress on support for large projects
On May 12, 2009, at 3:43 PM, Ralph Goers wrote: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a "bill of materials" (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my "library" isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. I'm fairly mystified how what you and Jorg appear to want could work with any of the scm systems I know about, that tag an entire file system subtree at once. Maybe I don't understand what you guys are talking about at all. here's what I think you want: file system structure showing projects +root +A +B +C ... +D Probably Jorg has further nesting, but I don't think that actually affects the argument. Projects A, C, E, G,... need to be released right now, whereas projects B, D, F... are just fine and don't need releases. IIUC you guys are supposing a parent pom for all these projects in "root" and want to be able to run a release on root and have the effect be to release just A, C, E, G and the root pom. So if you run a release on root the entire tree will get tagged including B, D, F etc that you didn't want tagged. So I think what you want to do is have a quick way to run releases on A,C,E,G,... and have each of those tagged individually and not tag the whole tree at once. My impression is that what you are fighting is the scm system, not maven. As far as project setup, what I've done in this situation is have a parent pom that isn't "root" but parallel to the projects: all the projects use this parent as their parent and obviously dont specify its location as "..". I then construct a pom that builds whatever I'm interested in working on in root, but don't check it into svn. I've never had to release more than 2 projects at once in such a setup, so just releasing modules individually hasn't been a problem for me. I can see that it would be a problem if I had 10 projects to release at once. I'd think this is additional new functionality for e.g. the release plugin rather than something that can be created by modifying existing functionality. I was really confused by this kind of situation until I realized that the problems with releasing complicated partial subtrees were caused by scm, not maven. After I arranged the source so tagging would correspond to the independent versions I wanted the layout became much easier for me to understand. Does this correspond at all to what you guys are talking about? thanks david jencks Ralph - 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: Progress on support for large projects
On May 12, 2009, at 7:02 PM, Ralph Goers wrote: On May 12, 2009, at 6:20 PM, David Jencks wrote: On May 12, 2009, at 3:43 PM, Ralph Goers wrote: On May 12, 2009, at 2:43 PM, Brian Fox wrote: As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Well, you've seen mine. Imagine Apache commons where you wanted to run a build from the root of commons. Not everything changes with each release so it is silly to deploy new jar versions that haven't changed. So you create a "bill of materials" (bom) pom that has the versions of all the subprojects and anything wanting to use a commons project can just import that and then specify dependencies on the various commons subprojects without specifying a version. But to build this all the subprojects need to have the bom pom as their parent or grandparent. Thus, any time you change the bom pom version every subproject has to change even if nothing changed in it. PITA. Granted, my "library" isn't as big as commons, put it still currently contains 22 pom.xml files that have to be modified each time the bom pom changes. I'm fairly mystified how what you and Jorg appear to want could work with any of the scm systems I know about, that tag an entire file system subtree at once. Maybe I don't understand what you guys are talking about at all. here's what I think you want: file system structure showing projects +root +A +B +C ... +D Probably Jorg has further nesting, but I don't think that actually affects the argument. Projects A, C, E, G,... need to be released right now, whereas projects B, D, F... are just fine and don't need releases. IIUC you guys are supposing a parent pom for all these projects in "root" and want to be able to run a release on root and have the effect be to release just A, C, E, G and the root pom. No. The root represents the library. The release is of the library, not the individual subprojects. I just don't want new versions created for subprojects that didn't change. So if you run a release on root the entire tree will get tagged including B, D, F etc that you didn't want tagged. Actually, I do want them tagged. The "bill of materials" represents a release of the whole library. It is just that some of the artifacts in the library didn't change. But they should all be part of the release tag. So I think what you want to do is have a quick way to run releases on A,C,E,G,... and have each of those tagged individually and not tag the whole tree at once. No. See above. My impression is that what you are fighting is the scm system, not maven. No. The SCM isn't a problem. However, mvn deploy will try to deploy artifacts that haven't changed since the last release. That is bad. Nexus should be able to silently ignore those or the deployer should somehow be able to detect that the artifact shouldn't be deployed. I'm even more mystified and understand how you want to use scm even less. One of the basic principles I have for scm is that stuff shouldn't be duplicated, in the sense that if some artifact is released at version 1.2.3.4 say, the scm location for that release can be found in only one, unique, place in the scm tree, such as an svn tag. Now if I understand what you are proposing, its to have +root(1.2-SNAPSHOT) +A(1.1-SNAPSHOT) +B(1.3-SNAPSHOT) Only B has changed since the last release, which was of root (1.1), A(1.1) and B(1.2); these are the version in the release tag. So you tag this after arranging the new release versions. You new tag has root(1.2), A(1.1) and B(1.3), and trunk has root(1.3-SNAPSHOT), A(1.1-SNAPSHOT) and B(1.4-SNAPSHOT) The problem I have with this is that A(1.1) is present in two different tags, violating the uniqueness principle I hold to. Have I yet again misunderstood the actions you want to take during release or do you think the uniqueness principle is not worth following? If I've misunderstood again, could you provide a more concrete example with versions and contents of tags to help me understand? thanks david jencks Ralph - 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: Progress on support for large projects
On May 13, 2009, at 7:02 AM, Ralph Goers wrote: On May 13, 2009, at 12:53 AM, David Jencks wrote: I'm even more mystified and understand how you want to use scm even less. One of the basic principles I have for scm is that stuff shouldn't be duplicated, in the sense that if some artifact is released at version 1.2.3.4 say, the scm location for that release can be found in only one, unique, place in the scm tree, such as an svn tag. Now if I understand what you are proposing, its to have +root(1.2-SNAPSHOT) +A(1.1-SNAPSHOT) +B(1.3-SNAPSHOT) Only B has changed since the last release, which was of root (1.1), A(1.1) and B(1.2); these are the version in the release tag. If B is the only thing that has changed then you would have: +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) In this case two artifacts would be deployed during the release: 1. The library bom pom (which, in this case, is the pom in root) for version 1.2. 2. The artifact for B 1.3 A 1.0 is part of the tag, is built and tested during the build, but is not redeployed to the repository. After the release the scm will contain: +root(1.2) +A(1.0) +B(1.3) Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... - development will continue after the release - therefore the version in "trunk" must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 - there is no plausible version for trunk/root/A - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? thanks david jencks - 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: Progress on support for large projects
On May 13, 2009, at 12:55 PM, Ralph Goers wrote: On May 13, 2009, at 10:41 AM, David Jencks wrote: Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... Your assumptions are not completely correct. a) In our case a release is aways off a branch. This isn't particularly relevant to the discussion but it does make production maintenance easier so I'll ignore it. b) tagging doesn't create a copy of anything. Maybe on the svn server that's true, but I'd never know it from the client view I get by svn co, svn up, etc. It just is a label that is a shortcut to a revision on a branch. Multiple tags that point to the same revision are not a problem and don't incur much overhead. I really don't care how much trouble releasing stuff causes infra disc purchase procedures :-) So the tree really looks like: +tags +root-1.0 (trunk revision 1) +A(1.0) +B(1.0) +root-1.1 (trunk revision 2) +A(1.0) +B(1.1) +root-1.2 (trunk revision 3) +A(1.0) +B(1.2) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) This assumes that A has not been modified since its initial release and B is currently under development and has not been released. So, we seem to have different views on acceptable ways to use svn. If I was involved in such a project I would kick and scream until - each release came from a single clearly identifiable scm location (violated by multiple tags for A(1.0), and the presence of A(1.0) in trunk) - trunk contained only SNAPSHOT version (except possibly while someone is actually doing a release -- behavior of the release plugin I'm not thrilled with) (violated by A(1.0) in trunk). or I gave up and forked it. I could be completely misguided in this, but it's my current viewpoint. - development will continue after the release - therefore the version in "trunk" must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. See above. While the tag applies to the whole subtree, no copy is made. From the point of view of what you get on a client machine, I don't understand this. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 No. There are multiple tags that all point to the same subversion revision. This is not a problem. Apparently we disagree on this. - there is no plausible version for trunk/root/A ? If A has not been changed its version is still 1.0. If it has then it is 1.1-SNAPSHOT. Again we disagree on whether this is acceptable. - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) Why would you allow a branch that matches a tag? If I was going to allow a branch to be created named root-1.2 then I would require that all tags be named root-1.2.n. If I did that then I would have +tags +root-1.0.0 (trunk revision 1) +A(1.0.0) +B(1.0.0) +root-1.1.0 (trunk revision 2) +A(1.0.0) +B(1.1.0) +root-1.2.0 (root-1.2 revision 3) +A(1.0.0) +B(1.2.0) /root-1.0 (branched from trunk at revision 1) +A(1.0.0) +B(1.0.0) /root-1.1 (branched from trunk at revision 2) +A(1.0.0) +B(1.1.0) /root-1.2 (branched from trunk at revision 3) +A(1.0.0) +B(1.2.0) /trunk at revision 4 +root(1.2-SNAPSHOT) +A(1.0) +B(1.3-SNAPSHOT) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? I'm not proposing anything. I'm just explaining what this particular project has been doing for the last 5 years and why Maven 2 is a PITA in this regard. Maven 1 was actually easier for this particular project. This process may work fine for the project in question and you in other circumstances, but would keep me from contributing no matter what build tool was in use. Here, the release plugin seems to me to strongly promote good scm practices. The only think I'd like to see is, given a setup like trunk (has no pom) +parent-pom +P1 +P2 +P1000 an easy way to release all the, say, odd numbered projects at once rather than running the release plugin on each one independ
Re: [VOTE 2] maven-assembly-plugin 2.2-beta-4
I'm eager to see this get out... this version works fine for me after I hacked the assembly descriptor parents so I could build it (no idea why I couldn't get to the parent snapshots) I'm not convinced all the worrying about regular expressions for includes/excludes is worth it. The only way to be really sure you're getting what was in svn is to do the assembly immediately after svn export. Otherwise you're apt to pick up or omit ide files (*.ipr etc from eclipse) that some projects put in svn and others don't --no matter how careful you think you're being a lot of the time you'll get it wrong. BTW, how/when will the almost as important assembly descriptor get released? thanks david jencks On May 28, 2009, at 3:23 PM, John Casey wrote: Hi, I've corrected the regression from the first VOTE thread for this plugin, and I'm ready to try this again...the URLs below have been updated where appropriate. --- As I'm sure you've noticed, we've had a large thread on this list regarding how to put together a proper ASF release using Maven. In order to enable the Assembly plugin to take on the burden of producing ASF source-release assemblies, we had to fix a few bugs. Along with this, I've also tackled the tar/zip file modes problem. The staged repository for this release can be found at: https://repository.apache.org/content/repositories/maven-staging-033 The JIRA notes for the release can be found at the following URL, or at appended to the end of this message: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126&styleName=Html&version=15298 Please vote! [ ] +1 Pull the trigger! [ ] +0 ...like I care [ ] -1 Stop right there and back away from the plugin slowly! Here's my +1. Thanks! -john === Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 ** Bug * [MASSEMBLY-238] - Assembly plugin removes file permissions * [MASSEMBLY-379] - Follow-up: file permissions are removed when creating tar.gz assembly * [MASSEMBLY-413] - Assembly plugin uses absolute paths from project instance after interpolation * [MASSEMBLY-414] - Allow regular expressions in include/exclude patterns for filesets --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation "What we have to learn to do, we learn by doing." -Aristotle - 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: [VOTE 3] maven-assembly-plugin 2.2-beta-4
I thought it was working great but...
what could cause this?
[INFO]
[INFO] Building Genesis
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set: /Users/david/geronimo/svn/geronimo/genesis/
trunk/target (included: [**], excluded: [])
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.tar.gz
[INFO] Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] Unable to load parent project from a relative path: Could not
find the model file '/Users/david/geronimo/svn/geronimo/genesis/
pom.xml'. for project unknown
[INFO] Parent project loaded from repository.
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.tar.gz
[INFO] Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip
[INFO] [source:jar {execution: attach-sources}]
[INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] Not executing Javadoc as the project is not a Java classpath-
capable package
[INFO] [gpg:sign {execution: default}]
Reading passphrase from file descriptor 0
It seems to be building the source archives twice. I guess there the
same both times so all that is lost is some time so maybe its not a
big problem but with a big project its some time.
This particular example is https://svn.apache.org/repos/asf/geronimo/genesis/trunk
rev 780259 with maven 2.0.10
I only see this with multi-module projects: single module projects
only build the source-archive once.
I'm running
mvn clean install -Papache-release
the apache 6 pom is the parent
assembly plugin is configured in pluginManagement:
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-4
gnu
and run in apache-release profile:
org.apache.maven.plugins
maven-assembly-plugin
single
validate
truerunOnlyAtExecutionRoot>
source-release
org.apache
apache-source-release-
assembly-descriptor
1.0-SNAPSHOT
Assuming it's not a configuration problem, at this point I'd rather
have a release than wait more days to fix this but if its an easy
fix it would be great to only assemble once.
thanks
david jencks
On May 29, 2009, at 4:41 PM, John Casey wrote:
Hi again,
I've corrected the regressions from previous VOTEs for this
plugin, and I'm ready to try this once again...the URLs below have
been
updated where appropriate. Also note that I've staged the site
documentation, and included a link to that as well.
---
As I'm sure you've noticed, we've had a large thread on this list
regarding how to put together a proper ASF release using Maven. In
order
to enable the Assembly plugin to take on the burden of producing ASF
source-release assemblies, we had to fix a few bugs. Along with this,
I've also tackled the tar/zip file modes problem. The staged
repository
for this release can be found at:
https://repository.apache.org/content/repositories/maven-staging-035
The JIRA notes for the release can be found at the follo
Re: [VOTE 3] maven-assembly-plugin 2.2-beta-4
I guess my description wasn't quite precise enough to get people to
look at the snippet. The snippet I showed has this bit twice:
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip
I'm pretty sure this is the assembly plugin rather than the source
plugin since it says "assembly:single"
And as I said I don't think this should block the release.
thanks
david jencks
On Jun 1, 2009, at 11:01 AM, John Casey wrote:
If you're talking about the [source:jar] bit, then that's another
plugin (maven-sources-plugin, IIRC) that may need to be turned
off...though that does produce a different type of artifact than the
project source structure we're attempting to put together for source
releases.
-john
David Jencks wrote:
I thought it was working great but...
what could cause this?
[INFO]
[INFO] Building Genesis
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set: /Users/david/geronimo/svn/geronimo/
genesis/trunk/target (included: [**], excluded: [])
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip [INFO] Setting
property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] Unable to load parent project from a relative path: Could
not find the model file '/Users/david/geronimo/svn/geronimo/genesis/
pom.xml'. for project unknown
[INFO] Parent project loaded from repository.
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip [INFO] [source:jar
{execution: attach-sources}]
[INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] Not executing Javadoc as the project is not a Java classpath-
capable package
[INFO] [gpg:sign {execution: default}]
Reading passphrase from file descriptor 0
It seems to be building the source archives twice. I guess there
the same both times so all that is lost is some time so maybe its
not a big problem but with a big project its some time.
This particular example is https://svn.apache.org/repos/asf/geronimo/genesis/trunk
rev 780259 with maven 2.0.10
I only see this with multi-module projects: single module projects
only build the source-archive once.
I'm running
mvn clean install -Papache-release
the apache 6 pom is the parent
assembly plugin is configured in pluginManagement:
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-4
gnu
and run in apache-release profile:
org.apache.maven.plugins
maven-assembly-plugin
single
validate
truerunOnlyAtExecutionRoot>
source-release
org.apache
apache-source-release-
assembly-descriptor
1.0-SNAPSHOT
Assuming it's not a configuration problem, at this point I'd rather
have a release than wait more day
Re: [VOTE 3] maven-assembly-plugin 2.2-beta-4
On Jun 1, 2009, at 1:47 PM, Paul Gier wrote:
When the source plugin forks the lifecycle it causes all the phases
up to "generate-sources" to be run again. So if your assembly
plugin is bound to any phase before that it will be run twice. Once
in the main lifecycle and once in the forked lifecycle. Since your
assembly goal is bound to the "validate" phase, the source plugin
config could cause what you are seeing.
Can you try either changing your assembly config to bind to the
package phase or changing your source plugin goal to "jar-no-fork"
instead of "jar"?
Changing the phase works great!!
thanks
david jencks
David Jencks wrote:
I guess my description wasn't quite precise enough to get people to
look at the snippet. The snippet I showed has this bit twice:
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip
I'm pretty sure this is the assembly plugin rather than the source
plugin since it says "assembly:single"
And as I said I don't think this should block the release.
thanks
david jencks
On Jun 1, 2009, at 11:01 AM, John Casey wrote:
If you're talking about the [source:jar] bit, then that's another
plugin (maven-sources-plugin, IIRC) that may need to be turned
off...though that does produce a different type of artifact than
the project source structure we're attempting to put together for
source releases.
-john
David Jencks wrote:
I thought it was working great but...
what could cause this?
[INFO]
[INFO] Building Genesis
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file set: /Users/david/geronimo/svn/geronimo/
genesis/trunk/target (included: [**], excluded: [])
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip [INFO] Setting
property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [site:attach-descriptor]
[INFO] Unable to load parent project from a relative path: Could
not find the model file '/Users/david/geronimo/svn/geronimo/
genesis/pom.xml'. for project unknown
[INFO] Parent project loaded from repository.
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent
recursive invocation.
[INFO] [assembly:single {execution: default}]
[INFO] Building tar : /Users/david/geronimo/svn/geronimo/genesis/
trunk/target/genesis-2.0-SNAPSHOT-source-release.tar.gz [INFO]
Building zip: /Users/david/geronimo/svn/geronimo/genesis/trunk/
target/genesis-2.0-SNAPSHOT-source-release.zip [INFO] [source:jar
{execution: attach-sources}]
[INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [gpg:sign {execution: default}]
Reading passphrase from file descriptor 0
It seems to be building the source archives twice. I guess there
the same both times so all that is lost is some time so maybe its
not a big problem but with a big project its some time.
This particular example is https://svn.apache.org/repos/asf/geronimo/genesis/trunk
rev 780259 with maven 2.0.10
I only see this with multi-module projects: single module
projects only build the source-archive once.
I'm running
mvn clean install -Papache-release
the apache 6 pom is the parent
assembly plugin is configured in pluginManagement:
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-4
gnu
and run in apache-release profile:
org.apache.maven.plugins
maven-assembly-plugin
single
validate
trueru
Re: [VOTE] Release Maven Eclipse plugin version 2.7
The new assembly plugin makes it trivially easy to have the release profile build the source distro, which is really amazingly nice. However you can easily have a separate profile to run an earlier assembly plugin to construct just the required source distro and run it with -N so it only runs once. Now that the policy has been clarified there are no more excuses to not following it. thanks david jencks On Jun 3, 2009, at 3:10 PM, Arnaud HERITIER wrote: I think there's no value to block all releases, waiting for this fix.I agree, support this change, but it won't help our users to have them waiting all our releases for several weeks. We are doing it like that (yes badly) for a long time now. Thus I don't think that one or two releases will change something. Arnaud On Wed, Jun 3, 2009 at 11:48 PM, Benjamin Bentmann < benjamin.bentm...@udo.edu> wrote: Barrie Treloar wrote: Staging repo: https://repository.apache.org/content/repositories/maven- staging-005/ -1 As far as I understand the recent discussions about proper releases [0] and the current docs [1], we are required to provide "a source package, which must be sufficient for a user to build and test the release". This requirement is not met by the "*-sources.jar" (no POM, no tests). One needs to grap an assembly descriptor to create a proper source bundle (John and Brian are working on improvements to our tooling to make this easy). Others may please correct me if I misunderstood the Apache release policy. Benjamin [0] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200904.mbox/browser [1] http://www.apache.org/dev/release.html#what-must-every-release-contain - 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: [VOTE] Release Maven Eclipse plugin version 2.7
On Jun 3, 2009, at 3:55 PM, Arnaud HERITIER wrote:
To be conform with ASF requirements, I understand that we have to
wait the
new assembly plugin to be able to produce the new sources distro.
There are
already 3 or 4 attempts to vote the release and it's not yet ended.
I think also that others ASF projects using Maven won't wait for
this fix if
they want to release something.
The purpose of assembly 2.2-beta-4 is to make it difficult to avoid
complying with apache policy. Right now it's not all that hard but
you have to do something apart from the release plugin. I haven't
tried this with say beta 2, but think it will work included in the
project root pom and run with mvn -Psource-distro -N deploy on a fresh
svn export, say after running release:perform.
source-distro
org.apache.maven.plugins
maven-assembly-plugin
2.2-beta-2
single
package
src/assemble/
source-release.xml
src/assemble/source-release.xml contains:
source-release
tar.gz
zip
${project.basedir}
true
**/${project.build.directory}/**
from
https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor/src/main/resources/assemblies/source-release.xml
david jencks
I have no problem, myself, to wait the release of the plugin some
more days
(I maintain it but I don't use it for myself ;-) ). But I don't
think it's a
good thing for our users. If Barry can do it today, it's possible
that he
can't in few days/weeks.
Cheers,
Arnaud
# Arnaud Héritier
# http://blog.aheritier.net
On Thu, Jun 4, 2009 at 12:40 AM, Barrie Treloar
wrote:
On Thu, Jun 4, 2009 at 7:18 AM, Benjamin Bentmann
wrote:
Barrie Treloar wrote:
Staging repo:
https://repository.apache.org/content/repositories/maven-staging-005/
-1
As far as I understand the recent discussions about proper
releases [0]
and
the current docs [1], we are required to provide "a source
package, which
must be sufficient for a user to build and test the release". This
requirement is not met by the "*-sources.jar" (no POM, no tests).
One needs to grap an assembly descriptor to create a proper source
bundle
(John and Brian are working on improvements to our tooling to make
this
easy).
Others may please correct me if I misunderstood the Apache release
policy.
Fair enough.
David mentions the assembly plugin makes this trivial.
Can someone link to step by step instructions?
As Arnaud says we have been bad previously and given the limited
resource on m-e-p to push releases it will be easier to let this one
slide.
If I can get the instructions I can ensure that future releases will
be fixed. But I don't have the capacity to create another release for
a while.
The release documentation
http://maven.apache.org/developers/release/releasing.html doesn't
mention anything about the ASF requirement.
I have some outstanding minor changes to that document so I will make
sure that something is added as well.
Barrie
-
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: [VOTE] Release Maven Eclipse plugin version 2.7
On Jun 3, 2009, at 4:36 PM, Barrie Treloar wrote: On Thu, Jun 4, 2009 at 8:54 AM, David Jencks wrote: On Jun 3, 2009, at 3:55 PM, Arnaud HERITIER wrote: To be conform with ASF requirements, I understand that we have to wait the new assembly plugin to be able to produce the new sources distro. There are already 3 or 4 attempts to vote the release and it's not yet ended. I think also that others ASF projects using Maven won't wait for this fix if they want to release something. src/assemble/source-release.xml Why isn't this descriptor part of the bundled ones? When can we add it do the release profile so it gets enforced without individual projects having to maintain this separately? You might want to consult the original discussion on this, its rather lengthy, and I'm sure I'll misrepresent it. The assembly plugin is not apache specific. The assembly descriptor might be. So it's being released as a separate artifact -- see the svn url and that should be clear. The assembly descriptor isn't necessarily useful without the newest assembly plugin. So the plan is to 1. get the assembly plugin released, 2. then the assembly descriptor, 3. then the use baked into maven projects and thoroughly tested, (other projects can also use it at this point) 4. finally release an apache 7 pom including this assembly config in apache-release profile. I was hoping (1) would happen monday afternoon, looks like it might possibly happen tomorrow morning -- one problem has surfaced but I'm not sure it's a regression from beta-3. To hurry this along, if you have a vote, test the plugin and use your vote. thanks david jencks - 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
Is site plugin 2.0 usable for multi-module projects?
After beating my head against the wall trying to get the site plugin to work I found http://jira.codehaus.org/browse/MSITE-395 which appears to indicate it is totally non-functional for multi- module projects. Does anyone know if there is a way to produce a usable site for a multi-module project using the site plugin 2.0 on os x? A working example would be great. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PluginManagement in ASF pom
I've been working on converting geronimo projects to use the apache 6 pom and think that the set of plugins tied down there is a very usable choice and makes maintenance of geronimo poms a lot easier. I certainly don't think stuff like eclipse and idea plugins belong in any root poms. For these in particular they are both AFAICT superseded by the built in idea tooling and m2eclipse. thanks david jencks On Jun 9, 2009, at 8:53 AM, Brian Fox wrote: On Tue, Jun 9, 2009 at 9:25 AM, Vincent Siveton wrote: Hi folks, I just spot the r766947 [1] of the ASF pom which add a pluginManagement tag for all ASF projects. Some questions: - some plugins like modello-maven-plugin or plexus-maven-plugin are more specific for Maven projects than ASF projects. Why not move them in the Maven pom? Why not external ASF plugins like tools-maven- plugin from geronimo project are not included? I simply moved most of our lock down list from the maven pom up to the apache pom. It doesn't hurt them to have the extra plugins, but if they are truely maven specific, i'll pull them back down today when I update everything for the source-release bundles. - some plugins like antrun-plugin are also defined in the super pom [2]. Why defining them twice? The maintenance will be hard: for instance the version of the maven-clean-plugin is different between super pom and asf pom... The super pom is for maven users in general, we should define our own destiny just like we tell our users to do. The rate at which we update the super pom should be very slow, leaning towards stable releases and never inserting alpha/beta when there is a final release available. The same is not true of Maven, we can use whatever we want. So for me it's not at all a concern that they are in two places. Super pom = everyone, ASF/Maven pom = our corporate pom. - some plugins are not included in the super pom, asf pom or maven pom. Brett told me on IRC that ant-plugin is not a "common" plugin. I am fine for ant-plugin but nothing is defined for eclipse/idea plugins which are commons IMHO. So what are common plugins for all asf projects and common plugins for Maven projects? We picked only the plugins that are bound by default to a lifecycle or are frequently bound by users, such as dependency and enfocer. Things like eclipse and idea are not frequently bound to a phase and so not locking them down is ok. If you feel strongly they should, then go for it...I was attempting to lock down the minimum required to produce stable builds for the users, and not lock down the world. IMHO I think it is the responsibility of Maven to provide a super pom but each ASF project should define its own pluginManagement list. WDYT? Yes they should, but what I found in helping new projects is the hurdle to get to a consistent ASF release was too high. This way they can choose to use a sane set of defaults we know work for ASF projects and go from there. Taking everything back out is just going to make everyone's life harder. Cheers, Vincent [1] http://svn.apache.org/viewvc?view=rev&revision=766947 [2] http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/maven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml - 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: Update on ASF Release requirements
On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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: Update on ASF Release requirements
On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencks wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - > Maybe you could point to some documentation that makes your point > that the Apache svn repository is itself a distribution subject to > LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey > wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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 co
Re: Update on ASF Release requirements
On Jun 11, 2009, at 9:56 AM, David Jencks wrote: On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencks wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - > Maybe you could point to some documentation that makes your point > that the Apache svn repository is itself a distribution subject to > LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. And one more thing :-D Also, in general the LICENSE and NOTICE files apply to what's actually in the artifact. So for the source-archive it's for the actual source code in svn and shouldn't include any stuff for other code that may get into binary artifacts by shading, unpacking, copying, generating, including, etc etc. that the binary artifact legal files have to talk about. I think it would be too confusing to try to generate separate files for the source and binary artifacts. thanks david jencks thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Fox wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey > wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter > wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apach
Re: Incorrect license metadata after inheriting org.apache:apache:6
These are added by the maven-remote-resources-plugin and you can customize the output using per-project velocity templates in src/main/ appended-resources/META-INF/ to add stuff to the basic LICENSE and NOTICE files. The plugin docs have more instructions. I think I saw that someone figured out how to not include the DEPENDENCIES file but I don't know what they did. thanks david jencks On Jul 2, 2009, at 4:13 AM, Jukka Zitting wrote: Hi, In Jackrabbit we recently upgraded to the org.apache:apache:6 parent POM to get the latest repository.apache.org settings, but as a side-effect we started getting extra LICENSE, NOTICE, and DEPENDENCIES files in the META-INF directories of our jar artifacts. This would be nice if the included license metadata was correct, but unfortunately it is not at least in our case. For example, we have many components where we're including external code snippets with separate licenses or copyright notice requirements. We already include our own custom license metadata files in the jar artifacts and it's confusing to have the remote resources plugin add these extra files. To avoid this confusion, is there some way (apart from not using org.apache:apache:6) for us to either disable the inclusion of these extra files or customize the files to match our needs? BR, Jukka Zitting - 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: Follow up on creating ASF-compliant source releases
On Jul 9, 2009, at 1:34 PM, Benjamin Bentmann wrote: Brett Porter wrote: Wouldn't it work if I just use the predefined "project" descriptor? Yes, if you do not have any source packages called "target". Really, what about the LICENSE/NOTICE files that get generated under target? As far as I grok the "project" descriptor (and also the "src" descriptor), these would be missing from the root of the source archive. I think Brian disagrees with me, but my understanding of the lengthy conversation on legal-discuss includes concluding that svn needs LICENSE and NOTICE files at expected checkout roots that cover what is actually in svn, as opposed to what gets in the binary, javadoc, or source jars. So these would get added to the source release packaging. thanks david jencks Also, the "project" descriptor would produce an assembly with the classifier "project", not what we want, do we? 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
Release plugin documentation request
I find that the release plugin docs don't give me an adequate idea of what to expect to happen in svn when I run release:prepare release:rollback release:perform release:branch After some experimentation I think I know what happens for some of these: release:prepare makes 3 svn commits - update current project to release version - create tag (from what? I have no idea) - update current project to next development version release:rollback, in an indeterminate number of commits, undoes anything committed since release:prepare was run for the first time in this release attempt. In particular if you tried to commit build fixes that only became evident during release:prepare, they will get undone. release:perform makes no svn changes release:branch I have no idea about. I suspect it would take about 15 minutes for one of the authors to update the docs with some accurate info along these lines and I doubt I would be the only one appreciating the effort. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Does gpg plugin work properly with gpg 2.0.12, the use of which is specified by apache?
Recently I followed the apache advice to update my code signing key to 4096 bits, see http://www.apache.org/dev/openpgp.html As part of that effort I installed MacGPG2-2.0.12 as the most likely version of gpg 2.0.12 for a mac. Although documentation seems a bit sparse I think I started the gpg agent as well. Running a release I see a message at every signing opportunity gpg: WARNING: "--no-use-agent" is an obsolete option - it has no effect You need a passphrase to unlock the secret key for user: "David Jencks (CODE SIGNING KEY) " 4096-bit RSA key, ID A2F9E313, created 2009-11-25 and every hour or so (??) a dialog box pops up for me to supply the passphrase (it was a long build). This never happened before I updated gpg, the passphrase in my settings.xml was used. We are using the apache 6 parent pom which specifies the 1.0-alpha-4 version of this plugin. Anyone have an idea what is going on? thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release plugin documentation request
Hi Stevo, Thanks but I think the existing release plugin documentation covers everything in those articles quite well. Neither one tells me what to expect to happen in svn when I run one of the goals. I guess -DdryRun=true is supposed to print the svn commands to be used on the console but they are in my experience very hard to find and I don't think this is applicable to anything but release:prepare. I'd also like to request that the meaning of release:clean be explained what exactly is changed? thanks david jencks On Nov 28, 2009, at 2:28 PM, Stevo Slavić wrote: Hello David, Maybe you can find answers to at least some of questions in following articles: - http://www.vineetmanohar.com/2009/10/23/how-to-automate-project-versioning-and-release-with-maven/ - http://weblogs.java.net/blog/2008/08/31/using-maven-release-plugin Regards, Stevo. On Sat, Nov 28, 2009 at 11:20 PM, David Jencks wrote: I find that the release plugin docs don't give me an adequate idea of what to expect to happen in svn when I run release:prepare release:rollback release:perform release:branch After some experimentation I think I know what happens for some of these: release:prepare makes 3 svn commits - update current project to release version - create tag (from what? I have no idea) - update current project to next development version release:rollback, in an indeterminate number of commits, undoes anything committed since release:prepare was run for the first time in this release attempt. In particular if you tried to commit build fixes that only became evident during release:prepare, they will get undone. release:perform makes no svn changes release:branch I have no idea about. I suspect it would take about 15 minutes for one of the authors to update the docs with some accurate info along these lines and I doubt I would be the only one appreciating the effort. thanks david jencks - 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
Does maven provide any support for re-signing artifacts with longer keys?
Apache has recently requested that all apache releases be signed with 4096 bit keys and SHA512, see http://www.apache.org/dev/openpgp.html I've released some artifacts using maven signed with an older 1024 bit key and most likely SHA1. Is there any maven support for re-signing these older artifacts with a new longer key? If not, does anyone have any advice for a non-maven way to do it? thanks david jencks
Re: Release plugin documentation request
Hi Dennis, Thanks for pointing out those pages. They indeed have the information I was asking for for those three goals. Might I suggest that these three pages are very clearly not examples but the basic usage guide for these three goals and would be much more visible linked from the usage page or better yet included in the goal explanation pages? thanks david jencks On Dec 6, 2009, at 1:23 PM, Dennis Lundberg wrote: Hi David Great to get some feedback on the docs. I think we have "prepare", "perform" and "branch" covered pretty well with these pages: http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html http://maven.apache.org/plugins/maven-release-plugin/examples/branch.html So I guess we'd need two more covering "rollback" and "clean". David Jencks wrote: I find that the release plugin docs don't give me an adequate idea of what to expect to happen in svn when I run release:prepare release:rollback release:perform release:branch After some experimentation I think I know what happens for some of these: release:prepare makes 3 svn commits - update current project to release version - create tag (from what? I have no idea) - update current project to next development version release:rollback, in an indeterminate number of commits, undoes anything committed since release:prepare was run for the first time in this release attempt. In particular if you tried to commit build fixes that only became evident during release:prepare, they will get undone. release:perform makes no svn changes release:branch I have no idea about. I suspect it would take about 15 minutes for one of the authors to update the docs with some accurate info along these lines and I doubt I would be the only one appreciating the effort. thanks david jencks - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache (parent POM) version 7
It looks to me as if this vote failed. I'd really appreciate it if someone would remove the apache-7 tag and roll back trunk to say version 7-SNAPSHOT so one doesn't have to search the mail archives to find out why the tag isn't represented at maven central. Concluding the vote thread might be good too :-) thanks david jencks On Nov 14, 2009, at 5:58 AM, Benjamin Bentmann wrote: Benjamin Bentmann wrote: John Casey wrote: https://repository.apache.org/content/repositories/orgapacheapache-001/org/apache/apache/7/ +1 I change my vote -1 after discovering that the version of the maven- javadoc-plugin being used by this POM, namely 2.6.1, is prone to fail during releases of multi-module projects [0]. Benjamin [0] http://jira.codehaus.org/browse/MJAVADOC-275 - 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: [Result] [VOTE] Apache (parent POM) version 7
Any idea when another try might be feasible? I'm updating a bunch of project's builds, having the completely built-in source assembly would be pretty handy. many thanks david jencks On Dec 10, 2009, at 1:40 PM, John Casey wrote: I've withdrawn the tag for this vote. We can try again later with the newer plugin versions. -john David Jencks wrote: It looks to me as if this vote failed. I'd really appreciate it if someone would remove the apache-7 tag and roll back trunk to say version 7-SNAPSHOT so one doesn't have to search the mail archives to find out why the tag isn't represented at maven central. Concluding the vote thread might be good too :-) thanks david jencks On Nov 14, 2009, at 5:58 AM, Benjamin Bentmann wrote: Benjamin Bentmann wrote: John Casey wrote: https://repository.apache.org/content/repositories/orgapacheapache-001/org/apache/apache/7/ +1 I change my vote -1 after discovering that the version of the maven-javadoc-plugin being used by this POM, namely 2.6.1, is prone to fail during releases of multi-module projects [0]. Benjamin [0] http://jira.codehaus.org/browse/MJAVADOC-275 - 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: Surefire and non-jar artifacts
Recall that a conformant rar file has all its classes in embedded jar
files, so putting the "outside" actual rar file on the classpath
doesn't give you access to any classes. If you put classes "loose"
inside a rar then a compliant j2ca container will probably ignore them.
On Feb 15, 2010, at 9:16 AM, Stephen Connolly wrote:
Hi,
So the lovely JCA resource adapters (a.k.a. rar files)...
In Maven 2.0.9, these were added to the classpath
What exactly was added to the classpath?
In Maven 2.2.1, these are no longer added to the classpath...
The former made testing resource adapters easy, but causes issues when
packaging a resource adapter in an EAR...
The later simplifies packaging RAR files inside an EAR (unless
possibly you want to try for a skinny RAR) but makes testing the code
that depends on the RAR more complex.
For example, using the lovely openejb, I now have to do:
maven-dependency-plugin
generate-test-resources
copy-dependencies
rar
true
test
${project.build.directory}/test-dependenciesoutputDirectory>
maven-surefire-plugin
${project.build.directory}/test-
dependencies/my-jca-impl.rar
This looks to me as if its putting the rar on the classpath, not the
jars inside that contain the classes.
Which is just plain ugly...
My first thought was to have an
configuration in surefire... but I just know that it would be abused
like some mad crazy fool... and because it would not be taking part in
depMgmt, it would cause issues with releasing so that's not best
practice way at all then
My second thought is to have
rar
true
So what do people think?
So are you proposing that if you have a rar, war, or ear, including it
as a dependency will figure out all the jars inside, compute the
actual internal classpath, and add all these to the maven classpath?
I have not problem with this but it's unclear to me if that's what you
are asking for.
thanks
david jencks
-Stephen.
P.S.
I've rejected my first plan... if Jason to aproves I'll resurect
it... otherwise Plan 2 or 3 (TBD)
-
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
Incompatibilities between maven 2.2.1 and 3.0.0-beta-1
I started trying to build geronimo trunk using maven 3 and ran into a couple
inconsistencies so far in our maven plugins. I don't know if we were doing
something unfortunate before I have no problem changing the geronimo code
to something that will work on both mavens
1. We were calling
org.apache.maven.artifact Artifact; //from dependencyNode.getRelatedArtifact()
if not null, otherwise dependencyNode.getArtifact()
artifact.getVersionRange().getRecommendedVersion().toString()
on essentially every element in the unpruned dependency tree (our pruning rules
are different from maven's). This no longer works. artifact.getVersionRange()
is now null on, apparently, non-direct transitive dependencies. The only
workaround I've come across is to put all the dependencies where this is
actually called in the pom the plugin runs on.
2. Plugin plugin = (Plugin)
project.getModel().getBuild().getPluginsAsMap().get("org.apache.geronimo.buildsupport:car-maven-plugin");
plugin.getExecutions() has changed. I'm not exactly sure what it used to
contain, but for a plugin that wasn't explicitly configured with an
element in the pom it was either empty or had one element in it. Now it
contains elements for every mojo in the plugin. I think I've figured out how
to find the one I want, so this is not a big problem for me. On the other
hand, the code here was originally to do my own merging of configurations
between parent pom and child because what maven was doing for me didn't work (I
don't remember the details). Has the merging been rewritten? Or, is there a
way to get object trees for each unmerged configuration so I can do it in my
plugin code?
Although (2) is not really a problem for me I would like to know how to work
around (1).
thanks
david jencks
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
maven-remote-resources-plugin ignores offline?
I asked about this on the users list about a month ago and got no response. I think the maven-remote-resources-plugin has a problem. When I build for the first time in 24 hours with -o, I still get stuff like this: [INFO] --- maven-remote-resources-plugin:1.0:process (default) @ geronimo-jetty-web-cts --- [INFO] Setting property: classpath.resource.loader.class => 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on => 'false'. [INFO] Setting property: resource.loader => 'classpath'. [INFO] Setting property: resource.manager.logwhenfound => 'false'. [INFO] snapshot org.apache.geronimo.modules:geronimo-naming-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.openwebbeans:openwebbeans-web:1.0.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.xbean:xbean-asm-shaded:3.8-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-jetty8-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-aries-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:aries:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:welcome-jetty:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:welcome:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:shutdown:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.modules:geronimo-persistence-jpa20-builder:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.plugins:openjpa2:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:jsr88-war-configurer:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:geronimo-shell:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.configs:connector-deployer-1_6:3.0-SNAPSHOT: checking for updates from nexus [INFO] snapshot org.apache.geronimo.framework:framework:3.0-SNAPSHOT: checking for updates from codehaus.snapshots [INFO] snapshot org.apache.geronimo.framework:framework:3.0-SNAPSHOT: checking for updates from apache.snapshots [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from codehaus.snapshots [INFO] snapshot org.apache.geronimo:geronimo:3.0-SNAPSHOT: checking for updates from apache.snapshots ... IIRC I get the same results with m-r-r-p v 1.1. When I don't have internet access, there's an extremely long delay (maybe a minute?) between each line. I get the same results with maven 2.2.1 and 3 beta 1. Does anyone else see this and/or think its a problem? So far I haven't located any of the code that might be responsible for this. thanks david jencks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: XMLBeans Plugin Release
None of the issues assigned to 2.0.1 are critical for geronimo. for geronimo the most important is http://jira.codehaus.org/browse/ MXMLBEANS-19, but that requires xmlbeans to release a correct pom instead of the incorrect one that has no attribution or known origin and that the maven project refuses to fix and IMO should go with upgrading the maven plugin to use xmlbeans 2.2.0. See http:// issues.apache.org/jira/browse/XMLBEANS-277. http://jira.codehaus.org/browse/MXMLBEANS-22 would be cool but requires upgrading to xmlbeans 2.1.0 and that isn't in maven repos. I'd hate to see what you come up with for a pom for it based on the one for 2.0.0. I'd suggest delaying that until xmlbeans approves a set of poms for the 2.2.0 jars. http://jira.codehaus.org/browse/MXMLBEANS-2 appears to be partially fixed (?) but is not a problem for apache projects. thanks david jencks On Dec 13, 2006, at 5:26 PM, Jason van Zyl wrote: Hi, The Geronimo folks need a release of the XMLBeans plugins, could someone help me look at the issues and see if the issues for 2.0.1 can be pushed off to a 2.0.2 or if the can be cleared up quickly. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
On Dec 14, 2006, at 11:05 AM, Stephane Nicoll wrote: Hi, This has been tackled a dozen of times and I am not sure it has anything to do with the EAR plugin, at least if we follow the spec. If I am wrong, please let me know. The valid way to bundle shared components/libs in a EAR is to define the Class-Path entry of the manifest in EJB module(s) using the component. It's certainly not by adding them in a module entry in the application.xml even though some application servers support this (JBoss namely). The EAR plugin supports the APP-INF/lib weblogic's trick by using the defaultJarBundleDir setting though. So I wouldn't say the EAR plugin has no dependency management features at all, I don't even see the point actually :) Make sure that your classpath entries got generated on the EJB side and it will just run fine. Now I agree it's not always easy so if you have ideas to improve, let us know. I am not sure we can do something at the EAR level, except generating EARs that do not follow the spec. I agree that spec support is the way to go. the jee5 ear lets you specify a lib directory (default is "lib") where all the jars inside get added to the classpath. We could work on jee5 support, that ought to keep everyone happy. Does the defaultJarBundleDir do this? I guess if so it might need to be put in the generated application.xml?? As you can tell I haven't looked at what the plugin actually does now. thanks david jencks Cheers, Stéphane On 12/14/06, Graham Leggett <[EMAIL PROTECTED]> wrote: Hi all, Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get the application.xml file built correctly. Between maven1 and maven2, the ejb plugin lost it's ability to bundle dependencies inside the ejb. This means (as I understand it) that it's now up to the ear plugin to add all the dependencies to the application.xml file. However, it seems that the maven-ear-plugin does not have any documented functionality to add dependencies to application.xml, except for explicitly declaring dependencies using the jarModule tag. This duplicates the dependency list, and removes all the power behind transitive dependency management, which is supposed to handle dependencies for you. Is there a setting I am not seeing, or does the ear plugin have no dependency management features at all? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
On Dec 15, 2006, at 3:34 AM, Graham Leggett wrote: On Thu, December 14, 2006 9:05 pm, Stephane Nicoll wrote: This has been tackled a dozen of times and I am not sure it has anything to do with the EAR plugin, at least if we follow the spec. If I am wrong, please let me know. The valid way to bundle shared components/libs in a EAR is to define the Class-Path entry of the manifest in EJB module(s) using the component. It's certainly not by adding them in a module entry in the application.xml even though some application servers support this (JBoss namely). The EAR plugin supports the APP-INF/lib weblogic's trick by using the defaultJarBundleDir setting though. So I wouldn't say the EAR plugin has no dependency management features at all, I don't even see the point actually :) Make sure that your classpath entries got generated on the EJB side and it will just run fine. Ok, then I'll put it this way: it has no dependency management features that are clearly enough documented :) If you create an ejb using the default ejb configuration, and then you add this ejb to an ear file again with a default configuration, maven goes through all the motions and creates what looks like a valid ear file. But this ear file refuses to load into Jboss (the dreaded NoClassDefFound exception). Is there a reason why a spec compliant ejb and ear can't be created by default by the ejb and ear plugins? I'm asking from ignorance - I don't have in depth knowledge of the internal structure of an ear file, that being maven's job to worry about this stuff for me. The problem is that to build an ear, you have to build an ejb jar that can only go in that ear, because details of the ear it is going in have to be put into the ejb jar manifest. Obviously there's no possible way to guess this from the point of view of the ejb jar (maybe you plan to run the ejb jar standalone) so you have to specify it explicitly in the ejb plugin configuration. As I pointed out earlier, jee5 includes a lib dir in an ear which you can even name whatever you want. This at least gets ears to the level of dysfunction of wars. thanks david jencks The only mention I can find about the classpath entry is a FAQ entry at http://maven.apache.org/plugins/maven-ejb-plugin/faq.html, but this rather cryptic explanation doesn't indicate why you might want to do this (although it seems clear from your explanation that it is necessary), or why this behaviour isn't the default behaviour for the plugin. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [regression] Cannot release plugins parent!
For a situation like this where a "parent" is also being used sometimes for building all the "children" although that is not its primary purpose, how about putting the modules in a profile that e.g. hudson can use? thanks david jencks On Apr 12, 2008, at 4:18 PM, Brian E. Fox wrote: Yes that's one reason. I often go into that folder and do a top to bottom build or resolve all dependencies etc. Modules is a normal part of the build hierarchy and we should start axing it out because of a release plugin bug. If you want to comment it out so you can do your release and put it back after, then that's ok. -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Saturday, April 12, 2008 5:55 PM To: Maven Developers List Subject: Re: [regression] Cannot release plugins parent! Is that to prevent you from having to set up 39 individual projects in Hudson (or any other CI server) ? Brian E. Fox wrote: Hudson uses this to detect the children so we need this in there. -Original Message- From: Benjamin Bentmann [mailto:[EMAIL PROTECTED] Sent: Saturday, April 12, 2008 8:47 AM To: Maven Developers List Subject: Re: [regression] Cannot release plugins parent! What is the purpose of having a element for our plugins? It's not like we want to build all plugins in one go, is it? Hudson used to do this if I remember correctly (the plugin ITs seem to have been removed recently). Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [regression] Cannot release plugins parent!
On Apr 13, 2008, at 1:21 AM, Benjamin Bentmann wrote: Brian E. Fox wrote: I saw leave it as it is because that is the normal scenario and the one users are most likely to have. This way we see and fix the same things they will need. +1. The reactor was meant for exactly those aggregating builds. The usual way to disable recursive builds is the -N flag. If that's causing problems with the Release Plugin, we should fix the cause, not the symptom. Really? I think the situation in plugins bears closer examination. It seems to me that both the reactor and release plugin work best with groups of projects where the directory layout matches the pom inheritance. This is decidedly NOT the case in plugins, as the parent pom for each plugin is a released version of the parent, not the version in the parent directory. Clearly in such an environment releasing the entire tree at once is not intended and the build should be set up to make sure it doesn't happen. The current setup combines two completely separate functions: 1. providing a single parent pom for all the plugins: normally each plugin in trunk will use a (possibly different) released version of the parent pom as parent, and never the snapshot version above it in the directory tree. 2. providing a convenience method of building all the plugins at once. This should never be activated when releasing the parent pom. Unless you are running a CI setup or looking for regressions from activity elsewhere you almost certainly don't want to run this build. The current setup mixes up these two functions and IIUC trying to release the parent will activate building and probably releasing all the individual plugins. I know of two easy ways to separate these two unrelated functions: a. Put the parent pom somewhere else, like in plugins/trunk/plugin- parent. The pom in plugins/trunk would just have the modules element. b. Put the list of modules in a profile where the release plugin won't see it. I prefer (a) because then tagging the parent pom wont copy the entire set of plugins in a unreleased state into the svn tag for the released parent pom which in my view creates unnecessary confusion for anyone trying to understand what's going on in svn. Are there any other situations where having the release plugin ignore the modules element would be appropriate? thanks david jencks Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where should release plugin copy from?
In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where should release plugin copy from?
On Apr 24, 2008, at 10:18 AM, Brian E. Fox wrote: I was pretty sure it does tag from the working copy? well from a release I did on march 12 New Revision: 636232 URL: http://svn.apache.org/viewvc?rev=636232&view=rev Log: [maven-release-plugin] prepare release directory-parent-1.0 Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory-server/ pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory/pom.xml geronimo/plugins/directory/branches/1.0/pom.xml Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml URL: http://svn.apache.org/viewvc/geronimo/plugins/directory/branches/1.0/directory/pom.xml?rev=636232&r1=636231&r2=636232&view=diff = = = = = = --- geronimo/plugins/directory/branches/1.0/directory/pom.xml (original) +++ geronimo/plugins/directory/branches/1.0/directory/pom.xml Wed Mar 12 00:23:14 2008 @@ -25,7 +25,7 @@ org.apache.geronimo.plugins directory-parent -1.0-SNAPSHOT +1.0 ../pom.xml .. New Revision: 636234 URL: http://svn.apache.org/viewvc?rev=636234&view=rev Log: [maven-release-plugin] copy for tag directory-parent-1.0 Added: geronimo/plugins/directory/tags/directory-parent-1.0/ - copied from r635397, geronimo/plugins/directory/branches/1.0/ New Revision: 636235 URL: http://svn.apache.org/viewvc?rev=636235&view=rev Log: [maven-release-plugin] prepare for next development iteration Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory-server/ pom.xml geronimo/plugins/directory/branches/1.0/geronimo-directory/pom.xml geronimo/plugins/directory/branches/1.0/pom.xml Modified: geronimo/plugins/directory/branches/1.0/directory/pom.xml URL: http://svn.apache.org/viewvc/geronimo/plugins/directory/branches/1.0/directory/pom.xml?rev=636235&r1=636234&r2=636235&view=diff = = = = = = --- geronimo/plugins/directory/branches/1.0/directory/pom.xml (original) +++ geronimo/plugins/directory/branches/1.0/directory/pom.xml Wed Mar 12 00:26:14 2008 @@ -25,7 +25,7 @@ org.apache.geronimo.plugins directory-parent -1.0 +1.0.1-SNAPSHOT ../pom.xml . which looks to me like the release plugin is following the process I outlined. thanks david jencks ... -----Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2008 1:07 PM To: Maven Developers List Subject: Where should release plugin copy from? In my experience the release plugin currently works like this: 1. modifies working copy poms to release version 2. commits poms 3. does a repo-repo copy to the new tag 4. updates working copy poms to the new version 5. commits new-version poms. Some projects (activemq) have a versioning scheme whereby branches, say 4.1, are kept at version 4.1-SNAPSHOT forever and releases, such as 4.1.1, 4.1.2, ..., are tagged directly off of the branch. The current release plugin process thus results in 2 commits to all the poms in the branch that modify the versions, then modify them back to their original values. This creates a fair amount of noise in the scm lists. Would it be possible for the release plugin to do the following? 1. modify working copy poms to release version 2. do a working copy to repo copy for the new tag 3. adjust the working copy poms to the new version, or revert if the new version is the same as the old version 4. commit the working copy poms if there is a new version. Is this process svn specific? If so could it be provided as an option? thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: namespace support in POM.xml ?
In particular, could you compare in detail this relaxng method and the
similar xml schema approach using substitution groups and abstract
schema types? (note that the substitution group part of this is
unnecessary but results in easier to read xml)? After studying your
blog post I don't see any major differences between the relaxng
approach and the xml schema approach beyond the differences between
relaxng and xmlschema. On the other hand this is the first time I've
seen relaxng.
Are there any tools like jaxb that work with relaxng?
thanks
david jencks
On May 21, 2008, at 10:56 AM, Jason van Zyl wrote:
Bryon,
How would you compare this with a method like this using XML Schema.
I'm not a huge fan of XSD, but there is a lot of tooling for XSD
especially in IDEs and that would be something we have to consider.
Do you actually use this method you describe in a production system,
or just a thought experiment?
On 18-May-08, at 2:49 PM, Bryon Jacob wrote:
I wrote a kinda lengthy blog post about doing this sort of thing:
http://freedomandbeer.com/posts/extensible-xml-with-xml-namespaces-and-relaxng
RelaxNG is a fantastic language for specifying schemas for XML -
the grammar notation is very natural to write in. Allowed elements
are specified using "name classes", and you can perform set
arithmetic over those classes to achieve some amazing results for
extensibility, by delegating validation of extension elements to
the author of the extensions, while retaining the ability to assert
the validity of the core document structure.
If I understand the problem that you're trying to solve here, it is
exactly analogous to the example in my blog post. I think you
would probably structure your xml somewhat differently than below -
you define the "profile" namespace prefix on the
element, but since the profile isn't a child of that element, the
declaration doesn't carry through. For your goals here, I don't
even think the element buys you anything -- what you
really want to do, it seems, is change the core Maven schema to
allow arbitrary extensions to a project's XML, as long as they are
partitioned into a new namespace - rewriting your example XML:
http://maven.apache.org/POM/4.0.0";>
...
http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation
">
true
Windows 98
...
Using RelaxNG, you could write the rule for the element
to allow any element NOT in the maven namespace to be included:
PROFILE =
element maven:profile {
element maven:activation {
element maven:activeByDefault { xsd:boolean}
}
| ANY_EXT_ELEMENT*
}
ANY_EXT_ELEMENT =
element * - maven:* {
attribute * { text }*,
( text* & ANY_EXT_ELEMENT* )*
}
And then, you could declare a RelaxNG grammar to parse a "project
with profile enancements" document like:
include "maven.rnc" {
ANY_EXT_ELEMENT =
element * - (maven:* | profile:*) {
attribute * { text }*,
( text* & ANY_EXT_ELEMENT* )*
}
| DEACTIVATION
}
DEACTIVATION =
element profile:deactivation {
element profile:os {
element profile:name { text }
}
}
Like I said, there's a much more detailed, and analogous, example
at the link above. hope this helps!
- Bryon
On May 16, 2008, at 1:53 PM, nicolas de loof wrote:
Hello,
many thread on this list makes proposal for some changes in the
POM.xml
format, to be included in 4.1.0 modelVersion.
Could we use XML namespaces to support progressive enhancements ?
Based on
this, proposal for new features could be added to maven, using an
to support the new schema, without requirement to wait
for next
major version to include POM structure changes.
example : considering the recent proposal for profiles enhancements
http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation
true
Windows 98
Could be rewritten :
http://docs.codehaus.org/display/MAVENUSER/Improvements+to+Profile+Activation+Deactivation
org.apache.maven.proposals
profile-enhancements
true
Windows 98
This can be compared with namespace support in Springframework
context files
: adding a new custom namespace allow to make the configuration
less verbose
or more powerfull, with no requirement to change the base XML model.
Nicolas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
--
What matters is not ideas, but the
Re: xbean in 2.1 break embeddabable usage of maven
I wonder if having xbean add an editor if there is nothing there for a class already would work. thanks david jencks On May 29, 2008, at 12:06 PM, Milos Kleint wrote: Well, the PropertyEditors class in xbean sets every imaginable property editor to java.beans.PropertyEditorManager.registerEditor() overriding and IDE's own editors. That means property customizers disappear etc, some places in the IDE don't cope with that.. I've seen a report where the GridBagLayout property setting WeightX turns java code to question marks instead of correct number settings, making the class uncompilable. as a hotfix, I've commented out every reference to PropertyEditorManager in the PropertyEditors class and used that. Seems to have no influence on the maven build or project loading. and fixes the issue. Milos http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditors.java On Thu, May 29, 2008 at 7:03 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: Milos, Additionally, it is impossible for us to know unless there is some representative test that is run on our side. I've had XBR in there for over a month now. Anything with system properties, threads, and now property editors have to have some representation in the tests. If you create something that represents the problem I'll fix it by the end of next week. On 29-May-08, at 5:47 AM, Milos Kleint wrote: Hey.. I've upgraded the netbeans users to latest 2.1-SNAPSHOT of maven embedder. I've done so to get the fix for issue with bad metaversion (RELEASE/LATEST) resolving.. However I've ended up with another severe problem. xbean seems to register it's own property editors into PropertyEditorManager on startup, wreaking havoc in the IDE. http://www.netbeans.org/issues/show_bug.cgi?id=135868 (50 duplicate reports since 2 days) or http://www.netbeans.org/issues/show_bug.cgi?id=136067 and there's probably more. is there a way to make xbean stop doing it? will I in turn end up with broken maven/plexus? Thanks for any pointers. Milos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - /maven/plugins/trunk/maven-site-plugin/pom.xml)
On Jun 30, 2008, at 9:21 AM, Brian E. Fox wrote: Sorting the dependencies purely for aesthetic reasons is a bad idea given the current first-wins scenario. I would rather have the dependency resolver throw an exception or emit a very obvious warning in the case where it has to use the order of dependencies in the top level pom to decide which version to use, and have the easy ability to sort the dependencies. I've seen too many projects with duplicate dependencies because there are a hundred or so in random order. thanks david jencks -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2008 9:56 AM To: Maven Developers List Subject: Re: [Proposal] Pom Code Style (WAS svn commit: r670264 - / maven/plugins/trunk/maven-site-plugin/pom.xml) Please keep in mind that the ordering of dependencies can (in some cases) change which version of a particular transitive dependency is used. If two direct dependencies both reference a third dependency - but using different versions - then the current resolution technique keeps the first one encountered, iff the two references happen at the same "level" of transitivity (distance from the current POM). Therefore, simply alphabetizing the dependencies list could change the transitive dependency list used for your build. -john Benjamin Bentmann wrote: Paul Gier wrote: Anyway, I definitely like the idea of a pom plugin to do "pom:reformat" or "pom:reorder" and maybe I can add a parameter about sorting the dependencies. Instead of a parameter, I believe sorting the dependencies should be a distinct mojo. Otherwise, how to handle the use case of only sorting dependencies, i.e. neither reformat nor reorder all the rest? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact signing feature branches
On Jul 11, 2008, at 9:42 AM, Brett Porter wrote: Hi, I've wanted to pick up my work on this for some time and was prodded by the [EMAIL PROTECTED] threads to take another crack at this. http://docs.codehaus.org/display/MAVEN/Repository+Security (the issue and related branches are linked) Are the sample settings in the repo sig policy section backwards? ignore warn david jencks I've created a couple of branches to try integrating the work again in as simple and non-intrusive manner (both in code and to the user) as possible. I already have commons-openpgp in the sandbox from some time ago to deal with processing the signatures (it doesn't have any external dependencies other than bouncy castle), so I'll integrate that. If anyone else wants to offer feedback or dive in, you're more than welcome! Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact retrieval, mercury, and jetty-client
On Jul 17, 2008, at 4:26 PM, Jesse McConnell wrote: hey all, I have been working on the jetty-client in the jetty project over in codehaus which is the library mercury uses that is doing the asynchronous retrieval and deployment of artifacts. Greg Wilkins and I have recently been increasing the functionality of the jetty-client and we are getting to the point where we need to do a bit more integration with mercury, namely in the area of security, authentication specifically. We have ssl support and cursory webdav support for creating directories on put operations if webdav is enabled server side in places and all of this shares the same async nio framework that jetty uses very successfully for scaling to very large numbers of connections. It is pretty nice and small as well. Anyway, the security api in jetty-client is still open and somewhat malleable if we add some additional options, but it ought to work for what is needed here. The specific integration bit needed right now in mercury is in mapping username/password credentials to the relevant host. In jetty-client we have this broken out by the security realm that the target host replies with in the authentication request header but that doesn't necessarily apply in maven-land. I am not sure what sort of api we ought to have in mercury for this, but the jetty-client allows for extending a couple of interfaces which allow you to setup your own security realm and mapping solution. It should also be able to support simple things like adding a realm that would prompt the user for username/password and then cache that for future use by other connections in that batch. I hope this interface can be made JASPI friendly. There's no explicit http client profile in jaspi and presumably the client side authentication has the same kinds of problems as the server side authentication but I suspect that we can work something out that is both efficient and spec compatible. thanks david jencks Anyway, I am interested in hearing how folks want to address this in mercury so any thoughts are more then welcome. I am not sure how much mercury has been discussed on the dev list up to this point but I am assuming that most of you have an inkling of what the goal of mercury is...if not ask away and someone will chime in :) cheers, jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: artifact retrieval, mercury, and jetty-client
On Jul 18, 2008, at 12:28 PM, Jesse McConnell wrote: djencks, I am not sure what the client side of a jaspi api would look like, can you give an example of what it would be doing? The basic idea is that, in a client, you'd be calling a authentication context before sending the message to secure it and after receiving the response to validate it. The server can conduct a conversation with the "validate response" part for stuff like basic auth challenges, form auth redirects, etc. The specific methods in ClientAuthContext from the jaspi spec are AuthStatus secureRequest(MessageInfo messageInfo, Subject clientSubject) throws AuthException; AuthStatus validateResponse(MessageInfo messageInfo, Subject clientSubject, Subject serviceSubject) throws AuthException; The MessageInfo object has the request and response messages accessible inside it. This might not be the ideal list to discuss this in more detail :-) thanks david jencks from my perspective what we need to wire up in mercury right now is some generic security api that something like maven can inject with the goop in setting.xml meshed with repositories tags so it can select the right 'security realm' based on hostname, returned realm, or whatever the case may be. I know you have done a mess of jaspi work on a jetty trunk branch...am interested in how that maps back to client type stuff :) client side is a pain jesse On Fri, Jul 18, 2008 at 2:16 PM, David Jencks <[EMAIL PROTECTED]> wrote: On Jul 17, 2008, at 4:26 PM, Jesse McConnell wrote: hey all, I have been working on the jetty-client in the jetty project over in codehaus which is the library mercury uses that is doing the asynchronous retrieval and deployment of artifacts. Greg Wilkins and I have recently been increasing the functionality of the jetty- client and we are getting to the point where we need to do a bit more integration with mercury, namely in the area of security, authentication specifically. We have ssl support and cursory webdav support for creating directories on put operations if webdav is enabled server side in places and all of this shares the same async nio framework that jetty uses very successfully for scaling to very large numbers of connections. It is pretty nice and small as well. Anyway, the security api in jetty-client is still open and somewhat malleable if we add some additional options, but it ought to work for what is needed here. The specific integration bit needed right now in mercury is in mapping username/password credentials to the relevant host. In jetty-client we have this broken out by the security realm that the target host replies with in the authentication request header but that doesn't necessarily apply in maven-land. I am not sure what sort of api we ought to have in mercury for this, but the jetty- client allows for extending a couple of interfaces which allow you to setup your own security realm and mapping solution. It should also be able to support simple things like adding a realm that would prompt the user for username/password and then cache that for future use by other connections in that batch. I hope this interface can be made JASPI friendly. There's no explicit http client profile in jaspi and presumably the client side authentication has the same kinds of problems as the server side authentication but I suspect that we can work something out that is both efficient and spec compatible. thanks david jencks Anyway, I am interested in hearing how folks want to address this in mercury so any thoughts are more then welcome. I am not sure how much mercury has been discussed on the dev list up to this point but I am assuming that most of you have an inkling of what the goal of mercury is...if not ask away and someone will chime in :) cheers, jesse -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: element in plugin POMs
Maybe I misunderstood what Benjamin is saying but I believe I've run into this also... IIUC the situation is that the plugin and its parent pom are in totally unrelated svn locations and _not_ including the svn tag in the plugin results in _completely incorrect and meaningless_ scm info in the generated site. So again IIUC the only plugins that are dealing with it correctly are those that include the correct svm info explicitly. parent pom at <>/tags/parent-1/pom.xml plugin at <>/trunk/foo-plugin/pom.xml No way to navigate from plugin to parent AFAICT or deduce plugin's scm location from the parents. I thought leaving out the scm tag only works when the entire set of maven projects was released at once with a fixed relationship between parent and sub-projects. Am I missing something? thanks david jencks On Aug 11, 2008, at 11:51 AM, Jason van Zyl wrote: It sounds more like problems in particular plugins. Restating the SCM URL is a bad thing and we should make it so that it can be used reliably. If certain plugins are not dealing with it correctly then those need to be fixed soon. On 11-Aug-08, at 11:41 AM, Benjamin Bentmann wrote: Brian E. Fox wrote: Seems fishy to me as well. We have inheritance for a reason. Over at Mojo I suggested adding several times for the following reason. Most of the time, a plugin inherits from a released parent whose SCM URL points to its tag, say repo/tags/parent-1 Now, running "mvn site" on a plugin POM that just inherits this URL will deliver repo/tags/parent-1/foo-maven-plugin-X i.e. the plugin's SCM URL points erroneously to a sub directory of the parent's tag. This phenomenon is irrelevant as long as no snapshot sites are deployed from the trunk. During a release, the Release Plugin's tagBase parameter should kick in and ensure the assembled SCM URL is correct. Not sure how/if this is related to the problems Dennis described. Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven evangelism instructions broken
The svn instructions at http://maven.apache.org/guides/mini/guide- maven-evangelism.html refer to urls such as svn://svn.codehaus.org/maven/scm/repository which don't appear to work anymore: $ svn co svn://svn.codehaus.org/maven/scm/repository poms svn: URL 'svn://svn.codehaus.org/maven/scm/repository' doesn't exist Should I file a jira on this, if so where? I sincerely hope the impossibility of supplying patches rather than complete poms will not affect the speed at which critical pom fixes can be applied. thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
