I’m currently using the library Dynamic Reports that uses Jasper Reports, but it seems the website is out of service now.
Will it be fixed soon ? Is the library still working ?
Thank you for your help.
Don't know what happened to the project but it also disappeared from SourceForge (https://sourceforge.net/p/dynamicreports/).
I guess the project is now on GIT
https://github.com/dynamicreports
Documentation and examples is still missing though
Pursuant to the failure of that website, the project was cloned by some users, from existing files and ported over to github. The documentation is still work in progress, as it seems that it has to be reconstituted from the ground up. The continuing work can be accessed at https://dynamicreports.readthedocs.io/en/latest/.
By the way, the original artifacts can still be downloaded from maven central and the library at least up to version 5.1.0. As for continuing support and maintenance, it's a matter of time, but these contributors contributors intend to see to it that this library flourishes.
Related
This is a project I've been working on off and on for months and I feel like I'm pretty close, but I just can't seem to get past the final hurdle.
The goal is to develop an organization extension library that contains both internal and 3rd party code that we frequently rely on.
History
As a test project, I started with Apache Poi because that is already in wide use in our environment. I have a plug-in and feature built just from the Poi .jars that allows me to build our current Poi applications as long as I add the plug-in (from my workspace) to my build path. The apps work on the servers because we have already distributed the Poi .jars by manually copying them.
The next step is taking that plug-in and getting it into an updatesite so that all of the servers and developers can synchronize on one version. I found and followed these two excellent blog articles (that I wish existed when I started this project):
http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/
http://www.dalsgaard-data.eu/blog/deploy-an-eclipse-update-site-to-ibm-domino-and-ibm-domino-designer/
With the caveat that the articles are written for Domino 9 and we are running 8.5.3 here, but that only matters in the last (installation) step.
Current
This brings us to the problem. All of the above seems to have worked great up to a point. I can install my feature to my designer client from the eclipse update site and it works great. However, the install is failing when I import that into our updatesite.nsf database. This means that while the developers can all install from the updatesite if I put it on a network drive, that doesn't deploy updates to our servers.
The problem is that when I try to install from the .nsf update site, the Eclipse Updater just hangs. I've let it go for well over an hour and eventually Notes becomes completely unresponsive.
So the question is, is there anything I might have done wrong, either in the development of the plug-in or server configuration that might be causing this issue?
Additional Info
I'm looking at the osgi console and that is largely unhelpful. I am getting the following errors as I'm trying to install: SEVERE Could not access digest on the site: no protocol: 0/5B004DDD5E38F3FF85257CAF004C72C7/$file/digest.zip ::class.method=unknown ::thread=Worker-7 ::loggername=org.eclipse.update.core
I could generate dumps if that would be useful.
Security is also locked down fairly tight here. It could be a security issue - is there a way to troubleshoot that? Once I get to the hang I'm just stuck guessing.
This has been edited for clarity and to update information
I know that this is post is over 5 years ago but...
for those that find this and are trying to resolve the error
SEVERE Could not access digest on the site: no protocol: "
is due to the update site project not having the URL of the Domino updatesite.nsf not being added to the Archives tab of the site.xml.
I found the updatesite.nsf also needs to be anonymously accessible as no credentials are prompted/passed through to the Domino server hosting the updatesite.nsf database (at least from DDE), YMMV from eclipse. So if Anonymous connections are blocked on the Domino server you will be out of luck.
To develop a plug-in you really want to have 3 projects:
the plug-in
the feature
the update site
Of course a feature can contain more than one plug-in (and probably should) and a update site can contain more than one feature (and probably should). Once you have an update site project it features a handy button "build all" that makes sure plug-in, feature and update-site get compiled in one go. And that button is what you really want.
You can point using a setting in your Domino Designer (or local Domino server) to the feature directory. Add a plain text .link file to framework/rcp/eclipse/links, that contains the path to your install site - it then picks up the features and plug-ins from there. After a build you would need to restart designer/server to activate the updated feature.
For the Domino server the approach using an updatesite.nsf and the respective notes.ini setting makes the most sense (to me). http restart required. Lazy people script the whole thing.
I still don't have a great answer for this, but I believe the issue is related to the environment here. I don't have the authority to change the environment, even if I were able to conclusively demonstrate it is the cause of this problem, so it is a moot point. All I can say is that at least one administrator computer had no issue installing from the update site.
For me, the solution for distributing the update site is to put it on a network drive and have everyone install it from there. The server has no problem using it from the updatesite.nsf.
I'm having trouble finding the official home of the MercurialEclipse plugin (is there one?), and I have a weird feeling there are actually multiple projects by this name.
Here are some of the projects I've found:
http://code.google.com/a/eclipselabs.org/p/mercurialeclipse/
http://www.javaforge.com/project/HGE
http://www.intland.com/products/mercurialeclipse/overview/
https://bitbucket.org/mercurialeclipse/main/wiki/Home
See also this ticket I filed: http://www.javaforge.com/issue/23290
It appears the home has moved back to bitbucket.
https://bitbucket.org/mercurialeclipse/main
At least that is where active bugs/feature_requests are supposed to be filed, according to this note.
New project home on Bitbucket
Furthermore, as of today (9/20/12):
javaforge is at MercurialEclipse 1.9.1
bitbucket is at MercurialEclipse 2.0
The MercurialEclipse 2.0 version has shifted to using JavaHg for its mercurial interactions.
Since Intland Software (owners of JavaForge) are developing and maintaining the plugin, the official web site is http://www.intland.com/products/mercurialeclipse/overview/, and their official project page http://www.javaforge.com/project/HGE.
The BitBucket page stems from the time when the plugin was developed by Vectrace, but they transferred the project maintenance to Intland, so it’s no longer relevant.
Regarding the Google Code page, see http://www.jroller.com/andyl/entry/how_open_is_mercurialeclipse — At some point in time Intland started requiring a login to JavaForge to use the plugin, which provoked a let’s say... vivid response. However they reverted this behaviour quickly, and as Intland has contributed so much to the project, I forgive them. Before they jumped in, the project had stagnated. In the meanwhile one of the original Vectrace developers of the project created this Google Code project though. If you are sympathetic to that, I guess you could consider the Google Code project the official repository.
The google code one should be the official home.
However to install it the official update site is :
http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable
Gone restricted again at intland:
www.intland.com/products/mercurialeclipse/overview/
www.intland.com/products/other-products/
Their codebeamer tracker and repo is stuck on 1.9.1:
www.javaforge.com/project/HGE
So i guess, bye bye javaforge.
Both code.google.com and bitbucket.org projects have code and are accepting issues.
code.google.com/a/eclipselabs.org/p/mercurialeclipse/
bitbucket.org/mercurialeclipse/main/overview
Of these, bitbucket seems to be more up to date.
They mention however the same URL for eclipse installer:
http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable
I've read a lot about IBugTraqProvider interface and implementing an issue tracker into the commit dialog of TortoiseSVN.
IBugTraqProvider is written here.
Is there a more simpler way not to do it, building the plug-in and installing it on TortoiseSVN. The Document is not that clear that a developer can create its own plugin.
I'm working with SalesForce as the Issue Tracker, and retrieved the WSDL file to integrate with the Working Items. Now I need to know how to connect it to TortoiseSVN.
Please any suggestions?
Take a look at issue-tracker-plugins.txt in the contrib directory in the TSVN source code. There's a fairly decent example in C# that should get you heading in the right direction.
When I built a plugin, I built a test harness that passed arbitrary information using the IBugtraqProvider interface, so that I could debug the plugin whilst building it, without having to reinstall the plugin into TSVN each time.
It seems to me from the following page
http://www.eclipse.org/eclipse/platform-team/target.php
and other pages like it. that there has been a robust, mature, properly integrated (and seemingly very smart) way to upload and synchronize files from an eclipse workspace with an FTP site for four to six years already.
It seams from that page and similar pages around the web that "The WebDAV and FTP plugins are built as part of the platform build" which to me in plain english would mean that if you have the core eclipse files you should already have it.
This is obviously not the case. you dont even have the plugins required to make basic ftp access unless you install it from a repository.
Not only is it not installed. it is not available from the default plugin repositries set up when you download eclipse.
Not only that but I could not even find the link to the repository anywhere.
RSE - which seams like a library out of the nineties with such limited functionality that shell clients writen for windows 3.1 could do more in less steps - has its plugin repository url posted in many places. but the team plugin has only links to CVS repositories of the source at best. even most of those are broken.
In conclusion.
Does anyone know how to install the "team" ftp client so that I can synchronize my content with FTP?
Well, here is an sftp plugin on sourceforge.
It is only about internal plugin defining a basic container for any ftp or webdav-based application.
You can see, when looking at:
the source of eclipse.ftp, that this is mainly an exception, some interfaces and a basic FTP container.
the sources of the target.ftp plugin, that that feature is here from more than 4 years, untouched, with basic functions only.
Only a more advance client like eclipse.team.ftp defines a client, but not on eclipse.team.ftp no more, since this is now the DSDP Target Management component which actually has developed a more advanced FTP/Webdav layer. It took over since 2006.
Ok, time for me to answer my own question.
No RSE does not do what org.eclipse.team.ftp was able to accomplish five years ago. Somehow that functionality never made it in. I have no idea why they dropped a perfectly logical solution in favor of the new backwards methodology.
However, visiting the site that #bmargulies recommended I realized that Jcraft still hosts the original FTP and WebDav Service for Team Services (upon which their sftp service is built)
So you can just point your eclipse install dialog at http://eclipse.jcraft.com/ and install the original plugin.
Good luck
I am also looking for this. Any solution for you yet?
This one also has been left dead and then excluded. :((
Team Synchronization on top of RSE
I guess there are still not enough Eclipse developers interested in it. Especially if one continue to see not only dead projects but even succesfull ftp-sync projects being shut out.
Really sad.
I have been having a real hard time getting API Tooling to work in Eclipse 3.4.2. It keeps telling me:
The minor version should be incremented in version 3.4.0.qualifier, since new APIs have been added since version 3.4.0.40001
That being said, I have generated the plugins that are used for the baseline from the exact same code that it is being analyzed against. The API Tools docs say that it compares the current code against the baseline to see if there are any differences. I can't see how there could be differences if the built version is built from the current code.
The way that I tested it:
Create a new eclipse workspace
Create a new Plug-in Project with API Analysis turned on
Add a simple class to that plugin and export the package with that class in it
Build/Export that plugin to some location on your hard drive
Set the workspace baseline to that location and do a full build
You get an error for the project in your problems view.
Thanks,
-One very perplexed user
Looks like this is something that got fixed in 3.5. Too bad my company doesn't want us using 3.5 in case there are any incompatibility issues. (there were 3.3 to 3.4)
My recommendation to anyone who wants to do Eclipse API Analysis is to use 3.5.
First off, I apologize for jumping on a thread late after its "active time" but I am currently running into this exact situation, but with Eclipse Helios 3.6.
From your answer, you noted that something was fixed in 3.5. Are you aware of what this exact fix was AND if you have yet been able to verify that it is working under Eclipse Helios 3.6?
I would really like to have PDE API tooling working but I'm nearing my time allowed on this effort and need to move forward onto some pending tasks.
Thanks!
EDIT: I would have posted this in a followup link but did not see any such links available.