[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [Fwd: Re: [jwt-dev] refactoring]
|
Hi Marc, hi Chris,
wow, kind a long discussion. Sorry for not being able to answer earlier and
to help to fix the build problems. It seems there was already some progress
in fixing the build problems, but not everything is fixed, since Hudson is
down again.
Great to hear that the FactoryRegistry has been fixed. I noticed the problem
that only one view is completely loaded, but not the other already some time
ago and I thought I created a patch for it, but I can also be wrong - maybe
I didn't upload it. But now its finally fixed! Thanks for that, Chris!
Chris, could you point to a wiki page where users can find a description how
the factory registry is bound to a new view? Is it by specifying it in the
plugin.xml as we had it already or do you use a new mechanism?
Concerning the problem with opening a file with an EPC view: I can confirm
that we once already had such a problem when changing a file and opening it
after restarting again. But I never tried to load it from the project
workspace, so I guess this is an "old" bug.
Concerning the figures of the EPC view:
- the initial node and final node are displayed in the EPC view as a kind of
event as there is no distinction for EPCs between such events and others
which is why I didn't create an entry in the palette for these elements.
- Roles and Data are dynamic entries in the palette and there is already an
open bug for this extension as far as I remember. I only added the static
elements in the palette in the first place, but you're right, those should
be added, too.
I hope that information helps a bit.
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Christian Saad
Gesendet: Freitag, 7. Mai 2010 16:54
An: Java Workflow Tooling
Betreff: 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/j
wt/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/j
wt/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/j
wt/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/j
wt/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/j
wt/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/j
wt/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
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
