Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [modeling-pmc] Epsilon GMT component
Title: Re: [modeling-pmc] Epsilon GMT component
Agreed.

Janet, does this seem like a reasonable way to migrate GMT?  In other words, only after you give the OK for a component based on IP matters, they can have the webmaster migrate their code to the /cvsroot/modeling repository from /cvsroot/technology?  Then, we can just shutdown /cvsroot/technology for those that don’t make the cut.

Thanks,
Rich


On 6/23/08 11:00 AM, "Ed Merks" <merks@xxxxxxxxxx> wrote:

Rich,

I also think this is a good opportunity to create a new CVS module that is properly within the modeling project's CVS structure where all the other projects reside.  So likely we'd want a org.eclipse.gmt parent with a module for each project/component in GMT that's being reviewed and migrated...




Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)


Richard Gronback <richard.gronback@xxxxxxxxxxx>


    To
    PMC members mailing list <modeling-pmc@xxxxxxxxxxx>, <emo@xxxxxxxxxxx>
    cc
    Richard Paige <paige@xxxxxxxxxxxxx>, Janet Campbell <janet.campbell@xxxxxxxxxxx>
    Subject
    Re: [modeling-pmc] Epsilon GMT component

    Excellent, thanks for the update.

    See inserted comments below...

    Best,
    Rich


    On 6/23/08 6:57 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:

    > Dear EMO, Modeling PMC,
    >
    > We are in the process of making the Epsilon GMT component compatible
    > with the Eclipse IP process and we could use some advice on the actions
    > we need to take. To my understanding we should do the following:
    >
    > 1) File CQs in the IPZilla for any 3^rd party jars we are using
    >
    > We are currently using jdom.jar which has been approved for other
    > projects (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1587). We also
    > use version 3.1b of the ANTLR runtime jar (version 3.0 has been approved
    > for other projects e.g.
    > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1359)

    Right, so you'll just need to submit piggyback CQs through the portal.

    > We’ve removed the simmetrics jar we were using as it licensed under GPL
    > which is incompatible with EPL
    >

    Great.

    > 2) File a CQ for the pre-Eclipse code (similarly to
    > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1460)
    >
    > 3) Change the namespace from org.epsilon.* to org.eclipse.*
    >
    > Do we need to set the complete path of Epsilon under Eclipse as the
    > namespace? In this case it would need to be org.eclipse.gmt.epsilon.*.
    > However, if GMT components are to be relocated soon, this would have to
    > change again. If we could set the namespace to just
    > org.eclipse.epsilon.* it would be more resistant to future relocations.
    > Is that OK?
    >

    I think org.eclipse.epsilon.* is fine.

    > 4) Set version of plugins to <1 as it is a component of an Incubation
    > project
    >
    > 5) Add (Incucation) to the name of the plugins/features
    >

    And download zips/jars.

    > 6) Set up an IP Log page under the Epsilon website (e.g. such as
    > http://www.eclipse.org/stp/development/ip_log.php)
    >

    You may want to leverage the query approach used by GMF (and now most of
    modeling, afaik)
    http://www.eclipse.org/modeling/gmf/project-info/ipquery.php  That is, until
    the official method is available:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=220977

    > I also have a question about EPL-incompatible libraries. For example, in
    > Epsilon (and I believe in other modeling components too) we need to
    > provide support for MOF 1.4 models which is realized by MDR (and which
    > appears to be incompatible with EPL). We would also like to provide
    > support for fuzzy string matching using Simmetrics (which as mentioned
    > above is GPL). As we cannot host those plugins on Eclipse, I was
    > wondering if we could host them elsewhere (e.g. on Sourceforge) and
    > provide a link from the Epsilon GMT site to them.
    >

    This is a complicated issue, so copying Janet for counsel. :)

    > I’d be grateful if you could confirm, complement or comment on the above
    > at your earliest convenience. I suspect that any information you provide
    > would also be useful for other GMT components that are in the same process.
    >
    > Best regards,
    > Dimitrios Kolovos
    > _______________________________________________
    > modeling-pmc mailing list
    > modeling-pmc@xxxxxxxxxxx
    > https://dev.eclipse.org/mailman/listinfo/modeling-pmc

    _______________________________________________
    modeling-pmc mailing list
    modeling-pmc@xxxxxxxxxxx
    https://dev.eclipse.org/mailman/listinfo/modeling-pmc


_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

Back to the top