Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Client] Make the jar executable and update docs (high prio) #62

Open
doriancransac opened this issue May 12, 2016 · 7 comments
Open

[Client] Make the jar executable and update docs (high prio) #62

doriancransac opened this issue May 12, 2016 · 7 comments
Assignees

Comments

@doriancransac
Copy link
Contributor

update wiki and denkbar.io djigger page for quicker starts of the client. This is the most frequent basic initial need that people have when they want to first evaluate the tool.

The scripts to be kept for advanced option management (Xmx, tools.jar, etc).

@doriancransac doriancransac changed the title [Client] Make the jar executable and update docs [Client] Make the jar executable and update docs (high prio) May 24, 2016
@doriancransac doriancransac added this to the R1.5 milestone May 24, 2016
@jeromecomte
Copy link
Contributor

Making the jar file executable means including the dependencies in the jars and thus duplicating them in collector.jar and client.jar. It used to be packaged this way in the past and we changed this because of that reason. Should you rollback these changes and build jar-with-dependencies?

@doriancransac
Copy link
Contributor Author

doriancransac commented May 26, 2016

That's quite a dilemma...

managing X archives (client, agent, collector) vs efficient single archive vs convenient single archive with dupplicated dependencies...

How about this:

We provide 2 zips : the efficient archive (the way it works right now) + an additional, immediately executable über-jar (only for quick client start)?

@jeromecomte
Copy link
Contributor

I would prefer having one single package to avoid confusion.

Is it really an issue not to have an executable jar? If java is installed the start script with "java.exe" always work.

If it is really an issue for the user, I would suggest the following option:

  • Client: convenient single archive with dupplicated dependencies
  • Collector: jars in lib Folder as it should be.

@doriancransac
Copy link
Contributor Author

You know how it works... double clicking a jar file will always be easier and more intuitive than looking for the correct platform-specific start script in a bin folder.

Several users made the comment that it would be appreciated. Whether we want to follow that advice/implement that suggestion is up to us. My opinion is that it doesn't cost a lot in any way, and if it helps users on their first attempt and helps our first impression, then why not.

@doriancransac
Copy link
Contributor Author

Up to you. Major changes comping with 2.0. Not sure it's actually worth worrying about until then.

@doriancransac doriancransac removed this from the R1.5 milestone Jun 13, 2016
@doriancransac
Copy link
Contributor Author

cleared milestone.

@doriancransac doriancransac modified the milestone: R1.5 Jun 13, 2016
@clangguth
Copy link
Contributor

Hi, just my two cents on this issue:

  • yes, it would be tremendously useful to have a single client UI jar (say, djigger-ui-1.8.x.jar) that "just works" by double-clicking (or running java -jar xxx.jar)

  • and no, I don't think there's a reason for that on the server (collector) side, as this one has far more dependencies (config files etc.) anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants