Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Fwd: Re: [jwt-dev] refactoring]

Hm, weren't there a lot of dependencies? ;)

Another thing:

Since the build server is down (again) and I noticed that the FactoryRegistry isn't working as intended (it seems to just load the first registry it finds at the extension point. I noticed this when the EPC view did not work since it apparently quit loading when it found the UML view factoryregistry) I did a bit of rewriting (which we wanted to do anyway at some time). FactoryRegistries are now bound to a certain view in the extension point (if not set the default registry is used). This also provides (reliable) automatic switching when the view is changed and one doesn't have to make case distinctions when implementing custom registries.

But before I upload the code I have a question: When enriching a workflow with the EPC aspect, then quitting and restarting the workbench I get an error that the epc conf wasn't found and the workflow cannot be loaded. If I then open it from the project workspace, everything is ok. Is this a new problem which I introduced or can you confirm this for the old version too?

Another question (perhaps for Florian): The EPC view defines figures for roles, data, initial/finalnode,... but somehow it seems they aren't added to the palette.

Regards,
Chris

Am 07.05.2010 14:14, schrieb Marc Dutoo:
You could also try to temporarily drop all conf packages and samples,
just to see if it works. The dichotomy method :)

Regards,
Marc

Christian Saad a écrit :
Hi Marc,

I don't think it's usually a problem but the
org.eclipse.jwt.we.conf.aspects package seems to be a possible
candidate where things go wrong, especially since most of the compiler
errors reported refer to the conf model/edit plugins. Of course this
could be just a coincidence but I think currently the only thing left
to try out and if I understood Mickael right its also in line with
what he suggested.

If it doesn't work, I'll try to ask on the mailing list.

Regards,
Chris

Am 07.05.2010 12:46, schrieb Marc Dutoo:
Hi Chris

I think that if having a org.eclipse.jwt.we.conf on one side and several
org.eclipse.jwt.we.conf.* (ex. ui) on the other side is a problem, there
it is far from being the only one of this type, so I'm a little bit
doubtful.

But you're the guy on the deck, so do whatever you feel can help you
solve this, and we'll make it better afterwards.
And looking at Mickael's opinion, it seems we're still not enforcing his
"all classes of a x.y bundle should go in an x.y package or
subpackages".

Is there a mailing list for athena / cbi ?

Regards,
Marc

Christian Saad a écrit :
I removed all the reexports because I tried to eliminate possible
causes of this error. Generally I'm a bit cautious using those because
it hides dependencies from the developer but anyway obviously this
hasn't been the problem here.

Would it be ok for you if I added a unique package to conf model&edit,
e.g. model stuff goes to org.eclipse.jwt.we.conf.model.* and edit
stuff to org.eclipse.jwt.we.conf.edit.*

And as said, if this doesn't work... the only thing remaining is to
make an offering to the Eclipse god...

Regards,
Chris

Am 07.05.2010 11:50, schrieb Marc Dutoo:
Hi Chris

I see you're making progress.

Why not add more visibility:=reexport in manifests ? It's an easy
way to
solve a lot of problems, and quite logical in a lot of case, for
instance you can't expect people using aspects without using EMF.

Your opinion ?

Regards,
Marc

Christian Saad a écrit :
Hi Marc,

thanks for fixing this so quickly, alas, Hudson is down again atm....

I've checked out your changes and also for me they don't give any
errors. I've refactored the helpers plugins but haven't uploaded them
yet as I'd like to do some local testing first.

Regards,
Chris

PS: jdom is used by the WE (to parse view files)

Am 06.05.2010 17:29, schrieb Marc Dutoo:
Hi

I've downloaded the Eclipse 3.5 Helios r2 updates, checked out
org.apache.xalan from Orbit. Now, no more build errors, and I've
successfully tested my committed refactorings.

I've also update the http://wiki.eclipse.org/JWT_CVS pge describing
how
to set up a development environment :
* added dependencies : ATL plugin, org.apache.xalan from Orbit
* TODO is jdom still used, where ?

Regards,
Marc

Marc Dutoo a écrit :
Hi

Opened a bug about it :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=311878

My analysis of the package conflicts :

*
jwt-we-conf-model.edit/org.eclipse.jwt.we.conf.aspects.event.provider

: already in jwt-we-conf-model, moved to .provider, no impact
because
was obsolete and not exported DONE
*
jwt-we-conf-property-model/org.eclipse.jwt.we.conf.aspects.factory
:
already in jwt-we-conf-model, moved to .property, 1 impact in
jwt-we-conf-property-model.edit (as well as in manifest and
plugin.xml) DONE
* jwt-we-sample-staticaspect/org.jwt.sample.logging : just been
removed, in duplicate with those in jwt-we-sample-logging DONE
* jwt-we-helpers-application/org.eclipse.jwt.we : already in jwt-we
STILL TODO



Still TODO : separate
jwt-we-helpers-application/org.eclipse.jwt.we,
test build and app


I'm sorry, but right now I've got a lot of build errors in my
workspace (ex in org.eclipse.jwt.converter.Converter : can't see
import org.eclipse.emf.common.util.URI ), possibly because I'm not
using Eclipse 3.5 r2 (so no latest atl plugins etc.).

Though I've already committed the items marked DONE above, since
they
have almost no impact, dear Chris, could you please test my changes
for me, in addition to renaming
jwt-we-helpers-application/org.eclipse.jwt.we ?

(obviously, I'll try having a workspace in order at some point -_-)

Regards,
Marc

Marc Dutoo a écrit :
Hi Chris, Mickael

Mickael, thanks for your expert inputs.

Since it is a bad practice, I guess I should do the refactoring
sooner rather than later, though I'd prefer have a bigger error
margin. I'll try having it done and tested before 16:00. I'll keep
you in touch.

Regards,
Marc

Christian Saad a écrit :
Hi Mickael,

great to hear from you :)

Thanks for the confirmation! After removing the reexports, I had
one
good run (more or less, if it gets through then it currently
fails
at the tests) and now again having problems (see below), e.g.
with
the
org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/event



package which is definitely shared between two plugins (and also
some others).

Marc, would it be possible to resolve this more or less
easily? (I
would prefer putting the files in different packages rather than
trying to get it to work the way it currently is because I've no
idea which part of the build causes this problem and if it
responds
to manifest declarations or not)

Regards,
Chris


@dot:
[mkdir] Created dir:
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/@dot




[javac] Compiling 24 source files to
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/@dot




[javac] ----------
[javac] 1. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/event/AspectEventManagerNotifyChangedListener.java



(at line 35)
[javac] private final AspectEventManager aspectEventAdapter = new
AspectEventManager();
[javac] ^^^^^^^^^^^^^^^^^^
[javac] AspectEventManager cannot be resolved to a type
[javac] ----------
[javac] 2. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/event/AspectEventManagerNotifyChangedListener.java



(at line 35)
[javac] private final AspectEventManager aspectEventAdapter = new
AspectEventManager();
[javac] ^^^^^^^^^^^^^^^^^^
[javac] AspectEventManager cannot be resolved to a type
[javac] ----------
[javac] 3. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/event/AspectEventManagerNotifyChangedListener.java



(at line 38)
[javac] this.aspectEventAdapter.notifyChanged(notification);
[javac] ^^^^^^^^^^^^^^^^^^^^^^^
[javac] AspectEventManager cannot be resolved to a type
[javac] ----------
[javac] ----------
[javac] 4. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/provider/AspectEnrichedItemProviderAdapter.java



(at line 34)
[javac] import org.eclipse.jwt.we.conf.Aspect;
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] The import org.eclipse.jwt.we.conf.Aspect cannot be
resolved
[javac] ----------
[javac] 5. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/provider/AspectEnrichedItemProviderAdapter.java



(at line 35)
[javac] import org.eclipse.jwt.we.conf.AspectInstance;
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] The import org.eclipse.jwt.we.conf.AspectInstance
cannot be
resolved
[javac] ----------
[javac] 6. ERROR in
/opt/users/hudsonbuild/.hudson/jobs/cbi-soa-jwt-integration/workspace/build/I201005060556/eclipse/plugins/org.eclipse.jwt.we.conf.edit/src/org/eclipse/jwt/we/conf/aspects/provider/AspectEnrichedItemProviderAdapter.java



(at line 36)
[javac] import org.eclipse.jwt.we.conf.ConfPackage;
[javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[javac] The import org.eclipse.jwt.we.conf.ConfPackage cannot be
resolved



Am 06.05.2010 11:31, schrieb Mickael Istria:
Hi,

You're right, it's weird anyway because it did work before, at
least
Mickael built it this way I guess, maybe he's got an idea ?
This is probably because CBI build is p2-based (uses
p2.gathering=true
property), and is more rigorous, and far better, about
dependency
resolution, whereas the old builder was not p2-based (standard
old-school build + p2 generation on the old-school update-site).

So maybe don't change too much things yet, just enough to now
whether
that's the right solution or not...
I think having the same package in several bundles is indeed the
cause
of the problem. That's one of OSGi worst practices, so that it
can be
the cause of such troubles. Basically for a bundle
org.eclipse.jwt.my_bundle, all classes inside of it must be in a
org.eclipse.jwt.my_bundle or child package. Otherwise, it
could be
confusing for developers, install-time resolver (p2) and runtine
resolver (Equinox).

Regards,

--

Mickael Istria
R&D Engineer
BonitaSoft - Open your processes <http://www.bonitasoft.com>
email
: mickael.istria@xxxxxxxxxxxxxx


This message and any attachment (the "message") is intended
solely for
the addressees and is confidential. If you receive this
message by
mistake, please delete it and notify the sender immediately. Any
use not
in accordance with its purpose, any out-spread or disclosure,
either as
a whole or partially, is prohibited except with formal approval.
Internet cannot guarantee the integrity of this message,
therefore
BonitaSoft will not be liable for the message if modified.



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

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

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


Back to the top