Plan to remove installation-tests from the jbosstools-base repo
by Mickael Istria
Hi all,
As tracked in https://issues.jboss.org/browse/JBIDE-12905 , we are
trying to move installation tests out of jbosstools-base/tests since it
is something that comes on top of JBT/JBDS, and which is not part of the
base. We decided it would make its own git repo, since it's not exactly
integration tests neither, and also because we can anticipate the fact
that some other "Stacks" (SOA, Fuse...) would like to use it to test
their update-sites.
So the repo is here:
https://github.com/jbosstools/jbosstools-install-grinder . Most stuff
was updated to work well with this change.
We're just waiting for some QA jobs will be adapted. Pavol is leading
this stuff for QA side. When he migrates to the new repo/job/URLs and
everything is working well, we'll remove this stuff from jbosstools-base.
The plan is to do it ASAP, but we are not in a hurry for that. So if
Pavol has some more important tasks to do, we'll wait after GA.
Does anyone have any objection, concern or question on this topic?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
10 years, 9 months
INFO: jbosstools-build-sites push forced
by Max Rydahl Andersen
Hi,
We had some non-public/non-reviewed code from JBDS go into jbosstools-build-sites repo a few hours ago by accident.
Since it was discovered quickly I went and push forced the latest clean version of jbosstools-build-sites.
Thus if you have jbosstools-build-sites checked out or updated within the last 2 hrs you will need to refetch and rebase your custom branches.
If not then this should not affect you :)
Ping me if any problems.
Thanks,
/max
10 years, 9 months
Could not resolve target platform
by Andrej Podhradsky
Hi folks,
I'm not able to resolve the new TP org.jboss.tools.target-platforms.jbosstools:unified:target:unified:4.2.0.c-SNAPSHOT
See my log in the attachment.
It seems that it isn't in the nexus repository, right?
--
Andrej Podhradsky
Quality Assurance Associate
JBoss SOA Platform
IRC: apodhrad at #jbossqa #jbosssoa #jbosssoaqa #devstudio-qa #brno
10 years, 10 months
new repo on github: jbosstools-install-grinder
by Max Rydahl Andersen
Hey,
FYI, I've just created jbosstools-install-grinder which Mickael Istria shortly will start filling up.
This repo will be the new place for the p2 and jboss central swtbot based tests Micakel and Pavol have
currently buried inside jbosstools-base where they had some funky circular dependencies and heavy build impacts.
By moving it out these can be more easily run by others and reused to for example testing more complex stacks and more combinations.
Mickael will send out the PR to cut out the old installscripts repo.
/max
10 years, 10 months
On the topic of useful PR title/descriptions and git commit messages
by Max Rydahl Andersen
Hey,
I'm seeing a tendency to just put the JIRA number + possible merge info in the topic of the pullrequest and git commit messages are long lines of text instead of properly formatted.
This makes it rather hard to look at the list of PR and git history and figure out what they are about plus they duplicate the merge info Github already knows about.
You might not be aware that git actually uses some rules/conventions on the git messages to make things like git log be readable and informative, git rebase and squash etc. can use the titles better and finally github uses the same conventions for their pull requests.
Thus if you treat the github pullrequest similar to how a good git commit comment is done (you can even copy/paste them if there is a 1-to-1 match) then we should be good.
Thus the basic conventions are:
1 line for title, max 50 characters and don't end with a '.'
Two new lines
paragraph of text, max 72 characters wide containing the necessary info/details.
And that 1 line title for our workflow is best started with the jira ID.
Thus a good minimal commit message would look like this:
JBIDE-1234 - hibernate tools 4 classloading is broken.
Because of changes in Hibernate 4 classloader we can no longer
do XYZ. Thus I've made it do ZXY instead.
For a PR you can either just copy verbatim the above or maybe add some refs/details:
JBIDE-1234 - hibernate tools 4 classloading is broken.
This should be applied not only to master but also branch jbosstools-4.0.x
With this github dashboard and git log messages becomes much more informative.
Links with more background/tips with respect to commits/messages/workflows:
http://who-t.blogspot.cz/2009/12/on-commit-messages.html
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
/max
10 years, 10 months
Re: [jbosstools-dev] Next-generation VPE - Visual Page Viewer (VPV)
by Yahor Radtsevich
On Nov 21, 2012 9:25 AM, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
wrote:
>
> > we've seen a few issues with the browsersim not working all smooth with
WebKit, but I guess for VPV this is less of a concern since we will simply
just
> > be using whatever built-into-eclipse browser is enabled by the user on
his platform, correct?
> > Yeah, it will use any browser. But of course, each browser, has its own
features/bugs which should be taken into account when creating the viewer.
>
> I guess those changes will actually leak into the various templates ?
i.e. the code would have to do "if browser=ie do X else do Y" ?
I hope none or only several of them will be affected, like rich:calendar,
which is very complicated and really 'rich'.
>
> > > If it is a rewrite we should make sure to move everything that is not
public api into internal packages.
> > > Will do it.
> >
> > Would also be good to make an effort on making the API to add support
for other libraries more approachable than previous VPE.
> > i.e. documented API's, example of how to do it etc.
> > Agree. We could also make creation of templates more approachable by
creating a simpler templating system. Now in VPE only Java and XML tamples
are allowed. But we could allow also something like javascript
micro-templating.
>
> interesting idea.
>
> > > How is that handled?
> > > One http server for one eclipse instance. Pages on the server will be
available under paths like localhost:xxxx/project/pathtopage/page.jsp. We
could also dispose the server when no VPE editor is opened.
> >
> > How about absolute relative paths like "/images/funky.png" - I guess
that will be handled the same way as before where the href's are rewritten
to have a proper "root" ?
>
> > Good question. I just forget about this root-relative case.
> > It looks like one server per viewer or at least one server per
workspace is needed to handle it. I assume, that our users may have several
editors opened, so one server with changing root directory is not an option.
> > Obvious drawbacks of multiple servers are:
> > - we have to manage their creation/disposal
> > - these servers will consume more resources (not much, but at least a
port and a connection-waiting thread per each)
> > - pages from different projects will not be able communicate with each
other, because of same-origin policy. (Anyway, now I am not planning that
they will communicate even on one server per workspace.)
> > These seem to be not very big problems, probably it is worth it to
create a server per editor, which should be pretty easy to maintain.
>
> well multiple open ports for an app is not exactly awesome.
>
> Especially not if these threads aren't fast to shutdown (i.e. instantly)
>
> How about multiplexing these somehow - can you control part of the
useragent or other parts of the browser which you could use in the request
to make the server respond differently ?
>
> i.e. useragent set to "VPV-root: xxxx/project/" and let the server
respond accordingly?
>
> Someway to expose the properties the visual page editor already have in
context of "root" and "absolute root" settings already.
I wouldn't like to change the user agent, because client logic may depend
on it. Changing/adding of another request headers won't work in WebKit.
Today we found that the following approach may work.
If we set URL as http://localhost:1234/index.jsp?root=xxxx/project/, then
all linked resources will be requested with the 'Referer' header set to
this URL. This header may be used on the server to return right resources.
What I like in this approach is that it will also work for any browser, a
SWT embedded browser or a stand alone browser.
Redirects/clicks from one page to another should be handled separately, but
it is possible in SWT to do URL rewrite before the page requests are sent.
Another drawback we found is that html frames won't work this way.
>
> > btw. who's github branch are you doing this work in ? Would be nice to
take a look and try run it from time to time.
> > Now it scaterred locally and in old svn workspaces. I will create a vpv
branch in github/yradtsevich/jbosstools-vpe.
>
> okey - let us know when something to look at.
>
> /max
10 years, 10 months
Re: [jbosstools-dev] Integration tests on coretests update site?
by Max Rydahl Andersen
cc'ing jbosstools-dev:
> Probably I missed discussion about this I'm sorry.
nope - it haven't really been discussed.
> What do you think about adding JBT integration tests (SWTBot tests) to JBT coretest ( http://download.jboss.org/jbosstools/updates/nightly/coretests) update site?
If the integration-tests will work on the core target platform then sure.
But afaik you still use a mix of reddeer and soa dependencies so not sure it makes sense to add them to coretests at this point ?
The tests that uses the core target platform and are plain core tests could go there afaics, but depend on the usecase and when these plugins will be considered "released"
> For QE it would be useful for running tests on Jenkins without building integration tests locally. Of course we can also solve this problem by creating separate update site for integration tests. I can't say what is easier.
Having a site for integration-tests might make sense if its dependencies keeps being a mix of things and never really released/tagged similar to the other plugins.
Is this *just* for running tests on jboss jenkins or your internal mchydra jenkins tests ?
/max
10 years, 10 months
