IzPack - Source Code

Related tags

Distribution izpack
Overview

IzPack

IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers.

License

IzPack is published under the terms of the Apache License, Version 2.0, meaning that you can adapt it to your needs with very minimal constraints.

Some third-party components (e.g., look and feel libraries) may be released under different terms.

Building IzPack from source

Java CI with Maven

IzPack requires Java SE 1.8 and at minimum Maven 3. Due to the JDK compatibility the maximum Maven version supported is 3.6.3 when compiled using JDK 1.8.

mvn verify install

The build generates a distribution IzPack installer JAR in izpack-dist/target.

The IzPack Maven plugin is inside the izpack-maven-plugin module.

Contributing to IzPack

While reporting an issue on our JIRA tracker is useful, investigating and offering a patch is much better!

We suggest that you follow our guidelines for contributing, and especially that you have a fork of https://github.com/izpack/izpack on GitHub. You can then offer contributions using pull requests.

We very much prefer pull requests over attaching patches in a JIRA issues.

Resources

During the migration from the Codehaus services, which were shut down, we had do divide different services to separate providers, there hasn't been available a compact offer comparable to the services the Codehaus in such a short time. There are some smaller drawbacks which couldn't be avoided, see below.

If you are wondering where to find some service the project offers visit out web site http://izpack.org/. This domain is still kindly provided and paid by Julien Ponge, the project founder.

Below I provide a list of new services divided by providers:

IzPack@Github

If you want to participate in development or improving our website, grab a Github account and send pull requests. All you need is the basic idea and the knowledge in using GIT and the Github services.

Don't use the Github issue tracker or Wiki at this time. We use more advanced services for this.

Source code

The IzPack source code is hosted at https://github.com/izpack/izpack. See the Developing and contributing section about how to contribute code changes.

Fork the Github repository, create a branch using an according JIRA issue as the branch name for each change and send pull requests from this branch to be able to create a changelog for each release and not get mixed up changes from your master branch for several issues at once.

Web page

The IzPack website is hosted at https://github.com/izpack/izpack.github.com. For bigger changes or refactory use a special branch for each change. Send pull requests.

The resulting website izpack.github.com is directly forwarded to izpack.org by an according DNS configuration.

IzPack@Sonatype

Sonatype provides the service of deploying snapshots and releases to the Maven Central repository.

For us being an open source project with the appropriate license, Sonatype offers a staging repository for our deployed binaries along with using the Nexus Professional repository service for free. See our wiki page Deploying IzPack for more information how this is set up and used.

IzPack@Atlassian

We have been set up a new JIRA and Confluence cloud instance kindly provided by Atlassian we received an on-demand open source license for. The central address is https://izpack.atlassian.net/.

Although the number of registered users is limited everyone is currently allowed to sign up.

Important
There is a drawback after importing the legacy issues from Codehaus JIRA: There are the same user accounts used for JIRA and Confluence, each of both can be enabled separately for each user. The former users have been recreated along with the issues they participated in, but just their synonyms. There are auto-generated user names and the mail addresses got lost. If you have been alread signed up to Codehaus, before signing up again try to find your user name in some older issues and ask by mail to (re)set your user name and mail address. Please tell me the full name shown in the issues, your current e-mail address and at least one Codehaus JIRA issue you participated in for security reasons. This will save work of moving references to issues and cleaning up duplicate user accounts. After that you will be probably able to reset the password of this migrated account and log in again. If you feel this is a problem for you just sign up straight away and from time to time I will try to clean up the user accounts manually. Former Confluence-only users must re-register in each case.

You can sign up to JIRA and Confluence with one and the same user account. It is your choice which one of both services you want use.

Issue tracker - JIRA

IzPack issues will continue to be tracked to JIRA. The central address is https://izpack.atlassian.net/.

By the way, the former Codehaus administrators kindly offered a HTTP redirection from the old Codehaus issues to the new address at Codehaus itself in case there are still old links. This has been activated for all former IZPACK issues and their issues IDs have been kept.

The Github issue tracking has been deactivated to not confuse anyone and because it is just too plain at the moment. There is no real advantage for us at the moment in using Github issues.

Confluence - Wiki

The IzPack Wiki has been reimported and left on Confluence. It seems to be the more comfortable choice and better user experience compared to the Github Wiki at the moment.

The central entry point to IzPack Confluence is at https://izpack.atlassian.net/wiki, or check the IzPack documentation directly. The content is considered to be up to date for Izpack 5, feel free to help us directly improving the documentation.

IzPack@Google

Google Groups - mailing lists

Regarding the mailing lists we ended up in reusing the existing mailing lists at Google Groups. There is a main reason - we kept all the old messages and subscribers from the Codehaus mailing lists mirrored there automatically and can continue to use it slightly.

Please note in advance that these are real mailing lists and you do not need necessarily an Google account at all to join them, see this support notice.

The existing subscribers have been left and don't probably have to re-subscribe. All existing lists have been left, just the mail addresses change.

In particular, there are activated the following lists:

If you are not a member of one of the above groups of your interest you may subscribe to them with or without being logged on as Google user on the web interface or by mail. For more help on Google Groups visit the according help center.

Be invited to join us again.

IzPack@Twitter

IzPack has a Twitter account. We will forward blog posts there and it is open for your tweets for registered Twitter users. Or just follow us to get the latest news.

Comments
  • Refactored ConfigurationInstallerListener (IZPACK-844)

    Refactored ConfigurationInstallerListener (IZPACK-844)

    Implementation for IZPACK-844. Complete refactoring of ConfigurationInstallerListener, including XSD and unit tests. Some field testing done by rkrell (see JIRA). New documentation is finished, old documentation remains for current pre-release users (cross-referenced).

    opened by omniamutantur 25
  • [IZPACK-1141]  Automated installation prompts user for missing values (WIP)

    [IZPACK-1141] Automated installation prompts user for missing values (WIP)

    This PR addresses http://jira.codehaus.org/browse/IZPACK-1141.

    The AutomatedInstaller will now prompt the user to enter any missing values for userInputPanel entries found in the automated xml.

    The XML entry must have no 'value' attribute to trigger the user prompt.

    A couple of notes:

    • This PR only adds this functionality for UserInputPanel entries. If others want, I could look into implementing the same system for other panels that require user input.
    • The prompt displayed to the user is generic: it does no validation or password masking for example.
    opened by FranciscoCanas 16
  • Fixes a couple of small issues

    Fixes a couple of small issues

    1. Incorrectly colouring pack sizes in the GUI when first calculating composite packs
    2. Incorrect URL to file path decoding. Previously did not support file names that had a + character in them.

    As previously discussed here: https://izpack.atlassian.net/browse/IZPACK-1582

    bug 
    opened by adamretter 15
  • IZPACK-1406 + IZPACK-1260: Improvements of dynamic variables handling

    IZPACK-1406 + IZPACK-1260: Improvements of dynamic variables handling

    This is an implementation of IZPACK-1406 and IZPACK-1260. It is the reincarnation of pull request #509 :

    Closing this, my latest changes have been merged to https://github.com/Helpstone/izpack/tree/IZPACK-1406_with_conditions and we'll expecting a brand-new pull request from there.

    Details: At the moment, there are dynamic variables saved as lists of a DynamicVariable list for one variable name, without considering references among them (unresolved values ${...} as part of a variable defintion) referring to another dynamic variable. To make the resolving as most complete as possible, dynamic variables are resolved in a limited number of cycles.

    To optimize this, there could be done the following changes:

    • Analyze the direct value references between variables and pre-order them at compile time using a directed graph, so that the variables dependent on "others" are shifted after the "others". The result is a pre-ordered list of dynamic variables compiled-in to the installer. Cycles should not be a problem, there should been left unresolved variables in this case (example: a={b}, b={a} -> a=={b}, b=={b} ).
    • Simplify the DefaultVariables implementation by relying on pre-ordering of the dynamic variables as provided by the list compiled in. This means especially resolving them in one cycle instead of repeating resolving several times. This could also improve the performance of variable resolution especially for installers having a big set of variables accessing files.
    • During compiling, there could be overgiven a List instead of Map<String, List> to the installer as serialized object.
    enhancement 
    opened by Helpstone 11
  • IZPACK-1295

    IZPACK-1295

    Pull request that fixes IZPACK-1295 https://izpack.atlassian.net/browse/IZPACK-1295

    Fixed problem that packs were installed in wrong order while using console mode.

    This is a show-stopper for us so I would appreciate swift handling. Cheers Jonas

    bug 
    opened by stenix71 11
  • Expired checker

    Expired checker

    This checker lets installers automatically expire on a date specified by variable "InstallerExpiresDate" in the installer XML file. The date must be in the format "yyyy-MM-dd". If "InstallerExpiresDate" is not defined, the installer does not expire.

    enhancement 
    opened by optotronic 11
  • Fixed problem with XDG shortcuts https://groups.google.com/forum/#!to…

    Fixed problem with XDG shortcuts https://groups.google.com/forum/#!to…

    Dear IzPack developers,

    Some time ago, I reported two problems (one on Linux and one on Windows) with shortcuts, please see https://groups.google.com/forum/#!topic/izpack-user/UrLck2vG-6U . This is the fix for the problem under Linux. If you accept this patch, then I will submit the other patch for the Windows problem.

    Sincerely,

    Thibault LINDECKER

    PS: Thank you for this great free software!

    bug 
    opened by ThibLind 10
  • Add PacksPanelConsoleHelper and modify basicInstall.xml

    Add PacksPanelConsoleHelper and modify basicInstall.xml

    basicInstall.xml was modified so that the test build also fails with HTMLInfoPanel

    Note: Need work on internationalization / translations Some methods are not yet implemented

    opened by thescouser89 10
  • [IZPACK-1069] Allow dynamic views on panels

    [IZPACK-1069] Allow dynamic views on panels

    This is to address http://jira.codehaus.org/browse/IZPACK-1069 Refer to the link above for more information.

    Allows a checkbox or radio button to show additional fields on the same userInputPanel, if conditions specified correctly. Ensures that fields are not validating during this process, validation only needs to occur when pressing the next button.

    Allow specifying the topBuffer as number of pixels with the "rigid" attribute. This comes naturally and dynamically showing and hiding fields make the spacing between the top field and title change.

    Let me know if anything needs clarification, and am fully open to feedback!

    ~~EDIT: Forgot to add functionality in console mode. Currently work in progress.~~ Checks to see if a console field should be displayed have been added, but I realize it kind of duplicates the code from the updateView() method of the GUI type fields. I plan to eventually come back to this in a seperate PR and find a way to abstract this out.

    opened by mtjandra 9
  • [IZPACK-986] - CompilerConfig -

    [IZPACK-986] - CompilerConfig - "severity" changed to "status"

    The schema defines "status" on a "dynamicInstallerRequirementsType", but the attribute being queried was "severity". In accordance with the schema I changed the name of the queried attribute to "status".

    opened by akutz 9
  • Implement Console version of InstallationGroupPanel

    Implement Console version of InstallationGroupPanel

    also, copy common InstallationGroup-related code outside the panel class to allow code sharing with InstallationGroupPanel in the future (existing code not touched)

    opened by radai-rosenblatt 9
  • [SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability

    [SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability

    Security Vulnerability Fix

    This pull request fixes either 1.) Temporary Directory Hijacking Vulnerability, or 2.) Temporary Directory Information Disclosure Vulnerability, which existed in this project.

    Preamble

    The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file permissions are set.

    This PR was generated because the following chain of calls was detected in this repository in a way that leaves this project vulnerable. File.createTempFile(..) -> file.delete() -> either file.mkdir() or file.mkdirs().

    Impact

    This vulnerability can have one of two impacts depending upon which vulnerability it is.

    1. Temporary Directory Information Disclosure - Information in this directory is visable to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.
    2. Temporary Directory Hijacking Vulnerability - Same impact as 1. above, but also, ther local users can manipulate/add contents to this directory. If code is being executed out of this temporary directory, it can lead to local priviledge escalation.

    Temporary Directory Hijacking

    This vulnerability exists because the return value from file.mkdir() or file.mkdirs() is not checked to determine if the call succeeded. Say, for example, because another local user created the directory before this process.

    File tmpDir = File.createTempFile("temp", ".dir"); // Attacker knows the full path of the directory that will be later created
    // delete the file that was created
    tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before the java code.
    // and makes a directory of the same name
    // SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
    tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
    // Attacker can write any new files to this directory that they wish.
    // Attacker can read any files created within this directory.
    

    Other Examples

    Temporary Directory Information Disclosure

    This vulnerability exists because, although the return values of file.mkdir() or file.mkdirs() are correctly checked, the permissions of the directory that is created follows the default system uname settings. Thus, the directory is created with everyone-readable permissions. As such, any files/directories written into this directory are viewable by all other local users on the system.

    File tmpDir = File.createTempFile("temp", ".dir");
    tmpDir.delete();
    if (!tmpDir.mkdirs()) { // Guard correctly prevents temporary directory hijacking, but directory contents are everyone-readable.
        throw new IOException("Failed to create temporary directory");
    }
    

    Other Examples

    The Fix

    The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.

    File tmpDir = Files.createTempDirectory("temp dir").toFile();
    

    The API both created the directory securely, ie with a random, non-conflicting name, with directory permissions that only allow the currently executing user to read or write the contents of this directory.

    :arrow_right: Vulnerability Disclosure :arrow_left:

    :wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

    First question, do we need to perform vulnerability disclosure? It depends!

    1. Is the vulnerable code only in tests or example code? No disclosure required!
    2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

    Vulnerability Disclosure How-To

    You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

    1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
    2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email.

    Detecting this and Future Vulnerabilities

    This vulnerability was automatically detected by GitHub's LGTM.com using this CodeQL Query.

    You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

    I'm not an employee of GitHub, I'm simply an open-source security researcher.

    Source

    This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

    The source code that generated this PR can be found here: UseFilesCreateTempDirectory

    Opting-Out

    If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

    This bot will respect the ROBOTS.txt format for future contributions.

    Alternatively, if this project is no longer actively maintained, consider archiving the repository.

    CLA Requirements

    This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

    It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

    The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

    - Git Commit Signoff documentation

    If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

    Sponsorship & Support

    This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

    This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

    Tracking

    All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/10

    opened by JLLeitschuh 0
  • [SECURITY] Fix Partial Path Traversal Vulnerability

    [SECURITY] Fix Partial Path Traversal Vulnerability

    Security Vulnerability Fix

    This pull request fixes a partial-path traversal vulnerability due to an insufficient path traversal guard.

    Even if you deem, as the maintainer of this project, this is not necessarily fixing a security vulnerability, it is still a valid security hardening.

    Preamble

    Impact

    This issue allows a malicious actor to potentially break out of the expected directory. The impact is limited to sibling directories. For example, userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot.

    Why?

    To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out"). The check is bypassed although /outnot is not under the /out directory. It's important to understand that the terminating slash may be removed when using various String representations of the File object. For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/; however, println(new File("/var", "/").getCanonicalPath()) will print /var.

    The Fix

    Comparing paths with the java.nio.files.Path#startsWith will adequately protect againts this vulnerability.

    For example: file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY) or file.getCanonicalFile().toPath().startsWith(BASE_DIRECTORY_FILE.getCanonicalFile().toPath())

    Other Examples

    :arrow_right: Vulnerability Disclosure :arrow_left:

    :wave: Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!

    First question, do we need to perform vulnerability disclosure? It depends!

    1. Is the vulnerable code only in tests or example code? No disclosure required!
    2. Is the vulnerable code in code shipped to your end users? Vulnerability disclosure is probably required!

    For partial path traversal, consider if user-supplied input could ever flow to this logic. If user supplied input could reach this conditional, it's insufficient and, as such, most likely a vulnerability.

    Vulnerability Disclosure How-To

    You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:

    1. Request a CVE number from GitHub by creating a repository-level GitHub Security Advisory. This has the advantage that, if you provide sufficient information, GitHub will automatically generate Dependabot alerts for your downstream consumers, resolving this vulnerability more quickly.
    2. Reach out to the team at Snyk to assist with CVE issuance. They can be reached at the Snyk's Disclosure Email. Note: Please include JLLeitschuh Disclosure in the subject of your email so it is not missed.

    Detecting this and Future Vulnerabilities

    You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.

    I'm not an employee of GitHub, I'm simply an open-source security researcher.

    Source

    This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.

    The source code that generated this PR can be found here: PartialPathTraversalVulnerability

    Why didn't you disclose privately (ie. coordinated disclosure)?

    This PR was automatically generated, in-bulk, and sent to this project as well as many others, all at the same time.

    This is technically what is called a "Full Disclosure" in vulnerability disclosure, and I agree it's less than ideal. If GitHub offered a way to create private pull requests to submit pull requests, I'd leverage it, but that infrastructure, sadly, doesn't exist yet.

    The problem is that as an open source software security researcher, I (exactly like open source maintainers), I only have so much time in a day. I'm able to find vulnerabilities impacting hundreds, or sometimes thousands of open source projects with tools like GitHub Code Search and CodeQL. The problem is that my knowledge of vulnerabilities doesn't scale very well.

    Individualized vulnerability disclosure takes time and care. It's a long and tedious process, and I have a significant amount of experience with it (I have over 50 CVEs to my name). Even tracking down the reporting channel (email, Jira, ect..) can take time and isn't automatable. Unfortunately, when facing prblems of this scale, individual reporting doesn't work well either.

    Additionally, if I just spam out emails or issues, I'll just overwhelm already over taxed maintainers, I don't want to do this either.

    By creating a pull request, I am aiming to provide maintainers something highly actionable to actually fix the identified vulnerability; a pull request.

    There's a larger discussion on this topic that can be found here: https://github.com/JLLeitschuh/security-research/discussions/12

    Opting-Out

    If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

    User-agent: JLLeitschuh/security-research
    Disallow: *
    

    This bot will respect the ROBOTS.txt format for future contributions.

    Alternatively, if this project is no longer actively maintained, consider archiving the repository.

    CLA Requirements

    This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

    It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

    The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

    - Git Commit Signoff documentation

    If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

    Sponsorship & Support

    This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.

    This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.

    Tracking

    All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/security-research/issues/13

    opened by JLLeitschuh 0
Owner
IzPack
Package Once. Deploy Everywhere.
IzPack
Sonatype Nexus Repository Open Source Codebase

Builds use Apache Maven and require Java 8. Apache Maven wrapper scripts are included in the source tree.

Sonatype 1.3k Jan 5, 2023
An open-source OTP & Call flooding android application with unlimited sending capability.

Tsunami v1.3 An open-source SMS & Call flooding Android application with unlimited OTP bombing capability ?? Notes ⚙ Click here for App Usage Guide Th

Utsanjan Maity 83 Jan 2, 2023
IzPack - Source Code

IzPack IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers. License IzPack is published under th

IzPack 297 Jan 5, 2023
Inria 1.4k Dec 29, 2022
Source code of APK-Explorer-Editor (AEE), an open-source tool to explore the contents of an installed APK!

APK Explorer & Editor (AEE) APK Explorer & Editor, an open-source tool to explore the contents of an installed APK, is strictly made with an aim to in

APK Explorer & Editor 271 Jan 8, 2023
mobsfscan is a static analysis tool that can find insecure code patterns in your Android and iOS source code.

mobsfscan is a static analysis tool that can find insecure code patterns in your Android and iOS source code. Supports Java, Kotlin, Swift, and Objective C Code. mobsfscan uses MobSF static analysis rules and is powered by semgrep and libsast pattern matcher.

Mobile Security Framework 347 Dec 29, 2022
Sourcetrail - free and open-source interactive source explorer

Sourcetrail Sourcetrail is a free and open-source cross-platform source explorer that helps you get productive on unfamiliar source code. Windows: Lin

Coati Software 13.2k Jan 5, 2023
A collection of source code generators for Java.

Auto A collection of source code generators for Java. Auto‽ Java is full of code that is mechanical, repetitive, typically untested and sometimes the

Google 10k Jan 5, 2023
A collection of source code generators for Java.

Auto A collection of source code generators for Java. Auto‽ Java is full of code that is mechanical, repetitive, typically untested and sometimes the

Google 10k Jan 9, 2023
OpenGrok is a fast and usable source code search and cross reference engine, written in Java

Copyright (c) 2006, 2020 Oracle and/or its affiliates. All rights reserved. OpenGrok - a wicked fast source browser OpenGrok - a wicked fast source br

Oracle 3.8k Jan 8, 2023
🔍An open source GitLab/Gitee/Gitea code search tool. Kooder 是一个为 Gitee/GitLab 开发的开源代码搜索工具,这是一个镜像仓库,主仓库在 Gitee。

Kooder is a open source code search project, offering code, repositories and issues search service for code hosting platforms including Gitee, GitLab and Gitea.

开源中国 350 Dec 30, 2022
JAP is an open source authentication middleware, it is highly decoupled from business code and has good modularity and flexiblity. Developers could integrate JAP into web applications effortlessly.

?? JAP 是什么? JAP 是一款开源的登录中间件,基于模块化设计,并且与业务高度解耦,使用起来非常灵活,开发者可以毫不费力地将 JAP 集

Fujie 140 Dec 1, 2022
Diagrams as code is a term used for storing the source of a diagram image as a text file.

Diagrams as code Diagrams as code is a term used for storing the source of a diagram image as a text file. Examples are architecture diagrams, or diag

null 26 Nov 21, 2022
Jsp Decoder Source Code

AntSword-JSP-Decoder 解码器模版 编译 python build.py 使用 将 dist/ 目录生成的 js 覆盖 antSword/source/core/jsp/decoder/ 目录下的文件 也可以直接从

null 15 Jun 20, 2022
Astra: a Java tool for analysing and refactoring Java source code

What is Astra? Astra is a Java tool for analysing and refactoring Java source code. For example: "References to type A should instead reference type B

Alfa 51 Dec 26, 2022
A gradle plugin based on ANTLR to generate UML diagrams from kotlin source code.

A gradle plugin based on ANTLR to generate UML diagrams from kotlin source code.

Alex Porter 15 Oct 26, 2022
FOSSLight source code repository

[Kor] FOSSLight FOSSLight is an integrated system that can efficiently process the open source compliance process. Features Compliance Workflow It can

FOSSLight 116 Dec 7, 2022
Source Code for 'Pro Java Microservices with Quarkus and Kubernetes' by Nebrass Lamouchi

Apress Source Code This repository accompanies Pro Java Microservices with Quarkus and Kubernetes by Nebrass Lamouchi (Apress, 2021). Download the fil

Apress 24 Oct 31, 2022