Re: IvyDE JIRA issues and changes for proposed release?
> Le 14 juin 2017 à 05:22, J Pai a écrit : > > There’s been some good progress on reviving the Ivy project (thanks Nicolas > and Jan for helping out with the reviews and merging PRs) and we seem to be > moving towards a state where the release is a possibility. The other project > IvyDE (the Eclipse plugin) however needs a bit more push I think. > > I am not a Eclipse user nor do I have any experience with plugin development, > so there’s not much I can contribute on that front. However, there has been > an external community member whose team(?) seemed to be interested in > contributing to that plugin and in fact seem to have built some features on > top of the current state of the plugin, in their own fork. They even proposed > the contribution on the mailing list[1]. I suggested they raise a PR (to make > it easier for review), but haven’t heard back. Given that and things in > general, do we have someone who has experience of the code base plus Eclipse > plugins who can help review that code? Furthermore, is there anything else > the user has to do (like signing some CLA) for that contribution? For a patch, due to its form, sending to the community a request for change, it is implied that it is a donation to the ASF with proper copyrights, so it is OK. I might be an issue if a contribution is only declared to be elsewhere (« look at my branch on github»). Sending a patch via email, jira or a PR is considered OK. And the CLA is mainly for the people directly contributing. > I think in general, do we have someone experienced with the plugin who can > look at some of the IvyDE open JIRA issues/enhancements and decide which ones > to fix in the upcoming release and make sure things work fine with the > proposed Ivy release itself? As for Ivy, I am volunteering to apply patches. For what to release, when, how, I am relying on the community to drive it. There is one topic that I will probably push though, on both Ivy and IvyDE; and the site: migrating to asciidoc. The migration I have wrote took me some time and is a kind of big hack. So the sooner the migration will be done, the sooner contributing documentation will be easier. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: IVYDE-382 proposed patch
Hi, For some reason git apply was refusing to process the patch and was just returning an error: corrupt patch at line 1964 So I played with git commands and work with the sources available on github. I have create a branch on the ASF repo, ivyDECredentials, which has one commit which squash all the forked commit on github. I have then created another branch, ivyDECredentials-cleaned, which rebase the work, remove unnecessary changes like the readme file, and did some file formatting. Now it needs some review and testing in order to be merged. I’ll take time to do it but if somebody else if wants to help, another pair of eyes on this is very welcomed. Also would be welcomed some documentation about this new feature. The IvyDE doc is quite complete, it would be really nice to keep it at this level. Nicolas > Le 14 juin 2017 à 05:18, J Pai a écrit : > > Hi Alexander, > > I actually just realized that your initial mail actually had a patch file > attached. I didn’t notice that before and only today noticed it while looking > at the mail list archive. So assuming this applies cleanly on latest master > branch of IvyDE, I think this should be fine too, instead of creating a PR. I > am not experienced with Eclipse plugins, so I personally won’t be able to > help much, but hopefully someone from the IvyDE team will be able to review > and decide about this patch. Thank you again for contributing this. > > -Jaikiran > On 26-May-2017, at 8:28 AM, J Pai wrote: > > Hi Alexander, > > Thank you for volunteering to provide this feature patch. I had a look a the > repo you pointed to and read the README. It does seem to contain a good > amount of work in that branch in multiple commits. > > To make it easier for whoever will decide about merging these to upstream > ant-ivyde project, would it to be possible for you to do the following: > > 1. *Fork* the ant-ivyde project (on github) > https://github.com/apache/ant-ivyde/ into your account. There’s a “Fork” > button on the right corner of the github page for the repo. > 2. Once forked into your account, you can push your enhancement and bug fix > related commits to either your master branch of your repo or any specific > branch of your choice. > - If the bug fixes are independent of the feature, then it would be > good if they are done in separate branches, so that a separate pull request > (PR) can be issued. > 3. Once you are ready with the commits, you can then issue a pull request > (PR) from your repo to the “master” branch of the ant-ivyde upstream repo > https://github.com/apache/ant-ivyde/. Typically PRs are meant to contain > commits that are all specific to a single feature or for a specific bug fix. > > Once the PRs are submitted, I’m sure one or more members of the development > team who have relevant knowledge of Eclipse and the project will review this > and either merge it or provide inputs. > > Thanks again for this, both Ivy and IvyDE project has been stagnant for a > while and with contributions like these, we should be able to release out a > new version soon. > > -Jaikiran > > > On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote: > > Dear Sir or Madam, > > as it was suggested in > https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847, > we are sending you our proposed patch for > https://issues.apache.org/jira/browse/IVYDE-382. The corresponding patch-file > is attached to this email. The source code is available at > https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the branch > "ivyDECredentials". > > Yours sincerely, > > Alexander Blaas > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Compress Antlib 1.5 based on RC3
I generally import each project's KEYS file, and having been to a key signing party before at ApacheCon, I have a small web of trust to help verify those signatures. The more people sign each other's keys, the easier it is to verify. On 14 June 2017 at 02:59, Jan Matèrne (jhm) wrote: > My first thought was 'I want to have all the stuff inside the distro.' > That means also the ASC. > But having the ASC inside the distro means letting the key on the lock ... > > So the 2nd thought was: how to verify the download? > - download > - hashvalue checksum > - pgp check > We could provide a howto file in the distro, but we also could provide a > build snippet for automating that. > a) provide the snippet via website and define an Ant property which > artifact to get > b) provide the snippet inside the distro and will only do the two checks > (getting the checksums directly from the ASF server) > > > Jan > > > > -Ursprüngliche Nachricht- > > Von: Stefan Bodewig [mailto:bode...@apache.org] > > Gesendet: Mittwoch, 14. Juni 2017 09:17 > > An: dev@ant.apache.org > > Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC3 > > > > On 2017-06-13, Jan Matèrne (jhm) wrote: > > > > >> Should we include the PGP [e.g. 1] signature in the future? > > > > > Answer myself: should be only on ASF server, so people could trust > > > that ;) Maybe place a note (next time) how to check that (do we have > > a > > > build snippet for that?) > > > > I'm not exactly sure what you mean. > > > > Should I have included the PGP signature of any of the artifacts inside > > of the vote email? > > > > The vote email I've sent may have been a bit terse and I'm happy to > > improve on it. > > > > Stefan > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker
[GitHub] ant-ivy issue #43: Generics and related fixes in tests and tutorials
Github user janmaterne commented on the issue: https://github.com/apache/ant-ivy/pull/43 Merged that, thanks. Hint for future PRs: smaller are better (easier to review) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy pull request #43: Generics and related fixes in tests and tutorials
Github user asfgit closed the pull request at: https://github.com/apache/ant-ivy/pull/43 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #43: Generics and related fixes in tests and tutorials
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/43 I mean, why use an NPE when one can have an assertion that fails? It's a cleaner approach. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #43: Generics and related fixes in tests and tutorials
Github user twogee commented on the issue: https://github.com/apache/ant-ivy/pull/43 That's exactly why I introduced assertNotNull :-) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-ivy issue #43: Generics and related fixes in tests and tutorials
Github user janmaterne commented on the issue: https://github.com/apache/ant-ivy/pull/43 Nop ... yes. You're right with 'null instanceof SomeClass'==true. But the two assertions are different: moduleId = null; assertFalse(moduleId.equals(null);; --> this will throw a NullPointerException --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: [VOTE] Release Compress Antlib 1.5 based on RC3
My first thought was 'I want to have all the stuff inside the distro.' That means also the ASC. But having the ASC inside the distro means letting the key on the lock ... So the 2nd thought was: how to verify the download? - download - hashvalue checksum - pgp check We could provide a howto file in the distro, but we also could provide a build snippet for automating that. a) provide the snippet via website and define an Ant property which artifact to get b) provide the snippet inside the distro and will only do the two checks (getting the checksums directly from the ASF server) Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:bode...@apache.org] > Gesendet: Mittwoch, 14. Juni 2017 09:17 > An: dev@ant.apache.org > Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC3 > > On 2017-06-13, Jan Matèrne (jhm) wrote: > > >> Should we include the PGP [e.g. 1] signature in the future? > > > Answer myself: should be only on ASF server, so people could trust > > that ;) Maybe place a note (next time) how to check that (do we have > a > > build snippet for that?) > > I'm not exactly sure what you mean. > > Should I have included the PGP signature of any of the artifacts inside > of the vote email? > > The vote email I've sent may have been a bit terse and I'm happy to > improve on it. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Compress Antlib 1.5 based on RC3
On 2017-06-13, Jan Matèrne (jhm) wrote: >> Should we include the PGP [e.g. 1] signature in the future? > Answer myself: should be only on ASF server, so people could trust that ;) > Maybe place a note (next time) how to check that (do we have a build snippet > for that?) I'm not exactly sure what you mean. Should I have included the PGP signature of any of the artifacts inside of the vote email? The vote email I've sent may have been a bit terse and I'm happy to improve on it. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
