Bugzilla – Full Text Bug Listing
| Summary: | Ant Task for Profile Definition | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Ian Buchanan <ibuchanan> | ||||
| Component: | Core | Assignee: | Christian Damus <give.a.damus> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P2 | CC: | Kenn.Hussey | ||||
| Version: | 3.0.0 | Keywords: | plan | ||||
| Target Milestone: | M5 | Flags: | give.a.damus:
luna+
Kenn.Hussey: review+ |
||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | Community Support | ||||||
| Attachments: |
|
||||||
|
Description
Ian Buchanan
Created attachment 144249 [details]
Ant Task for Profile Define
Potential solution for Ant Task to define a profile
I have pushed a new branch bugs/286404a with a proposed fix. Note that this branch is based on bugs/227616a because it seemed to make sense to add a new Ant plug-in into the new finer-grained feature structure, not the release 4.1 structure.
commit 6b6a22d:
* add a DefineProfileApplication that invokes profile definition in a
similar fashion to the application that imports UML models to EMF.
It presents a similar usage message (being based on the same EMF
infrastructure). The defined profile is saved in-place. The
application extension is in the org.eclipse.uml2.uml plug-in, as
this is where the profile definition API is, but it is internal
(not API).
* add a new org.eclipse.uml2.uml.ant plug-in that provides the Ant
task wrapping the DefineProfileApplication (like what was done
for model importing). This plug-in is added to the (new definition
of) the org.eclipse.uml2.uml feature, alongside the model
import/export plug-ins
The purpose of the new plug-in is to provide this new Ant task and any that may follow. The model importer Ant task is *not* moved to this new plug-in; it stays in the model importer plug-in.
(In reply to Christian W. Damus from comment #2) > I have pushed a new branch bugs/286404a with a proposed fix. Sorry, that is, of course, bugs/286404 (no 'a'). (In reply to Christian W. Damus from comment #2) commit 7524418: * add JUnit tests in a new org.eclipse.uml2.uml.ant.tests bundle. These tests cover execution of both the DefineProfileApplication Equinox app and the uml2.defineProfile Ant task. These tests are skipped in the stand-alone configuration (they naturally require an Eclipse run-time) The UML2 Hudson build project will have to be updated in the Buckminster invocation step to launch the new test launch config in this bundle. It seems to work in my local Hudson build. Thanks, Christian. See below. (In reply to comment #2) > * add a DefineProfileApplication that invokes profile definition in a > similar fashion to the application that imports UML models to EMF. > It presents a similar usage message (being based on the same EMF > infrastructure). The defined profile is saved in-place. The > application extension is in the org.eclipse.uml2.uml plug-in, as > this is where the profile definition API is, but it is internal > (not API). I'm not sure whether I'm sold on introducing a new package as opposed to just putting the new application class in the util package, but I suppose I could live with it. I'm even less sure about the new package being internal; does it have to be? > * add a new org.eclipse.uml2.uml.ant plug-in that provides the Ant > task wrapping the DefineProfileApplication (like what was done > for model importing). This plug-in is added to the (new definition > of) the org.eclipse.uml2.uml feature, alongside the model > import/export plug-ins I think I'd rather follow EMF's lead here and call the new plug-in org.eclipse.uml2.ant. It should probably either be included at the "top level" by the org.eclipse.uml2 feature or in a separate feature that gets included by the org.eclipse.uml2 feature. I'm not sure which feature in EMF includes their Ant plug-in... (In reply to comment #4) > * add JUnit tests in a new org.eclipse.uml2.uml.ant.tests bundle. > These tests cover execution of both the DefineProfileApplication > Equinox app and the uml2.defineProfile Ant task. These tests are > skipped in the stand-alone configuration (they naturally require > an Eclipse run-time) I think this bundle should be called org.elipse.uml2.ant.tests (for consistency with my comment above). (In reply to Kenn Hussey from comment #5) > Thanks, Christian. See below. > > (In reply to comment #2) > > I'm not sure whether I'm sold on introducing a new package as opposed to > just putting the new application class in the util package, but I suppose I > could live with it. I'm even less sure about the new package being internal; > does it have to be? Well, it doesn't make sense to me that the application class should be API. The only "API" for such things is the Equinox command-line interface. So, it didn't seem appropriate to put it in a public package (and it certainly isn't an utility). But, I don't mind putting it where you are most comfortable with it. > > * add a new org.eclipse.uml2.uml.ant plug-in that provides the Ant > > I think I'd rather follow EMF's lead here and call the new plug-in > org.eclipse.uml2.ant. It should probably either be included at the "top > level" by the org.eclipse.uml2 feature or in a separate feature that gets Sure, I can do that. I included the "uml" segment only because the tasks (so far) are overtly UML-oriented, not generalized for the run-time infrastructure. But, I don't suppose that's important. > included by the org.eclipse.uml2 feature. I'm not sure which feature in EMF > includes their Ant plug-in... I'll check how EMF organizes this and follow suit. > (In reply to comment #4) > > * add JUnit tests in a new org.eclipse.uml2.uml.ant.tests bundle. > > I think this bundle should be called org.elipse.uml2.ant.tests (for > consistency with my comment above). For sure, yes. (In reply to Christian W. Damus from comment #6) > > > included by the org.eclipse.uml2 feature. I'm not sure which feature in EMF > > includes their Ant plug-in... Kenn, EMF puts its Ant tasks plug-in in the org.eclipse.emf.ecore.codegen feature. I suppose that's because EMF's tasks are all intended for code generation workflows? I'm not sure I'd like to make the same assumption for current and future UML Ant tasks. My own preference is either to put org.eclipse.uml2.ant bundle in the org.eclipse.uml2 feature (as currently), or else in a new org.eclipse.uml2.ant feature included in it. I defer to your judgment. (In reply to comment #6) > Well, it doesn't make sense to me that the application class should be API. The > only "API" for such things is the Equinox command-line interface. So, it didn't > seem appropriate to put it in a public package (and it certainly isn't an > utility). OK. Would it make sense to put the application class in an 'app' subpackage in the new ant plug-in? > Sure, I can do that. I included the "uml" segment only because the tasks (so > far) are overtly UML-oriented, not generalized for the run-time infrastructure. > But, I don't suppose that's important. Yeah, at some point I could see adding Ant tasks for code generation which doesn't strictly depend on UML... (In reply to comment #7) > Kenn, EMF puts its Ant tasks plug-in in the org.eclipse.emf.ecore.codegen > feature. I suppose that's because EMF's tasks are all intended for code > generation workflows? I'm not sure I'd like to make the same assumption for > current and future UML Ant tasks. My own preference is either to put > org.eclipse.uml2.ant bundle in the org.eclipse.uml2 feature (as currently), or > else in a new org.eclipse.uml2.ant feature included in it. I defer to your > judgment. OK, let's put/leave the org.eclipse.uml2.ant bundle in the org.eclipse.uml2 feature. Thanks for your replies, Kenn. (In reply to Kenn Hussey from comment #8) > (In reply to comment #6) > > OK. Would it make sense to put the application class in an 'app' subpackage > in the new ant plug-in? I thought about this originally, but the problem is that it puts "ant" in the application's ID (the contributing bundle's ID is the implicit namespace qualifier of the application extension ID). > > Sure, I can do that. I included the "uml" segment only because the tasks (so > > far) are overtly UML-oriented, not generalized for the run-time infrastructure. > > But, I don't suppose that's important. > > Yeah, at some point I could see adding Ant tasks for code generation which > doesn't strictly depend on UML... Indeed. (In reply to Christian W. Damus from comment #9) > > I thought about this originally, but the problem is that it puts "ant" in > the application's ID (the contributing bundle's ID is the implicit namespace > qualifier of the application extension ID). Then again, this may not actually be a problem? (In reply to comment #10) > (In reply to Christian W. Damus from comment #9) > > > > I thought about this originally, but the problem is that it puts "ant" in > > the application's ID (the contributing bundle's ID is the implicit namespace > > qualifier of the application extension ID). > > Then again, this may not actually be a problem? I don't think it much matters what the application's ID is... besides, this application is designed specifically to be used from an Ant task. ;) Thanks for your help, Kenn!
I have pushed a few more commits to the bugs/286404 branch to address code review comments. These changes build clean and pass all tests in my local Hudson instance. Once merged to master, we shall have to add another JUnit test execution command to the Buckminster script in the UML2 build:
junit --launch "org.eclipse.uml2.ant.tests/UML Ant Tests.launch" --flatXML \
--output "${WORKSPACE}/buildroot/test.results/UML Ant Tests.xml"
(note the updated resource path for the launch config)
Commit b59bb0c:
Rename org.eclipse.uml2.uml.ant[.tests] packages and bundles as org.eclipse.uml2.ant[.tests].
Commit 956e910:
Move the profile-definition Equinox application from the org.eclipse.uml2.uml plug-in to the org.eclipse.uml2.ant plug-in.
Commit 80aa73b:
Merges the validation bundle refactoring from Master, which brings with it the 5.0 version numbers across several bundle and features.
Commit f3498b9:
Up-versions the org.eclipse.uml2.ant[.tests] bundles to version 5.0 as this would now be the version of the UML2 feature in which they are introduced to the master branch (and, hence, downloadable builds).
Thanks, Christian. I still see occurrences of "UML" where I didn't expect to, including: UMLAntPlugin -> AntPlugin UMLDefineProfileTask -> DefineProfileTask UMLAntAllTests -> AntAllTests UMLDefineProfileTaskTest -> DefineProfileTaskTest UMLDefineProfileTaskTest.profile.uml -> DefineProfileTaskTest.profile.uml UML Ant Tests.launch -> Ant Tests.launch Could you please rename those (and any references, e.g., in properties files, accordingly)? Sorry for being so picky... That's what code review is for! No worries.
I have pushed a new commit 806c164 to the branch.
This removes the "UML" from a bunch of type names and some user-facing text. In a few cases, I felt it necessary to retain some kind of disambiguating qualifier. For that purpose I use "UML2", which is the name of this Eclipse Project:
* UML2 Ant Tests.launch: Eclipse uses the name of the launch file as the
launch configuration name, and "Ant Tests" isn't specific enough to
identify it in a workspace that includes code from other projects than UML2
* similarly, the Ant tasks and tests bundles' localized names are "UML2 Ant ..."
to distinguish them as originating from the UML2 project in the Eclipse
About dialog
Note that the new name of the launch config requires a tweak to the Buckminster command to run the tests:
junit --launch "org.eclipse.uml2.ant.tests/UML2 Ant Tests.launch" --flatXML \
--output "${WORKSPACE}/buildroot/test.results/Ant Tests.xml"
A new test build in my local Hudson is green.
Searching for occurrences of "UML" not followed by a "2" (regex "UML(?!2)" case-sensitive) in the Ant-related sources turns up only references to the usual suspects such as UMLUtil, UMLPackage, and similar APIs.
I observed something in this latest look at the code that may be noteworthy: the org.eclipse.uml2.ant.tests bundle depends on the org.eclipse.uml2.uml.tests bundle, which looks perhaps like an undesirable dependency (it didn't look unusual when the bundle name was org.eclipse.uml2.uml.ant.tests) but I don't imagine that should be a problem. Perhaps some day we can factor out the code it uses into the org.eclipse.uml2.tests bundle (just the StandaloneSupport utility, AFAIK), but that's a new enhancement (if at all).
Thanks, Christian. The changes have been merged/pushed to master and the Hudson job configuration has been updated. However, while the tests ran locally for me, they are failing when run by Hudson. Could you please take a look? (In reply to comment #14) > * UML2 Ant Tests.launch: Eclipse uses the name of the launch file as the > launch configuration name, and "Ant Tests" isn't specific enough to > identify it in a workspace that includes code from other projects than UML2 > > * similarly, the Ant tasks and tests bundles' localized names are "UML2 Ant > ..." > to distinguish them as originating from the UML2 project in the Eclipse > About dialog Agreed. I changed the names of the previously existing test launch configurations to follow this pattern (i.e., I prefixed them with "UML2 "). > I observed something in this latest look at the code that may be noteworthy: > the org.eclipse.uml2.ant.tests bundle depends on the org.eclipse.uml2.uml.tests > bundle, which looks perhaps like an undesirable dependency (it didn't look > unusual when the bundle name was org.eclipse.uml2.uml.ant.tests) but I don't > imagine that should be a problem. Perhaps some day we can factor out the code > it uses into the org.eclipse.uml2.tests bundle (just the StandaloneSupport > utility, AFAIK), but that's a new enhancement (if at all). I'm not concerned about this dependency; org.eclipse.uml2.ant similarly depends on org.eclipse.uml2.uml, so there's symmetry. ;) (In reply to comment #15) > Thanks, Christian. The changes have been merged/pushed to master and the Hudson > job configuration has been updated. However, while the tests ran locally for me, > they are failing when run by Hudson. Could you please take a look? So odd. I have no problem in my local Hudson instance, but on hudson.eclipse.org, these tests are failing to load the uml2.defineProfile task implementation class: -------- 8< -------- /tmp/testAntBuildDefaultOptions7541274624784449481.tmp/build.xml:4: Problem: failed to create task or type uml2.defineProfile Cause: The name is undefined. !ENTRY org.eclipse.ant.core 4 3 2014-01-09 09:52:37.632 !MESSAGE The library "ant_tasks/uml2.ant.tasks.jar" specified from "org.eclipse.uml2.ant" for the antTasks or antTypes extension does not exist !ENTRY org.eclipse.ant.core 4 3 2014-01-09 09:52:37.633 !MESSAGE The library "ant_tasks/uml2.uml.ecore.importer.tasks.jar" specified from "org.eclipse.uml2.uml.ecore.importer" for the antTasks or antTypes extension does not exist !ENTRY org.eclipse.ant.core 4 3 2014-01-09 09:52:37.638 !MESSAGE The library "ant_tasks/uml2.ant.tasks.jar" specified from "org.eclipse.uml2.ant" for the extraClasspathEntries extension does not exist !ENTRY org.eclipse.ant.core 4 3 2014-01-09 09:52:37.639 !MESSAGE The library "ant_tasks/uml2.uml.ecore.importer.tasks.jar" specified from "org.eclipse.uml2.uml.ecore.importer" for the extraClasspathEntries extension does not exist -------- >8 -------- But, I see in the P2 repo generated by the build, that this nested JAR is present and complete in the resulting OSGi bundle. So why is the DefineProfileTask class not found at run-time? As far as I know, it doesn't have to be included in the host bundle's own classpath, and indeed that is specifically discouraged (IIRC). At least, this new bundle follows the same pattern as the org.eclipse.emf.ant bundle. Well, there's a test.xml in the org.eclipse.uml2.uml.tests bundle; is a similar file perhaps needed for the ant tests, I wonder? (In reply to Kenn Hussey from comment #17) > Well, there's a test.xml in the org.eclipse.uml2.uml.tests bundle; is a > similar file perhaps needed for the ant tests, I wonder? I've discovered what the problem is. First, I hadn't realized that the Bucky RMap configuration is such that my local Hudson build's Bucky actually materializes projects from my local Git clone in my home directory, not the clone of this clone that Hudson creates in the job's workspace. Because this is the same Git clone that I work on in my Eclipse workbench, the Ant tasks JAR was already in place when my local Hudson ran the test suite. If I first do a git clean on my local UML2 clone, I can reproduce the same test failures. It took me a while to figure this out, but the problem is that Bucky doesn't run custom Ant-based project builders when it builds the workspace, so the Ant tasks JAR never gets built. So, I'm working now on updating the Bucky build to explicitly invoke my Ant build step to create this JAR. Yep. That was it. I have pushed commit 1858d8a to master to fix the building of the Ant tasks JAR, which in turn fixes the execution of the JUnit tests which now can find their task and type classes. Most excellent. Thank you! An integration build containing the changes will be published soon. An integration build containing the changes is now available. |