Re: Incremental build API
On Mar 25, 2014, at 7:31 PM, Hervé BOUTEMY wrote: > Hi Jason, > > Interesting. > > What is the plan about org.sonatype.plexus:plexus-build-api already > integrated > in some plugins? > We consider it deficient for properly tracking stale outputs and being fine-grained enough to make an incremental compiler. We likely won't be developing that API any further but we'll continue to support that API in M2E. > Given the expected large diffusion of this API, wouldn't it be wise to put it > at Apache? > or Eclipse? > (I won't rehash previous discussions about freedom and preferences from each > people) We may in the future, but it is being developed for a customer and will likely remain in a high degree of flux. Our highest priority is getting it all working and Github is the easiest place to develop for now. > > Regards, > > Hervé > > Le mardi 25 mars 2014 10:43:57 Jason van Zyl a écrit : >> Hi, >> >> For those who are interested in incremental builds we, at Takari, have >> released a general purpose incremental build API with an initial focus on >> Maven. We've created a short, high-level description of the framework[1] >> and we've opened up our Git repository with the code[2]. We also have a >> some demos that people can look at[3]. We are, and have been, running this >> code in production for a few months but it is still a work in progress. We >> have implemented a Maven lifecycle that integrates this API but we've just >> started using it ourselves. We will open this lifecycle up shortly for >> people to try but for now, if you're interested in incremental builds take >> a look and let us know what you think! >> >> A note to those interested that the use of the API in Maven requires 3.2.1+. >> >> [1]: http://takari.io/2014/03/25/incremental-build.html >> [2]: https://github.com/takari/io.takari.incrementalbuild >> [3]: >> https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementa >> lbuild/src/test/java/io/takari/incremental/demo >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> - >> >> 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 > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Incremental build API
The scope of plexus-build-api is strictly limited to eclipse integration. As such, it does not provide enough fidelity to implement proper command line incremental build. In fact, even inside eclipse plexus-build-api does not correctly handle stale output cleanup, so we have to do Project/Clean after removing project resources, for example. Although m2e will support plexus-build-api for the foreseeable future, I think plugins that use it should migrate to the new API to get both correct behaviour inside eclipse and incremental build support on command line. I may even try to encourage migration with error/info markers about plexus-build-api usage in m2e, but I have not decided yet. -- Regards, Igor On 2014-03-25, 22:31, Hervé BOUTEMY wrote: Hi Jason, Interesting. What is the plan about org.sonatype.plexus:plexus-build-api already integrated in some plugins? Given the expected large diffusion of this API, wouldn't it be wise to put it at Apache? or Eclipse? (I won't rehash previous discussions about freedom and preferences from each people) Regards, Hervé Le mardi 25 mars 2014 10:43:57 Jason van Zyl a écrit : Hi, For those who are interested in incremental builds we, at Takari, have released a general purpose incremental build API with an initial focus on Maven. We've created a short, high-level description of the framework[1] and we've opened up our Git repository with the code[2]. We also have a some demos that people can look at[3]. We are, and have been, running this code in production for a few months but it is still a work in progress. We have implemented a Maven lifecycle that integrates this API but we've just started using it ourselves. We will open this lifecycle up shortly for people to try but for now, if you're interested in incremental builds take a look and let us know what you think! A note to those interested that the use of the API in Maven requires 3.2.1+. [1]: http://takari.io/2014/03/25/incremental-build.html [2]: https://github.com/takari/io.takari.incrementalbuild [3]: https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementa lbuild/src/test/java/io/takari/incremental/demo Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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: Incremental build API
Hi Jason, Interesting. What is the plan about org.sonatype.plexus:plexus-build-api already integrated in some plugins? Given the expected large diffusion of this API, wouldn't it be wise to put it at Apache? or Eclipse? (I won't rehash previous discussions about freedom and preferences from each people) Regards, Hervé Le mardi 25 mars 2014 10:43:57 Jason van Zyl a écrit : > Hi, > > For those who are interested in incremental builds we, at Takari, have > released a general purpose incremental build API with an initial focus on > Maven. We've created a short, high-level description of the framework[1] > and we've opened up our Git repository with the code[2]. We also have a > some demos that people can look at[3]. We are, and have been, running this > code in production for a few months but it is still a work in progress. We > have implemented a Maven lifecycle that integrates this API but we've just > started using it ourselves. We will open this lifecycle up shortly for > people to try but for now, if you're interested in incremental builds take > a look and let us know what you think! > > A note to those interested that the use of the API in Maven requires 3.2.1+. > > [1]: http://takari.io/2014/03/25/incremental-build.html > [2]: https://github.com/takari/io.takari.incrementalbuild > [3]: > https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementa > lbuild/src/test/java/io/takari/incremental/demo > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > 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
Operating system requirement
Under requirements [1], we're stating the following: "No minimum requirement. On Windows, Windows NT and above or Cygwin is required for the startup scripts. Tested on Windows XP, Fedora Core and Mac OS X." What exactly are we trying to say with the "On Windows, Windows NT and above or Cygwin is required for the startup scripts." sentence? is it just me or is the English weird? Also, what is tested on WinXP, Fedora and Mac? Is it Maven which is tested on these platforms, or the startup scripts? AFAIK we have no CI IT builds on Fedora. But we have it on Ubuntu. Also, should we state Mac even though we don't have CI IT builds on Mac? I know we're several devs on Mac though. /Anders [1] http://maven.apache.org/download.cgi#Requirements
Incremental build API
Hi, For those who are interested in incremental builds we, at Takari, have released a general purpose incremental build API with an initial focus on Maven. We've created a short, high-level description of the framework[1] and we've opened up our Git repository with the code[2]. We also have a some demos that people can look at[3]. We are, and have been, running this code in production for a few months but it is still a work in progress. We have implemented a Maven lifecycle that integrates this API but we've just started using it ourselves. We will open this lifecycle up shortly for people to try but for now, if you're interested in incremental builds take a look and let us know what you think! A note to those interested that the use of the API in Maven requires 3.2.1+. [1]: http://takari.io/2014/03/25/incremental-build.html [2]: https://github.com/takari/io.takari.incrementalbuild [3]: https://github.com/takari/io.takari.incrementalbuild/tree/master/incrementalbuild/src/test/java/io/takari/incremental/demo Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - 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
Re: [CHANGES PLUGIN] 'webUser' is ignored for JIRA report
Hi,
Please try the latest 2.10-SNAPSHOT version of the plugin.
It has a fix for an issue that sounds similar to yours.
On Mon, Mar 24, 2014 at 10:11 AM, Behrooz N wrote:
> Hello,
>
> I want to generate a JIRA report using Changes Plugin. I've managed to
> re-produce a situation which is contradictory:
>
>1. I use Maven and POM to generate the JIRA report.
>2. I checkout 2.9 source and use a JUnit test class to verify.
>
> In case (1), the following Maven configuration is used:
>
>
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.9
>
> true
> true
> Closed,Resolved
> USER
> PASS
>
>
>
>
>
> Then using mvn -X changes:jira-report, I get the following:
>
> ---
> ID: 2
> Address: https://MYJIRA.COM/issuetracker/rest/api/2/status
> Http-Method: GET
> Content-Type: */*
> Headers: {Accept=[application/json], Content-Type=[*/*]}
> --
> [DEBUG] Accept: application/json
> [DEBUG] Content-Type: */*
> [DEBUG] No Trust Decider for Conduit
> '{https://MYJIRA.COM/issuetracker}WebClient.http-conduit'. An
> afirmative Trust Decision is assumed.
> [DEBUG] Response Code: 200 Conduit:
> {https://MYJIRA.COM/issuetracker}WebClient.http-conduit
> [DEBUG] Content length: -1
> [DEBUG] Header fields:
> null: [HTTP/1.1 200 OK]
> Transfer-Encoding: [chunked]
> Date: [Mon, 24 Mar 2014 08:23:14 GMT]
> Keep-Alive: [timeout=15, max=99]
> Via: [1.1 MYJIRA.COM]
> Set-Cookie:
> [atlassian.xsrf.token=AMUY-0X4J-KTOA-WYA4|faf5142cf78de245e3573fc6cd122b41d1a0fe8e|lout;
> Path=/issuetracker]
> Connection: [Keep-Alive]
> Content-Type: [application/json;charset=UTF-8]
> X-AUSERNAME: [anonymous]
> X-AREQUESTID: [563x130866x1]
> Server: [Apache-Coyote/1.1]
> Cache-Control: [no-cache, no-store, no-transform]
>
> [DEBUG] Adding interceptor
> org.apache.cxf.interceptor.LoggingInInterceptor@5af3a14 to phase
> receive
> [DEBUG] Chain org.apache.cxf.phase.PhaseInterceptorChain@574e6595 was
> created. Current flow:
> receive [LoggingInInterceptor]
>
> [DEBUG] Invoking handleMessage on interceptor
> org.apache.cxf.interceptor.LoggingInInterceptor@5af3a14
> [INFO] Inbound Message
>
> ID: 2
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: {Cache-Control=[no-cache, no-store, no-transform],
> connection=[Keep-Alive],
> content-type=[application/json;charset=UTF-8], Date=[Mon, 24 Mar 2014
> 08:23:14 GMT], Keep-Alive=[timeout=15, max=99],
> Server=[Apache-Coyote/1.1],
> Set-Cookie=[atlassian.xsrf.token=AMUY-0X4J-KTOA-WYA4|faf5142cf78de245e3573fc6cd122b41d1a0fe8e|lout;
> Path=/issuetracker], transfer-encoding=[chunked], Via=[1.1
> MYJIRA.COM], X-AREQUESTID=[563x130866x1], X-AUSERNAME=[anonymous]}
> Payload: []
>
> In the above note that HTTPS is used, result Payload is empty and "webUser"
> is *ignored* (as anonymous) and Authorization Header is missing.
> Additionally, Maven ends with the following exception which makes sense
> based on the code:
>
> org.apache.maven.plugin.MojoFailureException: Could not find status Closed.
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:276)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:253)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:210)
> at
> org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:128)
> at
> org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
> at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
>
> In case (2), the source for the plugin version 2.9 is checked out. A simple
> unit test is written to simulate the same configuration:
>
> RestJiraDownloader d = new RestJiraDownloader();
> Log log = new DefaultLog(new ConsoleLogger(Logger.LEVEL_DEBUG,
> "test"));
> d.setLog(log);
> d.project = new MavenProject();
> d.project.setIssueManagement(new IssueManagement());
> d.project.getIssueManagement().setUrl(
> "https://MYJIRA.COM/issuetracker/browse/CSP";);
> d.project.getIssueManagement().setSystem("JIRA");
> d.setWebUser("USER");
> d.setWebPassword("PASS");
> d.setUseJql(true);
> d.setStatusIds("Resolved,Closed");
>
> Map params = JiraHelper
> .getJiraUrlAndProjectName(d.project.getIssueManagement()
> .getUrl());
> String jiraUrl = params.get("url");
> String pro
Re: Model Version 5.0.0
On Tue, Mar 25, 2014 at 8:55 AM, Baptiste Mathus wrote: > FWIW, I'm aware it's easily feasible to add that checksum validation in a > plugin, but you'll still have to repeat the coordinates. > And that very thing was my point: I don't think having to repeat those > coordinates to add metadata is great. > > Not even saying this *must* go in modelVersion 5, I just wanted that debate > to happen at least for future reference if people wonder why maven pom > can't store that dependency metadata (DRY'ly alongside its data, I mean). > > There's all sorts of other per-dependency information that would be useful, for example - flex applications needing to store RSL deployment paths and policy file urls. The 'maven way' seems to be sentenced to perennially repeat yourself, and live with the fact your plugin config and your dependency list can drift out of sync. Or to suffer some kind of excuse of 'just specify the dependencies you want to apply this metadata to with some kind of regular expression (!)'. XML even has a well-understood extension mechanism for this kind of thing. ... com.woo yay 1.0 /blah/blah /woo/policy.xml /// some plugin that enforces security:sha1 etc etc etc If your tooling doesn't understand namespaced nodes, it's trivial to strip them.
Re: Model Version 5.0.0
Nahh.. you misinterpret what I am saying (probably a fault of my communication)... when it is not a day I have taken as vacation time I will explain in more detail On 25 March 2014 08:55, Baptiste Mathus wrote: > FWIW, I'm aware it's easily feasible to add that checksum validation in a > plugin, but you'll still have to repeat the coordinates. > And that very thing was my point: I don't think having to repeat those > coordinates to add metadata is great. > > Not even saying this *must* go in modelVersion 5, I just wanted that debate > to happen at least for future reference if people wonder why maven pom > can't store that dependency metadata (DRY'ly alongside its data, I mean). > > Cheers > > > 2014-03-25 6:36 GMT+01:00 Dominik Bartholdi : > > > > > For this, there is already an enforcer rule available: > > https://github.com/gary-rowe/BitcoinjEnforcerRules > > Domi > > > > On 24.03.2014, at 20:31, Martijn Dashorst > > wrote: > > > > > On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > >> I see the checksums then as being another potential side artifact... > No > > >> need for modelVersion 5.0.0 > > >> > > > > > > I see it differently: the checksum validates the GAV coordinates. "I > mean > > > 'com.example.foo:foo:1.0', specifically verify that it matches this > > > signature 'sha1:1234567890abcdef'. > > > > > > For example, this enables me to check if a different version of an > > artefact > > > was uploaded to the same GAV than I expected (and reportedly the > original > > > author too). > > > > > > A plugin right now could capture them and deploy to repo, and you could > > >> have same plugin verify the resolved dependencies against the same > file. > > >> > > > > > > This assumes the whole chain of parties is to be trusted. That nobody > > will > > > try to side-load a version from a different repository. > > > > > > I find the idea of adding a checksum to a dependency interesting. > While I > > > don't care for the extra fields in the POM, it opens a better venue of > > > vetting the dependencies. > > > > > > Martijn > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! >
Re: Model Version 5.0.0
FWIW, I'm aware it's easily feasible to add that checksum validation in a plugin, but you'll still have to repeat the coordinates. And that very thing was my point: I don't think having to repeat those coordinates to add metadata is great. Not even saying this *must* go in modelVersion 5, I just wanted that debate to happen at least for future reference if people wonder why maven pom can't store that dependency metadata (DRY'ly alongside its data, I mean). Cheers 2014-03-25 6:36 GMT+01:00 Dominik Bartholdi : > > For this, there is already an enforcer rule available: > https://github.com/gary-rowe/BitcoinjEnforcerRules > Domi > > On 24.03.2014, at 20:31, Martijn Dashorst > wrote: > > > On Mon, Mar 24, 2014 at 8:06 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > >> I see the checksums then as being another potential side artifact... No > >> need for modelVersion 5.0.0 > >> > > > > I see it differently: the checksum validates the GAV coordinates. "I mean > > 'com.example.foo:foo:1.0', specifically verify that it matches this > > signature 'sha1:1234567890abcdef'. > > > > For example, this enables me to check if a different version of an > artefact > > was uploaded to the same GAV than I expected (and reportedly the original > > author too). > > > > A plugin right now could capture them and deploy to repo, and you could > >> have same plugin verify the resolved dependencies against the same file. > >> > > > > This assumes the whole chain of parties is to be trusted. That nobody > will > > try to side-load a version from a different repository. > > > > I find the idea of adding a checksum to a dependency interesting. While I > > don't care for the extra fields in the POM, it opens a better venue of > > vetting the dependencies. > > > > Martijn > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
