Well during the SVN times I had setup multiple Job: Saros, Whiteboard
and Nebula so the CI could track what changes were applied to which
project (this was back in 2011).
During the migration to GIT this *feature* vanished due to the fact how
the projects were setup.
If you look at:
http://saros-build.imp.fu-berlin.de/jenkins/job/Saros_Whiteboard/changes
you will notice that you will see mostly non Whiteboard changes or
better just every change applied
to the whole GIT repository.
The current problem for now is the no longer unique structure of the CI
jobs.
Regardless of the cons and pros on how the jobs are setup the structure
should be unique.
While you could argue that the Whiteboard is an optional plugin so the
UI plugin is also currently an optional plugin, e.g only if the UI
bundle is present the HTML UI will be used otherwise native SWT.
I know that the whole CI configuration is VERY cumbersome but excluding
the UI bundle from being recognized as build artifact which can be done
in the advanced settings is not the best solution either.
BR,
Stefan
On 02.02.2015 19:31, Zieris, Franz wrote:
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
