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 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? 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? 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] > -- Ioan Eugen Stan / CTO / http://axemblr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
