Hi Eric, Dhrubo Thanks for the support. We can do with a vote but this will slow things down. I guess I can work on code until the vote ends.
On Sun, Dec 2, 2012 at 2:45 PM, Eric Charles <[email protected]> wrote: > Big +1 on all your proposals > > - I would simply use 'all' instead of 'aggregator', I like 3 letters I'll keep aggregator, hope you don't mind > - I prefer <current-name> (not mailets-<current-name>), simpler. ok > - Are you meaning having a single site for all mailets? (I'm fine with > this). yes - too much overhead with managing a site for each component, we should do the same for the other projects. If it was my decision I would create just one site as the fragmentation is a killer. Right now we have way too many components for the number of developers. This also creates a lot of overhead. This is how I feel and see things, I don't know if you share my thought on this. > As this implies many changes, it would be best to start a vote (ACK with > lazy consensus) open for 3 days before committing. Will send right away. I'll copy all the things I mentioned in the previous email. Cheers, > Thx, > > Eric > > > > On 02/12/2012 10:57, Ioan Eugen Stan wrote: >> >> Hi Eric, >> >> Please see inline. >> >> On Sat, Dec 1, 2012 at 8:49 AM, Eric Charles <[email protected]> wrote: >>> >>> Hi Ioan, >>> >>> I have updated the current externals and the hudson build. >>> Can you check to update or even disable GUMP (see mail sent to >>> mailet-api, >>> GUMP is a continuous integration system used before hudson). >> >> >> I have no idea where is the configuration for gump so I don't know how >> to disable it. Asked on asfinfra IRC but no answer. Docs are also >> shallow so any help is appreciated - I noticed your email about the >> subject. >> >>> For the naming, just post here the list of names/versions you think to >>> change so we can all review them and identify the impact. >> >> >> New directory structure: >> >> --mailets -- contains aggregator pom >> + - ai >> | \- classic-ai >> + - base >> + - crypo >> + - maven-mailetdocs-plugin >> + - parent >> + - site >> + - standard >> >> New project names: >> >> Apache James :: Mailets Parent .................... SUCCESS [3.814s] >> Apache James :: Mailet API ........................ SUCCESS [0.200s] >> Apache James :: Basic Mailet Toolkit .............. SUCCESS [0.184s] >> Apache James :: Mailetdocs Maven Plugin ........... SUCCESS [2.274s] >> Apache James :: Crypto Mailets .................... SUCCESS [0.168s] >> Apache James :: Standard Mailets .................. SUCCESS [0.307s] >> Apache James :: AI Mailets ........................ SUCCESS [0.017s] >> Apache James :: Classic AI Mailets ................ SUCCESS [0.189s] >> Apache James :: Mailets Aggregator ................ SUCCESS [0.019s] >> >> New artifactId's and versions: >> >> ** all have groupId org.apache.james >> >> apache-james-ai-project-0.1-SNAPSHOT -> apache-mailets-ai-0.0.1-SNAPSHOT >> >> apache-james-ai-classic-0.1-SNAPSHOT -> >> apache-mailets-ai-classic-0.0.1-SNAPSHOT >> >> mailet-project-1-SNAPSHOT -> apache-mailets-0.0.1-SNAPSHOT (this is >> parent -- will contain all mailet specific project info and depend on >> james-project-1.8.1 -> all other mailets will depend on >> apache-mailets) >> >> apache-mailet-2.5-SNAPSHOT -> apache-mailets-api-2.5.0-SNAPSHOT >> >> apache-mailet-base-1.2-SNAPSHOT -> apache-mailets-base-1.2.0-SNAPHSOT >> >> apache-crypto-mailets-1.1-SNAPSHOT -> apache-mailets-crypto-1.1.0-SNAPSHOT >> >> maven-mailetdocs-lugin-0.2-SNAPSHOT -> changed version to 0.0.2-SNAPSHOT >> >> mailet-project-1.0-SNAPSHOT -> apache-mailets-aggregator-0.01-SNAPSHOT >> >> All chages are available as a github commit [1]. >> >> Further proposed changes TBD - will go on JIRA: >> >> * change directory names to mailets-<current-name> (not strong opinion) >> * clean-up 1: agggregate all project info, dependencies and other >> stuff to parent apache-mailets and remove duplication -- A MUST DO >> * move site related content under site -- A MUST DO IMHO >> * aggregate JIRA tracking under the same project - going through the >> project I noticed each mailet has it's own JIRA project, mailinglist, >> etc. I think it's a lot of overhead and not worth it. The community is >> not that big. I also think less is more. -- also a MUST DO IMHO >> * move code to java 1.6 (which will be end-of-life in spring 2013) - >> like all other James code >> * make a release and publish site >> >> [1] >> https://github.com/ieugen/james-mailets/commit/ee5658441803bac5a544bd2f424ae5e7226fd406 >> >>> Thx again, >>> >>> Eric >>> >>> >>> >>> On 01/12/2012 01:41, Ioan Eugen Stan wrote: >>>> >>>> >>>> Hello Eric, >>>> >>>> Please read inline, >>>> >>>> On Fri, Nov 30, 2012 at 12:44 PM, Eric Charles <[email protected]> wrote: >>>>> >>>>> >>>>> (see inline) >>>>> >>>>> >>>>> On 30/11/2012 10:27, Ioan Eugen Stan wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 30, 2012 at 8:29 AM, Eric Charles <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +1 on the idea to put mailets together, but yes, we need to take care >>>>>>> to >>>>>>> not >>>>>>> loose the tags/branches. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Great! I can move them in place under james/mailets/trunk. There are >>>>>> no branches, just a few tags. I don't have a solution to tags so I >>>>>> expect some help. From what I know, they are shallow references to >>>>>> certain commits. Not sure if they will work if I move them under >>>>>> james/mailets/tags . >>>>>> >>>>> >>>>> SVN folders in tags are simply a copy of another folder. You could call >>>>> tag >>>>> and branch 'foo' and 'bar', it would be the same. It's simply a naming >>>>> conventions. >>>>> >>>>> 'svn mv ... ...' should do the work, although I have never moved >>>>> tags/branches. Double check with another src :) >>>> >>>> >>>> >>>> It worked like a charm, thanks. >>>> >>>>> >>>>>>> I guess using a few carefull "svn mv fromUrl toUrl" can do the job >>>>>>> (no >>>>>>> need >>>>>>> for new commit/recommmit). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Yep, thanks. >>>>>> >>>>>>> About the naming, I would love to have consisten naming. For now, we >>>>>>> have >>>>>>> some mailet-aggregator, mailbox-project vs apache-crypto-mailets... >>>>>>> >>>>>>> I (re)open here the door to another discussion which is the naming >>>>>>> conventions of our artifcats... Regarding the mailets, I would >>>>>>> suggest >>>>>>> at >>>>>>> least to name the new top pom "apache-mailets" to be more consistent >>>>>>> with >>>>>>> the rest. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Agree, I would also like to update the versioning schema and go with >>>>>> http://semver.org/ , which I think is also ok with regard to OSGi. >>>>>> I think I can do them over the weekend and go with a release sometimes >>>>>> next week with the new project structure, artifact names and versions. >>>>>> >>>> >>>> New directory structure is available at [1], I'm waiting for the git >>>> mirror as requeste by me to infra. All our repos will then have git >>>> mirrors. >>>> >>>> [1] http://svn.apache.org/repos/asf/james/mailet/ >>>> >>>>> Cool. Before committing, please post here your naming proposal so >>>>> everyone >>>>> has time to commment and review. Naming and structure are always >>>>> sensible >>>>> topics. >>>> >>>> >>>> >>>> I would like to rename maven artifacts so they are more consistent. >>>> Don't have a strong preference but I like groupId: >>>> org.apache.james.mailets like the protocols groupId. I don't have a >>>> strong opinion on this, so I'm ready to drop in case of complaints. >>>> >>>> With regard to artifactId, I'm going with apache-mailets for the >>>> parent pom (where we will define all the properties and dependency >>>> management for mailets). apache-mailets-aggregator will aggregate all >>>> the projects. >>>> >>>> apache-mailets will have apache-james-project as parent. All other >>>> mailet projects, including apache-mailets-aggregator, will be children >>>> of apache-mailets. >>>> >>>> As for the version changes, I plan to add numbers and dots so they >>>> look like X.Y.Z. For example, apache-james-ai-project will have >>>> 0.0.1-SNAPSHOT instead of 0.1-SNAPSHOT. This is mainly to be >>>> consistent and so we don't create confusion in OSGi realm. >>>> >>>> Pull requests would be very nice but I think patches or github web >>>> reviews will have to do until we get the basics. >>>> >>>> Any help is appreciated, >>>> >>>>> Also, if you decide to change naming/packages/versions..., please also >>>>> add >>>>> in you todo: >>>>> - The impact on the other James components (pom, src...). >>>>> - The impact on the documentation (download page, mailet sites..) >>>>> >>>>> Thx again, >>>>> >>>>> Eric >>>>> >>>>> >>>>>>> Thx, Eric >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 29/11/2012 23:39, Ioan Eugen Stan wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hello devs, >>>>>>>> >>>>>>>> I wish to change the directory structure of the mailet project to be >>>>>>>> something similar to the mailbox project with all mailet components >>>>>>>> under the same roof. >>>>>>>> I think the current set-up is very bad for development since most of >>>>>>>> the components are linke together and should stay together. >>>>>>>> >>>>>>>> It should be very similar to the mailbox project structure where we >>>>>>>> have the api and implemnetations in the same folder. >>>>>>>> I made a quick mock-up that you can check out: >>>>>>>> https://github.com/ieugen/james-mailet-new >>>>>>>> >>>>>>>> It will also make git migration a lot easier since the whole project >>>>>>>> will require just one git repo, whereas in the current state we will >>>>>>>> need about 4. >>>>>>>> >>>>>>>> How should we do this with respect to the already available tags (a >>>>>>>> few). There are no branches. My Idea is to move the existing mailets >>>>>>>> project structure as a new commit under james/OLD and recommit all >>>>>>>> files with the new structure under james/mailets. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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]
