flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: AW: Re : Re: Splitting up flex-utilities (was Re: Where to put code examples?)
Date Sat, 25 Apr 2015 15:13:06 GMT
Hi Alex,

i think "flex-maven" would be enough and it will contain both the flex-maven-plugin and the
flex-sdk-converter. I guess the later will not get too much updates once it it released and
if it does, the flex-maven plugin will need adjustments anyway.

Chris

________________________________________
Von: Alex Harui <aharui@adobe.com>
Gesendet: Samstag, 25. April 2015 16:04
An: dev@flex.apache.org
Betreff: Re: AW: Re : Re: Splitting up flex-utilities (was Re: Where to put code examples?)

I wasn’t sure whether the two maven folders were going to have the same
release schedule or not.  Please propose the name of the repos as you
would like to see them.

Thanks,
-Alex

On 4/25/15, 3:13 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Have to admit when it comes to the maven projects, especially the
>flex-maven-plugin ... there is not much history ;-)
>But shouldn't it be possible to do this:
>http://stackoverflow.com/questions/359424/detach-subdirectory-into-separat
>e-git-repository
>
>But ... if the flex-maven-plugin is to get it's own repo ... even if the
>directory is called maven-flex-plugin, I have to change this to
>flex-maven-plugin as the Maven group only allows maven-{name}-plugin
>plugin for Apache Maven Plugins when interpreted as (Apache-Maven) Plugin
>and not Apache (Maven-Plugin) ;-)
>
>Chris
>
>________________________________________
>Von: Frédéric THOMAS <webdoublefx@hotmail.com>
>Gesendet: Samstag, 25. April 2015 11:13
>An: dev@flex.apache.org
>Betreff: Re : Re: Splitting up flex-utilities (was Re: Where to put code
>examples?)
>
>Hi,
>
>I like the idea, few remarks though.
>
>1- A general good practice is to have 1 project per repo, IMO the 2 maven
>projects should be able to live separatly.
>
>2- If infra cant separate and import the history per project, this repo
>can still be used for history.
>
>--- Message initial ---
>
>De : "Alex Harui" <aharui@adobe.com>
>Envoyé : 24 avril 2015 22:14
>A : dev@flex.apache.org
>Objet : Re: Splitting up flex-utilities (was Re: Where to put code
>examples?)
>
>Ok, so the proposal is:
>
>flex-utilities.git will keep the following (for now)
>ApacheFXG
>FXGTools
>MD5Checker
>MobileTrader
>CodeCoverage
>
>
>Then we should create more repos as follows:
>flex-installer.git:
>ant_on_air
>Common
>Installer
>installerBadge
>installerLocaleEditor
>
>
>flex-maven.git:
>Maven-flex-plugin
>Mavenizer
>
>
>flex-squiggly.git
>Squiggly
>
>
>flex-pmd.git
>FlexPMD
>
>
>flex-tdf.git
>TourDeFlex
>
>
>flex-tdf-mobile.git
>TourDeFlex Mobile (from flex-examples.git)
>
>
>
>
>I will update the Infra ticket on Tuesday if there are no objections.
>
>-Alex
>
>On 4/24/15, 2:02 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com> wrote:
>
>>On Apr 24, 2015 1:55 PM, "Alex Harui" <aharui@adobe.com> wrote:
>>>
>>> In the other thread you suggested that TDF and TDF Mobile go into the
>>>same
>>> repo.  I can add that to the Infra request, but a) I don’t know if it
>>> complicates the task (merging folders from two repos into a single
>>>repo)
>>> but also b) I thought a major motivation behind the split was so that
>>>when
>>> we merge from a develop branch to master, we don’t merge too much stuff
>>> that wasn’t released into master.  If TDF and TDF mobile have different
>>> release schedules, they should probably have their own repos.  Do they
>>> share a lot of code?
>>
>>They don't share any code.   I do see your concern regarding the merge
>>complexity.
>>
>>Let's just go with two separate repos, in that case.
>>
>>Thanks,
>>Om
>>
>>>
>>> -Alex
>>>
>>> On 4/24/15, 1:38 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com>
>>>wrote:
>>>
>>> >I don't think losing history is a major concern.  The history would be
>>> >there even if you delete the files.  I believe the concern is
>>transferring
>>> >history to the new repo.  I believe it is possible as well.
>>> >
>>> >I like your list and have no objections.
>>> >
>>> >(Replied in that other thread as well)
>>> >
>>> >Thanks,
>>> >Om
>>> >
>>> >On Fri, Apr 24, 2015 at 1:25 PM, Alex Harui <aharui@adobe.com> wrote:
>>> >
>>> >>
>>> >>
>>> >> On 4/24/15, 1:12 PM, "OmPrakash Muppirala" <bigosmallm@gmail.com>
>>wrote:
>>> >>
>>> >> >No objections.  I see flex-utilities as a incubator repo where we
>>>put
>>> >> >things initially.  When projects are ready to be released, ideally
>>they
>>> >> >should be moved over to their own repos before the first release.
>>> >>
>>> >> I’m not a git expert so I don’t know how easy it is to move a subset
>>>of
>>> >>a
>>> >> repo to another repo and not lose history.  IMO, if Infra has to do
>>>it,
>>> >>it
>>> >> is best for new code donations to land in a new repo of their own.
>>> >>
>>> >> Anyway, the link to the old thread is [1].  My proposal is copied
>>below:
>>> >>
>>> >> At the top-level is:
>>> >>
>>> >> ApacheFXG
>>> >> FlexPMD
>>> >> Squiggly
>>> >> Common
>>> >> installerLocaleEditor
>>> >> CodeCoverage
>>> >> MD5Checker
>>> >> TourDeFlex
>>> >> Installer
>>> >> maven-flex-plugin
>>> >> FXGTools
>>> >> MobileTrader
>>> >> ant_on_air
>>> >> installerBadge
>>> >> Mavenizer
>>> >>
>>> >>
>>> >> I would argue that we should leave the following in flex-utilities.
>>>I
>>> >> guess it sort of means that flex-utilities is for code that we don't
>>> >>have
>>> >> release plans for, but help us do other things like modify FXG
>>>files,
>>or
>>> >> check MD5s.  If we end up wanting to release something in
>>> >>flex-utilities,
>>> >> hopefully we can later move it to its own repo without losing
>>>history.
>>> >>
>>> >>
>>> >> ApacheFXG
>>> >> FXGTools
>>> >> MD5Checker
>>> >> MobileTrader
>>> >> CodeCoverage
>>> >>
>>> >>
>>> >> Then we should create more repos as follows:
>>> >> flex-installer.git:
>>> >> ant_on_air
>>> >> Common
>>> >> Installer
>>> >> installerBadge
>>> >> installerLocaleEditor
>>> >>
>>> >>
>>> >> flex-maven.git:
>>> >>
>>> >>
>>> >> Maven-flex-plugin
>>> >> Mavenizer
>>> >>
>>> >>
>>> >> flex-squiggly.git
>>> >> Squiggly
>>> >>
>>> >>
>>> >> flex-pmd.git
>>> >> FlexPMD
>>> >>
>>> >>
>>> >> flex-tdf.git
>>> >> TourDeFlex
>>> >>
>>> >> The thread died when Om wanted to move TDF into flex-examples and I
>>> >>asked
>>> >> him a question that never got answered.  Maybe we can pick up from
>>> >>there.
>>> >>
>>> >> -Alex
>>> >>
>>> >> [1] http://markmail.org/message/edii4ycwrj3pmor6
>>> >>
>>> >>
>>> >> >
>>> >> >Thanks,
>>> >> >Om
>>> >> >
>>> >> >On Fri, Apr 24, 2015 at 1:08 PM, Alex Harui <aharui@adobe.com>
>>>wrote:
>>> >> >
>>> >> >> I’d prefer #2 because some day we will agree on the plan
for
>>> >>splitting
>>> >> >>up
>>> >> >> flex-utilities into separate repos and it will be easier to
move
>>>and
>>> >> >> probably easier to package if if the examples are under
>>> >> >>maven-flex-plugin.
>>> >> >>  Right now, with flex-utilities being shared between releasable
>>> >> >>products,
>>> >> >> I think it would get messy if I put examples from some other
>>>thing
>>> >>like
>>> >> >> AntOnAir in the same folder.
>>> >> >>
>>> >> >> Anybody object to re-starting this discussion about splitting
up
>>> >> >> flex-utilities?
>>> >> >>
>>> >> >> -Alex
>>> >> >>
>>> >> >> On 4/24/15, 12:35 PM, "Christofer Dutz"
>>><christofer.dutz@c-ware.de>
>>> >> >>wrote:
>>> >> >>
>>> >> >> >Hi,
>>> >> >> >
>>> >> >> >
>>> >> >> >as I am currently writing the Flex Maven tutorials, I would
also
>>> >>like
>>> >> >>to
>>> >> >> >prepare some sample projects that demonstrate what I'm
writing
>>> >>about.
>>> >> >> >
>>> >> >> >
>>> >> >> >What do you thing where I should put these sample projects?
>>> >> >> >
>>> >> >> >-    flex-utilities/examples
>>> >> >> >
>>> >> >> >-    flex-utilities/maven-flex-plugin/examples (should
rename
>>>this
>>> >>to
>>> >> >> >flex-maven-plugin anyway)
>>> >> >> >
>>> >> >> >-    a third option
>>> >> >> >
>>> >> >> >
>>> >> >> >I would prefer no 1
>>> >> >> >
>>> >> >> >
>>> >> >> >Chris
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>>


Mime
View raw message