I did a quick test. The export seems to export too much (whole model).
Perhaps this can be made to work but it would be nice to be able to
select a package to export.
I did not try the import to see how it deals with duplicates.
Ron
Mark Fortner wrote:
Oh I see what you're trying to do. I misunderstood what you were
trying to accomplish.
If you have a core set of classes that you want to reuse in a
a number of different models you can simply export those core classes
into an XMI file
and import that file into other models.
In your dependent projects, you just add those entities that you've
imported to the appropriate diagrams and add
whatever associations you want.
I'm not sure if the -D parameter trick I talked about will keep
updating your dependent
diagrams, but that should be easy enough to test out.
My earlier comments were around handling deployment of applications,
rather than construction
of applications.
Hope I didn't confuse you too much,
Mark
On 5/25/07, *Ron Wheeler* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
It is a bit over my head but I can understand the direction that
you are
pointing.
Your example is a bit different than what I am looking for but perhaps
not that different in solution.
I suppose that I can take the AndroMDA starting model, add my core
classes (employee, business unit, etc.) and then save this as a model
for starting each portlet.
It appears that I still have the on-going problem of propagating
changes
made to the core classes to all of the models that might be affected
when I go from one major version to another where most of the core
classes get minor (I hope) enhancements.
Is there any solution for this?
Are there any tools for applying transformations to XMI?
Ron
Mark Fortner wrote:
> Ron,
> I usually create stereotypes and tagged values for the information
> that I want associated with each object. For example, if I want to
> create an EJB deployment descriptor, I take the fields that are
> required for the descriptor, create a stereotype called EJB, add
those
> fields to the EJB stereotype, and export this as an XMI file.
>
> You can then import the XMI file or use it as part of a profile (a
> collection of stereotypes) to suit your needs. You can use the '
> -Dargo.defaultModel=MyProfile.xmi' startup parameter to start
ArgoUML with your profile.
>
> You can apply any of the stereotypes from the profile to the
objects
> in each of your projects. When you're finished you can export your
> projects and XMI. You have to apply a transform to the XMI to
turn it
> into a deployment descriptor, but that's about the limit of the
work.
>
> I suspect that AndroMDA has the ability to handle those kinds of
> transformations. How you integrate this in to AndroMDA, is an
> "exercise for the student", as my old Calculus professor would say.
>
> If you don't want to rely on AndroMDA to handle the last bit,
then you
> can put this into an Ant target. It's simply a matter of
unzipping the
> ArgoUML, and applying your transform to the embedded XMI file.
>
> Hope this helps,
>
> Mark
>
> On 5/24/07, *Ron Wheeler* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> I am planning to use ArgoUMl with AmdroMDA to generate as
much of a
> Jetspeed Portal as possible.
>
> One of the issues that I think will come up in using
Jetspeed is the
> need/ability to break down a fairly big application into a
set of
> JSR-168 portlets.
> This implies, I think, that I am going to have a number of
AndroMDA
> projects in ArgoUML ; one for each Portlet since each
Portlet is an
> independent object that is loaded into the Jetspeed Portal
> depending on
> the user profile, etc.
>
> I think that this is going to result in the same basic entities
> (employee, business unit, code tables, etc.) appearing in
many ArgoUML
> models.
>
> It seems to make sense to define and maintain these entities
in one
> place and import them into each model in much the same way
that the
> basic AndroMDA entities are incorporated into the model at the
> start of
> a AndroMDA project.
>
> Is there some way to do this, using ArgoUML, so that changes to
> the core
> entities can be easily replicated to all of the portlet
models without
> having to go to each model and manually change each class in
the core
> that has changed. The work is one issue; the probability of
> forgetting
> to make a change or making an error in making the changes in
one
> portlet
> model is pretty high and will be hard to find when different
portlets
> handle the same entity differently.
>
> Suggestions about how the core entities should be organized
to make
> portlet modelling easier would be appreciated.
>
> Ideally I think that I would like to be able to export part (or
> all) of
> a master model of classes and import them into other models
> overwriting
> any existing instances of the same entity.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> For additional commands, e-mail:
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
