Hi Christian, Hi Stefan,
if I understand this correctly, Stefan argued against building the UI project
inside the “Saros” job.
Christian just re-added the UI project building to the job config – which
Stefan removed a few hours before.
At least a Jenkins plugin takes care of versioning the different job
configurations, but an edit war is still nothing desirable.
So let’s clear this up a little.
· Traditionally, the “Saros” job built the Eclipse plugin named
“Saros”. After the code splitting began, this job needed to build the Core
project and the Saros/E specific parts. So by now, a better name for this Job
would be something like “Saros/E”.
· Since we want to have an IDE-agnostic UI, Christian and Matthias
started the UI project (the sources of which could also be part of the Saros
core, but having a separate project makes it arguably harder to accidentally
mix business logic and UI).
· I understand that for building Saros/E, there are essentially three
projects that need to be built: “dpp.core” and “dpp.ui” for the IDE-independent
part, “dpp” for the Eclipse-specifics.
So where exactly is the disagreement?
@Stefan: Do you disagree with the three bullet points above? Or do you disagree
with the *way* these three projects are put together in our CI?
I hope it goes without saying that neither of you should alter the job
configurations until we have a common understanding of what the Jenkins jobs
should do.
Only then we can decide on the way how to let these jobs do that.
Best,
Franz
From: Stefan Rossbach [mailto:srossb...@arcor.de]
Sent: Monday, February 02, 2015 6:25 PM
To: Christian Cikryt
Cc: dpp-devel@lists.sourceforge.net
Subject: Re: [DPP-Devel] Build failed in Jenkins: Saros #1360
On 02.02.2015 18:01, Christian Cikryt wrote:
2015-02-02 16:31 GMT+01:00 Stefan Rossbach
<srossb...@arcor.de<mailto:srossb...@arcor.de>>:
So the following happened:
I amended Christians UI patch for making the UI plugin an OSGi module.
http://saros-build.imp.fu-berlin.de/gerrit/#/c/2069/
As you can see in his original patch he already changed the build.xml file
using Ant4Eclipse.
I looked at the Jenkins Gerrit Job and it was already correctly configured. The
build passed and so I submitted the patch.
I did not see any dedicated UI job and so I thought that this will be added
later after the OSGi stuff is added.
The problem is that the IntelliJ and Saros Job already build this UI plugin. I
do not not really understand why this has to be done twice.
The reason is that the master job is splitted into E and I job and the IntelliJ
job cannot use the needed libs inside the jar artifacts (unless they would be
extracted).
So rebuilding is the easiest solution because this way the same IntelliJ Ant
script can be used for both Gerrit and master.
I see two options here.
Copy the artifacts first from the other builds (yes I know using Maven would be
much better for maintaining an artifact repo) and prepare the workspace before
calling ANT4J.
Amend the build.xml file in the IntelliJ project as needed. And I really do not
understand why you have not done this as the build file already builds Saros/C
and Saros/I.
Neverless the configuration of these jobs are / were configured to actually
call the old build.xml with the needed parameters.
I already deleted the UI plugin stuff from the Saros build but I am not going
to touch the IntelliJ one.
And BTW it is really a bad idea to build something else in the Saros Build job
because the STF regression jobs simply take
all produced artifacts from the last build (Saros/C and Saros/E) and deploy
them to the Eclipse installations of our both test machines
before running the regression.
As Saros/E will have a dependency to the ui-module, I will have add the
UI-plugin stuff again (configured accordingly). BTW the resulting UI.jar does
not need to be an artifact of that job.
If I remember correctly you do not even need to modify the Saros/E job as long
as the dpp.*.ui folder is present during the checkout as AntJ4 will use this
folder when resolving the bundles.
I do not see any problem for building the UI project in a dedicated job. We did
this with Saros Nebula already.
And as for the new patch set. It is the same as Christians. I just removed the
UI dependency in Saros/E for now and added some Eclipse Autoformat stuff and so
regardless of the changes the same build errors would have occurred unless
someone had changed the Jenkins Jobs accordingly before committing this patch.
Guess what would have happened if you had notified me that you are planning to
bypass the review process :)
It is frustrating that you submit your patchsets without giving anyone the
chance to comment even if it is an amendment to one my commits.
And please stop going around blaming or insulting people.
BTW you are invited to ask questions if you don't know why we did something or
what we are planning to do as you are not able to attend our team meetings in
person. I am happy to answer those questions.
Regards,
Christian
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
