"Build Jars" problems and questions

Additionally, for a full solution there needs to be some capacity for jarring up test output directories, either separately or combined with product output directories.

Plus:

• Sort the list of modules. I don't enjoy the game find module "layout" in a list of

45 unsorted module names.

• make the table sortable

• optionally hide jars that aren't directly configured for the module but exported

from another module to the current module.
Most of my modules appear with about 117 jars, because in our module setup many
jars get exported from modules to dependent modules. It would tremendously
improve clarity if I only see the 3 or 4 jars from the module itself.
Maybe even never show the jars from required modules? I can configure their
packaging in each required module itself.

Hmmm... For anything non-trivial and anything that is not write-once-run-twice throwaway application - I'd always rely on Ant. Using IDE to define complex application build settings is a big no-no (in my book at least).

> Hmmm... For anything non-trivial and anything that is not write-once-run-twice throwaway application
> - I'd always rely on Ant. Using IDE to define complex application build settings is a big no-no
> (in my book at least).

• First of all: If there is a feature it should have good usability and no bugs. So what you are saying

does not at all affect my comments. If you argue to remove the feature completely then just complain
in another thread.

• Of course we do rely on ant, BUT: You need to configure most all of the build settings anyway in Idea,

don't you (src paths, output paths, module dependencies, etc.). Or how do you setup your Idea projects?

• Compiling, starting and debugging with idea is simply so much more lightweight: Even if I changed only

a single class, our ant scripts takes about 30 seconds to complete the build (just to scan each
module's files). There are many other inconveniences, like debugging multiple instance:
Even if I have a remote "debug" target in my ant script, I cannot debug two instances at the same time
without changing the ant scripts.

• Quite the contrary holds for "write-one-run-twice application": For those I could live with Idea's

generated ant build file. Running with Idea does not provide a big performance difference for small
projects.

>* Currently the absolute jar path is stored in the iml file. That's an
>absolute NO-NO:

My colleagues certainly cannot jar on "C:\Stephen\cvsroot-main\..."

Is storing file paths relative to the module content root OK then ?

• Isn't there an option to automatically jar after build? I rather have

Idea always
update the jars after compilation than never. Still an option would be
better.

• I really would have expected the ui in the regular modules settings tab.

Is there any reason why it isn't there? Luckily it's saved in the module
file at least.

We presumed following usecase:
"Occasionally you decide to generate jars for your project and fire up the
"Build jar" action which takes care of that."
I think it is the most frequently used case, because usually you would not
want to regenerate all the jars with every project recompile since it
greatly increases build time.
On the other hand, if building jars will be integrated with make, every
(rare) time you want to generate jars, you'll have to go to settings, enable
'generate jars on make' option, do recompile, goto back, disable the option.
Very unconvinient way to do one-time job.

• What is "Path Relative to Deployment Root"? Anything to do with webapps

that my
poor desktop application developer's brain cannot grok?

(term has come from the web application building indeed) Its just a path,
under which the file will be stored inside jar file.
E.g. by specifying realtive path '/x/y/z.jar' for the file z.jar, you tell
IDEA to generate jar file containing the file z.jar in x/y directory inside.

• How do I specify a manifest file for the jar?

By putting manifest.mf under META-INF directory inside jar file.
For example, by putting META-INF/manifest.mf into your module source
directory and have it's output directory included in the jar.

• What does "link via manifest" mean? Inserting it into the manifest

classpath entry?
Of which jar?

It adds Class-Path: entry for the selected file in the jar being generated.
E.g. if you generate jar file named 'x.jar', and selected 'link via
manifest' option for the file 'y.jar', then following entry will be added to
the x.jar/META-INF/manifest.mf:
'Class-Path: y.jar'

• There's a type in the dialog title: "Buld Jars". Also in the packaging

method drop down
shouldn't it be "JAR module OUTPUT ..." for both JAR entries? Or are
different things
jarred?

Not sure I caught this one. For every file you want to place in the jar
named 'main.jar', several packaging methods are shown:
For modules:
- 'copy module output' - place all files from the module output directory
in the jar files under specified relative path.
- 'jar module output and copy file to' - create separate jar from the module
output directory and copy that jar into main.jar file under specified
relative path
- 'jar, link via manifest and copy' - create separate jar from the module
output directory, copy the jar outside main.jar file according to specified
relative path, modify Class-Path attribute in 'main.jar'

For jar files, e.g. module libraries:
- 'copy files' - copy jar files inside main.jar under specified relative
path
- 'link via manifest and copy' - copy the jar outside main.jar file
according to specified relative path, modify Class-Path attribute in
'main.jar'

--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

Alexey Kudravtsev (JetBrains) schrieb:

Is storing file paths relative to the module content root OK then ?

Sure, that's what I had expected. But if the path starts with a path
defined in a path variable, then replace it first. Finally if the path
does not contain a path variable and cannot be specified relative (different
drives on windows) then fall back to absolute.

We presumed following usecase:

My usecase may be a little different (jars are required to run our app, because
it uses a plugin system). I can live with triggering the jar process manually.
Yet it would be easier if there were different actions for "Build Jars"
(executed immediately using the current settings) and "Build Jars Settings"
which opens the settings dialog.

>>* What is "Path Relative to Deployment Root"? Anything to do with webapps
>>that my
>> poor desktop application developer's brain cannot grok?

(term has come from the web application building indeed) Its just a path,
under which the file will be stored inside jar file.
E.g. by specifying realtive path '/x/y/z.jar' for the file z.jar, you tell
IDEA to generate jar file containing the file z.jar in x/y directory inside.

Ok I get it, "relative path in jar" would be a better name when I choose jar
as packaging. But of course that does not apply to the other packaging methods.
Hm - I don't know how to improve this. A tooltip for the table header at least?

>>* How do I specify a manifest file for the jar?

By putting manifest.mf under META-INF directory inside jar file.

I did know that, thanks ;)

For example, by putting META-INF/manifest.mf into your module source
directory and have it's output directory included in the jar.

Well... I currently have the manifest file in the top level directory side-to-side
to the build.xml. Is there any way to get it included from there?
I don't really like adapting my project setup to Idea - but I might make an
exception. (Though one of Idea's strengths is its power to work as I want,
with my existent setup, etc. I just failed to setup our project in NetBeans -
I have just not found how to export jars to dependent modules. The outlook of
having to flatten the jar dependencies by recursively specifying all needed jars
of each and every module was enough to make me stop trying NetBeans completely.)

>>* What does "link via manifest" mean? Inserting it into the manifest
>>classpath entry?
>> Of which jar?

It adds Class-Path: entry for the selected file in the jar being generated.
E.g. if you generate jar file named 'x.jar', and selected 'link via
manifest' option for the file 'y.jar', then following entry will be added to
the x.jar/META-INF/manifest.mf:
'Class-Path: y.jar'

Ah, so I can have several modules be jarred to the same jar with different relative
paths, right?

>>* There's a type in the dialog title: "Buld Jars". Also in the packaging
>>method drop down
>> shouldn't it be "JAR module OUTPUT ..." for both JAR entries? Or are
>>different things
>> jarred?

Not sure I caught this one. For every file you want to place in the jar

I was just pondering if there's a semantic difference between
"JAR module ouput" in "JAR module output and copy file to"
and
"JAR module" in "JAR module, link via manifest and copy to".
Is the latter just missing the word "oupur" because the text gets too long,
or this there a different meaning to it.


Should I create Jira issues for the more basic issues I mentioned (sorted module
list, etc) or are you still working on it anyway?

>My usecase may be a little different (jars are required to run our app,
>because
>it uses a plugin system). I can live with triggering the jar process
>manually.
>Yet it would be easier if there were different actions for "Build Jars"
>(executed immediately using the current settings) and "Build Jars Settings"
>which opens the settings dialog.

OK, will think about it.

>

Ah, so I can have several modules be jarred to the same jar with different
relative
paths, right?

Yes

>
>>>* There's a type in the dialog title: "Buld Jars". Also in the packaging
>>>method drop down
>>> shouldn't it be "JAR module OUTPUT ..." for both JAR entries? Or are
>>> different things
>>> jarred?
>>
>> Not sure I caught this one. For every file you want to place in the jar
>

I was just pondering if there's a semantic difference between
"JAR module ouput" in "JAR module output and copy file to"
and
"JAR module" in "JAR module, link via manifest and copy to".
Is the latter just missing the word "oupur" because the text gets too
long,
or this there a different meaning to it.

Yes, its the "JAR module output, link via manifest and copy to"

>
>

Should I create Jira issues for the more basic issues I mentioned (sorted
module
list, etc) or are you still working on it anyway?

Its fixed in the next build.


--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

Agreed in general, however the jar tool is one of those things that show up on feature checklists, and surprise new users when they aren't present. It's worth a bit of developer effort just for completeness and new user experience, even if it shouldn't be used in production build cycles. Once you start building a jar tool, of course, it's worth the effort to build it right.

--Dave Griffith

Dave Griffith schrieb:

Agreed in general, however the jar tool is one of those things that show up on feature checklists,

Which reminds me: It does not show up in the new features section of Idea 5.0
http://www.jetbrains.com/idea/features/newfeatures.html

Come on Alexey, nudge your marketing people to include it - it's a major
feature compared to some others listed there.

Also not shown in the new features list is the log-viewing functionality, which sounds small and stupid but is actually incredibly handy.

--Dave Griffith

On the other hand, if building jars will be
integrated with make, every
(rare) time you want to generate jars, you'll have to
go to settings, enable
'generate jars on make' option, do recompile, goto
back, disable the option.
Very unconvinient way to do one-time job.

How about building jars on a full build (as in Build -> Build Project)? Reconstructing the jar on every tiny make would indeed be incovenient, but if you only do that on a full rebuild, the extra time to build the jar shouldn't be that noticeable.

]]>

• First of all: If there is a feature it should have good usability and no bugs. So what you are saying

does not at all affect my comments. If you argue to remove the feature completely then just complain
in another thread.
What you are saying is basically "please implement a frontend for the Ant jar task". I just said that it may be easier to actually use Ant then. ]]>

• Of course we do rely on ant, BUT: You need to configure most all of the build settings anyway in Idea,

don't you (src paths, output paths, module dependencies, etc.). Or how do you setup your Idea projects?
</quote>

Yes, but that has nothing to do with actual build process. Idea compiled classes are never used for anything except debugging.

Whether the default should be module- or project-relative is debatable, but there should at least be some sort of relative path support (it would be best if the feature respected $PROJECT_DIR$ and $MODULE_DIR$, as well as user-specified path variables). We have cross-platform integration tests that require JARs, and colleagues often just need to make a quick test build; it is impractical to have to redefine all of those paths on every single machine. Nor can we have one common path because we often work on multiple branches.

I also second the opinion that these options belong in the module settings dialog and not on a separate menu.

This is still relevant with IDEA 8.1.3... any chance of seeing this addressed in a near-future version?