9 comments
Avatar
Permanently deleted user

see:
http://www.jetbrains.net/jira/browse/IDEABKL-609

Bad news: it's in the backlog => not for Irida.

Alain

0
Avatar
Permanently deleted user

see:
http://www.jetbrains.net/jira/browse/IDEABKL-609
Bad news: it's in the backlog => not for Irida.

Alain


Are you sure the backlog means not for Irida? I wasn't under this impression.



0
Avatar
Permanently deleted user

I would suggest that for groups building complicated, distributed systems where jars names are used to encode their versions, this is a critical feature. Everytime a new library that is part of our system get released or when we update third party jars, we have to manually go and remove the old references to jars files then re-add the newly versionsed and thus renamed jar files. This is a HUGE pain.

0
Avatar
Permanently deleted user

How is it different from your build files? Don't we have to do the same with
our build files? We keep one big Ant include file where we define all
libraries by version so we can reference different versions of those
libraries as needed and when moving from one version to another just change
reference name in our ant script.

      • I would personally prefer if Idea would allow shared library files and

multiple of them (some shared network files, some private). ***
One of the reasons is that in /lib directory of many distributions there are
very often much more jars then we want to include in our classpath so we
will not be able to just reference those /lib directories in distribution we
would have to copy files to some other directories


"Thomas Condon" <no_mail@jetbrains.com> wrote in message
news:22644039.1112323336290.JavaMail.itn@is.intellij.net...
>I would suggest that for groups building complicated, distributed systems
>where jars names are used to encode their versions, this is a critical
>feature. Everytime a new library that is part of our system get released
>or when we update third party jars, we have to manually go and remove the
>old references to jars files then re-add the newly versionsed and thus
>renamed jar files. This is a HUGE pain.
>



0
Avatar
Permanently deleted user

Ant build files cause us none of the problems we are asking a cure for. All we are asking for is a *.jar equivalent for including internal libraries we have. An applcation developer does not want to have to do anything other than do a cvs update on libraries. To be forced to go into the Libraries (Classpath) and manually add each new versioned library by name is a pain.

We WANT to use IDEA. It is a great product. I just wish someone at JetBrains would respond.

0
Avatar
Permanently deleted user

Keith Lea wrote:

Are you sure the backlog means not for Irida? I wasn't under this
impression.

>

I'm pretty sure I read a message posted yesterday by a JBer - Maxim ? -,
explaining just that: Dev = Irida, Backlog = later.

Alain

0
Avatar
Permanently deleted user

Thomas Condon wrote:

An applcation developer does not want to have to do anything other than do a cvs update on libraries. To be forced to go into the Libraries (Classpath) and manually add each new versioned library by name is a pain.


Here are two possible workarounds:

1. You can just put your project and module files (.ipr and .iml) in
CVS? Then, whoever updates the libraries updates the module libraries
paths, and everyone else just updates from CVS. No pain necessary. If
you are requesting this feature because developers keep adding and
removing jars, this workaround is for you, and in fact is probably the
best way to work with IDEA.

2. You can have a script of some sort (such as Ant) which copies/renames
the jars into more neutral name. E.g. rename myjar-build-2005-03-27.jar
to myjar.jar by doing a regular expression or other type of file mapper.
The file mappers in Ant are quite powerful. If you are requesting this
feature because your jar names are automatically generated, this
workaround is for you.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0
Avatar
Permanently deleted user

The naming convension is VITAL to how our build/deployment system works. I do not want to write a white paper on how our build system works, but it is quite impressive. It uses ant. Most of our developers use IDEA for day-to-day development, but when we deploy our applications (20+, all depending on custom jars we build and third party jars) we use ant. The naming convention gives us the ability to ensure consistent use of third party jar bewteen applications, and are also important in that we use JavaSpaces and Jini. New names ensure that the classes get remotely loaded properly.

We allow developers to use the IDEs of choice, although most use IDEA. We do not check in project files from IDEs. Only the ant build files get checked in.

We have a very large and sphisticated build system. This feature would be very helpful.

0
Avatar
Permanently deleted user

Thomas Condon wrote:

The naming convension is VITAL to how our build/deployment system works. I do not want to write a white paper on how our build system works, but it is quite impressive. It uses ant. Most of our developers use IDEA for day-to-day development, but when we deploy our applications (20+, all depending on custom jars we build and third party jars) we use ant. The naming convention gives us the ability to ensure consistent use of third party jar bewteen applications, and are also important in that we use JavaSpaces and Jini. New names ensure that the classes get remotely loaded properly.

We allow developers to use the IDEs of choice, although most use IDEA. We do not check in project files from IDEs. Only the ant build files get checked in.

We have a very large and sphisticated build system. This feature would be very helpful.


(I agree the feature should be added, I'm just proposing some
workarounds for you.)

You can just have a copy of the jars with simple names for IDEA
developers. In most projects, the developer's set up doesn't exactly
mimic the set up of the deployed application, so you can 'bend the
rules' a bit for the developer's convenience.

For example, let's say you've got 3rdParty1234.jar from CVS. You can
copy that to 3rdParty.jar using an Ant script and add 3rdParty.jar to
IDEA's library paths. The Ant build uses 3rdParty1234.jar, but IDEA uses
3rdParty.jar. Since 3rdParty.jar isn't in CVS, no harm no foul. It
doesn't even have to be in the same directory as 3rdParty1234.jar. At
the end of the day, IDEA only needs to know where to find some classes.
As long as you can automate the way to tell IDEA where the classes are,
that's all you need to do.

Hmm, unless... Does your running app depend on the file names? Are the
file names not configurable so they can be overridden? If so, all I can
say is 'ouch'. Not much way to workaround that.

Also, adding the IDEA .iml and .ipr files to CVS won't hurt anything,
and it will allow people to share configuration settings.

Another way I just remembered is that you can write a script to add the
jar references to the .iml files automatically. They are just XML files
anyway.

--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.