we are still on wicket 1.4, which is pretty much EOL.
I'm not an expert with Wicket and this is 5 year old code with parts from the SVN history missing due to branch restructuring, uncommented JIRA tasks for the changes and the original dev long gone.
I've started to look into migration to 1.5 and stumpled across the fact that this project uses patched JS like wicket-event.js, wicket-ajax.js. Additionally, it seems as someone manually added jquery libraries to have them minified and merged and updated manually in the project.
The mounts look like mountSharedResource("/js/wicket-event.js", new ResourceReference(WicketEventReference.class, "wicket-event.js").getSharedResourceKey());
I'm not really sure what to make of that.
The following questions arise:
Any input or follow-up questions on this scenario is very much appreciated. What are your thoughts?
How do I cope with those resource mounts? It is unclear why we have them in the first place, maybe only for the minifying? How does wicket find it's JS resources in the first place?
If I find that a patched JS resource makes sense, like patching it to attach custom classes to elements or add options for dropdown elements. How would I solve this now? Patch again? Use other means to achieve this?
EDIT: this is not only for JS resources, but also for CSS resources. It seems, that most mounts are really only done because we do that minification.
I'd recommend to remove all those custom mounts. This may break your app if you have customizations in wicket-xyz.js but it will most probably not work due to such custom modifications too. The best way for such custom modifications is to use monkey patching.
Once you see that your application works with Wicket 1.5 I'd recommend to upgrade to latest 6.x. Wicket 6.x has a lot of improvements in the management of resources - e.g. it will load some.js in DEV mode and some.min.js in PROD mode automatically.
See http://wicketinaction.com/2012/07/wicket-6-resource-management/ and http://wicketinaction.com/2012/07/wicket-6-javascript-improvements/ for more details.
Related
I am new to sakai, i want to add my own tool in sakai source code like announcement,syllabus...etc That tool having some my own functionality for this what i have to do, how can i develop my own tool in sakai.
Thanks.
Use one of the archetypes to get you started, then customise it. When you are comfortable you can change the UI layer to be whatever you like.
https://confluence.sakaiproject.org/display/BOOT/Developer+Tools
If you are looking for a solid "base" tool shell to begin with tool development my recommendation would be to start here: "Sakai Wicket Maven Archetype". There are a few other very good archetypes available but are often outdated and may cause you some problems based on my experience. This has been the one I've had the most success with.
This uses Wicket but does not mean you have to use Wicket to develop further with it. Make sure to pull the 1.2 version as last check the binaries for the others were not available yet so replace -DarchetypeVersion=1.4.1 with -DarchetypeVersion=1.2 It will compile and deploy successfully as a tool "as-is" that you can modify as needed. It also allows you to code in Java to directly access the sakai API and pull from its database or even add your own tables. I've successfully used it with NetBeans 8.0.1 and MySQL 5.6 under Windows 7 with Maven 3.2.3 and Sakai 10.1.
The code is well-documented and is no-frills but with enough varied functional use examples to allow you to do "almost" anything you want. The wicket manual is 600+ pages but in my experience you should be able to accomplish a lot just by looking at the code in the archetype.
I wish to create a document repository for my company. Reason is because my company have many documents and they did not have a version tracking in place. This means everyone is using different version all the time.
Plone is something new to me and i got to know from a good friend of mine. And too bad he is not around anymore to answer my question. I believed in him and i wish to materialize his idea, to use Plone as a document repository for my company.
I have install Plone and manage to view the default Plone page, add all company's username and change the logo to my company's logo. And now the biggest question is, how to setup the document repository? What i have in mind was to create a "page" for the user to add files, download files, search for files and read its description.
Any lead for me to go about?
Reusable,
Same problem here. We started to use Plone as our main DMS 4 weeks ago (inserting existing docs at present).
For working copies, we use iterate (insert plone.app.iterate under eggs in your buildout.cfg).
For versioning, Products.CMFEditions. I believe this worked out of the box.
For creating new workflow, look into plone.app.workflowmanager and read the docs.
In a previous question we asked, we were still looking at Dexterity which has alot going for it but eventually we decided on adapting an existing content type based on Archetypes.
As for inserting files, as long as the description is ok, they will be found through the in-built search functionality, but you might consider using Iterate mentioned above to make sure that nobody is using the same file twice.
As your new, as I am, the docs seem hard at first but are actually quite good.
And this book is still giving me the foundation we need to keep adding functionality.
Good luck
I think, you should get pretty far with vanilla Plone installation, without developing your own extensions or other customization add-on-products. Therefore, I'd recommend you to start with Plone 4 User Manual to find out everything you could do out-of-the box.
As #Speediro mentioned, versioning support comes built-in for the main content types (and you don't actually see CMFEditions mentioned anywhere), but it's not activated for file uploads. Although, as briefly mentioned in the manual: Content items can be configured to have versioning enabled/disabled through the Site Setup → Plone Configuration panel under "Types".
Working Copy Support (plone.app.iterate) should also be there already waiting for activation on Site Setup's add-ons-panel.
Yet, before the Plone Collective (=community) Developer Docs or Professional Plone 4 Development, I'd recommend Practical Plone 3. It has a bit outdated graphics (because it was made for Plone 3), but it's great next step after the user manual. E.g. how to define content rules to send e-mails notifications for content updates (still through the browser without coding). Or how to create custom forms using Products.PloneFormGen.
When you really need to write your own code, it'd be time for Professional Plone 4 and the Collective Docs.
If you can't have a developer to manage your stuff, I would recommand to stay on official Plone, no custom code and use only widly used addons.
I mean:
stay on the default theme (sunburst)
use the default plone content types
only customize the logo
activate plone.app.iterate in the addon controlpanel
do not play with workflow because they need to know what you are doing. by default a file has the visibility of it's folder. It mean if you can see the folder you will be able to see all files inside. You can just activate default worklfow for files under the ZMI.
Use collective.quickupload addon
Your database will going really fast to a huge size because Plone is doing indexing and indexing means lot's of spaces. So you will have to handle this as system adminstrator;
I've got a (dirty) production installation of Simple Machines Forum (SMF 1.1.13). It was a clean install, once... about five years, twenty updates, and 40 mods ago. Not to mention the custom code that was patched directly into the code base. This started as a for-fun side project, and didn't have any code management practices at the get-go.
Now SMF 2 is (getting closer to) going live, and I want to upgrade. But without leaving the custom features behind.
Keep reading, this is a general software management question, not an SMF support question...
I'm trying to figure out the best way to port the custom features into the new code branch.
In some cases, the custom 1.1.x functionality will already exist in 2.0. Yay, no work for me!
In some cases, there will be mod packages versioned for 2.0, and I can just install them directly on a clean SMF 2 build. Yay, minimal work for me!
In some cases, the code port will be fairly straightforward between the two versions (e.g. a few small changes in queries or global variable construction). (I've ported a few features/mods back from 2.0 to 1.1.x, so I'm starting to get familiar with it.)
In some cases, I'm just going to have to redevelop the features mostly from scratch.
Those last two options are gonna be hard to manage.
Any suggestions on how to port a large number of changes from one branch to another?
When it's not my own in-house code, that is. Here's my initial plan:
Diff between a clean version of 1.1.x and my "dirty" production code
Map each line diff to a feature ("That code update is the custom tagging feature, gonna have to port it line by line, and that one over there is the gallery, I can probably install an updated mod.") This would be SOMUCHEASIER if there were a diff tool that generated a consolidated report, instead of having to go through scores of files one at a time. Google and SO searches didn't find a tool like that-- Is there one?
Install a clean 2.0 branch
Install the available updated mods
Roll up my sleeves and go through my diffs feature by feature (this? is why I need the consolidated diff report. It would be hell to do page by page.) and build them back in.
Any better ideas? (Pointers to release management info are welcome, though of course with the caveat that it's not actually my code so I have limited control.)
Otherwise? I fear my options are ditch the custom features (not really feasible) or stay on the old branch. Both suck. Help!
tl;dr: Point me to a diff tool that will do consolidated file-by-file diff reports for entire directories. And/or help me figure out an easier way to migrate my custom code.
Your plan is generally the most practical approach, although I would say that you're heading in the wrong direction by looking for code-level differences. With no version control over the project lifetime and with no concise record of applied changes, in examining differences at the code level you are looking for a level of detail that may not give you the information you need to apply the same changes to a new implementation.
Move away from thinking of code-level changes and consider application-level feature and behavioural changes. What features have your changes introduced? In what ways does your application now behave differently due to your changes?
You say that there have been many unversioned changes over a long period - you will fail to find all the changes no matter what tools you have at your disposal and you will still need to consider the feature and behavioural changes that exist to fully represent the same features and behaviours in any upgraded implementation.
You know your application well, you use it and you do appreciate the feature changes that you have introduced even if you may not realise this.
Install a vanilla 2.0 release
Apply all appropriate mods
Apply relevant styling
Use the new system, note the differences in behaviour and develop from this a set of required features
Your feature set does not need to be complete - don't stall at the stage of trying to figure out all required changes, this will take too long.
Apply features gathered from most recent feedback (ideally through revertable mods)
Note the differences in behaviour at develop from this a set of required features
Repeat
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.