Hi,
I created 2 branches in committers/bmaggi/* (one for mars, one for luna)
I also created 2 jobs that published the Papyrus test framework (junit.utils, junit.framework), you can find it here :
Mars :
https://hudson.eclipse.org/papyrus/job/PublishTestFramework/ws/releng/extras/target/repository/
Luna :
https://hudson.eclipse.org/papyrus/job/PublishTestFramework-luna/ws/releng/extras/target/repository/
I installed the Luna version and the tests are working fine (at least the ones I launched)
Regards,
Benoit MAGGI
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille
Envoyé : mardi 21 avril 2015 10:14
À : Papyrus Project list
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] Publishing test utilities for customizer
Hi all,
I think it makes sense to have an installable test feature (Or even 2), for the Test Framework and the Test Plug-ins. As mentioned in a previous
discussion (I don’t remember where or when), AllTests can only be compiled if all test plug-ins are available, so an installable AllTests feature might help (Most developers don’t want to have all source plug-ins in their workspace)
So we’d need:
-
Test Framework: no test suite, only abstract classes and test-oriented helpers/annotations (junit.utils, junit.framework, test generation,
...) [Required]
-
Test Plug-ins: Main test suites [Optional]
-
Extra Test plug-ins: Extra test suites [Optional]
All these features could be packaged in a specific/separate nightly update site, like the Papyrus Developer Tools (Which are not
Released either). Separate, to avoid confusing users
The good news is that most test plug-ins are already packaged as features, so the effort to deploy them should be small (Buckminster required installable
features for tests, whereas Tycho doesn’t, so I’m not sure the test features have been properly maintained, but at least they already exist)
IIRC, the main issue we’ll have when installing test plug-ins is that they contribute to some extension point (ModelExplorer customization, Profiles,
Libraries...) which will clutter the environment (Sometimes in an intrusive way, sometimes just by adding noise).
Camille
Hi Christian,
You get it right J
For me the code is public but only packaged libraries in an
official repository is “published”.
I think we can agree on a first step to put it in a “temporary repository” (like developer tools).
I created a bug to track the task [1].
When the first stable incubating version for the “test generation tool” will be released,
I think the discussion will come back on how to provide a better dev/test tooling for downstream project (for example : Papyrus-RT)
ð
I think it would be interesting to publish some dev/test plugins
(For example : Edit Part hierarchy View, Edit policies view and Figure hierarchy view are very useful when digging in the hardcore customization)
Regards,
Benoit
1 :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=465087
Hi
I had a similar problem where QVTd which extends OCL wanted to extend the OCL test harnesses. My original solution was to connect to the full OCL GIT in the QVTd build, but this was fragile for exact commit synchronization.
I now solve it by adding an OCL-tests feature to the main build repo. Hopefully most people will ignore it.
Regards
Ed Willink
On 20/04/2015 23:03, Christian W. Damus wrote:
Inasmuch as the git repository is publicly available for read-only access, these are, of course, already “published”. I suppose it’s a question of whether there is enough perceived value in creating dedicated builds and binary downloads/repositories
for these bundles.
Is there provision in the Eclipse Development Process for a p2 repository that maintains a nightly snapshot of bundles but never actually releases them as a formal capital-R “Release”? If so, that might be a good option for these test
bundles. It will become even more interesting when the diagram tests generation framework is ready for some kind of more public consumption, because that is a tool that could be especially useful for anyone developing graphical DSLs with Papyrus.
I would say that I don’t think we should include any test bundles, not even these utilities, in the SDK. These are not software artifacts for which we plan features and a release roadmap as we do the for the Papyrus product. I would support
a move to publish these test utility bundles and the tests generation framework in their own dedicated repository.
On Mon, Apr 20, 2015 at 11:59 AM, MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:
Hi,
Some people doing customization in Papyrus asked for advices to setup test.
I pointed them to org.eclipse.papyrus\tests\junit\plugins\junit
But sadly these utilities are not “published”
@Christian, @Camille :
-
Do you think it is possible to publish org.eclipse.papyrus.junit.framework and org.eclipse.papyrus.junit.utils ?
-
Do you think it should be independent from papyrus (or part of the sdk feature) ?
Regards,
Benoit MAGGI
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5863 / Virus Database: 4334/9585 - Release Date: 04/20/15