Hello Linus,
You're right, I miss-interpreted the suggestion, I thought you were
talking about merging the two projects. :), Sorry about this.
Everybody agrees that ArgoUML should be a business logic project.
(This was my main concern).
Also I don't support the idea to have two versions of business logic
(two versions of ArgoUML), but temporarily because there was no other
way we had to change ArgoUML, and because we couldn't just commit
experimental changes to the core ArgoUML we used a COPY of ArgoUML and
introduced ONLY the changed classes in the classpath.
We don't filter features or code from ArgoUML, we include the raw
ArgoUML code if it's possible, if not we change it. Also we agree on
this, ArgoUML should suffer some changes, especially in
ProjectBrowser. My opinion is that these changes should be done
carefully, maybe in a separate branch, not to affect the hole project
until we are sure their form is good enough.
I'm glad that Subversive exists because the competition will only make
better SVN GUIs, so I would really love to see some competitor to
ArgoEclipse.
The update site. I don't quite understand why you mention OS
environment, because Java is supposed to be independent from OS
(Windows, Linux, Mac). I only see two options Java Web Start or
download the JAR. Which basically are the same.
I think there are more issues here. After my knowledge, after we
change ArgoUML not to interfere with ArgoEclipse, we still need to
wrap that ArgoUML copy in a plugin, so that ArgoEclipse could use it.
How will ArgoUML download site generate the plugins, because
ArgoEclipse will be in a different place. Will ArgoUML download site
copy a ArgoEclipse version?
Thank you for your comments,
Bogdan
On 9/6/06, Linus Tolke <[EMAIL PROTECTED]> wrote:
Hello Bogdan!
Well, actually I think you miss-interpreted my suggestion. My idea was
not to merge the projects. Instead the idea was to take the necessary
changes to the ArgoUML code from the ArgoEclipse project and merge that
into ArgoUML. To me that is the first step towards making ArgoUML
separable into GUI parts and other functionality. This is because the
changes identified and made in the ArgoEclipse project is currently the
best information we got on the necessary changes to ArgoUML to allow
keeping the GUI separate.
In the comparison with Subclipse. I would presume that Subclipse is
build of some libraries containing logic and some things interfacing
with Eclipse. I would then presume that the libraries are provided to
Subclipse from the Subversion project. This instead of the Subclipse
project maintaining its own set of libraries with logic attempting to
implement the exact same logic as the other Subversion clients do. That
would allow the Subversion project to efficiently provide the
infrastructure for any GUI implementation and all GUI implementation to
have bugs in the logic fixed and updates in the protocol done at the
same time. Discussions about protocols, file formats, and logic is then
a matter within the Subversion project and not a discussion between the
Subversion and the Subclipse projects.
By maintaining a separate copy of ArgoUML there is a risk that the file
format will become incompatible, or that bug fixes in the logic will be
different in the two version of ArgoUML. We then have a fork. I am
striving to keep it together as one so that you won't have to work with
constantly copying updates or make judgments on what changes you like
and what changes you don't like for ArgoEclipse. Instead you should
spend your time to scrutinize and test any change to the core ArgoUML as
how it relates to the Eclipse version of ArgoUML (ArgoEclipse) and make
sure that there are test cases in the core ArgoUML project that
guarantees that the functions works as expected by ArgoEclipse.
About the update site...
When you come to the download site you come there with a certain purpose
in mind. Your purpose is to find a version of ArgoUML that fits your
environment. If the environment is Windows, Linux, Mac, or Eclipse,
shouldn't matter. Admittedly you might not see the Windows, Linux, and
Mac versions if you use the Eclipse-built-in updater and we can refrain
from having links to the Eclipse-version of ArgoUML if we want (but we
don't because we would want to point out to everyone that there is an
Eclipse version available when they download whatever other version they
are looking for). There is also another dimension to the download site
and that is the version numbers. Each new version of ArgoUML would be
accompanied with a new version of ArgoEclipse with the same release
number that works with that version of ArgoUML. If that is not the case,
then we are confusing the users. By keeping it together, building them
together, testing them together, the risk of diverging paths and release
plans is reduced.
Another comparison to Subclipse and Subversion... the protocol between
the server and the clients (HTTP + something) is probably rather stable.
I mean that it is not a big deal if you use non-matching versions of
client and server. The API between ArgoUML and ArgoEclipse is not
stable. I am attempting to convince you to change it so that we will
just have one, and not two non-compatible implementations. Then I
suspect that a lot of changes are needed here and there to support new
things within Eclipse and within ArgoUML. Maybe eventually we will
arrive to the point where ArgoEclipse need not be updated for every new
versions of ArgoUML. That would be the ultimate goal for us but please
notice that Subclipse/Subversion has been there for quite sometime
already.
/Linus
> -----Original Message-----
> From: Bogdan Ciprian Pistol [mailto:[EMAIL PROTECTED]
> Sent: den 31 augusti 2006 20:25
> To: [email protected]
> Subject: RE: About the future of ArgoUML and ArgoEclipse
>
> Hello all,
>
> I would like to write a few lines to tell you my opinion about the
> proposals from Linus.
>
> Linus suggested that the ArgoEclipse project be merged with ArgoUML,
> the ArgoEclipse downloads be relocated to the argouml-downloads site,
> ArgoEclipse is an alternate distribution format of ArgoUML,
> ArgoEclipse+ArgoUML should be called ArgoUML, it is ArgoUML from the
> Eclipse point of view, in consequence the perspective name should be
> ArgoUML not ArgoEclipse, the Show View group name should be ArgoUML
> not ArgoEclipse, the name of the update site on the web page should be
> ArgoUML not ArgoEclipse, this will make ArgoUML be the market name
> and ArgoEclipse is the project within ArgoUML that enables ArgoUML
> from within Eclipse, a headless build is not an absolute requirement.
>
> My opinion is this: The ArgoEclipse project shouldn't be merged with
> ArgoUML. Take the example of Subclipse, Subclipse is not merged with
> SVN, they are distinct. ArgoUML, in my opinion, should do exactly the
> reverse, try to be a core project with just functionality, without
> GUI, it shouldn't rely upon Swing or SWT (as a plugin) or anything
> else, it should provide just the business logic for other GUI parts.
> This will allow the developers to focus on specifics, if we mess all
> of them together then it will become even harder to try to adapt
> ArgoUML for something else (other GUI maybe). If we want both Eclipse
> plugin and Swing application then we should have distinct projects.
> ArgoUML shouldn't have anything to do (as a project because the
> developers could interact or even contribute to all the projects) with
> the Eclipse plugin or Swing application, it should have a stable,
> strong API, so that every GUI project can use easily the API. So if I
> think that ArgoEclipse should be a separate, should be one of the GUIs
> of ArgoUML. If this would happen then ArgoUML will become more
> popular, because it will allow other interested developers to build
> ArgoUML GUIs for their IDE or applications.
>
> The downloads: ArgoUML should have links to ArgoEclipse download site,
> because of the decentralization. It doesn't matter a lot where is
> located the plugin, but to be more decentralized, and I think is good
> to make responsible a specific GUI project about it's downloads. If
> you download Subclipse you don't go to http://subversion.tigris.org,
> you go to http://subclipse.tigris.org.
>
> ArgoEclipse is an alternate distribution format of ArgoUML? I
> thinkArgoEclipse is ArgoUML+a GUI part.
>
> ArgoEclipse+ArgoUML should be called ArgoUML? Depends on what happens,
> if we merge ArgoUML with this plugin then it should be called ArgoUML.
> This will mean that ArgoUML is everything: Swing GUI, Eclipse plugin,
> and ArgoUML core. If we will not merge the projects then obviously we
> need a different name, ArgoEclipse sounds good.
>
> It is ArgoUML from the Eclipse point of view, in consequence the
> perspective name should be ArgoUML not ArgoEclipse, the Show View
> group name should be ArgoUML not ArgoEclipse?
> I agree with Linus, this plugin definitely is ArgoUML with a different
> GUI, the components from it should be renamed. When I first named
> them, I chose very quickly some names that were in my head, also you
> could observe the inconsistency (because I chose all the names
> quickly): some components are called ArgoUML (in the New Wizard the
> ArgoUML file in the ArgoUML group, in Export Wizard the ArgoUML
> group). Also Subclipse is just the plugin's name, it uses SVN
> everywhere.
>
> The name of the update site on the web page should be ArgoUML not
> ArgoEclipse? When you go on the update site what are you uploading,
> ArgoUML or ArgoUML (project) + Eclipse plugin stuff (project). Only if
> the ArgoUML will merge with ArgoEclipse I think it's not confusing to
> call the update site ArgoUML.
>
> This will make ArgoUML be the market name and ArgoEclipse is the
> project within ArgoUML that enables ArgoUML from within Eclipse? My
> opinion is that ArgoEclipse (as a name and plugin) extends the ArgoUML
> (name and project/application) outside it's boundaries enabling it to
> be used in Eclipse and popularizing it. ArgoEclipse isn't just ArgoUML
> renamed (only if we merge the two will be the case), it's ArgoUML plus
> something new, something that doesn't hide ArgoUML. Everyone knows
> that Subclipse is a cloth for SVN, Subclipse doesn't undermine SVN,
> they exist as two market names and are becoming more and more popular.
> Subclipse also by becoming more popular, makes SVN more popular.
>
> About the headless absolute requirement, I agree it's an absolute
> requirement, but it would be nice to have it, so it is on our To Do
> List.
>
> Please feel free to comment on this or disapprove me if you think I'm
> wrong.
>
> Cheers,
> Bogdan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
