Hi, On Sun, Dec 23, 2012 at 2:44 PM, Eric Charles <[email protected]> wrote: > > > On 23/12/2012 13:20, Ioan Eugen Stan wrote: >> >> Hello, >> >> >> On Sun, Dec 23, 2012 at 12:50 PM, Eric Charles <[email protected]> wrote: >>> >>> Hi Ioan, >>> >>> >>> On 22/12/2012 15:49, Ioan Eugen Stan wrote: >>>> >>>> >>>> Hello, >>>> >>>> On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <[email protected]> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I try to build trunk and get now Failed to execute goal >>>>> org.apache.rat:apache-rat-plugin:0.8:check (default) on project >>>>> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1] >>>> >>>> >>>> >>>> Eric, please try and build the project again and see what it's causing >>>> RAT plugin to fail. I have a hunch that there are some files generated >>>> by your IDE that cause it to fail. Look at target/rat.txt for the >>>> cause. >>>> >>> >>> I build with CLI (not IDE). >>> Rat is not happy with the .settings folder in apache-mailet-ai. >>> >>> I tried to configure the exclusions in the parent, also tried to define >>> the >>> rat plugin on the apache-mailet-ai itself, without success... >>> >>> I think it's a matter of folder depth (apache-mailet-ai is one more depth >>> than the others). >>> >> >> You cna configure RAT in the parent with Ant style wildcards. For >> example, to ignore all iml files at any depth use: >> <exclude>**/*.iml</exclude> . I hope you won't need to >> escape the dot in the case of '.settings'. Rat needs to be improved so >> it will ignore some common IDE files. >> > > I tried to tune them without success... > > I triggered a manual build on jenkins and it does not give the exception. > https://builds.apache.org/view/G-L/view/James/job/james-mailet/1908/ > > Do you see it on your PC? > I had RAT no issue before the changes and changed nothing in my env. >
I have no issues with RAT. I think you're missing something small or there is a bug somewhere. Try deleting the offending files. >>>>> I see also mailet packages changes. Are the other projects updated to >>>>> take this into account? If the projects rely on a release, this has no >>>>> impact for now, but do you plan to migrate them. If we don't do it now, >>>>> there is a high risk to desynchronize code. The more we wait, the more >>>>> difficult it will be. >>>> >>>> >>>> >>>> I've looked at james-server and it depends on release versions, except >>>> for mailet-base which is SNAPSHOT. >>> >>> >>> >>> Let's keep in mind we need to impact james-server before or after the >>> mailet >>> release >> >> >> Yes, it is a good point. I wish to cut a release soon. It's long over >> due and now we have good OSGi headers and more consistent packages. >> >>> >>>> I'm looking into starting the release process. It will take some time >>>> as we need release them individually because of the dependencies. >>>> >>> >>> Why don't we release all mailet at the same time and align all the >>> version >>> to the same number? It will be easier for the release and also to impact >>> james-server. >> >> >> I thought about that, it's good that you brought it up. I like the >> idea, but wouldn't that be a problem when we need to provide patch >> releases: release all mailets under the new version even though we >> changed only Crypto mailet for example? If we do this we would send >> the message that people should upgrade even though nothing changed. >> And this is wrong. Did I answer your question correctly? >> > > Yes, this is the well-known never-ending debate... > I can agree with you, but I find we are a too little team to seek > perfection. Also, when I see e.g. Apache Camel with has a single release > scheme all its various components, I think we can also do it... Agree. I was just looking at jclouds and they have a similar policy for all their artifacts. I think we can use a consistent version for all our libraries. I'll raise an issue for this and fix it, then go on with the release. The new version should be 2.5.0 for all artifacts. > >> With regard to james-server, we can upgrade it to the new versions >> after the release. Ideally we should have some tests that ensure >> things will work the same but I hope we can skip that now and make it >> better in the future. >> >> With regard to the release process, do you have some time to talk me >> through it? >> > > All is documented on > http://www.apache.org/dev/publishing-maven-artifacts.html. If it doesn't > work fine, just ping back. Thanks, > Thx, Eric > > > >> Cheers, >> >>> >>>> Cheers, >>>> >>>>> A good think would be to upgrade the other project to the current >>>>> mailet >>>>> snapshot and update them to reflect the repackaging. >>>>> >>>>> Thx, Eric >>>>> >>>>> On 16/12/2012 00:37, Ioan Eugen Stan wrote: >>>>>> >>>>>> >>>>>> Hi again, >>>>>> >>>>>> Did some work on a private branch [0] for [1]. I moved all site >>>>>> related stuff under apache-mailet-aggregator which builds last so we >>>>>> can aggregate javadocs and other stuff at the end. >>>>>> >>>>>> Please review [0]. >>>>>> >>>>>> Right now I wish to stage the new mailet site and see how it performs. >>>>>> I think there are a few bad links over there. >>>>>> Please help with the staging. >>>>>> >>>>>> The main idea is to have all documentation in one place instead of >>>>>> being spread across the project. This should make things easy to track >>>>>> and consistent. >>>>>> >>>>>> [0] https://github.com/ieugen/james-mailet/tree/single-site >>>>>> [1] https://issues.apache.org/jira/browse/MAILET-43 >>>>>> >>>>>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan >>>>>> <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> INFRA moved and deleted the project. >>>>>>> >>>>>>> În data de 15.12.2012 14:25, "Eric Charles" <[email protected]> a >>>>>>> scris: >>>>>>> >>>>>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I just moved all of the issues to MAILET except for Mailet AI for >>>>>>>>> which >>>>>>>>> I >>>>>>>>> don't have kharma. I also raised INFRA-5660. >>>>>>>>> >>>>>>>>> Eric, could you move Mailet AI? >>>>>>>>> >>>>>>>> >>>>>>>> Seems like Mailet AI is deleted. >>>>>>>> I don't see it anymore as a user nor as an administrator. >>>>>>>> Thx, >>>>>>>> Eric >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan" >>>>>>>>> <[email protected]> a >>>>>>>>> scris: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> After the response on INFRA it looks like move + delete is an >>>>>>>>>> option. >>>>>>>>>> I am going move issues this week-end + ticket on infra to delete >>>>>>>>>> obsolete projects. Eric, is that ok with you? >>>>>>>>>> >>>>>>>>>> I personally enjoy a clean working place. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan >>>>>>>>>> <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hello Eric, >>>>>>>>>>> >>>>>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've analyzed the situation a bit. Here's a summary. >>>>>>>>>>>>> >>>>>>>>>>>>> Total number of issues per project - total issues (including >>>>>>>>>>>>> open) / >>>>>>>>>>>>> open issues. >>>>>>>>>>>>> >>>>>>>>>>>>> James Basic Mailet Toolkit - MAILETBASE 7 Issues / 0 open >>>>>>>>>>>>> James Crytography Mailets - MAILETCRYPTO 9 Issues / 0 open >>>>>>>>>>>>> James Mailet - MAILET 46 Issues -- not applicable >>>>>>>>>>>>> James Mailets Standard - MAILETSTANDARD 13 Issues / 5 open >>>>>>>>>>>>> James MailetDocs Maven Plugin - MAILETDOCS 7 Issues / 3 open >>>>>>>>>>>>> James Ai Mailets - JAMESMAILAI 2 issues / 1 open >>>>>>>>>>>>> >>>>>>>>>>>>> We have a total of 9 open issues. spread over the 5 projects we >>>>>>>>>>>>> wish >>>>>>>>>>>>> to close. We would make history confusing for 38-9= 29 issues >>>>>>>>>>>>> if >>>>>>>>>>>>> we >>>>>>>>>>>>> move + delete jira projects. I personally think it's reasonable >>>>>>>>>>>>> for >>>>>>>>>>>>> people to do a bit of extra work if they wish to find out more >>>>>>>>>>>>> about >>>>>>>>>>>>> the issues related to each commit. Another argument is that >>>>>>>>>>>>> those >>>>>>>>>>>>> issues are not that important so people will probably never >>>>>>>>>>>>> search/get >>>>>>>>>>>>> to them. >>>>>>>>>>>>> >>>>>>>>>>>>> Considering this, my recommendation is to Move+Archive >>>>>>>>>>>>> ('Hiding'). I >>>>>>>>>>>>> believe keeping all those projects will be more confusing than >>>>>>>>>>>>> useful >>>>>>>>>>>>> on the long turn. >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to make Basic Mailets Read-only following [2] but I >>>>>>>>>>>>> don't >>>>>>>>>>>>> have >>>>>>>>>>>>> enough rights to change the Permissions. Eric do you have >>>>>>>>>>>>> permissions >>>>>>>>>>>>> to make the project Read-Only/ Archive them? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I also read this morning [2] (which is not an apache page) but I >>>>>>>>>>>> also >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> had >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> not the rights to do anything. I think those settings are in the >>>>>>>>>>>> hands >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> of >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> apache infra and the goal is not to give delegation to the >>>>>>>>>>>> projects >>>>>>>>>>>> on >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> that >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> level. >>>>>>>>>>>> >>>>>>>>>>>> Closing a jira project is just like opening one: it's infra >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> responsibility I >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> think. >>>>>>>>>>>> >>>>>>>>>>>> But once again, I simply don't like the idea of losing any >>>>>>>>>>>> historical >>>>>>>>>>>> information and I expect infra will ask you why you want to do >>>>>>>>>>>> this. >>>>>>>>>>>> Even retired projects (in the attic) are still accessible on >>>>>>>>>>>> JIRA. >>>>>>>>>>>> >>>>>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new >>>>>>>>>>>> JIRA >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> project >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (with a comment on the old ones to redirect to the new ones). >>>>>>>>>>>> >>>>>>>>>>>> But unless someone pops-up here, it's all in your hand. >>>>>>>>>>>> >>>>>>>>>>>> To make this information available, please simply announce it in >>>>>>>>>>>> a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> separate >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> everyone is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> well informed on what's going on. >>>>>>>>>>>> >>>>>>>>>>>> Thx, Eric >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'll ask on infra about the best course of action. I'll CC you in >>>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> mail. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I think simple is better. What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://confluence.atlassian.com/display/JIRA/Moving+an+Issue >>>>>>>>>>>>> [2] >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://confluence.atlassian.com/display/JIRA/Archiving+a+Project#ArchivingaProject-'Hiding'aproject >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thx, Eric >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/MAILET-41 >>>>>>>>>>>>>>> [2] http://wiki.apache.org/general/Jenkins >>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/MAILET-44 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> 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] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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] >>> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Ioan Eugen Stan / CTO / http://axemblr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
